出島のように、見えない壁を意識してつなげていく
経済産業省のDXレポートによると、「企業が競争上の優位性を確立するには、常に変化する顧客・社会の課題をとらえ、素早く変革し続ける能力を身につけることが重要」である。そのために目的ごとに組織を横断したチームを編成し、顧客視点で優先順位を決め、状況に合わせて意思決定する必要がある。「変化に素早く対応し続ける」ため、アジャイルやマイクロサービスの手法が取り入れられる。
ところが、現状は違う。企業は「安定して効率的に対応し続ける」能力を持っている。具体的には業務、システムの目的ごとに部署を分割して個別最適化をしていく。そして長期的に視点で定めた目的や優先順位に従い、業務をこなす。従来型のウォーターフォールやモノリスはこうした従来の在り方を前提として成り立っている。
そのためDXを推進するとなると、両者の間で悩むことになる。このギャップを解決するために重要なのは「意識的に分離し、つなげる」ことと鈴木氏は言う。イメージとしては長崎の出島だ。従来の世界と完全に分離した孤島にしてしまうと、流通が遅すぎて成果が小さくなってしまう。あるいは半島のような場所だと従来型の影響を受けやすく、結局実態が昔と変わらず成果を出しにくい。
だからこそ、出島だ。陸とは世界が異なるものの、橋でつながっている。鈴木氏は「両者の間にある『見えない壁』を意識して橋を渡す」ことが重要だと話す。
アジャイル開発を電車に例えると
まずはアジャイル開発から見ていこう。鈴木氏は「突然ですが、クイズです」と切り出した。タクシーと電車のどちらがアジャイルっぽく見えるだろうか。
答えは電車だ。タクシーはどこへでも行けて自由度が高いものの、調達に時間がかかり、ドライバーのスキルに左右されることもある。一方電車は、運行区間や料金があらかじめ定められていて自由度が低い半面、ルールが明確なので、安定的・継続的に何かをデリバリーするときには便利である。
電車の在り方をスクラムで考えてみよう。電車は定期的に駅から駅へと運行している。ホームでは乗客が並んで待ち、電車が着くと定員まで乗客を乗せて発車する。電車の運行がスプリントで、出発ホームがプロダクトバックログ（やりたいことのリスト）、乗客はプロダクトバックログのアイテム（リストの1つ）となる。
電車は乗客を安全に目的地まで運ぶことに集中すればいいので、次の電車の乗客が誰かは気にしなくてもいい。これは「いまやること」と「次にやりたいこと」の分離であり、開発リソースの調達が不要で無駄がないと言える。
ただし、電車に乗り遅れないようにする（荷物をまとめてホームで待つ）のは乗客の責任となる。スクラム開発で言うと、プランニングまでに要件を詳細化し並べ、見積もり可能なレベルにする必要がある。
ここに見えない壁がある。この詳細化は開発側ではなくビジネス側の責任なのだ。スプリント内で開発者が詳細化していると、見積もりは曖昧になってしまう。
プロダクトオーナーの役割
そこでビジネスを理解できるプロダクトオーナー（PO）が要件の詳細化を主導していく。この詳細化は調整事項が多いため、スプリントとは独立して行う。もしPOが企画部門やビジネス側出身で詳細化のスキルが乏しいのであれば、開発経験者をPO支援（プロキシPO）につけるといい。なおスクラムマスターが暗黙的にPOを担うことも多いが、これはアンチパターンだ。スクラムマスターが機能しなくなってしまう。
鈴木氏は「POの最大の仕事は決定すること」と言う。電車の例だと、どの電車にどんな順番で誰を乗せるかを決めることにあたる。決定を遅延させたり、覆したりしてはいけない。また、POをうまく機能させるためには組織全体でPOの決定を尊重する必要があるが、困難もある。
POはユーザーや開発者に向けた横の調整だけではなく、意思決定者や業務との縦の調整もしていく必要がある。会社の意思決定者に向けては説明責任があり、業務現場にはオペレーションの業務調整など合意形成する必要がある。
もしPOがスティーブ・ジョブズのように、会社の全権を掌握する意思決定者であり、プロダクトの育て方も理解し、業務側の意思決定者でもあり、顧客の未来も見えているのであればいいが、通常は縦と横の調整は難しい。
この壁を越えるための策として、鈴木氏は「組織としての意思決定プロセスを明確にする」ことを伝えているそうだ。鈴木氏のおすすめは、縦の合意形成に必要な人を集めたミーティングの定期的な開催。これをスプリントと同じサイクルで行うのだが、ミーティングはスプリントプランニングの手前なので、スプリントレビューとは別にする。
鈴木氏は「偉い人と細かく定期的に話す。3カ月前だと忘れられてしまうことでも、毎週やっていると現場と意識が合うのでミーティング時間が短くなり、ITをグリップしている感覚も持てるので、うまく回るようになります。また小さな失敗の報告がしやすくなります」と話す。
システムは分割せず、新しいサービスで置き換えていく
マイクロサービスは、複雑化したシステム（モノリス）の弊害となる機能間調整や実行時影響（スローダウン）を解決するために生まれた。機能間の依存をなくしてしまえば、機能間調整や実行時の影響を抑えることができるという発想だ。技術的には機能をサービスに分割し、APIでつなげる。サーバーもデータベースも独立できるので、スローダウンが起こりにくくなる。
またマイクロサービスは、各モジュールが単一の明確な責任を持つ「高凝集」、各モジュールが独立し依存しない「疎結合」な設計にすることで将来の変更容易性が高まる。各モジュールはアジャイルで開発するのが基本だ。
ただし高凝集・疎結合は実現難易度が高いという課題もある。逆に低凝集・密結合、つまりモノリスの「大きな塊にいろんなものを詰め込める」スタイルにもメリットはある。分割を考えることがないので、設計がシンプルになる。サーバー台数が少ないので全体管理コストも低い。加えてデータの整合性は、データベースのトランザクション機能が保証してくれる。
なお昨年GitHubの元CTO Jason Warner氏が「近年のアーキテクチャにおける大きな間違いは、すべてをマイクロサービス化しようとしたこと」とツイートしていた。鈴木氏も「全く同じ考え」と言う。「粒度を考慮することは大事だし、いきなりすべてをマイクロサービスにする必要はない」
基本的なセオリーはいいとして、実際に既存のシステムをマイクロサービスにしようとすると壁が立ちはだかる。一括再構築ではうまくいかないし、単純な分割も成功しにくい。むしろ密結合のまま分割するのは危険だ。
鈴木氏は「マイクロサービス“化”を意識していくことがとても重要」と強調する。対象システム、組織の規模、成熟度に合わせて段階的にマイクロサービスにしていく。途中経過では粒度が混在することもある。
大事なのは既存システムを分割しないこと。その代わりに、新サービスで機能をすり替えていく。システムのなかに機能A～Cがあったとして、まず機能Aを新規のサービスとして作り、システムの中にある機能Aを使わなくする。同様にすべての機能を新サービスとして切り出せたら、元のシステムは使わないようにする。
マイクロサービス化と同様にプラットフォームの整備も重要だ。DevOpsを実現できるような基盤を整備し、共通化していく。一般的にはパブリッククラウドにPaaSを中心に組み上げていくケースが多い。段階的に行うので、長期的な視野が必要だ。例えばNetflixは2008年からAWSへの移行を開始し、クラウドシフトの完了を宣言したのは2016年1月だ。なお最後に移行したのは顧客管理システムだったそうだ。
「見えない壁」を超える人の心構え
今回何度も出てきた見えない壁とは、鈴木氏によると「ビジネスとIT、組織とIT、経営とITの壁」となる。ITに対して「要件を決める」「意思決定する」「投資する」といった期間を、かつての年単位から1週間単位のように大幅に短縮しなくてはならない。企業のさまざまな要素とITの距離を縮めていく必要がある。うまく折り合いをつけながら、壁を打ち破っていくことが大事だ。
「壁を越える人の心持ちも大事」と鈴木氏は言う。まずは他者をリスペクトすること。それぞれのやり方には背景があり、意味がある。自分と異なるからといって否定するのはよくない。目指す先は一緒だと共有し、オープンに話し合う。自分の立場ややり方を分かち合うことで、両者の間に橋を架けていく姿勢が求められる。うまくいかないことがあっても他人のせいにせず、自らで考えて動いていく。鈴木氏は「ただし妥協しないこと」と話し、最後に「今日お話したことが皆さんの中で何かとつながり、動き出すきっかけになればうれしいです」と述べて講演を締めくくった。
エンタープライズDXへの取り組みを紹介中
Graat（グロース・アーキテクチャ＆チームス）は、アジャイルやマイクロサービスへの取り組みを通じて「IT」と「チーム」の力を引き出し、エンタープライズDXを支援しています。中途採用も行なっていますので、ぜひご覧ください！
