第2章で、目的を明確にして必要なところから学ぶのが効率が良いと学びました。第3章で、理解を深めるうえで、実際に何かを作ることで理解を検証しながら進むのがよいと学びました。
しかし「何を学べばよいかがわからない」「作って学ぼうにも、何を作ればよいかがわからない」──そういう悩みをお持ちの方も多いかと思います。本章ではその悩みをどうやって解決するかを学びます。
やれと言われたことをやる
「何を学べばよいかがわからない」と言う人は多いですが、その人が何も学んでいないかと言うと、そうではないように思います。たとえば会社や上司から何らかの勉強を要求されて、行っているはずです。ただ、おそらくその勉強は第1章で解説した「応用対象」軸なのでしょう。「応用対象」軸の知識は社外に露出しにくい特徴があるため、たとえば勉強会や雑誌の記事などで露出しているエンジニアと自分を比べたときに、自分が勉強していないように思って不安になるのです。
「言われたことをやる」というのは、格好悪いことに思うかもしれません、しかし、あなたが会社組織に属している場合、会社はあなたがなるべく早く戦力になることを期待して、何を学ばせるかを決めているはずです。自分で学ぶ対象を決められないのであれば、まずは会社の判断に従うことは有効な選択肢です。
残念ながら、世の中には社員の成長に興味がない会社もあるようです。その状況をどうすればよいかについて解説するのは筆者には荷が重いです。その会社だけに属している状況は一種のロックインですから、勉強会などでほかの会社の人と交流するとよいのではないかと思います。
他人の真似をする
あこがれのエンジニアや上司、先輩がいるのであれば、その人の真似をするのも一つの選択肢でしょう。
ただし「Xを学ぶことが大事」という発言を真に受けてXを勉強するのはちょっと待ってください。発言ではなく、行動を見ましょう。世の中には「Xを学ぶことが大事か自信が持てない」という自分をごまかすために「Xを学ぶことが大事」と叫ぶ人がいます。その人が本当に学んでいるのか、具体的に何をやって、どういう成果を出したのかを見ましょう。Xを学ぶことは手段であって、目的ではないはずです。しかし手段と目的が入れ替わって、Xを学ぶことが目的になってしまうことが多いです。
少し未来のことを見てみましょう。図1は先輩Aさんの真似を続けたBさんの知識の分布です。CさんはBさんと同じ程度の知識を持っています。Bさんの知識はAさんの部分集合です。ということは、BさんはAさんに何も与えることができません。一方CさんはAさんが知らないことを知っています。AさんとCさんはお互いに与え合うことができるわけです。Aさんにとって、付き合う価値が高いのはどちらでしょうか？[1]
図1 BさんはAさんに何も与えられない。Cさんは与えられる
このありがちな罠を避ければ、周囲の人の真似をするのは割と有効な選択肢です。
「解決すべき問題」を見つける
やはり「作って学ぶ」が最強です。しかし何を作ればよいのでしょうか？ それを決められないのは、第3軸「応用対象」軸の知識が不足しているからです。選択肢を考える材料が足りないのです。まずはこの軸を意識して、情報収集することから始めてはどうでしょうか？
なぜ学ぶのでしょう。それは「何かをより良い状態にするため」のはずです。だから「より良い状態にするべきもの」を見つける必要があります。それは技術的な「製品のこのコードが遅いのを解決したい」かもしれませんし、人生設計の「もっと年収を上げたい」かもしれません。まずはここを具体化することを目指しましょう。
顧客は誰か
まず、あなたの顧客は誰ですか？ あなたが学ぶことで誰を幸せにしたいのですか？
あなた自身を幸せにしたい、つまり「自分が顧客」というのもありです。困っている同僚を助けたい、つまり「同僚が顧客」もありです。自分の会社が作っているソフトウェアのユーザを幸せにしたい、つまり「ユーザが顧客」もありです。「上司が顧客」も「家族が顧客」も「趣味のサークル仲間が顧客」もありです。
どれか1つを選ばなければいけないわけではありません。しかし、自分も喜ばず、他人も喜ばないような学びは、本当にそれが必要なのか疑ったほうがよいでしょうね。
顧客の欲求と問題を理解する
顧客が明確化されたら、次はその顧客がどんな欲求を持っているか、情報を収集します。
とはいえ「何が望みですか？」と言葉で聞いても、適切な答えが返ってくるとは限りません。「自分が何を求めているのか」を顧客がうまく言語化できないこともあるからです。彼らが何を求めているのか、どういう問題を抱えているのかを、あなたが観察して発見することが必要です。
見つかった欲求や問題に簡単な解決方法があるとは限りませんから、最初に見つかった1つにのめり込むのではなく、まずはたくさん収集するほうがよいでしょう。
成果を出すための3つのチャンス
知識を応用して成果を出すためのチャンスとしては、大きなものが3つあります。これを目標設定に使ってみましょう[2]。
予期せぬ成功
顧客に評価されると思っていなかったものが、見せてみると意外と評価されることがあります。たとえば、自分自身が「ないと不便だ」と思って作ったツールを考えてみましょう。「自分自身が顧客」なので、他人が評価するかどうか関係なく、自分が作りたいように作りますよね。これを、他人に見せてみると、意外と「こういうものが欲しかったんだ！」と言われることがあります。これはチャンスです。
ただし、このチャンスが発生するためには3つの条件があります。まず何かを作っていること、それが他人に評価されると思っていないこと、それでも他人に見せていること、の3つす。いろいろなことにチャレンジしていることが必要なわけです[3]。
予期せぬ失敗
逆に「これは評価されるだろう」と思って作ったのに、評価されなかった場合もあります。たとえば「顧客はきっとこれを評価するはずだ」と思い込んでいると、作ったものを実際に顧客がちっとも評価しないことがあります。
「これは失敗だ、別のことをやろう」では学びが深まりません。成功すると思ったのに失敗したということは、あなたの「世界の振る舞いの理解」と実際の「世界の振る舞い」に何か違いがあるということです。その違いは何でしょうか？ 違いを見つけることができれば、それは次のチャレンジの助けになります。
たとえ事前に顧客に「どんなものが欲しいのか」を聞いていたとしても、作ってみせると「うーん、こうじゃないんだよなぁ」などと言われることがあります。人間のコミュニケーションには失敗がつきもので、顧客が彼らのニーズを適切に言語化していないかもしれないし、あなたが言語化されたものを適切に理解できていないかもしれません。
失敗の原因を理解することを次の目標にしましょう。
顧客の問題
「予期せぬこと」が起こっていない場合、そもそもあなたが顧客のモデルを自分の中に持っておらず、何も「予期」できていないことが考えられます。第3章で学んだように「このプログラムを動かすと何が起きるか？」という質問に対して、プログラミング言語のモデルを持っている人は正解不正解は別として何らかの答えを出すことができますが、モデルを持たない人は答えることができません。顧客のモデルについても同じです。
顧客のモデルを作るために、情報を収集し、抽象化を行う必要があります。特に「顧客の抱えている問題」のモデルが重要です。顧客を観察して、彼らの抱えている問題を発見しましょう。そのモデルに関連しそうな情報を収集しましょう。たとえば、彼らの作業の中で一番手間取っているところはどこだろう？一番失敗の可能性が高いところはどこだろう？ 彼らが一番不安に思っているところはどこだろう？ この問いの答えを探すのです。
完璧を求めない
ここまでの説明を読んでも、まだ何をするかを決められないのですか？ それは、失敗や変更を許さない「完璧主義」が邪魔をしているのかもしれません。
「何を学ぶべきか」に完璧な正解はありません。それなのに、最初から完璧な正解を求めて、それがわからないせいで行動できなくなる人がいます。足踏みしていても何も変わりません。まずは一歩踏み出してみましょう。進んでみて駄目だと思ったら方針転換すればよいのです。「移り気な自分」を受け入れることです。
いくつかの選択肢があって、どれが良いかがわからないのであれば、それはあなたの今の知識では全部同等の価値があるということです。足踏みをしていたのではどれも手に入りません。コインを投げて決めてもよいのです。とにかく進むことです。
行動して、一歩進むことで、新しいものが見えるようになります。より一層、よくわかるようになります。
おわりに
本章では「何を学ぶか・何を作るか」という悩みについて、決めるうえでの糸口をいくつか提案しました。「何を学ぶか」は「限られた時間で何を学ぶか」であり、最大限の成果を得るために限られたリソースをどう配分するか、という経営学の課題です。また「何を作るか」は「誰に対して価値を提供するために何を作るか」であり、顧客の欲求を理解しようというマーケティングの課題です。「何のために？」（why）の質問を繰り返していくと、抽象度が上がっていって、異なる分野との融合が起きるようです。
本特集の最後に
本特集では、筆者がどのような「学び」のモデルを作っているのかを文章の形で出力しました。この企画は、拙著『コーディングを支える技術』の余白を埋めるために書いたコラムが予想以上に好評だったこと、つまり「予期せぬ成功」がきっかけになって始まりました。
この出力を読んで、みなさんはどう思われたでしょうか？ もし疑問や違和感がありましたら、ぜひフィードバックいただけるとありがたいです。筆者のモデルが改善されますし、みなさんのモデルもアウトプットと結果の観測をすることで改善されます。
この原稿をレビューして、筆者と議論してくださった中山心太氏に感謝します。
