エンジニアの必須スキルというと、何が思い浮かぶでしょうか。
私は課題化能力だと思います。
課題化能力
そんなに難しい話ではありません。
1つの目的と、1つの事実から、課題を定義します。
例）
目標：ユーザーに商品を買わせたい
事実：ユーザーが商品ページに辿り着けていない
課題：ユーザーを商品ページに来てもらう
課題ができたら、解決のための調査をして、案をいくつか出します。
案が良さそうならその対応をします。
対応をした後に、課題が解決されているか確認します。
図にするとこうです。
確認は、課題に対して対応が即しているか、目的を満たしているかを主に見ます。
何てことはなく、チケット駆動開発や、デバッグ作業はまんまこれです。開発中はこれの連続と言っていいと思います。
なぜ重要か
上で言ったように、全ての基本の作業だからです。
恐らく多くのエンジニアはできて当たり前だと思っているでしょうが、世の中的にはそうではありません。このスキルが無くても勤まる仕事はたくさんあります。
しかしエンジニアの仕事はこれができないと勤まらないと思います（厳密に言えば勤まらないというより、良くない結果に繋がる）
勤まっていたら、誰か別の人が補助してくれているからかろうじて何とかなっているだけです。
逆にこれができるのであれば、今時点でどれだけ技術的に未熟だろうが、長い目で見たら邪魔にはならない存在だと思います。
課題化が上手い人、下手な人
世間に大勢いるエンジニアの中にも、この作業が不得手な人がたくさんいます。
（奇妙なことに、シニアクラスでさえ割りと居ます）
上手く行かないパターンとしては、例えば以下のような状態です。
課題化の時に、事実や目的からブレイクダウンできていません。
課題から遡っていくと、目的とは無関係な都合や、〜するべきという思想、事実などが絡まってよくわからないことになっています。
結果、行動の中心となるのは課題そのものです。これは適切な課題化とは言えません。その後の調査、対処、確認もよくわからないことになってしまいます。
何故このような事が起こるかと言えば
- 事実ベースで物事を見るのは難しい
- 限られた情報から適切な目的を見定めるのは難しい
- 目的・事実から適切に課題化するのは難しい
ということだと思います。
N事実：1目的：1課題
上手く課題化できているかどうかは、目的・事実・課題の構造でわかると思っています。
以下の状態が望ましいです。
事実1 があるが 目的A なので 課題はこれだ
事実2 があるが 目的A なので 課題はこれだ
事実3 があるが 目的A なので 課題はこれだ
よくない状態は以下です。
事実1 があるが 目的A なので 課題はこれだ
事実2 があるが 目的B なので 課題はこれだ
事実3 があるが 目的C なので 課題はこれだ
1事実 、1目的、1課題でいいのですが、説得力を増すためにN事実にしても問題ないと思います。しかしN目的にしてはいけません。
判断が非常に難しくなり、その後のフローに悪影響を及ぼします。
また、目的が複数あるパターンは、やはり悪い構造が隠れているケースが多いです。
（個人の都合、好み、宗教、先入観etc）
この構造を元に議論をしなければならない
実際の業務では、ステークホルダーや同僚と、この構造を元に議論をして仕事を進めなければなりません。
その時に、主張・認識の構造が複雑だと非常に厄介なことになります。「何言ってんのか分かんねー」って言われます（私もたまに言われます）
何故かと言えば、実際の業務ではもっと複雑なことになっているからです（下図）
複雑なことをシンプルにしたい時に、複雑さを増す行為は邪魔になります。
課題化が難しい理由
繰り返しになりますが。
課題化の難しさの1つは、目的を絞るところにあります。
目的とは「こうしたい」「こうあるべき」ですが、自ずと「誰が」「誰にとって」が必要になってきます。
「誰」を考えると、恐らくユーザー、我々、ステークホルダー、お客さんなどあがるはずですが、それぞれ一個ずつ考えて、競合する時は悩まなければなりません。
するとどんどん哲学的な話になるはずです。それが嫌なので多くのプロジェクトでは議論を避けがちになったり、他から丸パクリするはずです（悪くない手だと思います）
しかしフワッと決めれば決めるほど、コーディングレベルの階層でそれが分からなくなります。そこが難しい要因の一つです。
課題化が上手い人ほど、ふわっとして決まらない時にどうアクションするかの手段を持っていると思います。
課題化の難しさの2つ目が、事実ベースで考えるのが難しい点です。
どうしても先入観や、結論あり気に寄ってしまいます。これは意識して物事を見るしか無いのではないでしょうか。事実以外をとにかく排除するというのは、普通に生きているとあまりやらない行為です。訓練が必要だと思います。
最も混ざるのが思想、べき論です。「やるべきだったのにやらなかった」は思想です。「やらなかった」だけが事実です。これは大きく異なります。
課題化の難しさの3つ目は、事実と目的から課題を作るのが難しい点です。
例えば何か事故を想像してもらえればわかると思いますが、原因というのは幾らでも言うことができます。事故が起こらないためにできることは数多くあり、どれも正しいように見えます。課題というのは数珠つなぎのように連鎖しているものなのです。その中で、どれが最も適切で、効果的で、自分が取り組むべきことかを見定めるのはもう才能としか言えないと思います。
実はこれこそ大勢で知恵を出し合う部分です。適切な課題選択が需要です。
ですが、この基礎スキルが無いとその議論すらままなりません。
適切な課題化のメリット
適切な課題化ができると何かと良いことがあります。
- 目的がより鮮明になる
- 事実がより端的になる
- 課題を解決できるか、取り組むべきか一目瞭然
まあこれらは鶏が先か卵が先かみたいな状態ですけどね。
エンジニア採用に使おう
というわけで、このスキルはエンジニア採用の時によく見るべきだと考えています。
逆に、見られている部分であると思います。
何気ない雑談でも、その人にこのスキルがあるかは分かってしまいます。
例えば
「◯◯をしたんですよ」 に対して
「え、何故それをしたんですか？」 と言った時に
◯◯という目的があったが、◯◯という事実があったので、◯◯で解決した
みたいなエピソードが出てくると、私なんかはすごく安心します。
おまけ このスキルの利点
このスキルはエンジニアリングに必須ですが
何よりビジネスそのものに対して必須スキルです
これが上手いならエンジニア以外でもやっていけるでしょうし、昇進しても問題ないのではないかと思います
逆に下手ならずっと苦しむのではないかと思います（周囲も含め）
もし可能なら、自分で噛み砕いたあと相手に伝えたり、広めるスキルもあるといいですね。それができる人は世の中で非常に僅かに思えますが、話をシンプルに解決へ導いてくれるので頼られているイメージがあります。
