20代のお仕事で大事だと思ったこと
皆さんおはこんばんにちは！
（5001文字/約7分で読めると思います）
選挙も控えてるし、これを機に選挙の仕組みや国政の構造だったりを改めて学び直そうと思い立ち、ちょうど1週間前に基礎となる小選挙区や比例代表のことを調べ記事にした甲斐もあってか、そこそこ自分なりの意志を持って期日前投票に臨んだものの、比例代表の政党名略称が立憲民主党・国民民主党で両方とも"民主党"となっていて、意外なところでつまづいてしまった今日この頃です。（民主党と書いた場合は、それぞれの党の有効得票数に応じて票を分け合うらしいです）
そんなこんなで何事もやってみなくちゃ分からない気付きだらけの日々ですが、ここ最近は政治だの資産だのわりと大局視点のトピックが続いていたので、翻って自分のお仕事についてのこれまでを振り返りつつ、整理していこうかなと思います。
というのも、10月末に社内の大きめのリリースが一段楽し、エンジニア人生二度目のリリースでありながらその過程も含めて学びも多く、最近目にした「仕事を任せられるエンジニアになるために意識してほしいこと」という記事を読んでいても、確かに、、と思うことやまだまだだなぁと思うことが多かったので、これを機に今の現在地や学びをまとめておこうと思った感じです。
完全に個人的な備忘録みたいになってしまいますが、エンジニアである人もそうでない人も、仕事において、言われればそりゃ分かってるけどできているかは別の話だよねみたいなことは結構あると思うのでそんな感じで照らしながら読んでみてもらえれば幸いです。
前提として自分のキャリアを整理しておくと、2019年卒で通信販売の会社に入社したものの、先輩が怖すぎて半年で退職し、ECも通信販売も結局ITが関わってくるし、そこら辺の周辺知識がないと太刀打ちできない。。！と感じてプログラミングスクールを通じた転職を試みて、2020年3月から受託開発のエンジニアとして、バックエンドやらフロントエンドの実装を担当しているといった感じです。（なので、マネジメントみたいな観点はまだないです）
今回のリリースに関しては、納期がなかなかにタイトだったものの、案件当初からいたわけではなく、途中から合流した形なので、その中で試行錯誤したこと、学んだこと、これから意識付けていきたいことなどをまとめていければと思います。。！
スケジュールの共有と更新
まずはスケジュールに関してですが、今回大事だなぁと強く思ったのは、「タスクを渡されたらヤバくてもヤバくなくてもこれくらい掛かりそうという個人の見積もりは立てて、常に共有・更新しながら進める」ということです。
なんだ、当たり前やんと思われるかもしれませんが、大事なのはヤバくてもヤバくなくてもという部分で、タスクの重さに関する判断はリーダーや自分よりも経験がある人に共有しておかないと意外な盲点に後から気付き、慌てることになるというのを痛感しました。
『〇〇できる機能を実装する』というタスクにおいて、自分にとっては〇〇できる部分だけだったらこれくらいか、、と見積もりを立てて臨んでいましたが、ある程度進めた段階で、ちなみに「〇〇する過程で、△△はできないようにする箇所は考慮してますか？」と問われて「あっ。。」となってしまいました。
これも早めに自分が必要だと思っている実装箇所・懸念すべき箇所をリストアップして、これで過不足ないかを最初の段階で確認しておけば焦る必要はなかったので、自分の見積もりなんて所詮は素人に毛が生えたようなもの、、と思っておいてざっくりとしたものを共有しておけばよかったと思っています。
そういうのはリーダーが早めに気付くべきだという視点もあるかもしれませんが、それはそれで他者に依存的な体質になってしまいますし、いつまでも自分のタスクに責任が持てなくなってしまうので、そこはバランスよく自分の理屈を土台として見積もりを早めに提示し、意見を貰うという段階までは意識すればできることなので今後はやっていきたいなと思いました。
スケジュールを更新する余裕を持つことも大事で、リスケばかりでケツが詰まってしまうのは元も子もないですが、現在地を常に共有することで分担できる作業があるかもしれませんし、その分空いた工数を別のタスクで賄えば全体最適としては結果的に良かったなんてこともあり得ます。
一度立てたスケジュールは勿論そのままいくことが望ましいですが、チームで動いているのであれば、適材適所もありますし、何より共有しないと始まらないので、そこは更新する余白も残しつつ現在地の共有を癖づけていきたいです。
また、これは余談ですが、この自分の頭で考えて見積もり→上長からのFBという流れは自分が成長するスピードも上げてくれると思い、「何をすればいいですか？」という0ベースの質問ではなく、「自分はこうこうこういうロジックでこういう建て付けにしたんですが」という前提があれば、指摘箇所によって、どこを修正する必要があるのかが明確になり今後に繋げることもできます。
「いや、結局リーダーに最初から全部聞いた方が手戻りもないし、余計なコストもないし」と言われればそれまでですが、せっかく振ってもらった自分のお仕事とどう向き合うかで吸収率が変わってくるならば、不完全であることは自覚した上で、自分の頭で考えたプランを提示して添削してもらった方がいいのではとも思いました。
完璧を目指さない
自分で立てる見積もりプランにも通ずる話なのですが、この"完璧を目指さない"という意識も大事だなと感じました。個人的な話になってしまいますが、自分には常に「こいつ優秀だな」と思われたい下心があると思っていて、もちろん向上心という視点では必要な下心ではありますが、逆に「優秀じゃないと思われる減点は取りたくない」というブレーキがかかってしまうという欠点があります。
つまり、不完全なものではなくほぼ完璧なものを提出したい病というものです笑。これが意外に厄介で、見積もりでも実装でも、自分が納得するまで繰り返し時間をかけてしまいがちで、時間を掛けてでも完璧に近ければそれに越したことはないんですが、そんなことは滅多になく、結局意図した方向と違い修正工数だけで時間を喰われるなんてこともあり得ます。
そういう意味でも"完璧を目指さない"というのはネガティブな意味ではなく、今できる範囲で組み上げたもの、積み重ねたものを都度提示して、FBを貰い、修正を繰り返し徐々に完成を目指していくというのがチームで働く上で大事なのではと思いました。
そもそも自分が考える完璧なんてものは、経験豊富な人から見れば穴だらけであって、それならば「ここまでは分かっていて、ここまでが懸念点、不明点だと思っている」という不完全でありながらも自分の意見を伴った段階のものを見てもらって次に進んだ方がいいと思います。
これは開発特有の話かもしれませんが、当初は開発後のテストでバグがないプログラムというのが品質の良いプログラムと思っていた一方で、先輩方は「バグがあまり報告されないのは怖い」と言っていて意外に感じたことを覚えています。
ここまで規模が大きく複雑化してきたアプリ開発において、エラーハンドリングや正しい挙動というのを人一人が全て最初から担保できるということはなく、むしろある程度形にして最低限のフローが確認できたらあとはテストを通じて皆で品質を上げていく、という位の心構えが最終的には完璧に近い形へと繋がっていくのかもしれません。
そういう意味では、一エンジニアも機械ではなく人間なので、最初から完璧になんてことはない前提で動いていったら必要以上にプレッシャーを抱える必要もないですし、無駄にプライドを守る必要もないかもしれませんね。。
会社は学び舎ではないけども
色々つらつらと書いてきましたが、書きながら思ったことが、仕事との向き合い方で学べる量は変わってくるなぁということでして。今の時点で26歳、エンジニアになって1年半程ということで、そこそこ頑張っているつもりはありますがまだまだ知らないことも多く、自分の力であっと言わせるプログラムを！なんて世界はまだまだ遠いように思えます。
かといって焦っても仕方がないので、まずはアウトプットの土台となる足腰として色々なことをインプットしていくのが大事な時期かなとも思っています。
そんなインプットに関してよく言われるのが、「会社は学校じゃないんだから、1から10まで教えてもらえると思うな」っていうフレーズで、これだけ見るとやや厳しい言い回しのように感じますが、言いたいことの意味自体は納得できます。
新卒の新人教育とかであれば、会社にとっても未来への投資という意味で色々なことを手厚く教えて貰える機会が設けられたりしますが、じゃあそのテンプレを通過したらみんな一人前かというとそうでもないのが現状かと思います。（もしそうならテンプレ志向の日本はもっと強いはず）
だとすると結局、テンプレを通じた受動的な学びではなく、能動的に一生学び続けられる人が強いのかなとは思うんですが、ここでいう受動的な学びというのが「会社は学校じゃないんだから」という箇所で指摘している部分だと思っていて、いつまでも教科書を与えられないと学べないようでは駄目だよということを言っているのではないでしょうか。
じゃあ能動的に学ぶとはどういうことかというと、見積もりでも、実装でもまずは自分の頭で考えてみて、現時点で持っている材料で組み立ててみた仮説を持って検証に臨み、改善を繰り返していくという行為だと思います。この仮説→検証→改善というサイクルをどれだけ多く回せるかが、良質なアウトプットを生み出す足腰に繋がってくるのではないでしょうか。
また、このサイクルも若いうちにしか回せないとものだと思っていて、外せない、失敗できないプロジェクトを仮説を以ってしてトライできるかというと、それは難しく、責任が伴い、背負うものが大きい立場になればなるほどこのサイクルは回しにくくなるので、まだ若く、失敗しても死なない今の内だからこそ回せるだけ回しておこうとも思えました。
冒頭の会社は学校じゃない！というのは、会社は「手放しに教えてください！」という人にものを教える場ではなく、自分の仮説を携えて、検証という形であれば学びを得られる場所という意味だと思っているので、そこは履き違えず、まずは自分を起点として物事を考えていければと思いました。
知識 × 経験 = 腕力
見積もりから、完璧を目指さない、能動的な学びを！と色々書いていく中で、結局一人前になるとはどういうことなのかなぁとぼやぼや考えていましたが、今イメージできているのは、壁に直面したとき、全部を全部自分で処理できる人ではなく、壁がどのくらいの厚さ・高さでどこにどういう順番で登れば超えられるかという筋道が立てられて、その手順を踏む上で自分だけでできることと他の人の助けがが必要な部分の整理ができる人、みたいな感じです。
で、この筋道を立てるのと、手順を踏む際の整理をする上で必要なことは「知識」と「経験」だと思っています。知識というのは勿論、日々の学びやググりや、同僚から得ることも多いですし、点と点である日突然結びつくこともあるので、これは自ら獲得することができるんですが、経験というのは機会やタイミングもありますし、こればかりは自分だけではどうしようもないことだったりするので、知らなそうなこと、やったことないことをできる機会があれば積極的に手を上げて、経験し、新しい知識へと紐付けていきたいです。
今回のリリースではバタバタしながらも、リーダー陣は"やばいねぇ〜"と言いつつ取り乱すことはせず、まずはどれくらいの緊急度なのか、自分たちの対応だけで解決するのか、などの整理を冷静かつ迅速に終わらせ、粛々と対応する姿を目の当たりにし、時には腕力でゴリっと解決する様を見せられ、何事も「知識」と「経験」、時に掛け合わせた腕力なんだなぁと実感しました。
これらも一朝一夕で得られるものではありませんが、会社という場を能動的な学び舎としてフル活用させてもらいつつ、いずれ来る自分の創造したいアウトプットに向けて足腰を鍛えようと思いました！やるっきゃない！ではまた！
この記事が気に入ったらサポートをしてみませんか？