【27】アーキテクチャーに I（自我）なし

デーブ・クイック

　アーキテクチャーという単語には、確かに i が含まれていますが、それは、注目を求め、議論を支配する大文字の I ではありません。小文字の i は単語の中にぴったりとフィットします。正しい綴りと発音という条件を満たすためにそこにいるだけです。

　それが、ソフトウェア・アーキテクトとどう関係があるんだ、と思われたかもしれませんが、私たちの自我は、私たちにとってもっともたちの悪い敵になりうる、ということを言いたいのです。次のようなアーキテクトを見かけたことはありませんか？

自分の方が顧客よりも要件をよく理解していると思っている人物。
デベロッパーを自分のアイデアを実現するために集めたリソースだと思っている人物。
自分のアイデアの弱点を突かれると防衛的になったり、他人のアイデアを無視する人物。

　経験のあるアーキテクトなら、過去のいつかの時点で、これらの落とし穴のどれかには落ちたことがあるでしょう。私などは、すべてに落ち込み、自分自身の過ちのために苦い教訓を得たものです。

　どうしてこんなことになるのでしょうか。

過去の成功。　成功と経験は自信を生み、私たちをアーキテクトに育て上げてくれ、より大きなプロジェクトも呼んできます。しかし、自信は傲慢に直結しています。いつかプロジェクトが自分の能力よりも大きくなってしまったときに、傲慢さが生まれているはずですが、自分ではまだ気付いていないのです。
周囲からの敬意。　設計上の厳しい質問は、セーフティネットとして非常に重要です。しかし、私たち自身の傲慢さ、防衛的な態度、経験の強調が、そのような質問を拒んでしまうのです。
人間であるがゆえの弱点。　アーキテクトは、1 つ 1 つの設計に自分を投影しています。そのため、作品に対する批判は、自分に対する批判のように感じてしまいます。ですからすぐに防衛的な態度を取るようになってしまいます。それを止めるのはとても難しい。意識的に努力しなければ、自分の限界を認識することは困難です。

　どうすれば、このような落とし穴を避けることができるでしょうか。

要件は嘘をつかないと心得なさい。　要件として正しく完全なものがある場合、よいアーキテクトとは、要件を満たすアーキテクトです。顧客と密接に連絡を取り、1 つ 1 つの要件が提供するビジネスバリューを互いに理解することが大切です。アーキテクチャー設計の主導権を握るのは、要件であってあなたではありません。あなたは、要件を満たすために最善の努力をすべきです。
チームを大切にしなさい。　チームメンバーは、単なるリソースではありません。あなたとともに設計を進めるコラボレーターであり、あなたのセーフティネットにもなってくれる人たちです。大切にされていないと感じている人々は、セーフティネットにはなってくれません。アーキテクチャーはチームのものであり、あなた 1 人のものではありません。あなたは指導こそしますが、苦しい仕事をするのはメンバー全員です。チームメンバーがあなたの助けを必要とするのと同じかそれ以上に、あなたにはチームメンバーの助けが必要なのです。
仕事にチェックを入れなさい。　モデルはアーキテクチャーではありません。アーキテクチャーがどのように動かなければならないかについてのあなたの理解の内容を示しているだけです。プロジェクトのアーキテクチャーが個々の要件をどのようにサポートしているかをはっきりと示せるようなテストをチームメンバーとともに考えましょう。
自分自身を見つめ直しなさい。　私たちの大半は、自分の仕事を防衛しようとし、自己中心的な利害ばかりに目が行き、部屋の中で自分が一番賢いと思いたくなるという自然な傾向を持っています。プレッシャーがかかると、そんな傾向が表に出てきます。毎日、数分ずつでも周囲とのやり取りを反省してみましょう。メンバーのアイデアに対し、それにふさわしい敬意を払ったでしょうか。善意からのインプットに対し、否定的な反応を返していなかったでしょうか。あなたのアプローチに反対意見が出た理由を本当に理解しているでしょうか。

　アーキテクチャーから大文字の I を取り除いたからといって、成功が保証されているわけではありません。失敗の原因からあなたの欠点、弱点に起因するものが取り除けるだけだということを忘れないでください。