アジャイル手法を戦略計画に統合するSSCMモデル：サプライチェーン成熟度の実践的活用法

うーん、最近よく考えてたんだけど…。アジャイル開発って、もうどこでも当たり前になったよね。ITの現場なら、たぶん誰もが一度は聞いたことあるし、やってると思う。でも、なんだろうな、この「アジャイルやってます」っていう言葉が、ちょっとずつ、本来の意味からズレてきてる気がしてならないんだ。

なんかこう、とにかく早く、細かくリリースすること自体が目的になっちゃってるというか…。スプリントを回すことが仕事、みたいな。それで、目先の機能ばっかり作って、全体として何を作ってるのか、どこに向かってるのか、だんだん見えなくなってくる。…正直、そういう現場、少なくないんじゃないかな。気づいたら、似たようなシステムが乱立してたり、後から修正するのがめちゃくちゃ大変な「技術的負債」だらけになってたり。これって、アジャイルが悪いわけじゃなくて、使い方を間違えてるだけなんだと思う。

で、このモヤモヤをどうにかできないかなって思ってたら、面白い考え方を見つけたんだ。それが、この記事で話したい「シナジスティック・サプライチェーン・マチュリティ（SSCM）モデル」っていうやつ。…うん、名前はちょっと、ごついよね。正直、僕も最初は「何それ？」って思った。でも、要はソフトウェア開発を「サプライチェーンマネジメント」みたいに捉え直そうぜ、っていう話。投資とか、リソースとか、長期的な価値とか、そういうのを一つのシステムとして見よう、と。そうすると、短期的な視点に陥りがちなアジャイルに、一本筋が通るんじゃないかっていう提案なんだよね。

まず、何が問題なのか？

そもそも、アジャイルはウォーターフォールみたいな硬直した開発へのアンチテーゼとして出てきたわけだよね。それは知ってると思う。変化に対応しやすくて、ユーザーの声を聞きながら少しずつ良くしていく。すごくいい。素晴らしいアプローチだ。実際、チームの自律性とか、対応力は格段に上がった。

でもね、問題は、組織が大きくなったり、扱うシステムが複雑になったりした時。アジャイルの強みである「短期的な価値提供」が、皮肉なことに「長期的な計画性のなさ」につながっちゃうことがある。うん、まさにそれ。

場当たり的な意思決定が正当化されて、スプリントをこなすだけの「作業」になっちゃう。本当はもっと根本的な改修が必要なのに、目に見える新機能の追加が優先される。インフラとか、共通基盤みたいな「見えない部分」は後回し。…心当たり、ない？

これ、日本だと、例えば情報処理推進機構（IPA）が出してる「ソフトウェア開発データ白書」とか見ても、プロジェクトの課題として「要求変更への対応」とか「品質の確保」が常に上位にある。これって、表面的なアジャイル導入だけじゃ、根本的な問題は解決してないってことの裏返しにも見えるんだよね。結局、場当たり的な対応が増えれば、品質は落ちていくから。

アジャイルそのものの失敗じゃない。これは、アジャイルな活動と、もっと大きな戦略的思考を結びつける「何か」が欠けているっていう話なんだよ。

そこで出てくるのが「SSCM」っていう考え方

じゃあ、その「何か」って何？っていうところで出てくるのが、さっき言ったシナジスティック・サプライチェーン・マチュリティ（SSCM）モデル。…長いからSSCMって呼ぶけど。

これは、ソフトウェア開発や製品開発を、一種の「サプライチェーン」として捉える考え方。最初は「え、サプライチェーン？ 部品とか工場とか？」って思うんだけど、よく聞くとすごくしっくりくる。

考えてみてほしい。工場で製品を作るとき、部品の調達とか、組み立てラインの効率とか、在庫管理とか、全体を最適化するよね？ ある部品が他の製品にも使えるなら、共通化してコストを下げたり。ソフトウェア開発も同じじゃないか、と。

• ある機能（部品）は、他のプロダクトでも再利用できないか？
• 認証機能や決済機能（組み立てラインの一部）は、最初にしっかり作っておけば、後々すごく楽になるんじゃないか？
• あっちのチームとこっちのチームで、同じようなデータ分析基盤（倉庫）を作ってないか？

こういうシステム全体の視点を持つことで、一つ一つのスプリントが、より大きな価値を生み出すための「投資」になる。SSCMは、そういう長期的な視点と相乗効果（シナジー）をアジャイルに埋め込むための、まあ、思考のフレームワークみたいなものだね。

アジャイルとSSCM、どっちが偉いとかじゃなくて

ここで大事なのは、SSCMはアジャイルを置き換えるものじゃないってこと。むしろ、補完するもの。アジャイルが「どうやって作るか（How）」の短期的なサイクルだとしたら、SSCMは「何のために作るか（Why）」の長期的な羅針盤みたいな役割を果たす。

スプリントを始める前に、ちょっと立ち止まってSSCMの視点で考える。四半期の計画を立てるときに、SSCMのマップを広げてみる。それだけで、日々の作業の意味が全然違って見えるはず。正直、言葉で言うより、表にしてみた方が分かりやすいかも。

ね、全然違うでしょ。SSCMを取り入れるってことは、反応的に動くんじゃなくて、意図的に、戦略的に動くってことなんだ。

じゃあ、具体的にどうやるの？

じゃあ、このSSCMの考え方を、どうやって普段のアジャイル開発に組み込むのか。元の論文だと結構小難しく書いてあるけど、要するにこういうことだと思う。ここでは「動的コストサーフェス」っていう、ちょっと面白いツールも絡めて説明してみるね。

ステップ１：まず「何のために作るのか」をはっきりさせる (SSCMフェーズ1)

当たり前だけど、これが一番大事。何となく機能を作るんじゃなくて、このプロダクトの最終的なゴールは何か、誰のどんな問題を解決するのかを定義する。この時点で、関係者間で「実は考えてることが全然違った」なんてことが分かるだけでも、ものすごい価値がある。

ステップ２：現状のシステムと「摩擦」を地図にする (SSCMフェーズ2)

今のシステムがどうなってるか、可視化する。チームごとにバラバラのAPIを使ってる、とか。同じような顧客データがあちこちに散らばってる、とか。そういう「非効率」や「摩擦」になっている部分を洗い出す。ここが、後で言う「コストが高い土地」になる。

ステップ３：レバレッジの効く「インフラ投資」を仮説立てする (動的コストサーフェス)

ここがSSCMの肝。「どこに投資すれば、将来一番リターンが大きいか？」を考える。例えば、「最初に共通の認証基盤を作っちゃう」とか、「デザインシステムを整備する」とか。こういうのは初期コストは高いけど、後々の機能追加はすごく楽になる。

この時、動的コストサーフェスっていう考え方が役立つ。これ、プロジェクトの「地図」みたいなもので、どのルート（開発順序）を通ると、将来的な総コスト（時間、労力、技術的負債）がどう変化するかを可視化するイメージ。近道に見える道（短期的な機能実装）が、実は後からものすごい山道（高コスト）につながってたり、遠回りに見える道（インフラ整備）が、後々高速道路（低コスト）につながってたりするのを「見る」ためのツールだね。

ステップ４：アジャイルのサイクルに組み込む (SSCMフェーズ4)

ステップ3で見つけた「高速道路につながる道」（＝レバレッジの効くインフラ投資）を、具体的なスプリントのタスクに落とし込む。ユーザーストーリーだけじゃなくて、「インフラ叙事詩（Epic）」みたいな感じでバックログに積む。アジャイルの反復的なやり方はそのままに、進むべき方角だけSSCMの地図で確認する感じ。

ステップ５：戦略的な成熟度を定期的に評価する

やりっぱなしじゃダメ。SSCMは「成熟度モデル」だから、自分たちが今どのレベルにいるのかを定期的に振り返る。また場当たり的な開発に戻ってないか？ シナジーはちゃんと生まれているか？ 動的コストサーフェスの地図を更新しながら、次の戦略を練る。これを繰り返していく。

一つ、具体的なケースで考えてみよう

言葉だけだと分かりにくいから、具体的な例で考えてみる。あるデジタルマーケティング代理店が、社内向けのITプロダクトを3つ作ることにした、としよう。

1. 広告指標ダッシュボード：色々な広告媒体（Meta, TikTok, Googleとか）の成果をまとめて見るやつ。
2. クライアントポータル：顧客が発注したり、進捗を確認したりするサイト。
3. Eラーニングプラットフォーム：デジタルマーケの有料講座を提供するサイト。

これを、何も考えずにアジャイルチーム3つに「はい、よろしく！」って渡しちゃうとどうなるか。多分、それぞれのチームが個別にユーザー管理機能、決済機能、グラフ描画ライブラリ、UIコンポーネントを作っちゃう。結果、3つの似て非なるシステムが出来上がる。メンテナンスコストは3倍。最悪だよね。

ここでSSCMの考え方を入れる。

まず、この3つのプロダクトに共通する「部品」は何かを洗い出す。「ユーザーアカウント管理」「分析データ基盤」「UIコンポーネントライブラリ」…いっぱいある。これらが「シナジーを生む源泉」だ。

次に、動的コストサーフェスで考える。「個別に3つ作るルート」と、「最初に共通基盤を作るルート」の長期的な総コストを比較する。最初は共通基盤ルートの方がコストが高い。でも、2つ目、3つ目のプロダクトを作る頃には、圧倒的にコストが低くなってるはず。その「地形」をステークホルダーに見せて合意形成するんだ。

その上で、開発ロードマップを再構築する。

• フェーズ1：まず、全プロダクトで使える「ユーザー認証基盤」と「共通UIライブラリ」を作るスプリントを最優先でやる。
• フェーズ2：次に、それを使いながら「ダッシュボード」のコア機能を作る。
• フェーズ3：ダッシュボードで使ったグラフ描画コンポーネントを流用して「Eラーニング」の進捗表示を作る。

…というように、一つ一つの開発が、次の開発を楽にする「投資」になるように計画を立て直す。これが、SSCMをアジャイルに組み込むっていうことの具体的なイメージ。単に機能を積み上げるんじゃなくて、能力（Capability）を積み上げていく感じかな。

この考え方の注意点とか、限界

でもね、もちろん、このSSCMっていう考え方も万能薬じゃない。いくつか注意点がある。

まず、初期投資と時間が必要だってこと。ステークホルダーが「とにかく早く何か見せてくれ」っていうタイプだと、説得するのが大変かもしれない。「今、土台を作っておけば、将来的にはもっと早く届けられますから」っていうのを、さっきの動的コストサーフェスみたいなツールも使いながら、ちゃんと説明して納得してもらう必要がある。

あと、すごい初期のスタートアップみたいに、プロダクトの方向性自体がまだフワフワしてるときには、あまり向いてないかも。探索的に色々試して、ピボットを繰り返すような段階では、重厚な計画はむしろ足かせになる。ある程度、プロダクトのビジョンが固まってきた中規模以上の組織で、特に効果を発揮する考え方だと思う。

そして何より、リーダーシップの理解と、文化の変革が必要だよね。「機能の出荷数」じゃなくて、「システム全体の健全性や将来性」を評価するような文化がないと、現場だけが頑張っても、結局は目先の成果を求められてしまうから。

まとめ、というか思うこと

長々と話してしまったけど、結局、アジャイルを捨てるんじゃなくて、アジャイルに「羅針盤」を持たせる、みたいな感じなのかな、と思う。アジャイルの原点って、アジャイルソフトウェア開発宣言にも書かれているように、顧客価値とか、変化への対応っていう、すごく人間的なところにあるはずなんだ。

それがいつの間にか、「スプリント」とか「ベロシティ」みたいな言葉だけが一人歩きして、目的と手段が入れ替わっちゃった。SSCMは、その目的…つまり、「長期的に、持続的に、より良い価値を届ける」っていう本来のゴールをもう一度思い出させてくれる、一つの地図なんじゃないかな。

日々のスプリントに追われていると、どうしても視野が狭くなる。でも、たまに顔を上げて、自分たちが作っているものが、もっと大きなサプライチェーンの中でどんな役割を果たしているのかを考える。それだけで、明日からの仕事の意味が、少し変わってくるかもしれない。

…あなたの現場では、どうですか？ 短期的な成果に追われて、長期的な視点を見失ったりしていませんか？ もしよかったら、コメントであなたの現場の話も聞かせてくれると嬉しいです。