課題解決の一般的なイメージ
日々のタスクをこなしながら、「もっと課題解決がしたい」と思っているエンジニアは多いと思います。言われた機能を作るだけでなく、チームやプロダクト、顧客が抱えている課題を自分の手で解決したい。この記事は、そう考えているメンバークラスのエンジニアに向けて書いています。この記事では、同じ会社やチームにいて、機能や作業を依頼する人を「依頼者」と呼びます。
ただ、「課題解決がしたい」と言ったとき、頭の中にある姿はどんなものでしょうか。多くの人は「課題を渡されて、それを解決する」姿を思い浮かべると思います。タスクをこなすのと同じように、誰かが課題を持ってきて、自分がそれを解決する。課題は最初からそこにあり、自分の仕事は解決の部分だ、というイメージです。
しかし、実際の課題解決はこのイメージとは違います。渡されるのは、ほとんどの場合、課題ではなく要望です。課題は、要望の奥から自分で定義する必要があります。
要望・ゴール・現状・課題の違い
この記事では、「要望」「ゴール」「現状」「課題」の4つの言葉を使い分けます。人によって意味がずれやすい言葉なので、先にこの記事での定義を示しておきます。以降の章は、すべてこの図の例で進める前提です。
図には入れていませんが、1つ補っておきます。現状だけでは、課題になりません。依頼者が2時間かけて報告書を作るのを当たり前だと思っていれば、それは課題ではなく日常です。ゴールを置いて初めて、現状との差が課題として見えます。だから課題とゴールは対になっていて、片方だけでは決まりません。
要望をそのまま実行する失敗
前の章の例で考えてみます。「CSV出力ボタンが欲しい」という要望を受けて、そのままCSV出力ボタンを作ったとします。実装は難しくないので、数日でリリースできるでしょう。依頼者も「ありがとう」と言ってくれるはずです。
ところが、しばらくして様子を見ると、依頼者は毎週CSVをダウンロードし、Excelに貼り付け、集計して報告書を作っています。転記の手間は減りましたが、集計はそのままで、報告書の作成には相変わらず2時間近くかかっています。ボタンはたしかに使われていますが、課題は残ったままです。こうなると、「やっぱり集計まで自動化してほしい」という次の要望が来て、結局もう一度作ることになります。
これが、要望を課題だと思い込んで実行してしまう失敗です。依頼者の言葉どおりに実装したので、作ったもの自体に間違いはありません。失敗なのは、課題を確かめずに作り、ボタンで課題が片づいたと思い込んだことです。
エンジニアがこの失敗に陥りやすいのには、理由があります。
- 要望は機能の形で来るので、そのまま実装に落とせてしまう
- 早く手を動かしたいので、聞き返す前に作り始めてしまう
- 「なぜ欲しいんですか」と聞くのは、依頼を疑っているようで気まずい
どれも実装者として自然な感覚ですが、この感覚のまま進むと、要望の奥にある課題を見ないまま手が動きます。
ここで一度言い切っておきます。要望に応えることは、課題解決ではありません。 要望は依頼者が考えた解決策の一つであり、その解決策で課題が解決するとは限らないからです。解決しない解決策をきれいに仕上げても、課題はなくなりません。
要望どおりで上手くいくケース
ここまで読むと、「でも、言われたとおりに作って上手くいったことも何度もある」と思う人がいるはずです。そのとおりで、要望をそのまま実行しても課題が解決することはあります。それは大きく2つのケースです。
要望が課題の解決策になっている
1つ目は、依頼者が自分で現状とゴールを把握していて、要望がその差を埋める解決策になっているケースです。依頼者が「報告書の作成に2時間かかっているのを10分にしたい」と分かったうえで、「集計まで自動化した週次レポートが欲しい」と要望を出してきた場合がこれに当たります。
依頼者が課題を定義する仕事を済ませているので、エンジニアが掘り下げなくても、要望どおりに作った結果として課題も解決します。
課題そのものが単純
2つ目は、課題そのものが単純なケースです。「このボタンの文言を直してほしい」のように、要望と課題の解決策の間にほとんど距離がない場合は、掘り下げても同じ答えにたどり着きます。この場合も、要望どおりに作った結果として課題は解決します。
上手くいった理由の取り違え
厄介なのは、この2つのケースがあるせいで、要望をそのまま実行する癖に気づきにくいことです。上手くいった経験が積み重なると、「要望に応えれば課題は解決する」と思うようになります。
しかし、上手くいったのは要望に応えたからではなく、要望が課題の解決策になっていたからです。要望が解決策になっているかどうかを確かめないまま同じやり方を続けると、なっていないケースに当たったときに前の章の失敗が起きます。
つまり、要望どおりで上手くいくかどうかは、要望を聞いただけでは分かりません。分かるのは、要望の奥にある課題を確かめてからです。
課題解決の流れ
課題解決は、次の5つの工程で進みます。図の番号と対応しています。
1. ゴールを引き出す
「なぜそれが欲しいのか」を自分で仮説を立てたうえで、依頼者には「これができたら、何が嬉しいですか？」と聞きます。返ってくるのは「週次報告を楽にしたい」のような粗い答えなので、「どうなったら楽になったと言えますか」と重ねて聞き、確かめられる形まで一緒に言葉にします。ゴールは、自分一人ではなく依頼者と決めるものです。
2. 現状をつかみ、差を課題にする
依頼者の作業を見せてもらって現状をつかみ、ゴールとの差を課題にします。ゴールと現状はどちらが先でもよく、行き来しながら決まるものです。
3. 依頼者と合意する
ゴールが決まると必要な解決策の規模も見えてきますが、その規模が依頼者の権限で決められる範囲を超えることは珍しくありません。この例でも、集計の自動化はCSVボタンよりずっと大きな開発です。
その場合は、課題とゴールを依頼者と一緒に、決められる人（依頼者の上司やプロダクトの責任者）のところへ持っていきます。メンバークラスのエンジニアの仕事は、決められる人に判断材料を渡すところまでです。ここで依頼者と合意しておかないと、依頼者から見れば「頼んだものと違うものを作ってきた」ことになります。
4. 解決策を決めて実行する
合意が取れて、ようやく解決策を決めて実行します。ゴールが「10分で終わる」なら、解決策は週次レポートの自動配信かもしれませんし、集計済みのデータを画面で見せるだけで足りるかもしれません。要望のCSVボタンは、候補の一つにすぎません。
5. 事実をもとに更新する
実行して終わりではありません。自動配信を始めてみたら依頼者は届いた数値をさらに手で加工していた、というように、想定と違う事実が見えてくることがあります。その事実をもとにゴール、現状、課題を更新します。この繰り返しが、課題解決の実態です。
こうして並べると、「解決」は4番目の工程で、その前に3つの工程があることが分かります。課題解決がしたいと思ったとき、やるべきことの大半は、解決の前にあります。
依頼を受けたときの最初の質問
ここまでの流れを、依頼を受けるたびに全部たどる必要はありません。文言の修正のように、要望がそのまま課題の解決策になっていると一目で分かる依頼は、聞かなくてもかまいません。それ以外の依頼で必要なのは、掘り下げるべきかどうかを、最初の時点で見分けることです。
そのために、依頼を受けたらまず1つだけ質問してみてください。
これができたら、何が嬉しいですか？
「なぜ必要なんですか」と聞くと依頼を疑っているように聞こえますが、「何が嬉しいか」なら依頼者はゴールを話しやすくなります。
答えは、だいたい次の3つに分かれます。
- ゴールと現状が言葉になっている（「報告書の作成に2時間かかっているのを10分にしたい」）
- 粗いゴールで止まっている（「週次報告が楽になる」）
- 曖昧なまま（「とりあえずあると便利」）
1つ目なら、次に、要望がその課題の解決策になっているかを確かめます。確かめ方は、要望を実行した後の状態がゴールを満たすかどうかを、頭の中でたどることです。CSV出力ボタンを作っても集計は残るので、ゴールの「10分で終わる」は満たしません。これは掘り下げる合図です。
同じ答えでも、要望が「集計まで自動化した週次レポート」なら満たすので、そのまま進めて問題ありません。
2つ目と3つ目は、ゴールも現状もまだ言葉になっていないので、要望が解決策になっているかどうかを確かめようがありません。CSV出力ボタンの例がこれで、「週次報告を楽にしたい」で止まっています。ここから先は、前の章の流れのとおりに、ゴールと現状を言葉にしていきます。
この質問は、依頼者との関係を変える効果もあります。この質問から始めて会話を重ねるうちに、依頼者は「この人は言ったものを作るだけでなく、ゴールを一緒に考えてくれる」と感じるようになります。課題解決がしたいと言うエンジニアが最初にできることは、この1つの質問を習慣にすることです。
70点でいい依頼、100点を狙う依頼
とはいえ、すべての要望にここまでの工程を踏む工数があるかというと、ありません。
勘を磨いたうえで、要望をそのまま対応しても70点が出せるなら、それでよい依頼もあります。一方で、業務の中心に関わる依頼は、そのまま対応して70点が出せるとしても、掘り下げて90点、100点を目指すべきです。
どの要望にどれだけ力を入れるかは、嗅覚を磨いたうえで、コストと天秤にかけて決めていくしかありません。工数は有限です。
- 影響範囲が小さく、目的も明確なら、そのまま実装する。
- 影響範囲が大きい、あるいは手戻りが高くつくなら、目的を掘り下げる。
- 目的が曖昧でも、低コストで試せるなら、小さく実装して反応を見る。
おわりに
課題解決は、要望に応えることではありません。要望を受け取り、ゴールと現状を言葉にして、その差を課題として定義し、依頼者と合意します。解決は、その後に来る最後の工程です。
最後に、最近受けた依頼を1つ思い出してみてください。その要望の奥にあった課題は何だったでしょうか。それは依頼者が定義して渡してくれたものだったでしょうか。それとも、自分で定義する必要があったものだったでしょうか。次に依頼を受けたとき、「これができたら、何が嬉しいですか？」と聞くところから始めてみてください。
参考にした本
この記事の考え方は、自分の経験と次の2冊をもとにしています。
『ライト、ついてますか』ドナルド・C・ゴース、G・M・ワインバーグ（共立出版）
記事の「要望を課題だと思い込む」は、この本の「相手の解決方法を問題の定義と取り違えるな」に当たります。要望は依頼者が考えた解決方法であって、問題そのものではない、という話です。また、この本は問題を「望まれた事柄と認識された事柄の相違」と定義しています。望まれた事柄がゴール、認識された事柄が現状で、その差が課題です。記事の「課題は現状とゴールの差」は、この定義をもとにしています。
『イシューからはじめよ』安宅和人（英治出版）
この本は、「問題を解く」より「問題を見極める」ことに力を注げ、と説いています。記事で「解決は最後の工程にすぎない」と書いたのは、この考え方に沿ったものです。「どの問題に取り組むべきか」の選び方に重点がある本なので、記事の「要望から課題を定義する」話を、もう一段上の視点から読み直したい人に向いています。