現場で起きている
最近、こんな相談を受けることが増えた。
- Agile 開発を取り入れた
- AI を積極的に活用している
- チームのモチベーションも高い
それなのに、経営的には全然楽にならない、という話だ。
基本的には、それらがドライブする改善が、
ビジネスモデルに結合されていないからである。Q.E.D.
さて、
だが、実際に現場に入ってみると、
誰もサボってないし、雰囲気も悪くない。
むしろ、よく頑張っている。みんな賢い。
ただ、よく見てみると、
- 重要な判断がずっと保留されたまま
- 影響を測る指標がなく、良くなっているのか分からない
- Retro はしているが、学習が次に接続されていない
しかし、それがその現場では合理的となっており、
しかも、まずいことになっていることに誰も気づいていない。
指摘しても、「分かるけど、とは言え…」である。
どの現場にも事情がある。事情が。
多くの場合、「不確実性」がなくなることはない。
不確実な状況で、どのように判断可能性を回復するかに
外部の一歩引いた立場で、介入するのが私の役割だ。
同じ LLM モデルの回答が揺れる理由
かつて、教えて君に対して、ｸﾞｸﾞﾚｶｽ (ggrks) と言っていた時代がある。
自分で検索してから質問しろということだ。
現代では、うまい言葉が思いつかないが、
AI に聞けと言いたくなる場面が多々ある。
何言語で書かれたどんなソフトウェアか分からないようなものの
局所的なログだけ見せられても困る…と思うものの、
何か手がかりがないか、より状況を把握するためにはどんな情報が必要か
ChatGPT に相談してみると、ちゃんとした回答が返ってくる。
分かりやすくまとめて返信すると、
「ありがとう。ChatGPT ではそこまで教えてくれなかった。」
などと感謝される。
彼はちゃんと ChatGPT に聞いていたのだ。
なんなら Gemini にも聞いていた。彼は自主的に考えることを放棄していない。
ここで疑問が湧き上がる。
「同じモデルなのに、なぜ差が出るのか？」
私の ChatGPT とあなたの ChatGPT は学習度合いが違うからという話ではない。
多くの場合、理由はシンプルだ。
- 前提
- 制約
- 変えてはいけないもの
そういったコンテクストが与えられているかどうかが違う。
AI は優秀だが（特に今年の11月以降凄まじいが）、
それでも、「与えられた前提の中」でしか判断できない。
そしてこれは、人間の意思決定とほとんど同じ構造をしている。
「決めない」は、いつから問題になるのか
Agile 開発では、不確実性を前提に「後で決める」判断が合理化される。
- 仕様は変わる
- 将来は読めない
- 今は動かしたい
この判断自体は、間違っていない。合理的である。
問題は、
「将来を決めないこと」と「今、最低限決めること」が区別されないまま進む点にある。
Agile 開発は「決めなくても良い」のではなく、
「不確実性を前提に、今決めることを限定する（減らす）」のである。
「要件がふわっとしているから Agile でやりたい」といった
いわゆる「PO が決められないから Agile」をイヤと言うほど見てきた。
相談を受ける立場としては、「お前はもう、◯んでいる」と言いたくなるし、
チームの立場では、「PO が責務を果たしていない」と批判したくなる。
が、これは現場目線であり、PO には彼らなりの決められない事情があるのである。
事情が。
ステークホルダーが多い案件などでは特に、PO が一人で決められることは稀で、
「今、決める」のスピード感が合わず、決定が先送りにされがちである。
このようして、このような状況が一般化することになる。
そして、
決められていない前提は、消えるわけではない。
多くの場合、コードに埋め込まれる。
決定の空白が生むもの
未決定のまま進められた実装は、次第にこうなる。
- 仕様の「正」がコード断片に散らばる
- 暫定が恒久化する
- 誰も「どこまで変えていいか」を説明できなくなる
結果として、
- 触るのが怖い
- 変えると壊れそう
- だから決めない
という負のループが完成する。
これは誰かの怠慢ではない。
合理的な選択の積み重ねが、構造として固定化した結果だ。
AI は原因ではなく、増幅器
AI の導入により、この力学はさらに強まる。
- 前提が曖昧でも実装は進む
- 動いている限り問題は見えない
- 仮定や前提は短時間で固定化される
AI は間違っているわけではない。AI には AI の事情がある。
与えられたコンテクストの中で全力を尽くしている。
ただ、未決定な状態を高速に増幅する。
Agile 開発に限らず、
- AI は、新規案件なら良いけど保守案件ではまだ使えるレベルにない
- AI の書いたソフトウェアは、メンテナンスできる気がしない
- AI の書いたコードで PR したら、レビュワーに迷惑をかけた
- AI 協業時代に求められるのは、エキスパートだけ
的な議論は、プロジェクトの未確定な前提のみならず、チームの知識量や経験の差が
人間には吸収できない程に AI によって増幅された結果とも言える。
だからこそ、
使う人間側の判断構造がより重要になる。
これは「失敗」ではなく、名前のない状態だった
こうした状態は、
個別のトラブルとして扱われがちだ。
しかし、見てきた限り、
同じ力学は何度も繰り返される。
同じ現場でも、違う現場でも。
この構造を、
Decision-less Agility と呼ぶことにした。
名前が付くと、
初めて「これは今どの状態なのか」を
チームで話せるようになる。
再現性のある状況に名前が付くと、
初めて「判断」や「対話」が可能になる。
たかが名前、されど名前。
続きは Web で…()
こうした壊れ方を、個別の失敗ではなく
繰り返し現れる構造として整理したものを「Failure Patterns」としてまとめた。
（Alexander 的、Coplien 的）Pattern Language である！！
この記事は、その中の一例にすぎない。
日本は年末でギアが下がっているが、
ベトナムはまだ年末じゃないことで生まれた余力を使って
- 脱「Agile 開発に詳しいおじさん」
- 脱「経験を言語化できない感覚おじさん」
を果たすべく、気合いを入れてまとめた。
この取り組みでは、具体的な解決手順を示さない。
状況を構造として捉えるための言葉と枠組み を示すのみだ。
犯人探しも魔女狩りもしない。
無理に理解する必要はない。
ただ、「あー、これあるわー」と思ったなら、
きっとどこかで役に立つ。
え？具体的な解決方法？？
AI に聞け、ｶｽ（お仕事のご相談お待ちしてます笑）
Merry Christmas & Happy New Year!
Have a nice holidays!!