VUCA時代の国内ITリーンの新潮流 - すべての企業がテックカンパニー化する時代のITオペレーション改革

1. 目次

• ITリーンは、アジャイルやDevOpsの源流であり、ITの生産性改革のフレームワークである
  製造業のトヨタ生産方式をITの世界に適用したもので、「ムダをなくす」「決定を遅らせる」「速く提供する」「生産性を測定する」といったリーン経営のコンセプトに基づき、「サイクル型開発」「テスト駆動型開発」「集合ベース開発」といった様々な開発方法論が示されている。
• 時代がITリーンを求めている
  VUCA時代（Volatility：変動、Uncertainty：不確実、Complexity：複雑、Ambiguity：曖昧）に突入し、IT部門にも変化への柔軟性や機敏性が強く求められるようになっている。こうした時代において、不確実な環境下で本質的なIT価値を如何に高めていくかを追求してきたITリーンの考え方が改めて注目されている。
• ITリーンを進めるためには組織上の土壌形成が必要である
  一方、米国シリコンバレーで発展したITリーンの考え方は国内ではなかなか定着していないのが実態である。この背景には、国内企業の組織構造、投資管理プロセス、プロジェクト管理といった慣習やルールが障壁となっている可能性がある。本稿では、こうした問題構造を紐解き、如何にすればITリーンのメリットを享受できるのかを考察する。

トヨタ生産方式に端を発するリーン経営、そしてその考え方をITの世界へ持ち込んだITリーンが語られ始めて実に10年以上となる。発展の系譜については様々な見方があるものの、根源的な目的論を同じとするものとして、スクラム、XP、アジャイル、DevOpsといった多くの方法論がITの世界でも提唱されてきた。

ITリーンでは、IT開発プロセスの生産性を高めるための様々な考え方や手法が提唱されているが、今日改めて脚光を浴びている最大の理由は、不確実な事業環境において、成長に直結する仕事にいかに経営資源を注力させるかを突き詰めようとしている点であろう。事業環境の変化を最初から完全な形で予測することは不可能であることを前提とし、成果を生まない仕掛在庫／WIP（ITリーンの場合：開発途中のITプロジェクト）を可能な限り減らし、小さなバッチサイズ（システム機能単位）で製品をリリース（新機能を本番リリース）する。そして、市場の反応（システム利用者のフィードバックや反応）に応じて改善活動を繰り返していくことこそが事業を成功に導く（ビジネスに寄与するITシステムを実現する）ための最善の方法であるという考え方が、近年の不確実な経済環境下において、その有効性を改めて評価されているのである。

1. ITリーンとは何か
2. なぜ今、ITリーンなのか
3. 国内IT部門のジレンマ
4. ITリーンオペレーションへの一歩を踏み出す
5. 変革ポイントI：組織・ミッション
6. 変革ポイントII：人員リソース
7. 変革ポイントIII：制度・ルール
8. まとめ

自動車業界で世界の覇者となったトヨタの生産方式は、製造業のベストプラクティスとして世界中で研究され、90年代以降ではITの世界にもその要素が適用されるようになった。製造業における生産性の阻害要因として定義された「7つのムダ」は、ITの開発プロセスにおける生産性阻害要因に置き換えられ、これらを解消するための様々な手法が提言・実証されている。

代表的なのは、本稿の趣旨でもあり、冒頭でも述べた「在庫のムダ」を減らすために、開発機能単位を小さくし、本番リリースの回数・頻度を増やし、リリース後の分析と改善のフィードバックループを回していくというものである。この要素が取り込まれたアジャイル開発プロセスなどでは、ともすると繰り返し型の手続きが注目されがちだが、これはあくまで手段論であり、重要なのは投資に対して成果を生まない開発途中のプロジェクトを減らす点や、将来の不確実性に対して一度に計画して長期間かけて後戻りできない開発を進めてしまうリスクを低減する点にある。このため、大規模プロジェクトで散見される複数の機能を同時並行で開発するようなタスク設計も、少しでもリリース回数を増やすことを是とするリーンにおいては、並行する作業を切り替えながら進めた結果として一定期間で1つのタスクも完了できないより、1つのタスクに集中することで確実に完了させる（リリースする）ことが求められる。また、「不良をつくるムダ」に対しては、不良を検知するためのプロセスは究極的には無意味であり、不良を予防するプロセスこそが重要であるという考え方に基づき、テスト駆動型の開発プロセスが提唱された。これ以外にも、バリューストリームマップ（ムダを発見するための手法）、同期（複数モジュールのビルドとテストのコントロール）、集合ベース開発（情報共有や意思決定に要するリードタイム削減）など、多岐に渡る知識体系が提供されている。本稿最後に挙げた参考文献は、ITに従事されている読者にとっては既知のものが多いだろうが、それ以外の読者の方はITリーンの世界感を分かりやすく解説しているのでご一読いただきたい。

では、なぜITリーンがここにきて改めて注目されているのか。この背景には、昨今の経営環境がVUCA（Volatility：変動、Uncertainty：不確実、Complexity：複雑、Ambiguity：曖昧）と表されるように国内のみならずグローバルレベルで経済・政治・技術が予測できないスピードで変化していることがある。こうした時代において、大企業であっても旧来のビジネスにしがみついて生き残ることは難しくなってきており、刻々と変化する経済環境を先読みし、新たなチャレンジをしていくことが切実に求められるようになった。ここで重要なのは、10年同じやり方で継続できることを約束されているわけではなく、先の読めない環境下でのリスクを含むチャレンジが求められているという点である。各企業は各々の成長戦略を定め、これに資するいくつかのセグメントに経営資源を投下していくわけだが、事業参入に必要なITの開発に年単位を費やすことはもはや許されなくなった。また、不確実な経済環境下におけるチャレンジであるがゆえに、最初に定めたIT化の方向のままでうまくいくとは限らず、数ヵ月後には当初とは異なる方向へ舵を切り直すということも十分に想定しておかなければならない。

一方、国内のITの現場に目を向けると、このような経済環境のスピードや不確実さにどれだけ追随できているだろうか。いまなお、2～3年かけて1つの巨大なシステムを作り上げるウォーターフォール型のシステム開発プロジェクトが多くの企業で見かけられる。また、ウォーターフォール型の特徴として、最初に決めた仕様に変更が生じるとシステム全体がリリースできず、延々と開発とテストを繰り返すデスマーチに突入することになる。しかしながら、事業の視点で見れば、そこで決められた仕様はリリースの1年以上も前に決められたものであり、1年以上経過したリリースの時点でそのまま通用させることはそもそも難しい状況になっている。こうした意味では、スピードや変化への柔軟さの観点で国内のシステム開発の現場はVUCA時代に即さなくなってきていると言わざるを得ない。

では、国内のITの現場が現状に甘んじてきたのかと言えば決してそうは思わない。筆者が接してきたクライアント企業では、能力的にも優秀で、責任感も強く、自社事業に対する貢献意識の高い社員がほとんどであった。また、筆者自身も長らくITの世界に従事してきた経験から、米国シリコンバレーを中心に発展したITリーンの考え方は「（何となく）日本の大企業には馴染まない」という感覚を覚えた。では、なぜ国内のITの現場にリーンの考え方を適用することが難しかったのか。この背景にはもう少し根深い問題があると筆者は考える。本稿ではその点を紐解いていきたい。

1つ目の理由として考えられるのは、歴史的に国内のIT部門は事業に対して直接のオーナーシップを求められてこなかったことである。市場や顧客との間にはビジネス部門が存在し、IT部門が直接対峙することはほとんどない。ゆえに、システムの要件を打ち出すのはビジネス部門であり、IT部門はこれを実現することだけに責任を負ってきた。いわば、企業内のコーポレート機能の1つとして要請されたことを粛々と実行する限定的な役割である。また、IT業界全体を見ればビジネスモデルを根幹から覆すレベルの目覚ましい進歩を遂げてきたが、これを担ってきたのは、残念ながら各企業のIT部門ではなく、多くの場合はソフトウェア企業であった。マーケットとの間にはビジネス部門が介在し、新技術開発の領域ではソフトウェア企業がこれを担い、各企業のIT部門はビジネス部門の要求をソフトウェア企業に伝達することが主な役割となってしまった。これにファンクション部門（市場や顧客と直接フェーシングしない部門）の声が小さいという日系企業にありがちな組織上の力学も相まって、本質的な付加価値を生み出す力が弱まってしまったのではないだろうか。いわゆる「ITガラパゴス」や「手配師」などと揶揄される構図である。このような状況下で、ITリーンで提唱される改善サイクルを適用しようとしても、自社事業に自分たちのアイデアをぶつける機会もなければ、これまでそれを求められてこなかったがゆえに、事業アイデアを考えること自体も専門性や経験の観点から難しいのである。

2つ目の理由はIT投資の仕組みである。多くの企業では、ビジネス部門からの開発要望をリストアップし、（計画上の）投資対効果の高い順に並べた上で、IT予算や開発リソースのキャップで足切りをする。そして、投資判定時に見込んだリターンを実現すべく、定められた優先順位で要望された機能を開発するという流れである。一方、ITリーンでは初期構想に長期間をかけるのではなく、成果が出なければ途中で止めるという判断も含め、できるだけ小さな機能単位で本番リリースを繰り返し、改善判断を行っていくことの重要性を説いている。これを前述の多くの企業で行われているIT投資の仕組みに当てはめてみると、経営層やビジネス部門から「事業採算計画が立たない」「成果をコミットできない開発に投下できる予算はない」という反応を招くことが容易に想像されてしまう。新たな価値を生み出すためのチャレンジよりも、いかに失敗しないかを重んじる傾向にある国内企業のカルチャーが計画時点の完全性を求める格好となり、ITリーンを推進する上では高い障壁となってしまうのである。

3つ目の理由は、ウォーターフォール開発プロセスとPMBOK式プロジェクト管理への過剰な信頼である。一定規模以上のシステム開発プロジェクトは大変な困難を極める。迷走し、無秩序状態となった開発プロジェクトは本当に悲惨である。このため、経験豊富なIT部門は状況の可視化や責任所在の明確化によるリスク低減を徹底的に追求することとなり、これを体現したものがウォーターフォール開発プロセスやPMBOK式プロジェクト管理である。システム開発プロジェクトのリスクをコントロールすることは極めて重要であり、決して否定するものではない。その一方で、昨今の不確実な事業環境下で真に事業に寄与するITの成果を求めるならば一定割合でリスクと不確実性を許容せざるを得なくなってきているのも事実であろう。数年をかけて石橋を叩きながら大きなものを一度に作るというシステム開発は、もはやビジネスの世界との時間軸がずれ過ぎている。数年前に決めたシステム仕様は既にその大半が役に立たず、要件定義フェーズの承認会議でサインオフしたじゃないかという議論は、もはや意味をなさなくなっている。

前章で述べた背景は、いずれも日系企業の歴史的な組織論や業界慣習の中で醸成されてきたものであり、もはやIT部門だけの自助努力で脱却することは難しい。ITリーンオペレーションを自社のスキームとして活用・浸透させていくためには経営層やビジネス部門のマインドチェンジと、これに基づく社内の制度やルールの変更をまずは進める必要がある。

この際、いきなりすべてを変える必要はなく、パイロット的な取組みとしてスモールスタートすれば良い。よりスピードや柔軟性へのニーズが高く、ITリーンのメソッドが馴染みやすいフロント系のシステム、いわゆるSoE（Systems of Engagement）と表される領域のビジネスシステムから始めてみるのはいかがだろうか。具体的には、ECシステム、カスタマーサポートサイト、代理店システムなどがイメージしやすい。そして、この限定的な領域では、いくつかの事柄をこれまでのやり方とは大きく変えてみよう。

まずは、社内の組織・ミッションの観点で、IT部門とビジネス部門の役割と責任を変える。具体的には、マーケティング・R&D・営業といった市場や顧客にフェーシングしている部門が負うKPIやミッションを、IT部門も同じように与えると同時に、これを達成するための権限も与えるのである。また、別のやり方として新たな組織を作るという選択肢もあり得る。たとえば、デジタルマーケティングを推進するチームとして、マーケティング・企画・営業・ITから人員を集めたチームを組成し、会社全体とは異なるサイクルで仕事を進めるといった具合である。

次にIT部門のリソースの在り方である。ITリーンオペレーションを適用するプロジェクトでは小さなバッチサイズのリリースを繰り返しながら、しばしば大きな方向転換をスピーディーに行っていくことが求められる。このようなプロセスでは、ウォーターフォール型の大規模プロジェクトで採用される外部サプライヤーへの請負型の発注形態では身動きが取れなくなってしまう。外部サプライヤーへ開発を委託することの多い国内では、準委任型の発注形態に切り替える必要がある。

また、外部サプライヤーの選定に際しては、決められたことを実直に開発することに長けたサプライヤーよりも、リーン開発の経験を有し、マーケットの反応を定量的に分析し、反応に応じた次の一手を一緒に考案できるサプライヤーを選びたい。社内にこうしたノウハウが少ない国内企業ではこのようなプロセスを外部サプライヤーがどれだけ支援できるかが成否の鍵となる。

続いて、社内の制度である。前述で外部サプライヤーに求めたようなノウハウを社内に蓄積できるような教育制度や評価制度を作っていかなければならない。そうしなければ、いつまでたっても外部サプライヤー頼みのままの空洞化構造から脱却できない。この領域で活躍できる人材が育たないだけでなく、仮に優秀な人材がいても、適正な評価を受けられず外部へ流出してしまう事態を引き起こしてしまうだろう。具体的なやり方としては、従来型の仕事のサイクルとは異なるミッションを有するチームを組成した上で、この組織のミッションと連動させる形で、人材要件や評価基準を設けるということになるだろう。社員の採用や外部サプライヤーの選定などもこの要件に沿って進める必要がある。

もう1つのルールの観点として、投資判定やプロジェクト状況の経営報告のあり方も変える必要があるだろう。従来のプロセスでは年に数回しかなかった本番リリースのような重要なマイルストンがITリーンを導入すると1～2ヵ月に一度は生じるようになる。この際、これまでのような重厚な経営報告をやっていては間接コストが大きくなり過ぎ、本業である開発作業に注力できなくなってしまう。より効率的で簡便なものに変えなければ到底現場は回らないだろう。また、前章でも述べたとおり、リーンプロジェクトでは一定の不確実性や曖昧さを肯定し、初期段階ではある程度のリスクテイクが求められる。1～3ヵ月程度のサイクルでリリースを繰り返しながら、これに応じた方向転換を繰り返すことになるが、これを経営レベルで健全な状態だと認識し、より良い方向へ向かうための建設的な議論をしていかなければならない。リーンに対する理解が進まないことで、経営層から報告の体裁を咎められたり、不確実な外因の責を問われたりするようなことがあれば、企業内にリーンを根付かせることは難しいだろう。

筆者自身も、アジャイル開発に取り組む企業においてリリース間際に経営層やビジネス部門から従来型の管理手法に基づく要請や指摘を受け、結局リリースすることができず、やむを得ずウォーターフォール型の開発プロセスへ戻すようなケースに遭遇したことがある。従来型の管理手法からのチェンジマネジメントを促進する意味では「過去のITプロジェクトが数10ヵ月を要したのち、投下リソースのどれだけが事業成果に直結したのか」「これまでのやり方で将来にわたって会社や事業が生き残っていけるのか」といった、ITリーンオペレーションが求められる時代背景に今一度立ち返る必要がある。

国内のIT部門には、勤勉で本稿で触れたような方法論に幅広く精通しているにもかかわらず、前章で述べたような組織的な障壁に阻まれ、日々の仕事では実践できないでいる方がたくさんいるように思う。また、経営層やビジネス部門の立場で（あるいはIT部門の経営層として）、IT投資効率やIT開発の生産性に対して苦慮している方の中には、世の中で注目されている先進的な仕事のやり方がなぜ自社で導入できないのかを疑問に感じていた方もいたのではないだろうか。本稿では、ITリーンの方法論そのものではなく、これが改めて脚光を浴びている時代背景と、ITリーンオペレーションを導入するための要諦、すなわちIT部門の自助努力だけでなく、経営層やビジネス部門が一丸となった組織変革が必要であることについて述べてきた。

このような取組みを部分的にでも推進していくことは、部門間の壁を取りはらい、事業成長にコミットする一体型の組織を醸成していくことの一端を担うだろう。さらには、ITリーンオペレーションの特徴である早期に成果が表出させられる点（Quick Win）をうまく活用することで、より大きな潮流を作り出していくことも期待できるだろう。

参考文献

• 『リーンソフトウェア開発』
  Mary and Tom Poppendieck著
• 『リーン開発の本質』
  Mary and Tom Poppendieck著
• 『リーン開発の現場』
  Henrik Kniberg著
• 『The DevOps逆転だ！究極の継続的デリバリー』
  Gene Kim/Kevin Behr/George Spafford著
• 『リーンソフトウェア開発と組織改革』
  Mary and Tom Poppendieck著
• 『リーン・スタートアップ』
  Eric Ries著

KPMGコンサルティング株式会社
マネジメントコンサルティング
ディレクター　石井 信行
シニアマネジャー　井城 裕治