最近、ちょっと思ってたんだけどさ…。ITの現場に長くいると、たまに…いや、結構な頻度で出くわす「アーキテクト」っていう人たち、いるじゃない？ ソリューションアーキテクトとか、テクニカルアーキテクトとか、まあ色々呼び名はあるけど。なんかこう、ピカピカのノートPCと潤沢な予算を持ってて、Visioで描いた図面がもはや現代アートみたいな、そういう人たち。
多くの組織で、彼らの役割ってなんか…勘違いされてる気がするんだよね。現場からすごく離れた場所で、全体像を把握してる「つもり」になってる。でも、その全体像って、高高度を飛ぶドローンから撮った写真みたいに、ディテールが全然見えてないことが多い。正直、実際に手を動かして何かを作るより、エレガントなフローチャートを一日中描いてる方が好きなんじゃないかなって思う時もある。
なんでアーキテクトは「象牙の塔」に住んじゃうのか
これ、本人たちだけの問題でもないんだよな…。まず、彼らに渡される予算が、時としておかしな方向に向かわせる。まるで駄菓子屋にいる子供みたいに、実用的な使い道もないのに100万円もするエッジコンピューティングデバイスを買ってみたり、ベンダー主催の豪華なカンファレンスに招待されて、まだ存在しない「未来の技術」の話を聞かされて帰ってきたり。
で、オフィスに戻ってきて「未来を見てきた」なんて得意げに話すんだけど、その間も開発者たちは、会社を支えてるレガシーシステムのデバッグに追われてる。…この光景、目に浮かぶようだよね。
もっと悪いケースだと、彼らがアカデミックな高みから、現実世界の制約を無視したソフトウェア設計の「あるべき論」を説き始めること。自分たちの直属の部下でもない開発者たちに向かって、まるで神々が下界の民に知恵を授けるかのような、ちょっと見下した態度でね。あれはキツい。
あとは、マネージャーが技術的なことをよく分かってない場合に、「保険」として雇われるパターン。内部のチームや外部のベンダーを「監視」するっていう名目で置かれるんだけど、当のアーキテクト自身の技術力が理論先行で、実践的じゃないことも少なくない。そうなると、開発者からすれば、ただただ動きを遅くする官僚的なレイヤーが一つ増えただけ。価値を生まないのに、ただただ面倒な存在。戦略と実行の橋渡し役のはずが、ただの偉そうな肩書を持った中間管理職で終わっちゃうんだよね。
先に結論を言っちゃうと、目指すべきは「庭師」
じゃあ、どうすればいいのか。このぐちゃぐちゃな状況をどうすればいいのかって話だけど。
先に結論を言っちゃうと、これからのアーキテ行くと、いや、アーキテクトは「チェスの名人」みたいに駒を動かすんじゃなくて、「庭師」みたいに環境を育てる人じゃなきゃダメなんだと思う。
この考え方は、元米軍大将のスタンレー・マクリスタルが書いた『[Team of Teams: New Rules of Engagement for a Complex World]』っていう本に出てくる考え方にすごく近い。彼は「組織の駒を一つ一つ動かすチェス名人であろうとする誘惑は、指示するのではなく、可能にする庭師としてのアプローチに道を譲らなければならない」って言ってる。これ、マジでその通りだと思う。
特に、日本企業特有のトップダウンな文化とか、稟議とか根回しとか、そういうのが根強い組織だと、この「チェス名人」型が生まれやすいのかもしれない。でも、それじゃあもう今の複雑な世界では戦えない。アーキテクトは、開発者一人ひとりの能力やアイデアが育つための「土壌」を耕す人であるべきなんだ。
必要な時にアドバイスはするけど、基本的にはチームが自律的に解決策を育てていくのを信じて待つ。実験が奨励されて、失敗が許容される空間を作る。そのためには、何より「謙虚さ」が必要不可欠。これがないと、ただのエゴのぶつかり合いで終わっちゃうからね。
「ダメな建築家」と「育てる庭師」、何が違う？
じゃあ、具体的に何が違うのか。ちょっと表にまとめてみた。頭の中の整理も兼ねてね。
| ダメな建築家（チェス名人） | 育てる庭師 | |
|---|---|---|
| 関わり方 | 「こうあるべき」論を振りかざす。現場のコード？ あまり見ないかな…。 | 「今、何に困ってる？」って聞くことから始める。開発者と一緒にコード書いたりもする。 |
| 設計思想 | 完璧な青写真（ブループリント）を最初に描きたがる。変更には不寛容。 | まずは小さく試す。フィードバックを元に、有機的に設計を育てていく感じ。 |
| チームとの関係 | 指示する人（マンダリン）。自分は「賢人」で、開発者は「作業者」だと思ってる節がある。 | 導く人（メンター）。チームのアイデアを尊重して、それを実現する手助けをする。 |
| 知識の源泉 | カンファレンス、ベンダーの営業トーク、理論書。まあ、外からの情報が多め。 | プロダクトマネージャー、事業部の専門家、そして何より開発者自身との対話。 |
| 成功の定義 | 自分の描いた設計図通りにシステムが完成すること。個人的な栄光。 | チームが自律的に問題を解決し、ビジネスが成功すること。チーム全体の勝利。 |
…まあ、だいたいこんな感じかな。要するに、一方通行の指示じゃなくて、双方向の対話ができるかどうか。そこが一番大きいのかもしれない。
データの話ができないのは、もう論外
あとね、もう一つすごく大事なことがある。それは、アーキテクトがデータサイエンスとか、AI、機械学習の言葉をちゃんと理解してるかってこと。これはもう、会議で賢そうに見せるためとかじゃなくて、必須スキルだと思う。
これって、別にアーキテクトがデータサイエンティストになれって話じゃなくてね。どういう技術があって、それをビジネスのどの部分に応用すれば「とんでもない成果」が出るか、その可能性を見抜いて、周りを巻き込んでいく力が必要だってこと。
例えばさ、顧客の支払いパターンとか。「このお客さん、期日通り払う確率何パーセント」みたいなのを、もうERPシステムに直接、主要なデータとして埋め込んじゃうとか。これができれば、キャッシュフローの予測精度が劇的に上がる。あるいは、工場の重要な機械の異常振動をセンサーで検知して、壊れる前に予防保全のアラートを出すとか。こういう発想ができるかどうか。
アーキテクト自身がセンサーをハンダ付けする必要はない。でも、何が可能で、それがビジネスにどういうインパクトを与えるかを、自信を持って語れないとダメなんだ。在庫予測の精度を上げる時系列モデルとか、配送ルートを最適化するクラスタリングアルゴリズムとか…そういう「武器」の存在を知っていて、それをどこで使うべきか提案できる。そういう人が、これからのアーキテクトだと思う。
最後は、やっぱりコードでしょ
で、最後にこれ。一番シンプルだけど、一番大事なことかもしれない。
口だけじゃなくて、手を動かせってこと。シンプルに。いくら素晴らしい設計図を描いても、それを裏付けるコードを書けない人の言うことを、開発者やプロダクトマネージャーが本気で聞くと思う？
自分で料理したことないシェフの言うこと、信用できないでしょ？ それと一緒。フルタイムじゃなくてもいいから、定期的に自分でも手を動かして、開発の現場感覚を失わないこと。自分のスキルを証明し続けること。そうやって初めて、仲間からの信頼を勝ち取れる。そして、その信頼があって初めて、アーキテクトの描いた設計図は、ただの綺麗な絵じゃなくて、現実のものになるんだと思う。
アーキテクトっていう役割が、ただの笑い話じゃなくて、本当に組織の成功の要になるためには…うん、やっぱり現場に降りて、泥臭い仕事から逃げないことなんだろうな。空中の楼閣を描くのはもう終わり。現実の地に足の着いた建物を作っていかないと。
あなたの周りには、どんなアーキテクトがいますか？ 「庭師」タイプ？ それとも「チェス名人」タイプ？ よかったらコメントで教えてください。
