アーキテクティングの必要性
SHARES
最近の話
最近何に関心を持ってる?と聞かれたら即答で 「アーキテクティング」 と答える。
少し前は「分散システムとの向き合い方」というテーマだったが、それが昇華されて「アーキテクティング」に変わっている。
アーキテクティングとは、 ”ソフトウェアの成功に必要なアーキテクチャを決める活動” のこと。
※ 〇〇アーキテクチャの実践!とかではなく、要件定義や開発運用、品質特性や品質保証といった広義の設計と開発に関わる活動を指している
今の自分に最も不足している考えや技術で、これが高い水準でできる様になれば飛躍的にソフトウェアの成功確度を引き上げられる領域だと思っている。
個人としてもそうだが、組織でも高い水準でのアーキテクティング活動、長い目で見るとアーキテクティング文化が必要だと思っており、それをいかに組織で作っていくか、いかに自分自身を変えるかが最近のテーマ。
これは難しいことで、スケールする事業、スケールするプロダクトに向き合わなければ真に使える考えや技術は得られないと思っている。
なぜなら、アーキテクチャはスケール(拡張, 拡大)が要求される状況になって初めてその価値が証明されるから。答え合わせができてこそ、良い気づきが得られる。
※ スケールがマストではないが、スケールが要求されるシーンでよりその価値が高まるという意味
そもそも事業をスケールさせること自体が非常に難しく、かつそれを目の当たりにできることも稀なので、アーキテクティング力が強く要求されること自体が貴重な機会であり。故にきちんと身につけたいというのが動機としてある。(背景はこの辺りの話)
また、これまでの自身の開発を振り返ると、アーキテクティングとしての技術や知識、経験がもっとあれば良かったのに...と思う「たられば」な状況を多く経験してきた。元々アーキテクティングに対する意識はあったが、我流だったので詰めが甘かった。正直、胃が痛くなる様な思いもしてきたが、そういった経験を無駄にはしたくないという思いがある。
まだまだ個人も組織も成長過程であるが、ここでもう一段ギアを上げていきたい。
本当にアーキテクティングは必要なのか
前提の文脈によるが、自分は 「アーキテクティングが必要だ」 と言い切りたい。
アーキテクティングは事業成長には間接的に影響を及ぼすため、その価値が証明されるのが遅く(遅行評価)、短期的には納得感を生みづらい & 評価されづらい活動である。
しかし、1年~2年といった中期で捉えれば価値を発揮できるものではあるため、時間軸の目線を揃えて必要性を説く必要がある。
この価値を理解してもらうことがアーキテクティングの一部なのだが、それ自体難しいなと、今向き合い始めて改めて思っている。特に成長を強く求められる事業に紐づくプロダクトであればあるほど。
スケールする機会でなければ価値が証明できないのに、スケールが求められるほど理解が得られにくいという、一見矛盾している様にも思えるが、様々な事業上の引力(スタートアップ環境など)を考慮した上でアーキテクチャを決めて推進するのがアーキテクティングだと理解している。
アーキテクティングに強みを持つエンジニアをアーキテクトと呼んだりする。
「アーキテクチャには正解も不正解もない、あるのはトレードオフだけだ」という言葉が巷にはある様に、アーキテクトは 選択肢のトレードオフ を理解して、状況に応じた適切な判断を下すことが求められる。
アーキテクティングに注力することは短期的な成長(ex: 開発成果を最大化)を犠牲にしている様に見られるが、中長期での事業成長や機会を失わないために構造的な課題を解決 or 予防策を講じて、来る新たな事業機会に適応できる様にする活動で、実はこれ自体がトレードオフであったりもする。
“アーキテクティングに注力すること” に存在するトレードオフ
- Pros
- 中長期(1年~2年後)での事業成長と機会の最大化
- Cons
- 短期(半年~1年)での事業成長と機会を最大化
決して事業成長を無視した開発者のエゴではなく、むしろ事業機会を最大化するに必要なことは何か?来る事業機会にどう適応するべきか?という逆算的な思考で問いを考えている。少なくとも自分は。
こうしている、こうしたい
今はまだアーキテクティングの基礎を改めて触れ始めて、全体の輪郭を掴み始めたくらい。
なので、ざっくりとこうしている、こうしたいというものがある。
- 型を徹底して真似る
- 検証と学習を繰り返す
- 実践して成果を作る
- 自分達の考えを定める
- 周りに広める
型を徹底して真似る
持論だが、どんなものでも先人の型があるなら、何よりもまずは型から入るべきだと思っている。
簡潔に言えば、守破離の守だ。
幸いにも2010年代の荒波を乗り越えた歴戦の傑物が多くの知見を発信してくれており、また最近は基礎を体系的に説く本まで出ており、良質なインプットを得られる機会に恵まれている。
何を意識するべきか、課題に対してどの角度で切り込むべきかといった向き合う姿勢の部分から真似ていきたい。
例えば、元DeNAで現在bellFaceでCTOを務めるYamaguchiさん(zigorouさん)の資料(技術選択とアーキテクトの役割)で示されていることは本当にその通りで、真に受けていきたい。ref
推しの良質な資料を挙げておく。
- ソフトウェアアーキテクチャの基礎
- Design It!
- マイクロサービスアーキテクチャ
- SoftwareArchitect
- 技術選択とアーキテクトの役割
- マイクロにしすぎた結果がこれだよ!
- ソフトウェアアーキテクチャの基礎
- Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity
- モジュラモノリスに移行する理由
なお、この文章で言う「アーキテクチャ」や「アーキテクティング」といった言葉の定義は全て「ソフトウェアアーキテクチャの基礎」の内容をそのまま流用している。つまりこれ自体が型に習っているということ。
検証と学習を繰り返す
基本は型から入るが、単にインプットだけではできる様にはならない。
検証と学習こそが武器を作る。「ソフトウェアアーキテクチャの基礎」の中でも Proof of Conceptsで確らしさを掴むアプローチを推奨している。
決して頭でっかちにはならず、いざとなれば先陣を切って泥臭く手を動かし、自ら答えを作る振る舞いをしていきたい。
死ぬほど汚いメモだが、時に殴り書きしながらコンポーネントの絵を整理する図
実践して成果を作る
学習はゴールではなくプロセス。
先にProof of Conceptsをすると言ったが、そこで得た気づきや課題や手応えを実プロダクトや事業に反映してこそ真の価値が生まれるものだ。巷ではこれをBeyond PoCと呼んだりもする。
これに関しては今絶賛作りに行っているので、一定成果が残せたら何らか発信したいと思う。
いつだって成果は論より証拠だ。
自分達の考えを定める
自分達の考えを自分達の言葉で話せる様になりたいとも思っている。
それはどういうことかというと、「ソフトウェアアーキテクチャの基礎」といった拠り所を持ちつつも、自分達の解釈で、自分達が向き合っている課題領域での答えを作るということ。
ちょうど先日、Timeeさんのイベントでこれをそのまま表すことをCTOの方が話されており、自分の理想の半歩先を行っていると思った。
説明するより見てもらったほうが早いので、動画を置いておく。
動画の中の37分30秒あたりからのTimeeでの実践に関する話が本当に素晴らしい。
その背中を追いたいと思う。
周りに広める
長い目線での話になるが、周りに広める、組織に還元する所まで至りたいという願いがある。
具体的には今の組織に新しいメンバーが加わり、そのメンバーが仮に退職してしまった場合などでも役に立つ様なアーキテクティング(知識と技術)が身につけられる組織にしたいというのが究極の理想。
例えば採用で「〇〇出身者はアーキテクティングに対する意識がある」みたいな、実力が認められてお墨付きを得られる様な組織にしたい。と、個人的には思っている。
どうそこに至るかは正直見えていないが、少なくとも自分はアーキテクティングの重要性や価値を組織の文化や仕組みにフィードバックし続ける存在でいたいと思っている。
その価値を誰よりも信じているので。
最後に
半年後には気が変わって「やっぱり新規開発や〜」と言っている可能性もありそうだが(これはこれでイテレーティブなので良い)、今時点でのアーキテクティングに対する考えを残しておきたいと思い、筆を取った。
毎日「なるほど!」「もっと早くに理解しておきたかった…」ということばかり思っているが、着実に歩みを進めてその価値を証明していきたい。