■ 1. 講演の前提
- 大企業ありがちな課題の抽出:
- 79企業に対するアジャイル開発コンサルティングの知見から、ありがちな課題を3つ取り上げる
- 企業ごとに規模も文化も抱える課題も異なるため、大企業共通の一般論を主張するものではない
- 特定企業が判別できるような具体的な話は避ける
■ 2. 課題1: ビジネスをハンドリングする人の不在
- ハイパフォーマンスなチームだけでは不十分:
- 高性能な車も運転できなければただの置き物であり、維持費ばかりかかる
- 経営者が欲しいのは人材そのものではなく、人材が生み出す成果である
- 成果が出ない状態は経営者にとって望ましくない
- アジャイル開発ができるだけでなく、経営者に向けた利益や成長に繋がっているかを問う必要がある
- アジャイルにビジネスを回す流れ:
- ビジネスをハンドリングするのはスクラムで言うプロダクトオーナーである
- プロダクトオーナーが戦略を練り、成否を確認するKPIを設定する
- マイルストーンごとに目標値を定め、予算を確保する
- 目標達成の仮説をプロダクトバックログに積み、開発者が開発して市場投入する
- 評価の結果、仮説が誤っていれば新たな仮説を積み直す
- チーム内にハンドリング役がいない問題:
- ある程度大きな企業ではプロダクトオーナーに相当する人がチーム内にいない
- チーム内のプロダクトオーナーは現場の判断権限のみを持ち、ビジネスの決裁権を持たない
- ビジネスの決裁権はチーム外のマネジメントが持つ
- 外部マネジメントによるアジリティ低下:
- アジャイルの理解が浅いマネジメントはウォーターフォール型の計画を出す
- 現場のプロダクトオーナーはその計画に基づき柔軟にこなすだけの開発スタイルになる
- ビジネスのハンドルが外側にあり、年に1回程度しか切られない
- ハンドルを切るタイミングが遅く、ビジネスのアジリティが下がる
- 対策1: ハンドルを持つ人をチームに入れる:
- 決裁権を持つ人をチーム内に入れ、当事者意識とマインドチェンジを促す
- 具体的なやり方は当該企業の競争力に関わるため公開しない
- 対策2: 出島の設置:
- 出島を作って権限を移し、アジャイルをビジネスとして回せる体制にする
- アジャイルをビジネスで回す上で最も良い形だが、組織をいじるため負担が大きい
- 対策3: 報告によるマネジメントの味方化:
- 組織もプロジェクトの仕組みも変えず、開発チームから報告を上げる
- 開発の進捗だけでなくビジネスの進捗もログ等から自分たちで用意して報告する
- 上位のマネジメントを味方に引き入れ、裁量をプロジェクト側に持ってくる
- コストがかからない対策である
■ 3. 課題2: 組織への責任感が強いステークホルダー
- ステークホルダー特定のセオリー:
- 新サービスは社内事務にも既存の関連システムにも影響し、それらは別部署が所管する
- プロジェクト開始前にステークホルダーを特定し、協力を得られる状態にして推進するのがセオリーである
- 縦割り構造によるオーバーヘッド:
- 組織が分かれていると予算もミッションも組織ごとに異なる
- 過渡期に旧来の事務と新しい事務を並行して担う依頼をしても、相手は人員が足りない
- 足りない人員で対応すれば負荷過多とミスを招くため、要求を飲めず防御行動に入る
- 防御行動に入られると説得して仲間にする攻略に時間がかかり、走り出しが遅れる
- 上位組織によるコントロール:
- 組織間のオーバーヘッド解消は、その上位の組織がコントロールするのが最も効率的である
- 経営者が課題を持つ人と定例で話す場を設け、財務のトップも参加する企業がある
- 予算手当てが必要ならその場で決めるという柔軟な動き方をする
- 人員が拡充されることで「できない」が「できる」に変わり、ステークホルダー間の調整が進む
■ 4. 課題3: 肥大化して複雑に絡み合った機能
- 影響範囲不明なシステムの限界:
- どこを直せばどこに影響するか分からないシステムでアジャイル開発を行うのは無理である
- アジャイル開発は何度もソースを修正するため、都度影響調査が必要になり開発に集中できない
- アーキテクチャが足を引っ張る
- 独立機能への分割:
- 影響範囲を絞り込める独立機能への分割が、アジャイル開発に最も合うアーキテクチャである
- モノリシックなシステムを一足飛びにきれいに分割できるプロジェクトは存在しない
- 利益が得られそうな部分だけを切り離してアジャイル開発し、切り離す範囲を広げる移行が現実的である
- AIによる代替の限界:
- 影響波及が不明な巨大システムをAIのインプットにするとトークンが爆発し、コストと処理時間がかかる
- 最大の問題は物忘れが激しくなり、出力結果が全く当てにならなくなることである
- 現場ではインプットが大きい時に要約や集約でインプットを減らしてからソースコード生成に走る
- インプットを増やさないことがAI活用における重要なファクターである
- 影響範囲を絞って小さく開発した方が品質は良くなる
- 人による確認の必要性:
- 生成AIが生成しテストしたコードをそのまま本番環境に載せることはできない
- 現状のレベルでは人が必ず確認し、問題ないことを確認してリリースする
- 影響範囲が分からないシステムでは人の確認もできないため、機能分割が重要になる
■ 5. 3つの問題の整理と企業変革
- 問題の分類:
- 1つ目はビジネスの問題であり、ビジネスのためにアジャイル開発を使いこなす必要がある
- 2つ目は組織の問題であり、縦割りのオーバーヘッドを何らかの方法で解消する必要がある
- 3つ目はITの問題であり、保守しやすい形に機能分割する必要がある
- 企業変革を阻む要因:
- これらはアジャイル推進の課題であると同時に、企業の変革を阻む要因でもある
- 分かってはいるが対策が難しい領域である
- グランドデザインとロードマップ:
- 業務とITと組織を別々に対策するのは難しく、一緒に考えてグランドデザインを描く
- 描いたグランドデザインを一気に実装するのは難しいため、マイルストーンを置いて地道に対策する
- グランドデザインとロードマップを引いた上で個別課題に対処するのが王道である
- 初めての企業には難しいため、経験者が支援する「モダナイゼーション Powered by Lumada」を提供する
■ 6. Q&A: 大企業でのアジャイル推進
- 偉い人の巻き込み方:
- トップレベルを巻き込むにはトップに直接インプットし、危機感を持たせることが重要である
- トップが危機感を持てば、その下のマネジメントに対しても指導が入る
- 中間マネジメント層はプロジェクトの仕組みとして参加を求め、逃げられないようにする
- 企画側のマインドチェンジ:
- マインドチェンジは難しく、明確な答えは持っていない
- 企画時の負荷を下げることが有効な手になる
- 何十ページもの企画書を書いた後に方向性を否定されると、修正への抵抗が生まれる
- エグゼクティブサマリーやリーンキャンバス1枚で軽く企画すれば、修正を受け入れやすくなる
- リソース確保の現実解:
- 何かしら価値が出ればお金がつく
- ユーザーの取り込み強化やヘルプデスクの要求への迅速な対応といったテーマを掲げる
- そのテーマで機能を切り出してアジャイル開発をするのが現実ラインである
- トップダウン以外のステークホルダー説得:
- トップダウンでない方法で進めている例の方が多い
- 担当者に交渉しても断られるため、相手側のキーマンを抱き込み、そこを中心に話を進める
- キーマンには常に状況を伝え、味方でい続けてもらうように振る舞う
- 同じ会社内ならキーマンは見当がつき、部署内で誰がキーマンか聞くこともできる
- 期待値が合わない状態での開始:
- 刀を研ぐところから始めるのはありである
- アジャイル開発ができる状態になってから企画側が追いつく方が、両方同時に育てるよりうまくいく場合がある
- ただし道半ばの例しか知らないため、「なし」ではないという回答にとどまる
- 最終的には時間をかけて期待値を合わせ、誤解を解く作戦を取る
- 機能分割の基準:
- データモデルで分割できるようにしないと後で苦労する
- トランザクションテーブルに相当するものは分割したい機能の中に入れ、単独で改修できるようにする
- 隣の機能のデータはインターフェース経由で自分たちのデータベースに持ってくる
- 隣のデータベースを直接覗かないことが基本である
- 定着に向けた外部活用:
- うまくいっていない場合は外部の力を借りるのが最も手っ取り早い
- 外から連れてきた人の方が内部の人より言うことを聞いてもらえる
- 自走に向けた支援メニュー:
- 自走状態に持っていくには最低限コーチをつけた方がよい
- 案件がない段階向けに、1ヶ月から1ヶ月半のスクラムシミュレーション教育を用意する
- 体制に入ってスクラムマスターを担う場合はひと月張り付く
- コーチはイベントのある日だけのスポット参画も可能で、予算に合わせて動く
- うまくいかなかった例:
- アジャイル経験者がキーマンとして動く案件では、自分たちのやり方が最善という前提で改善提案が通りにくい
- ヘッドが2つある状態はやりにくい
- 日立がプロダクトオーナーを担う依頼は、顧客のビジネスを代わりに担うことになるため断っている
■ 7. 問いの転換: 意思決定と学習を測る
- 測る対象の転換:
- アジャイルを測るのではなく、意思決定と学習を測る
- 「自分たちはアジャイルできているか」ではなく「正しいものを決め、正しく学び、そのサイクルを回せているか」を問う
- 判断力・実行力・学習力:
- 判断力は何を作るべきかを決める力である
- 実行力は決めたものをどう早く安全に作るかの力である
- 学習力は作った結果をどう学んで次の判断に生かすかの力である
- このサイクルの質が高まり回る数が増えるほど、価値創出の総量が増える
- 実行力だけ強くても判断が雑なら間違ったものを作るため、3観点をすべて担保する必要がある
- 主張の結論:
- アジャイルが回った上で成果を出すには、実行力に加え判断力と学習力を含めた組織のケーパビリティ計測が重要である
■ 8. AI時代の課題構造
- AI活用の現状:
- 73.1%のエンジニアが業務でコーディングエージェントを使っている
- 5割弱のエンジニアが自分のコードの半分以上をAIで生成している
- AIを入れるフェーズは終わり、AIがある前提でどう進めるかという段階に入っている
- ファインディでもAI未使用期から改善期にかけてアウトプットが増加している
- 実行力は量では測れない:
- アウトプット量が増える一方で、出したものの品質が論点になる
- スタンフォード、DORA、ファインディのレポートはいずれも速度向上を示す
- 同時に手戻りなど品質面の悪化も示されており、スピードだけでなく品質の観点も見る必要がある
- 判断力と学習力の指標欠如:
- 実行力にはDORAやベロシティといった指標が存在する
- 判断力と学習力はそもそも測る指標が存在しない
- 判断や学習のログが残らないため、計測自体が難しい
- コンテキストが渡らない実態:
- AIを活用するエンジニアの約55.1%が、AIに過去の意思決定の背景を渡せていないと回答する
- 半数以上が、決めた経緯を踏まえてAIに渡し良いアウトプットを出すという本来やるべきことをやれていない
- 会場調査の結果:
- 意思決定や学習の蓄積度合いを5段階で尋ねたところ、会場の回答は4が1名で他は3未満に集中する
- 胸を張って蓄積できていると言える組織はほとんどない
■ 9. 開発資本という新しいアセスメントモデル
- 開発資本の定義:
- 判断力・実行力・学習力の3つを含めて開発組織を「開発資本」として捉える
- 開発資本とは、企業がソフトウェアを通じて価値を生み続けるために組織に蓄積された能力、知識、基盤である
- 「資本」という言葉により、蓄積されて複利で効いてくる概念として開発を見る視点に変える
- 3つの評価観点:
- スピードは早く作って出して学べるかであり、作る速さだけでなく学ぶ速さが要点になる
- クオリティはコンスタントに価値を届けられているかであり、手戻りの少なさや本番品質、保守性を見る
- コントロールは変更を予測して制御できるかであり、構造・プロセス・複雑性の制御を見る
- 従来評価からの拡張:
- 従来はスピードの中でも「作る」に偏っていた
- 価値を最後まで届けられているか、学ぶところまで含められているかへスピードの観点を進化させる
- AI時代を踏まえ、開発を制御できているかという要素も加える
- 開発資本が高い組織は最終的にビジネスROIに繋がる
- 開発資本とビジネス成長や開発者体験との相関はマーケットリサーチで検証中である
- 判断力・学習力の測り方:
- 学ぶ速さとして、過去の知見をどれだけ蓄積し共有できているかを取る
- 得た知見を開発プロセスに還元できているかを取る
- コントロール観点で、ハーネスや開発標準の整備度、社内に残るコンテキストの活用度を取る
- 定性情報での取得に加え、定量での取得方法を検討中である
- 開発資本スコア α:
- 前日の7月1日にファインディチームプラス上でリリースした
- 各種ツールを接続すると、スピード・クオリティ・コントロールを組織単位で評価できる
■ 10. 開発資本を高めるアプローチと事例
- ファインディチームプラス:
- 開発プラットフォームとして提供し、そのソリューションを通じて開発資本を高める支援を行う
- 事例1: ファインディインサイツによる判断力支援:
- 相談、問い合わせ、アンケート、インタビュー、社内会議といった顧客の声をデータソースとする
- AIが取り込み、仮説検証・評価、ナレッジの資産化、インサイト分析を行うAIエージェントである
- インサイトマネジメント機能は相談ログを取り込み、顧客の要望やペインを蓄積して傾向をまとめる
- NTTドコモのプロダクトPoC開発で活用された
- 少数体制のPoCで現場から届くフィードバックの粒度がバラバラで、整理と優先順位付けにリソースを奪われていた
- ツール活用によりインサイトを管理でき、何を作るべきかの判断ができるようになった
- 実行力の支援:
- 実行力はファインディAI+で支援する
- 事例2: ファインディコンテキストによる学習力支援:
- プロダクト開発にまつわる意思決定をデータとして資産化する
- 人だけでなくAIエージェントの自律的な判断の質まで向上させる
- 55.1%がAIに文脈を渡せていないという課題に対するソリューションである
- 組織内の一次情報を取り込み、判断のコンテキストや意思決定ログを構造化して生成する
- Slackから、施策の内容、理由、検討した選択肢、意思決定の理由を含む意思決定ログを残す
- GitHubの情報から同様にADRを自動生成する
- コンテキスト構造化の効果:
- NotionやSlackの生データを直接AIに使わせる場合と、ADRとして構造化を挟む場合を比較した
- 構造化を挟むとAIのトークン量が減りコストが下がる
- AIから出てくる回答のスコアの品質が大きく向上する
- 議論が短縮され、人のリソース時間も削減される
■ 11. まとめと指標運用の論点
- 価値創出のボトルネック:
- AIで作る速さは早くなったが、手戻りや「決める」、学習が組織に残らない構造がボトルネックになる
- 実行力だけでなく判断と学習を開発資本として捉え、蓄積し測る視点が必要である
- まず自組織の判断や学習がどこにどんな形で残っているかを棚卸しするところから始める
- 指標のハックへの懸念:
- 特定の指標のみを見ると指標はハックされる
- 開発資本という概念で多角的に見た上で、どう高めていくかを考える
- 寄与の度合いはまだ検証段階であり、アルファ版利用者からのフィードバックを求める