はじめに
新卒エンジニアとしてチームに配属され、3ヶ月が経ちました。
このタイミングで、個人的に学んだことを後から見返せるようにまとめます。
本記事で扱う内容はどれも初歩的なものですが、次のような方の参考になる可能性があります。
- 漠然と「できない感」「仕事が遅い感」を抱えている方
- これまで自分の仕事のやり方を振り返ったことがない方
- 仕事の進め方を最適化する“きっかけ”が欲しい方
考え方自体は知っていても、継続して実践できている人は意外と少ないと思っています。
本記事では、一個人の経験をベースに「理想的なアプローチ」と「現実の行動」のギャップを埋めるための工夫を書きます。
対象読者
- 「漠然とできない感、仕事の遅さ」を感じている方
- 過去に自分の仕事のやり方を振り返ったことがない方
- 受験勉強などで一直線に成果を出せた自信がない方
- 最適化の契機を得たい方
本記事の読み方
各セクションは独立して読めるようにしているので、気になるところだけ拾うのがいい読み方だと思います。個人的に面白い章は下記だと思います。まあ、主観なので参考までに。
目次
マインド
理解に時間をかける
本配属後の初週で、牛尾剛さんの『世界一流エンジニアの思考法』を読みました。
世界一流エンジニアの思考法
本書の主題として最も印象的だったのは、次の点でした。
一流＝理解が爆速ではない
一流＝理解に意識的に時間を投資している
詳しくは本書や著者のブログで語られていますが、皆が想像する以上に理解の速度に差はない（差に見えるものの多くは経験値の差）という話です。
中でも実践しやすいと思ったのが、次の点です。
- 分からないままミーティングを終えないこと
立場を問わず聞く。
そして「聞いても自他ともに違和感がない状況」を日頃から作っておくことが重要だと感じました。
完璧主義を手放す
自分はウォーターフォール的に「最初に固めてから完璧に進める」タイプでした。
しかしアジャイルな現場で感じたのは、次の事実でした。
完璧主義は生産性を落とす
全部を100点でやろうとすると、重要度の低い部分に時間を使ってしまいます。
そこで重要なのが「濃淡をつける」ことでした。
① やることを選ぶ（実行前）
優先度（インパクト × コスト）
投資対効果の意識を、3ヶ月にわたって再三叩き込まれました。
例1：バグの優先度付け（トリアージ）
私は、機能追加による画面表示のバグを温度感高めでMTGで報告していました。
しかし意外と、リーダーやシニアの反応は薄めで、「後回しでも良さそう」という判断でした。
その根拠をテスターに尋ねると、次のように答えてくれました。
時間は限られているので、バグのトリアージ（優先度づけ）が重要。
具体的な基準は以下。
- 最優先：データ損失（事業的損害・信頼の毀損が大きい）
- 高：機能が動かない／主要機能が使えない
- 低：UI崩れなど（驚かせるが致命的ではない）
優先度づけの判断基準は、他にも引き出しを持っておきたいです。テスト技法の学習は優先度付けがうまくなるのかなともふわっとですが思っています。
小ネタ
トリアージは1995年の阪神・淡路大震災から広まったようです。起源は1888年に森鴎外がヨーロッパからトリアージのシステムを輸入したけど差別として広まらなかったらしい。
例2：「インパクトに対してリソースが釣り合うか」
あまり使われていないサービスの改善提案をしたとき、
「それでどれだけ効果が出る？その時間を他に使った方が価値が出るのでは？」と指摘されました。
ここで学んだのは次の2点です。
- 施策の良し悪しだけでなく、効果測定の観点とセットで考える必要があること
- 優先度は感覚ではなく、判断軸を持つべきということ
実際、そのサービス自体に改善点はあったものの、ユーザー数が少ないため「今そこにリソースをかけるべきではない」という判断に至りました。
新卒は何でも片っ端から手を付けたくなりがちなので、特に意識したい点です。
ただし優先度は判断がつけづらいケースもあります。例えば新規開発では、
- 新規機能数を増やすのか
- 既存機能のクオリティを上げるのか
どちらを優先するかは難しい問題です。
ビジネス的インパクト（利益が出るか等）を判断軸に置くべきですが、リリース直後はユーザーの声が十分に得られないこともあります。
また、ユーザーの声が常に真とは限らないケースもあります。こういった判断は今後も難しいテーマだと感じています。
取捨選択（濃淡をつける）
アジャイル的な価値観（少ない労力で最大の成果）を出すには、全部を100点でやらないことが重要です。
つまり 見切りをつける（濃淡をつける） という考え方です。
例1：読書にも「濃淡」がある（スキミング）
- 本には「既知の部分」と「未知で重要な部分」が混ざっている
- 読むべきところだけ拾う読み方ができると、インプット効率が上がる
- Web記事は目的を持って必要箇所を拾うのに、読書では頭から読みがち
→ 読書も同じように“目的ベース”にしたい
詳細には独学大全の掬読が参考になると思います。この本はそこらのハウツー本とは一線を画すぐらい面白くて参考になります。オススメ。
独学大全
例2：仕様書（仕様駆動開発）でも「濃淡」が必要
弊社では昨今話題の仕様駆動開発（SDD）を実験的にですが取り入れています。ただし、アジャイルとのバランスを撮るのが非常に難しいことがネックになっています。
- 仕様書は重要だが、全部に回答すると膨大になりやすい
- アジャイルと「重い仕様書」は噛み合いづらい面がある
→ 書くべき箇所を絞る意思決定が鍵
例3：テスト設計も結局「全網羅は不可能」
理論上は全パターンを網羅すべきですが、組合せ爆発で人力では無理です。
だからこそテストでは、科学的に範囲を絞る＝濃淡の技術が重要だと感じました。
T字型を目指す（探索と集中）
新卒あるあるとして「何でもやります」と言って抱えすぎると、結局できずに信頼を落とすリスクがあります。
だから自分のキャパシティを把握しておく必要があります。
一方で「何でもやります」にはメリットもあります。
- 普段やらない領域（例：営業寄りの話など）に触れてコンフォートゾーンを広げられる
- 変化が激しい業界で、新しい挑戦のハードルを下げる訓練になる
ただし、ずっと続けると器用貧乏になりがちです。
T字型人材（広く浅く＋一点突破）で考えると、
- まず広く触って選択肢を知る（探索）
- その後、尖る領域を選んで集中する（深化）
という流れが良いのかなと、現時点ではふわっと考えています。
タスク見積もり（予測として）
見積もりは単なる時間予測ではなく、次の意味を持つと感じています。
優先度判断の材料
信頼を守るための予測
- このタスクは2時間？1日？
- 改善タスクはどれくらい時間が吸われる？
- 定常業務は何分で終わる？
見積もりができると、
- 期待値調整ができる
- 「何時までに終わる」と言える
- 信頼を落としにくい
という効果があります。
具体的な見積もりの精度を上げるやり方は自分なりですがこちらで解説
② 手戻りを減らす（実行中）
早期フィードバック
タスクをもらったら、すぐ実装しないようにしています。
- 自分なりの進め方を整理する
- 「この認識で合っていますか？」と短文で投げる
これだけで方向ズレの手戻りが大幅に減りました。
進め方の相談
さらに有効だったのは、次のようにオープンクエスチョンで最初に聞くことです。
「このタスク、どう進めるのが良いと思いますか？」
シニアの思考プロセスを直接学べるため、その後の実装の質が変わります。
右も左も分からない新卒ほど、まずやるべきだと思いました。
変更の影響範囲が大きいところから実装する
例1：フロントエンド実装手順
UIより「データの契約（API）」変更の方が影響範囲が大きいです。
連鎖的にAPIのデータ変更がUIまで波及することもあります。
そのため、弊社のチームでは次の実装手順で開発しています。
- API（OpenAPI等）を作る／固める
- APIクライアントを実装する
- サーバー状態管理（React Query, RTK Query）を実装する
- クライアント状態管理（Redux/ZustandなどUI状態）を実装する
- UI（まずHTML/構造）を作る
- 最後にCSS（見た目）を整える
「影響範囲が大きい→小さい」へ向かって進めることで、後半の変更が局所化しやすいのがメリットだと思います。
③ 精度を上げる（実行後）
時間計測
2ヶ月目に入り、カンバン形式でタスク管理を始めました。
目的は次の2つです。
- 1日のタスクと優先度を明確にする
- タスクごとの所要時間を把握する
時間を測ることで、定常業務が何分かかるかが見えるようになりました。
具体的には、弊社では毎週WR + 各種申請を行うのですが、大体12〜13分で終えられると分かりました。
これをやり始めたきっかけは『プロフェッショナルの条件』3章「時間を管理する」に影響を受けています。（この本自体は自体は一般的な自己啓発本で特筆するべきところはないと思う）
補足：タスク管理アプリの利用
タスク管理には自作アプリを使っています。元は Notion でタスク管理していたのですが、時間計測を自動化しようとしたら課金が必要になったので自分で作りました。
-
InProgressに移動したら自動でタイマー開始 -
PendingやDoneに移動したらタイマー停止
タスク管理を業務に溶け込ませることで、所要時間の見える化ができるようになってきています。シンプルですが重宝しています。
現在の課題は、業務終了時に Pending にしないと業務時間外も計測されてしまう点です。
カンバンボードでタスク管理をしているのは TECH WORLD の【Notion脱却】外資ITエンジニアが実践するGitHubで人生を管理する方法
影響を受けてます。タスク管理の面倒さと効能の塩梅がカンバンはちょうどいいと思っています。
まとめ
本記事の内容は、新卒３ヶ月目が学んだことを整理しました。偉そうに書いてますが、まだまだ私自身やれていない時も多いため、この記事を十字架として日々仕事に取り組めたらなと思ってます。
人間の能力的な差は対してなく、ただやり方を間違えているだけ
この考え方は大好きです。普段大変なこともあるかもしれないですが、前向きに行きましょう。
この記事では仕事編についてまとめましたが、技術編についても別途記事を出そうと考えているので、よければ見てください。