中長期を見据えたアーキテクチャ戦略は果たして必要なのか

中長期を見据えたアーキテクチャ戦略は果たして必要なのか

なんでそんなことを考えているのか

自分のキャリアの中で中長期を見据えた取り組みを何度かしてきた。想定通りうまくいったものや、失敗したと感じる施策もあった。振り返るとそれぞれのなぜは言語化できるようにおもう。ただ昨今のAIのようなパラダイムシフトの中で本当に中長期の戦略を考えることに如何ほどの意味があるのかと疑問に思うことも増えてきた。これらのテーマについて自分の考えを発信することはまだ正解がみえてないので避けてきたが、GWでやや余裕があるので答えがわからないながらも思考を整理すべく書いてみることにした。

中長期を見据えたアーキテクチャ戦略の必要性

私の主張としては、目先の課題や目的に対するアーキテクチャ戦略自体は当たり前に必要だと考えている。

  • 技術的負債を最小限に抑えるため
  • AIが理解しやすいコードにする必要があるため
  • チームの生産性を向上させるため
  • etc…

などこれらは当たり前かもしれないが、事業を支える観点ですぐれたアーキテクチャはアウトプットに直接影響し、その先のアウトカムの創出にも寄与する。これは多くの人がそう思っていると思う。

では、“中長期を見据えた”アーキテクチャ戦略は必要なのか?という問いに対してはどうだろうか。ここでいう中長期のアーキテクチャ戦略というのは、例えば複数サービス展開をしていきたいという考えであれば、共通認証基盤が必要になるよね?という話だったり、組織が大きくなったらチームが細分化して担当領域が細かくなるはずだからマイクロサービスの戦略をとっていったほうがよいのではないか? みたいな話である。将来のあるべき姿を想定して、そこに向けて今から準備をしていこうというスコープの検討、これが必要なのかを最近疑問に思っている。

なぜ疑問に思っているかというと

  • 将来のあるべき姿を想定してそこに向けて準備をしていくことは、将来のあるべき姿の想定が違った場合にやっていることが無駄になってしまう
  • 期待した未来がくるまではそのアーキテクチャは、直近の最適化されたアーキテクチャではない可能性がある。そのため本来期待した恩恵を受けるまでの期間はある意味、備えるだけのコストが重荷になる。
  • いまのAI時代であれば常に目の前の課題の最適化を最速でやることが可能になってきている
  • headless SaaSやMCPのようにプロダクトの価値提供の形自体がAIによって変わりつつあり、従来の延長線上で描いた将来像につながる確度が低くなっている

以上の背景から中長期を考える必要がないのではないか?という疑問も持つようになった。

疑問には思うけれども…

中長期を見据えておかないと辛い部分はやはりでてくると考えている。特に後から変更が効きにくい不可逆な判断にこそ中長期の視点が必要で、そこを短期最適だけで進めたときに後から払うコストが大きくなる。まあ単純に従来の運用開発と照らし合わせてAIで容易にできるならそんな考える必要なく、AIにできないことはちゃんと先をみて作ろうぜって話なのかもしれない。一例ですが

  • AIで容易に変更できること
    • アプリケーションレイヤーの対応全般
  • AIで容易に変更できないこと
    • データベースのスキーマ / データの分離対応(本来領域が違うテーブル同士をJOINしている場合など)
    • オブザーバビリティの整備など(全部自前で作るよりは、Otelにのっかってplugableな設計にしておくなど)
    • etc…

後者のようにドメイン的に許してはいけない越境をしてしまっていたり、データが蓄積される場所やその連携方法をとりあえず目先の目標のためにえいやで作ってしまうと、たぶん将来の誰かがとても苦しむことになると思う。

というか短期的な観点での最適化と中長期を観たときの最適化だと、前者のほうが手軽だしメリットがあるし最高みたいな空気になるとおもう。それは中長期的な観点での備えをやらないというトレードオフ(白黒というかグレーなグラデーション)なのではとおもうので、ちゃんとその判断をした結果やってるのであれば問題はないのだとおもう。

中長期施策を推進する難しさ

アーキテクチャは課題を解決するための手段でしかないので、何を選ぶにしてもトレードオフになりがちだし、どんなアーキテクチャがいいかは所属する組織の様々な状況に応じて変わる。なのでいいアーキテクチャは何かということは一旦置いておく。

その上でここは個人的な振り返り。これまで中長期的な取り組みでうまくいかなかったなーと思うものを振り返ってみると、大体は中長期のプロジェクトに最後までかかわれなかった / 引継ぎ先がなかったというケースが多かった。中長期的な取り組みとして立案・導入をしたが、リソースの問題で担当外になってしまったパターンや、それが何でどう必要なのか関係者に伝えきれないために期待していない方向に進んでしまったなど、いわば注力できなかったのでやりきれなかった。中長期の施策を考えるときは将来的な組織状況などを考慮した上で立案・導入するのだから、リソース状況的に別PJにアサインしたいといわれても、そこでもっとぶつかるべきだったのかもしれない。もしぶつかった結果それでも外れるのであればアーキテクチャの廃止か継続可能なコミットメントし続けられる体制を模索するべきだったのだとおもう。そこの思考を放棄していたことについては他責になってしまったいたと反省している。

おわりに

先日昔の職場の上長とお会いして、この記事のような内容の話をさせてもらった際に「まこたすが偉くなったらいいんだよ」と言われたのがとても印象的だった。たしかに自分がやろうとしていることは中長期的にこうあるべきという意思をもって描いているし、それが組織の生産性をあげると信じてやっている。その実現性をあげるために偉くなることは一つの手段としてとても重要なので、そういうキャリアも考えてもよいかもと思った。