あなたが見るべきは解決策ではない
久富徹先日、近所の馴染みの店に行ったところ、オーナーがこのようなことを話していました。曰く
飲みに行った店が1500円で3杯飲めるチケットを売っていた。通常営業時間前に1時間早めに開けて、チケットを買ってもらい、すぐに作れる3杯を提供している。お腹が空いた人には1杯分のチケットでちょっとしたおかずを選ぶことができる。これはいいな、と思った。自分の店にも導入したい。
ということで、これは新しい取り組みをやりたいと言うことなのだな、ということは分かりましたが、この取り組みをやることで何を改善したいのかが私には分かりませんでした。例えば、
- 自分の店になぜ客が来ないのか
- 自分の店はどの時間帯が空いているのか
- 自分の店に誰を呼び込みたいのか
- 自分の店でこの取り組みをやって利益は出るのか
などが考えられていないようでした。
皆様お気付きのことかと思いますが、「通常営業時間前に一時間早めに開けて、チケット制で3杯だけ提供する」目的は
- 土地や設備の稼働率向上
- 通常営業時間より早い時間から安く飲みたい見込み客へのアプローチ
- 粗利の向上
などが挙げられます。ひっくり返すことでどういう課題を解決しようとしているかが明確になります。
- 1日6時間の営業であれば、支払っている家賃のうち1/4しか売り上げに貢献していない。固定費が売り上げに占める割合が高すぎる。
- 早い時間に軽く飲みたい人にとって、今の営業時間や価格帯が合っていない。
- レギュラーメニューのフードは、原価が高く調理にも時間がかかる。粗利を圧迫するし、限られた時間で多くの顧客にフードを提供することができない。
つまり、1500円でチケットを3杯売ることは、飲み屋の経営者にとって課題ではなく解決策の一つに過ぎません。
私が専門にしているソフトウェア開発のプロジェクトでも同じようなことを見聞きします。例えば、「AIにコーディングを任せて爆速にしたい、なぜなら今の開発速度では他社に負けてしまうからだ」という課題設定をしたとします。このようなプロジェクトに携わってみると、本当の課題は
- 要件がなかなか固まらない
- 現場が意思決定できず、すべてにおいて上位レイヤー（時には経営層）の承認が必要
- レビューが遅い
- テストが不足している
- ドキュメントがない
など、リリース可能な状態になるまでのリードタイムを引き延ばす課題が多数積み上げられていたりします。例えば「要件がなかなか固まらない」というプロジェクトにClaude Codeを導入したらどうなるでしょうか。間違ったもの（あるいは正しいのか間違っているのかすら不明瞭なもの）を今までより速く多く作ることになります。レビューするシニアエンジニアが詰まっているところに大量のPRが出たら、レビューの精度はむしろ落ちて技術負債が積み上がるか、シニアエンジニアが旅に出てしまうことでしょう。また、リリース頻度、リードタイム、PR滞留時間、バグ修正時間などを計測していないプロジェクトでは、AIを導入して「何がどう変わったのか」を説明することができないでしょう。繰り返しの説明になりますが、課題が何かを知らずして解決策を導入することはできません。
プロジェクトマネージャーが考えるべきは、
- まず現状を知る「類似機能を作る速度は競合他社と自社でどれぐらい違うのか」
- 現状をもたらしている原因を知る「自社の開発速度を下げている原因は何か」
- 原因を引き起こしている要素を特定する。「その原因の真因は何か」
です。最後に特定した「真因」こそがプロジェクトマネージャーが解くべき「課題」です。これが正しく特定できてからようやくHOW、つまり解決策を考えることができます。Claude Codeを導入することも、1500円で3杯飲めるチケットを売ることも、それ自体は悪い施策ではありません。問題は、それが何を解決するための施策なのかを見失うことです。プロジェクトを前に進めるために必要なのは、流行の解決策を持ち込むことではありません。まず、解くべき問題を正しく定義することです。