『誰も教えてくれない問題解決スキル』（芝本 秀徳 著）という、個人的にすごく勉強になった本がある。
そこで語られているのは、「問題とは現状（AsIs）とあるべき姿（ToBe）のギャップである」という定義だ。
私が現場で「生産性」を問題として活動した時も、まさにこの定義からスタートした。
ギャップ（問題）の定義と、課題への分解
当時の現状（AsIs）は、新機能のリリースに「3ヶ月から6ヶ月」もかかっていた。
私が定義したあるべき姿（ToBe）は、「圧倒的スピード感での機能提供」だ。時間がかかればかかるほど機会損失に繋がり、必要な機能がすぐ使えないことは利用者をヤキモキさせる。当然お金にも絡むため、生存戦略上、絶対にスピードが必要だった。
このギャップに対し、私は「生産性の低さ」と問題の名付けをした。
そして、その問題を解決するために、現状の「課題」を以下のように洗い出した。
- 古いコードベースとフレームワークによる開発効率の悪さ
- バージョン管理にGitを使用していないことによるマージコンフリクトの多発
- DDD等のモダンなアーキテクチャがなく、作成者の「センス」に委ねられたルール
- 単体テストがないため、修正時の影響確認が地獄（手動テスト頼みでリファクタリング不能）
- 設計書が古いExcelで、差分確認が不可能
- AIを使った開発体制への未対応（設計書をマークダウン化し、AIに参照させやすいプロジェクト構造にする必要性）
- レビュー体制がなく、ナレッジが共有されない
チームに変革を浸透させる「泥臭い」プロセス
課題をチームに伝える時は、全てをぶつけるのではなく「3つ」ぐらいにキュッと絞った。
それでも、最初は当然壁にぶつかった。
設計書をExcelからマークダウンに変更することの意味合いは全く伝わっていなかったと思うし、アジャイルの導入や「ふりかえり」を始めても、最初は全く盛り上がらず、発言内容も当たり障りのないものばかりだった。
浸透には時間がかかるもので、まぁまぁこなれてきたと感じるまで3ヶ月、チームに完全に馴染み、自発的な発言が増えるまで6ヶ月かかった。皆の協力もあり、設計書の運用やアジャイルの進め方は無事に定着した。
技術的な課題（DDD導入やAI向けコードベースの構築）については、言葉で説明するだけでは動かないので、私自身がAIチャットや書籍を読み漁り、まずは「雛形」を作成した。「こんな風にやればいいよ」と、自ら手を動かして一旦動作するモノを作り、会議の場で説明することでチーム内に普及させた。
成果と、AIがもたらした「新たな問題」
結果として、開発速度はだいたい30％ほど改善し、ソフトウェアの質も目に見えて良くなった。
しかし、オチがある。
そこにAIを本格導入したことによって、生産性が10倍・20倍に跳ね上がり、爆速で作れるようになってしまったのだ。
すると今度は、「利用者への展開方法」や「人間が検証するプロセス」が完全にボトルネックになるという、全く別の巨大な問題が発生してしまった。次はこれを解決する方法を考えなければならない。
組織を動かすなら「無関心層」を巻き込めるか
チーム内での変革であれば、丁寧に説明し、質問に回答していくことで着実に変化を起こすことができた。しかし、これがもっと大きな「組織」を変えるとなると話は別だ。
人が絡む以上、必ず「抵抗する人」と「無関心な人」が現れる。
この時、抵抗する人を説得することにリソースを割いてはいけない。抵抗する人は一旦無視して、「関心のある人」と強固に協力する。
そして、大多数を占める「無関心な人」に対して、「新しいやり方をした方が自分たちにとって得だよね（ラクだよね）」という状況を作り、そちらに寄せる。それが、組織のギャップを埋めるための最も確実な戦い方だと感じている。
コメント