ひょんなことからアーキテクト職として本格的に働くことになって、早くも1年と少しが経った。まだまだ勉強することばかりだが、一つ分かったことがある。 アーキテクトというのはやはり難しい。そして、それはアーキテクトとしての意思決定が文脈的だからである。
文脈の中に生きる意思決定
例えば、以下のような状況下での意思決定を考えてみる。あなたは新しい Web サービスを立ち上げることになった。そのための技術選定とアーキテクチャ設計を行っている。 そのサービスは著名なインフルエンサーとのコラボレーションを基軸にしていて、インフルエンサーが SNS 上で集客を行うと、突発的にリクエストが集中することが予測されていた。 一方で、なにもない時に定常的なトラフィックはそれほど想定されていない。必要なときにしなやかに、素早くシステムをスケールアウトする必要がある。ビジネスロジックはそれ程難しくない。サービスから得られる収益は限られており、如何にコスト効率よくサーバープロセスを処理するかが鍵になる。
この要件を技術的観点から見たときに、あなたは突発的な負荷が発生しても素早くスケールアウトし、少ないサーバーリソースで動作する Golang を選択するかもしれない。技術的観点だけを見れば悪くないチョイスだろう。
だが、話はそう簡単ではない。あなたの組織はすでに別の大規模サービスを運用している。その大規模サービスは Java で運用されており、組織にはその知見が蓄積されている。運用効率化をするための各種ツールも整っている。Golang でシステムを構築した場合これらの組織的なバックアップは皆無だ。こうした組織的な側面に目を向けると、技術的にはナンセンスだとしても Java を選んだほうがよいという意思決定をするかもしれない。
ここであなたは、さらに別の観点として人材開発に目を向けてみる。あなたは定期的に複数のエンジニアと行った 1-on-1 ミーティングを持っている。多くの中堅エンジニアたちが新しいチャレンジに飢えていた。「いいかげん新しい技術スタックやチャレンジをしてみたい」と複数のエンジニアが口々に言っていたことを思い出す。Java を選定することは無難にシステムを運用する上でプラスかもしれない。しかしその代わりに、従来の技術選定に飽き飽きしたエンジニアが退職届を提出してくるかもしれない。彼らは最近趣味で Golang を勉強しており、もしここで Golang を業務採用すれば、技術的好奇心に駆られ、寝食を忘れて新規サービスの立ち上げに邁進してくれるかもしれない。
ここに上げたとおり、アーキテクチャの意思決定には技術的妥当性やビジネス要件の他にも、様々な文脈が存在する。文脈がことなれば最良の意思決定も最悪になりうるのである。 これがアーキテクトの仕事が難しい所以であると思う。技術的知識に精通するだけはなく、組織の置かれた状況、ビジネスのフェーズ、過去の経験も俯瞰的に捉え、その文脈の中で最高の解を見いださなければならない。
文脈をつたえる大切さ
以上の理由から、アーキテクチャ上の意思決定をするにあたってはその置かれた文脈を伝えることが大事だ。もしこの文脈を伝えずに意思決定をしているとどうなるだろう。
「あのアーキテクトはたしかに優秀かもしれないけど、言っていることは訳がわからない。この間は Java だといっていたのに、今回は Golang だという言う。一貫性がないじゃないか」
こんな調子の文句を聞くことがある。これは文脈を伝えていないからであると思う。
エンジニアとアーキテクチャの議論をしていると、しばしば、というか頻繁に意見が対立する。アーキテクチャの議論が難しいのは、それが大抵の場合、お互いに間違っていないからである。ある文脈に根ざして考えればその意思決定はたいてい合理的なのである。それ故に、文脈を適切にとらえコミュニケーションする力が大事である。文脈を適切なストーリーとして言語化し、相手に伝えることによってなぜその意思決定が今我々のおかれた状況下で最も合理的なのか、初めて理解してもらうことができるのである。
アーキテクトは優れた技術者であると同時に、優れたストーリー・テラーである必要があるのだと思う。
原文記事: yuichi-murata.medium.com
