楽しいモノリシックアーキテクチャ開発

ソフトウェアがビジネス活動において重要なのは疑う余地がありません。同時に、複雑化しているのも誰もが認めるところでしょう。ことWeb開発においてその兆候は目覚ましく、伊藤直也氏がスライド「開発組織のマネジメント」でこう述べています。

相対的にWeb開発は昔より難しくなっていて、昔より重要性が高い

その複雑化に対応するため、ウェブアプリケーションを含むあらゆるソフトウェアがモジュール化、部品化を進め、それに合わせ組織体制も整備されているところかと思います。ですが、ビジネスやサービスの観点でみれば、どれだけ部品化したところでひとつの大きなシステム（モノリシックアーキテクチャ）でしかなく、にもかかわらず部分最適化が進んだ組織には、全体のビジネスの意義やそれに伴うやりがいといったものが極めて希薄化、見えない化している印象があります。それは特に実際の顧客から離れた基幹のAPIやインフラといった部分に関わるメンバーほど顕著なのではないでしょうか。開発の遅れや品質に問題のあるモジュールが全体の足を引っ張ったり、それを理由に周囲のモジュール群の進捗が遅れたりする状況はままあるように思いますが、効率化を意図としながら本末転倒であることは明白です。顧客像や全体的な価値がもっと正しく見える化されるべきではないでしょうか。

マイクロサービスでも不十分な理由

マイクロサービスやSingle Purpose Services、サービス指向アーキテクチャーといった考え方があります。これらはひとつひとつの部品を限りなくシンプルに、かつデプロイといった関連作業を含め分離し、HTTPといった高次で汎用的な手法で連携する設計思想です。非常に有用で、これらがベースになることは間違いありません。ですが、さきほどの課題を解決するには不十分です。なぜなら例えば、"1"が入力されると感情豊かに「Yes!Yes!」と応答し、"0"が入力されると感情豊かに「Nooo!」と応答するシステムをまかされたとしましょう。シンプルですので開発は容易ですし、運用するのも難しくありません。ですが、一体のこのシステムが誰のための何になっているのかいたって不明瞭です。「もっと感情豊かにしてくれ」と要求されても正直あまり響きませんし、そうする意義も伝わりません。結果的にもうひとつYes!を付け加えて"Yes!Yes!Yes!"に変更する程度のやっつけ仕事になる可能性があります。さらに例えるなら、このYes!No!システムで利用するミドルウェアの管理運用チームはどうでしょうか。彼らはある意味、そのミドルウェアが稼働していれば業務を完遂しています。そこに「もっと高速に"Yes!Yes!Yes!"と応答したい」とか「いつどちらを応答したか記録するので巨大なデータベースがほしい」という要求があったとしても正直あまり響きませんし、意義も伝わりません。Yes!No!システムそのものの存在理由に疑念を抱く危険性すらあります。こうしてモジュール間で無用な押し問答とその連鎖を重ね、全体として低価値なものを長時間かけて作り上げる悲喜劇の幕開けとなるでしょう。もちろんこれは極端な例ですが、こういううまくいかないエピソードは現場に溢れていますし、事象が見えにくいためビジネスサイド側からは理解されません。どんな最先端の開発手法や開発フローを選択していても起きている印象があり、これらはプログラミング言語の選択や開発手法の問題ではないのです。

見えない何かの可視化の仕組み作りを

システムを行き交う電子的な情報の流れとは別に、それを逆流するもっとメタ的で感情的な情報の流れが必要です。それは顧客の喜び、満足度、シンプルに売り上げかもしれません。良いアイディアはありませんが、どんな些細な部品を担当していてもエンドユーザーを感じることができて、全体を俯瞰すると依存度や影響度の高いモジュールを発見でき、その重要度が誰でも（ビジネスサイドの人間でも）理解できる、そんな仕組み作りが重要かもしれません。各モジュールのアクセス数、訪問者数や稼働率といった実際のシステムの指数と兼ね合いを持たせると、より具体性が増しそうです。見えない何かの流れを可視化することが、巨大ソフトウェア開発を気持ち良く円滑に進められる一助になるのではないでしょうか。