テクニックにこだわりすぎて目的を見失う・他者への配慮をなくす

今年3月くらいに、businessweekのアップルの設計プロセスの記事を読んだ。オルタナティブブロガの松尾氏のエントリ（Appleのデザインプロセスの秘密）経由だったと思う。記事にある「Paired Design Meetings」というのを読んでビビっときたことがある。2種類の定例会議を続けるというもので、片方は制約をあまり考えないブレインストーミング形式、もう1つは現実的な実装方法等を考える形式でやる。毎週その2種類の定例会議を続けるそうだ。

これを続けるのは、想像以上に難しいと思う。相互に否定しなければならない要素が含まれているからだ。私はこれを視点の入れ替えというふうに捉えており、それを定期的に行うということの重要性を感じている。ビビっときたのはその点にある。前職でのサービス開発でも現職でのソフトウェア開発管理の研究開発にもあてはまっている。手法や技法を中心に据えすぎて結局何をやりたいかがわからなくなったり、手法や技法の結果ばかりを気にするあまり全体として配慮がなくなったり、ということがよく起こる。手法や技法が自負できるようなものだとその傾向は強くなるだろう。

完璧な手法や技法があればそのような心配はなくなるのだが、なかなか存在しない。ある側面では真実をあらわしているようにみえるが別の側面では必ずしもそうではないということが私の感触だ。手法や技法の適用はかなりボトムアップにはじまる。ある程度適用の結果がみえてきた段階でトップダウンな視点からいったん見直す。具体的には、結局何の役に立つのか、それ以外に効率的な方法はないのか、得手、不得手があるとしたらどこかということを考えなければならない。後者は自分の作業の否定にもつながる可能性があるので、その重要性をわかっていてもなかなか難しいところだ。無意識に防御反応がはたらくのか、視点を変えているつもりでボトムアップな視点のままでみていることがある。

ちょっとぼんやりした話になっているが読者の身のまわりでもよく起きていると思う。たとえば、ソフトウェア開発プロジェクト内で何らかの開発支援ツールの検証をしているメンバがそれを利用することに固執してしまい、制約や運用の難しさに関する視点や全体の目的の達成度合いが抜けてしまっていることがあるだろう。また、新しいパラダイムやフレームワークにこだわりすぎてそれを利用すること自体が目的になってしまっていることもよくある。結局何を作りたいかという話ではなく、どんなやり方やどんなツールで作るのかという話にすりかわっていることはよくある。

冒頭のアップルのミーティングは、この視点変更をたびたび起こそうとしていると解釈することもできるように思う。私自身の活動でも、連携先の計測データを用いて結果を伝える局面があるが、そのときには技法や手法や観測結果の一部に固執しすぎていないかをチェックする時間を長くとるようにしている。また、なるべくボトムアップの期間とトップダウンに見直す期間の間を置くようにしている。