エンジニアとして必須の最小スキル：課題化能力
エンジニアの必須スキルというと、何が思い浮かぶでしょうか。
私は課題化能力だと思います。
課題化能力
そんなに難しい話ではありません。
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つ目は、事実と目的から課題を作るのが難しい点です。
例えば何か事故を想像してもらえればわかると思いますが、原因というのは幾らでも言うことができます。事故が起こらないためにできることは数多くあり、どれも正しいように見えます。課題というのは数珠つなぎのように連鎖しているものなのです。その中で、どれが最も適切で、効果的で、自分が取り組むべきことかを見定めるのはもう才能としか言えないと思います。
実はこれこそ大勢で知恵を出し合う部分です。適切な課題選択が需要です。
ですが、この基礎スキルが無いとその議論すらままなりません。
適切な課題化のメリット
適切な課題化ができると何かと良いことがあります。
- 目的がより鮮明になる
- 事実がより端的になる
- 課題を解決できるか、取り組むべきか一目瞭然
まあこれらは鶏が先か卵が先かみたいな状態ですけどね。
エンジニア採用に使おう
というわけで、このスキルはエンジニア採用の時によく見るべきだと考えています。
逆に、見られている部分であると思います。
何気ない雑談でも、その人にこのスキルがあるかは分かってしまいます。
例えば
「◯◯をしたんですよ」 に対して
「え、何故それをしたんですか？」 と言った時に
◯◯という目的があったが、◯◯という事実があったので、◯◯で解決した
みたいなエピソードが出てくると、私なんかはすごく安心します。
おまけ このスキルの利点
このスキルはエンジニアリングに必須ですが
何よりビジネスそのものに対して必須スキルです
これが上手いならエンジニア以外でもやっていけるでしょうし、昇進しても問題ないのではないかと思います
逆に下手ならずっと苦しむのではないかと思います（周囲も含め）
もし可能なら、自分で噛み砕いたあと相手に伝えたり、広めるスキルもあるといいですね。それができる人は世の中で非常に僅かに思えますが、話をシンプルに解決へ導いてくれるので頼られているイメージがあります。
Birchbox、こう考えた
同僚とサービス分析の勉強会をやったのですが、個人的に考えた部分をメモ程度にまとめます。
私ならこう考える、みたいなものです。
注意：今回は考察が浅いです（約2時間）
参考資料
Beauty Box Subscription for Women
『オンライン→実店舗』がNYのマーケティングトレンド : NY で デトックス
何の会社？
化粧品の試供品を定期購買してもらうサービス
あとEC
数字とか
2009年からスタート
シリーズA 2011年 10億円くらい
シリーズB 2014年 60億円くらい
2016年 72億円くらい
2015年9月 100万人ユーザー 300人従業員
2016年1月 スタッフ15％削減
感想
毎月10ドルで試供品を配布する、5ドルがクーポンになる。
ってそれ送料考えたら売上ゼロなんじゃないでしょうか。どう考えても安すぎます。
ひょっとして調達だけで回したタイプのアメリカ型企業？2016年にガタが来てるのでありえますね。
結構話題になったらしく、類似サービスが日本にも多いですが1500円/月とかでした、やっぱ5ドルは安すぎです。
ドモホルンリンクルを思い出しました。ああいう「試供品を配りたい」という化粧品メーカーを取りまとめたサービスですね。
サービスを考える時に、「似たような戦略を取ってる会社を一本化する」というのは着想としてありだと思います。
化粧品のサブスクリプションという市場は良いなーと思いました。
何よりパイが巨大です。その分プレイヤーも多いのは確かですが。
日本国内の市場規模は調べたら2.5兆円と出てきました。
化粧品に対する月平均購入額は2500円程度。年齡によってさほど増減しないのは意外です。日本においては20代女性も40代女性も自由になるお金が大差ないということかもしれません（未調査）
2500円/月*約3000万人=9000億円/年
アメリカだとざっくりこれの3倍ですかね。
ビジネスモデル
試供品だから仕入れが安いだろう理論ですね。なぜか検索すると定期購買との比較が出てきますが、ちょっと違うのでは。
文脈としてはアウトレットに近いと思います。刺さったのもミレニアム世代ということで、お金がない層にウケてますね。
アウトレット、試供品ビジネス
そもそも「お試し」というものは、商品の使い始めのハードルを低くする戦略ですね。なので、継続利用してもらわないといけません。
このサービスもハードルを低くするという点で軽商品メーカーからウケると思います。しかし思うように継続利用に流せているサービスは少ないのではないでしょうか。Birchboxの売上高をみると、試供品定期購買分の売上がほとんどのようです。ECサイトはいずこ？
考えるに、アウトレットや試供品というのが安さ文脈に乗っかってしまっているせいかもしれませんね。安さを求める客が定額のものを買うかという話です。（ここらへんは妄想ですが）アウトレットも、アウトレットと銘打って実はアウトレットではない店が多いと聞きました。安さの代名詞になってしまっています。難しいですね。
とは言っても化粧品のような非耐性消費財は、何にせよ買わないといけないのでそこを握れていないのは妙な感じがします。AmazonDashのような文脈で上手いことできないのでしょうか。まだ知らないことがありそうです。
理想と現実のギャップ
毎月新作をアップし続けるのもなかなか難しいようです。そして、目新しい商品を出すと既存の方をカニバリますよね。初手からカニバリを内在したサービスは難しそうです。
あとこういったサービスをやると、ユーザーの感想などの情報を化粧品メーカー側に上げたくなりますが、ぶっちゃけそこら辺は化粧品メーカー側で既にやってるんじゃないでしょうか？「確かにそれはすごいね、でももうやってるから要らないよ」だと思います。こういうのあるから怖いです。そういうのはデータの質も問われるので、案外データを売る商売は頓挫します。研究職を舐めちゃいけません。
ユーザー数は落ちたものの価値はある
同サービスは2016年に5ドルクーポンをやめ実質値上げになりユーザーが離れたらしいですが、ネガティブなネットワーク効果は別に生まれない構造になっているので、残るユーザーも居るようですね。
100万人のユーザーが例え50万人になっても十分だと思います。
化粧品メーカーからしてみれば数十万人の見込み客へのアプローチ手段ですから無視できないわけで、ユーザーを大量に抱えた時点で勝ちですよね。
真似できるか
ただ同サービスを丸ごとパクる場合には注意が必要で、競合が居る前提で数万人のユーザーを作れるかという難しい話になりそうです。
そんなのもう無いでしょ？と思うんですが。
もしくは正々堂々殴り合うしかないですね。そういうのは大企業におまかせしましょう。
真似したいか
小売こわい
あと、ECに繋げられないとどうしても「試供品配るだけ」に思えてしまいます。既に世の中にたくさんあります。もちろんシステム化されていないのでシステム化要求は時代の要求としてあるでしょうけど、それだけでやるかと言われればモチベ弱いです。
たぶん、その商品がとにかく好きとか、新作見るのがたまらないとか、そういうワイワイやるのが好きな人はやってて楽しいのではないでしょうか。
よくよく考えたら週刊漫画とかもこの文脈に近いのかもしれません。モノ次第？
注目ポイント
おそらく創業者（既に退職）は上記のような現実を早々に理解したのではないかと思いました。それで調達しまくってとにかくユーザーを増やし、チャネルを作ってしまったのではないかと思います。
化粧品メーカー側とユーザー側、どちらのチャネルを作るのが大変かと言えばユーザー側だし、リテンションが物を言うタイプですから。
しかし新たな世代を取りこぼす可能性もあるので、そこは注意が必要な気がします。圧倒的優位なのは確かでしょうけど。
また何か気づいたら書きます。
ソースコードの引き継ぎ改修案件が難しい理由
ここ3年くらいで何度か体験したことです。
条件としてはこういう状態です。
- 既に完了しているプロジェクトの追加改修
- プログラマーはもう居ない
- 仕様書はほぼ無い
- 完成したのが2年前とか
よくある話ですね。
こういう「ちょっと変えて欲しい」案件を、別に私は軽く見ていたつもりはなかったのですが、想像以上に上振れることがわかりました。
大体想像の30〜40％増のバッファで見積もるのですが、現実は80％〜300％という感じです。
原因は少し複雑です。
前提として大きいのは、引き継いだコードの質が自分のものより下であることです。
それだと「場合に依る」と思えるでしょうけど、意外と（？）十中八九自分より不出来であることが多いです（私が特別優秀というわけではなく）
理由はたぶんこうです
- きちんとしたコードを書くようなプロジェクトでは、どこの馬の骨とも知らない人に引き継がせないし、最低限プロジェクト内にエンジニアが居ないみたいな状況にならない
- 2,3年前だと皆レベルが低いみたいな状況がある（黎明期問題）
- バージョンが上がりすぎていて、非推奨なコードになってしまっている
- 外注の新規開発したコードって大抵クソですよ（元も子もない）
コードの品質やらなんやらがひどい場合。修正箇所を直そうとしている内にバグや潜在バグをポロポロと見つけてしまいます。もちろん直そうとはしないのですが、コードが密結合になってるとどうしてもそこを触らなければならなくなってきます。
そういったコードは、例えば既に顕在化していたり、それなりに重いバグならクライアントに交渉できますが、そうではないケースがあります。潜在していたり、凄く小さいものだったりします。すると交渉する方が大変で、勝手に直すほうが早くなってしまいます。
完全に放置する手もありますが、それを直さないと目的の改修ができないことがありますし、検収時にバグが再現されてしまうと自分の責任を問われます。最低限、説明が求められてしまいます。どっちにしても時間が取られてしまうわけです。
この「ちょっとしたバグ」が、密結合によりどこまでも連鎖していくパターンが結構あります。1個バグを潰したら3つバグが誕生するやつです。
すると今度は、整合性を取るために若干のリファクタが必要になってきます。糞真面目ほど、それは無視できなくなりますし、やはりクライアントにリファクタの説明をするのは非常に高コストです。
とやってる内に、1行直せばいいところがいつの間にか30行に、みたいなことがままあります。
厄介なのは
- やってみないとどれだけ量があるかわからない（連鎖するから）
- 一件一件が非常に小さいため、説明する手間のほうが大きい
あたりでしょうか。
たまたま自分の出会った案件がそうだったのだ、と最初は思ったのですが、最近はこちらの方がデフォルトだと考えるようになりました。それほど高確率で上振れます。
これの対策が見つかりません。
上記で書いたように、説明しようが追加料金を求めようが手間のほうが上回ります。「全力で不具合を無視する」という発想が出てきそうですが、不具合を無視したら修正タスクが終わらない状態になるのです。
回避するにはそもそも時間単位での仕事にしてしまうか、バッファを数倍レベルで盛るくらいでしょうか。
（反面教師じゃないですが、自分で一から作る際は密結合を頑張って回避しますし、資料を何かしら残します）
まとめ
ちょっと修正する程度の保守単発案件は死ぬほどおいしくないです。
実際そういう案件を拒否している会社もちらほら見かけます。
やるとしても、それなりに大きい案件を選ぶか、時間単位での仕事にするべきだと思います。
その時も、見積もりはかなり盛ったほうがいいと思います。
新技術とどう向き合うか、どのフェーズで戦う人材になるか
ガートナーのハイプサイクルというのは有名だと思います。
ガートナー | プレス・リリース | ガートナー、「先進テクノロジのハイプ・サイクル：2017年」を発表
新技術が世に生み出される時、一旦過度な期待を経るという経験則に基づいて、現在存在する新技術がどこのフェーズに居るかというものを分析したものです。
エンジニア、特にWeb系のような場所にいると、新技術とは向き合わなければならなくなりますが、どのフェーズで戦うかで戦略が大分変わりそうだと思いました。
※新技術というと特殊なものに感じますが、言語やフレームワークでも似た現象が起こると思います（少し緩やかになるでしょうけど）
安定期で戦う
多くの人は安定期で戦います。
既に市場が確率されていて、第一人者が居て、先輩が居ます。
将来のキャリアパスもある程度見えていて、見えているからこそ将来安泰か、不安かもわかります。
上がつっかえているため、イニシアチブを取るのは難しいかもしれません。
給料は適正価格に落ち着いていますが、徐々に安売りが始まるはずです。
いつまでその技術で食っていくのか、よく考えなければなりません。
期待のピーク前後で戦う
技術者としては非常につらい状況です。
世間や上司、クライアントの期待値は非常に高いのに、思った成果が出ることは稀です。
毎日胃が痛くなることは間違いないでしょう。
しかし、世間の注目度は高く、予算をジャブジャブ使える時期でもあります。
普段はやれないような派手で夢のある案件に絡めるかもしれません。
その上、世間のエンジニアからも羨望の眼差しで見られます。
やりがいもあるかもしれません。
しかしこのフェーズで戦うためには、その少し前から勉強を始め、追いつき、日々更新される技術刷新に対応していかなければなりません。地頭の良さとタフネス、スピード感が必要です。
幻滅期〜啓蒙活動期で戦う
実は一番美味しいのではないかと思うのがここです。
既に多くの人が安定期の職を持っています。そしてピーク専門の人は去りました。
残るのは頭の痛い課題だけです。
取り組みたいという人は少ないでしょう。
しかし、もしそれが仕事にできるのなら、イニシアチブを取るチャンスです。
頑張って少し勉強するだけで、ベテラン扱いされます。
責任も重いのですが、成功ライン・失敗ラインが業界的にまだふわっとしているので、評価できる人も居ない状況です。
これを3年〜5年続けられれば、運が良ければ良いポジションと知見が得られるでしょう。
世間的には必要な技術なのに、3年以上取り組んでいる人が滅多に居ない状況で、それゆえに引く手数多になるかもしれません。
黎明期で戦う
もはやこれは研究職に近いです。
旨味とか狙ってはいけない領域です。あくまでその技術自体に可能性を見出して取り組むものだと思います。
もし期待のピークまで到達できれば、ちやほやされるかもしれませんがその後幻滅期が確実に来ます。
そういった周りの雑音の無視しつつも、技術の価値を世間に伝え、どれだけ真の仲間を集められるかという状況に成ってきそうです。
とは言え、殆どの技術は日の目を見ずに地下に潜り続けるでしょうから、やはり学術的な研究に近い作業ですね。
まとめ
と言ったように、同じ技術でもどのフェーズで戦う人かによって、価値観や戦略がガラッと変わってきます。性格まで違うかもしれません。例えばピークにいる人達は、盛り上がってる方に近寄っていきます。
フェーズが違うと話が通じないこともあるでしょう。フェーズが違う会社に転職したりすると、あまりに違う雰囲気で困惑することも多いと思います。
まずは自分がどこに住み着きたいか意識して、相手や周囲はどこを意識しているのか、よく観察したほうが何かと良いと思います。
技術でベンチャー企業を立ち上げる時は、特にこれが重要になるでしょう。
最初に入ってくる人と、安定してから入ってくる人の性格がガラッと変わってしまいます。会社はどのポジションを中心に据えるのか、あるいは全フェーズを内在するのか、考えていかないと価値観に依るすれ違いが起こってしまいます（経験あり）
自分のセンスの無さに苛つく
もうかれこれ１年以上、独自アプリを作っているのですが。
未だに仕様を作るのが苦手です。
ほとんどを自分で作っていると気がつくのですが、自由度が高すぎると変数が多くなり、決められなくなるのだと思います。
「とりあえず動く」まではいくが、「なんか違う」がずーっと残り続ける感じです。
そして自由度があるので、変えようと思えば変えられてしまうのです。
最初はそういうのを無視してMVPで作ろうなんて思っていましたが、「変えられる」というのは呪いのようについてきます。どうしても「もっとこうした方が」に思考が奪われてしまうのです。
そして何より、圧倒的にセンスが無いことも問題です。
これは覚えがあります。美的センスに似たものです。
例えば家具の配置、服の色、適切なモノを適切な場所に効果的に配置する作業というものが壊滅的に苦手です。
それだからか、画面の構成をいつまでもウンウン悩んでしまいますし、作ったはいいが明らかにダサいオブジェをこさえてしまいます（目だけ肥えている）。
デザイナーをアサインすれば、とも思うのですが（一時期していましたが）
人を増やすと今度は人のコントロールをしながらプロダクトのコントロールをする必要が出てきます。おまけに開発も必要です。自分のセンスが無いと、どうしても意思決定が鈍る気がします（熟練デザイナーであればそれも良いようにしてくれるんですけどね）
どうやら私はそういったマルチタスクが非常に苦手なようです。
これまで見てきた、ワイヤーをさらっと作り上げてしまうディレクターやクライアントが眩しく見えます。
世にあるどのUIも非常に素晴らしいものに見えてきます。
解決策はあまり多くありません。
今は「センスとか問われないくらいに定石を覚え、パクリ、考え続ける」くらいでしょうか。
量をこなすしかありません。
あるいは、デザイナーではなくとも他人の意見を聞くのがいいです。「ここはもっとこうした方がいいんじゃない？」というのは、例えそれを否定する結果になっても考える切っ掛けになり、一段回良くなると思います。
もう少し、0から100まできちんと設計・デザインする経験を詰むべきだったなと少し後悔しています（そんな余裕一ミリもありませんでしたが！）
