新卒エンジニアの失敗談を洗いざらいお話しする記事
はじめに
初めまして。
「成果を出しまくって昇進しまくるぞ」と意気込み、じげんに入社して早７ヶ月―。
未だに何ひとつ成果を残すことのできていない男、池田と申します。
このような企業のブログやインタビュー記事などでは、「成果を上げた裏にはこんな苦労があった」といったサクセスストーリーが多いですが、今回は何ひとつ成果を出せていない、うだつの上がらないいち新卒社員の失敗談を余すことなく書き記していきたいと思います。
最後に失敗だらけの私がこの会社で働いている理由も添えさせて頂ければと思います。
この記事が、仕事が思うようにいかない方々の心の拠り所や、願わくばこれからじげんに入るご予定の皆様の参考になればと想い、つらつらと文字を紡がせていただきます。
目次
私について
現在の仕事内容
自己紹介が遅れましたが、私は現在、アルバイト情報メディア「アルバイトEX」をはじめとする、求人サービスを展開する求人Div.でエンジニアをしています。
サービスは前述のアルバイトEX(https://arubaito-ex.jp/)を担当しており、マーケターの方々が考えた施策の実装（表示方法の変更や計測体制の構築、データ収集など）や施策の考案が日々の通常業務です。どのような求人サイトがユーザやクライアントにより良い価値を提供できるかを技術面、施策面から模索しています。
ふわふわな動機で入社
私がじげんへの入社を決めた理由は、「ビジネスについてたくさん学ぶことが出来そうだから」というふわふわとしたものでした。エンジニアという職は、学生時代に情報系の大学院でプログラミングに親しんでいたため、強みを活かせると思い選びました。こちらも特に展望はなく、院での研究に力を注ぎたかったため「技術職であれば就活に時間を割かずに済むだろう」という安易な考えでした。しかし内定をいただいて以降の懇親会やインターンを通してじげんへの思いはより一層強くなりました。向上心と当事者意識の強い先輩方や同期を目の当たりにし、この刺激的な環境の中で働きたいと感じ、じげんへの入社を決めました。
今考えればこの成り行き任せな入社動機が、この後の私の身に起こる出来事を象徴していたのかもしれません。
失敗談その①：やりたいことが伝わらない
新卒研修
新卒社員は4月に入社すると、エンジニアを含む全員が2週間の新卒研修に参加します。
じげんの新卒研修の内容はその年々によって変化し、チャレンジングな人事の方々がユニークな研修プログラムを設計してくださいます。この研修では、各事業部の仕事内容やじげんで働く心構えを学び、事業立案やディレクションのワークを通して事業家としての基礎を叩き込まれます。それぞれのワークではチーム毎に順位がつき、研修の最終日には個人毎の総合順位が1位から最下位まで発表されます。
新卒研修の結果
私はグループで行われる事業立案ワークの発表においてリーダーとして発表に臨みました。三日三晩考え、自信満々の発表を終えたところで社長から、「何をしたいのかわからない」「で、そのサービスを求めている人は誰なの？」と言われて全く答えられませんでした。内心では「新卒だし、いい経験になったな」と自分に言い聞かせていましたが、その後4時間は一言も誰とも話せませんでした。チームメイトへの申し訳なさが抑えきれず、帰ってからはずっと猫の動画を見て現実逃避をしていました。
失敗の原因：課題から考えていなかった
ビジネスとして顧客からお金をもらう以上、顧客の課題を解決することが必要となります。しかし今回は解決する課題が何かが明確になっておらず、それっぽいビジネスを提案しただけに終始してしまいました。「誰の」「何を」解決するサービスなのかが伝わっていなければ、何をしたいのか、どうやってお金を頂戴するのかが伝わるはずがないのです。
来年以降このワークに臨まれる方も、他社で事業づくりに関わる方も「誰のためのサービスなのか」をはっきりさせることを大切にしてください。
研修以降、私はプレゼン等の場で課題から話すことをこころがけましたが、話の伝わり方がまるで違いました。「そもそもやる意味あるの？」「何がしたいの？」というような根本的な疑問を投げかけられる機会が格段に減ったと思います。
顧客の課題起点の考え方はこちらの書籍が参考になりましたので、ご興味あればご一読されることをお勧め致します。
参考文献：顧客起点マーケティング
失敗談その②：施策が通らない！
エンジニア開発研修
新卒研修が終わると、新卒社員は本人の希望や適性を踏まえて配属が決まり、各事業部やユニットでの業務に入りますが、私たちエンジニアは、通常業務に加わる形でもうひとつの研修が用意されていました。それが、新卒エンジニア継続研修(通称：エンジニア研修)です。
エンジニア研修では、「社内課題を解決する」1つのアプリケーションの開発を、約2ヶ月半後(6月末)を納期として、ヒアリングから公開まで各自1人で行い、最後に全社に向けて作ったアプリケーションについてのプレゼンテーションをし、新卒研修と同様に順位をつけて評価されます。このワークは、所属部署の業務と半分半分の時間配分で実施し、それぞれにメンターとなる先輩がサポートしてくださいます。新卒研修と同様に順位をつけて評価されます。この研修は、ヒアリングからアプリ作成まで一気通貫の開発経験を通し、課題に対してどのように技術を活用していくのかという事業目線での技術者を育てることや、メンターとの議論と実際に手を動かして開発することによる技術力の醸成が狙いとしてあるようです。
私は、社内で使われるサービスを作るためには社員のツールチャネルを増やさないことが必要であると考え、社内で使われている既存のサービスを統合したアプリケーションを提案し、チャネル数を減らし、新しいサービスに代替することを提案しました。具体的には、新しく入った社員の方が、先輩社員に話しかけやすくすることを目的とした顔写真付きの座席表を提案し、実装しました。
エンジニア開発研修の結果
「これは人に使われるいいサービスが出来た」と思い、自信満々にドヤ顔で上司にプレゼンしたところ、「それPL(損益計算書)に全然影響ないじゃん」と言われ、「確かに、、」としか返せませんでした。
全社発表でも、「面白いと思った」というご意見は頂いたものの、「いいね、それやろう」というような意見はもらえませんでした。
失敗の原因：定量的なインパクトを示さなかった
新卒研修の反省を活かし、誰のためのサービスかをはっきりさせ、サービスを提案したものの、そのサービスを求める誰かが「どのくらいの人数」いて、「どの程度の利益になる」のかの視点が欠けていたと考えています。
会社では毎日多くの施策が検討されますが、社内資源は限られています。その中で、自らの施策を実行する意思決定を会社や上司に促すためには、施策がもつインパクトを蓋然性と共に伝えることが必要だったのです。
一橋大学の延岡氏が提案したSEDAモデルでは、ビジネスにおいて提供する価値をScience、Enginnnering、Design、Artに分類しています。このモデルによれば、意味的な価値を提案するだけでなく、形式的な価値への拡張や解決される課題の大きさを定量的に示すことでより良いビジネスになると説明しています。
「面白い」と思わせるだけではアートにすぎず、統合的な価値を創出できていないためビジネスとしての魅力は伝わらないのです。今回でいえば、顔写真付きの座席表によってどの程度の工数が削減され、どの程度の従業員のモチベーション向上やコミュニケーション円滑化が図られるのかを定量的に示すことができれば、「面白いね、それやろう」という声がもらえたかもしれません。
イノベーション実現のための SEDA モデル
イノベーション実現のための SEDA モデルと アート思考のものづくり
もし読者のみなさんがサービスを作る機会がある場合、ペルソナを立てると思いますが、その人たちの何人に対して利益に結びつく行動が期待できるのかをハッキリさせた上で実行や提案を心がけてください。
結果的にこの研修でも私は1位を取るという結果は出せず、帰ってから元気を出すためにYoutubeでサンドウィッチマンの漫才をずっと見ていました。
失敗談その③：実装が納期に間に合わない！
求人Div.での業務
研修終了後、私は求人Div.に配属されました。冒頭でもお伝えしたとおり、私はアルバイトEXというサービスのエンジニアを担当することとなりました。
私は学んだスキルを遺憾無く発揮するべく「先輩エンジニアをアッと言わせてやるぞ」「エンジニアなのに起案とか分析とか上流までやってやるぞ」と腕をブンブン回して業務をスタートしました。
求人Div.での業務の滑り出し
ひとつ目のタスクが納期に間に合いませんでした。もちろん２つ目も３つ目も間に合いませんでした。納期を遅らせてしまったことで関係する人々に多大な迷惑をかけてしまいました。
失敗の原因：工数見積りが甘かった
こうした状況を見た先輩方は「エンジニアにとって工数見積が全てと言っても過言ではない」と教えてくださいました。工数見積が正確ということは、実装の道筋が明確に見えていることに等しく、目の前の一つひとつの実装はこの工数見積の精度を上げるために取り組んでいると言っても過言ではないと。
エンジニアが実装を担当する上で調整すべきは”気合い”ではなく”見積り工数”であったのです。
私は「これどれくらいでできる？」という質問は、「どれくらい気合いがあるか」を聞かれていると勘違いしており、プロジェクト全体を進めていく上で「どのくらい時間がかかるか？」を純粋に聞いているだけの質問に気合いで応えようとしてしまったために、結果的に多くの人に迷惑をかけてしまいました。
仮に「これくらいで終わるでしょ？」と要求されたとしても、気合いで応えようとせずにある程度のバッファを設けて答えるくらいがちょうど良いのです。
B.Boehmらは要件定義時の工数見積の不確定さを以下の図で表しており、「実装段階に比べて、要件定義時の見積工数が極めて不確実性が高いこと」を示しています。
- B. Boehm
- Published 4 October 1993
- Computer Science, Economics
- IEEE Transactions on Software Engineering
参考：http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5010193
従って、気合いを見せる前に現実的な工数を丁寧に見積り、その上で手を動かしながら経験を積み、構造化しつつ見積り精度を上げ、伝えた工数に対してスケジュールを巻けるように気合いを出すべきでした。
工数を見誤り、納期遅れを繰り返した私は、毎晩カップルYoutuberの動画を子守唄にして眠りについていました。
もし読者のエンジニアの皆さんの中に、自らの技術力やスピードに過度に自信を抱いている方がおられましたら、予想工数と実際にかかった工数を比較し、自身の工数見積精度のメタ認知をしてみることをお薦めします。
私がじげんで働く理由
失敗させてくれる
ご覧のように、入社してから現在までの私は反省だけが積み上がり、成果は積み上がらない社会人1年生を過ごしています。「ユーザの課題の発見」「課題を持ったユーザのボリューム」「見込める利益」「工数見積り精度」…と次から次へと自分自身に対する課題が肥大していく私です。入社前と入社後のギャップといえば、自分が思いのほかできなかったことでした。
しかし、案外元気に働くことができています。
自分でも驚くのですが、この要因は「失敗させてくれる環境」にあると思います。
無論、失敗するとわかっているものにわざわざGOを出される訳ではなく、失敗を通して仮説を検証しPDCAを回すことを推奨してくれるということです。上記でお話しした数々の誇れない事実を通して、需要想定と合わせて工数見積を意識して仕事をするようになり、目の前の仕事をロジカルに捉えられるようになったと感じます。また、今自分はどんな目標に対してどれくらいの工数（人）をかけて仕事をしているのかを把握することで、遅れが出た場合のリカバリープランや仕様のスコープ変更を定量的に判断するようになりました。
一つひとつの失敗も良い刺激として私に作用していると思います。
当事者意識が育つ
自分の頭で考えさせてくれるところも私が会社に入ってよかったと感じている部分のひとつです。上司からはよく「代替可能な単純作業者になるな。思考することや判断することが重要な仕事だ」と口酸っぱく教えられます。
決められた業務をこなす作業は確実に進捗を生みますが、考える作業は時に前提を疑わなくてはならず、机上の空論の段階では非生産的な時間に感じられることも多いです。また、「あいつは仕事していない」という有無の確かめようもない周りの目も気になってしまいますし、優秀な人なら数分で終わる思考に何日も何週間も時間を費やす場面が多くあります。このような場面において、上司の言葉は私にとってとても救いになっており、徹底的に思考する勇気をもらえるのです。
もし当事者意識が磨かれる刺激的な企業で失敗を恐れず挑戦したい方がおられましたら、じげんを検討してみて問題ないと思います。
おわりに
いかがでしたでしょうか？
入社時の「わからない」「伝わらない」状態から「わかるように、伝えられるようになった気がする」といった成長過程に甘んじている私ですが、今後ともこの環境で自分が成長していくことは間違いないと思われます。
「成果を出しまくって昇進しまくるぞ」と意気込みじげんに入社して早7ヶ月―。
未だに何ひとつ成果を残すことのできていない男の目は、依然として燃えている。
