結論として、3年目の仕事をより良く進めるためには─
読み手を意識した発信、抽象度の高い仕事の整理、未完成コードの管理、目的ドリブンな行動、抽象化思考、シングルタスク集中、助けを求める姿勢、継続的な振り返り、コード品質への責任、タスク設計、そして健康管理の11ポイントを意識して実践することが大切だと感じました。

はじめに

株式会社アトラエでGreen,Yentaのエンジニアをしています、　ぶると申します。
「どすこい塾」というコミュニティや「Flutter Tokyo」のオーガナイザーとしても活動したりしています。

昨年、新卒 1 年目終了時に 『新卒 1 年目を終えて：2 年目以降の仕事を加速させるには？』 という記事を書きました。

それから 1 年が経ち、アプリ開発に加えて Web フロントエンドエンジニア としても本格的に取り組み始めたり、弊社の受付アプリをFlutterで作成したりしてました。

本記事では、2 年目から 3 年目にかけて実際のプロジェクトで得た学びを整理し、3 年目に意識したい 11 のポイント にまとめました。

1. 読み手を意識したコミュニケーションを徹底する

なぜ重要か

伝えたい情報を最小限に絞ることで、相手が短時間で正確に理解できます。とりあえず揃えて全て出すは3流だと思ってます。
誤解や手戻りが減り、チーム全体の生産性が向上します。

具体的な方法

必要十分な情報に絞って要点を伝えます。
3行で伝える。（依頼なのか報告なのかを明示しつつ）
公開チャンネルを優先して投稿します。
求めるアクションを明示します。（例：ここだけで OK など）

2. 抽象度の高い仕事を進める意識を持つ

なぜやるかを明確に

何をどこまでやるかを決める

いつまでにやるかを決める

選択肢を出し提案して決定

状況を共有・相談

こにふぁーさんのこの記事を読み、とても良い学びを得られました。
ありがとうございます。

なぜ重要か

抽象度の高いタスクは、放置すると “モヤモヤした仕事” になりがちです。上記 5 ステップを意識すると、輪郭がはっきりし、関係者が安心して任せられる状態を作れるかと思います。

具体的な方法

ステップ	やること	チェックポイント	実践例
1. Why	ドキュメントやチャットを調査し、直接ヒアリングして目的を腹落ちさせます。	“自分の言葉で意義を説明できるか？"	「障害対応を改善」と言われたら、まず現状の障害頻度や影響度を数値で把握し、“なぜ今やるべきか” を言語化します。
2. What	完了条件を決め、ゴールをドキュメント化します。	“これをやれば依頼者・自分が納得する？”	"インシデントの初動 10 分以内" を目標に設定し、今期は手順書整備＋ローテーション体制構築までと範囲を宣言します。
3. When	マイルストーンを引き、自分で締切を設定します。	“いつ終わる予定か即答できる？”	① 現状分析 2 週間 ② 課題整理 & 方針策定 1 週間 ③ 全体共有 1 週間・・・とスケジュールを引きます。
4. Options	方針案を複数用意し、意思決定軸を提示します。	“メリデメを比較できる？”	インシデント管理は「専任コマンダー制」vs「当番制」など 3 案を比較表で提示し、影響範囲と運用コストで評価します。
5. Share	共有・相談の場を自ら設計し、攻めの報連相を行います。	“あれどうなってる？” と聞かれない？	Slackチャンネルで4hごとに状況をポスト。関係者を CC に入れて情報を一本化します。

やる時のチェックリスト（自分向け）

Why が説明できるか？（目的・意義を 1 分で語れる）
ゴールと完了条件を文書に残したか？
期限とマイルストーンをカレンダーに入れたか？
代替案と決定軸を提示したか？
共有チャネル・定例ミーティングを設計したか？

Tips

60％で一度共有 ⇒ フィードバックを受け、方向性を早めに修正します。
ステークホルダーを絞る ⇒ 意思決定者と実行者を最小限にして議論を高速化します。
ログを残す ⇒ 決定理由を Notion にまとめ、後からの“なぜ？”を減らします。

3. 抽象化して考えてみる

なぜ重要か

抽象化によって異なる技術や概念の共通点が見えるようになり、キャパが広がります。
マルチタスクをシングルタスクと捉えれるようになります
他の技術スタックに移ったときにも、心の壁を作らず適応しやすくなります。
自分は特に「壁があると動けなくなるタイプ」なので、この視点はとても大事にしています。

具体的な方法

異なる技術を「構造」や「目的」で捉えるように意識します。
たとえば Flutter / Kotlin / Swift は文法やエコシステムは異なっても、以下のような本質は共通しているのでその辺を理解すると楽に考えれるようになりました。
- 状態管理
- UIへのデータバインディング
- ライフサイクルの把握
- 宣言的 UI（Compose / SwiftUI / Flutter / React など）

4. デグレや未完成コードのリリースを防ぐ仕組みを整える

なぜ重要か

ユーザーに伝えてない機能がユーザーに見えてしまうといったことにつながる可能性があるため。

具体的な方法

未完成コードは main へ merge しません。
段階的な QA とバグトラッカー（bugsnag など）の常時監視 を導入します。
大規模変更では 有識者レビューとリスク評価 を必ず行います。

5. 目的ベースで仕事を捉えるクセをつける

なぜ重要か

「なぜやるのか」を明確にすると、優先度や進め方を判断しやすくなります。考えずにとりあえずやるは3年目は絶対しないです。

具体的な方法

問題が起きたら 事実 → Why → 自分の考え の順で整理します。
振り返りで 「誰の課題を解くのか」 を言語化します。

6. マルチタスクをやめてシングルタスクに集中する

なぜ重要か

並行作業は切り替えコストが高く、品質と速度の両方を下げがちです。

具体的な方法

優先度の高いタスクを 1つずつ選び、時間ブロックを設定します。
実際には別のタスクではあるけど抽象化して考えれると脳のキャパも余裕ができます。(例えばKotlinとSwiftは別言語だけど、実際は似てるよねみたいな)
GTD の「次に取るべき行動は？」 を常に自問します。
- GTDとは: https://gtd-japan.jp/about

7. 困った時は早く助けを求める

なぜ重要か

早めに助けを求めることで、プロジェクト遅延や品質低下を防げます。
助けを求めないと、結局自分だけではなくチーム全体に迷惑をかけます。

具体的な方法

15 分悩んだら Slack に相談します。 すぐにミーティングを組んでも構いません。
チームのキャパを可視化、理解し、余裕のあるメンバーに早期ヘルプを依頼します。

8. 継続的な振り返りと改善を習慣にする

なぜ重要か

小さな改善を積み重ねることで、大きな成長につながると思っています。なんとなくで生きないようにしないとです。

具体的な方法

週次 OKR を設定するなどして、金曜にスレッドで振り返ります。
付箋やスティッキーズ を使って、意識すべき行動を常に視界に入れます。

9. コード品質と自動テストを強化する

なぜ重要か

不具合の早期検知により、修正コストを最小化できます。

具体的な方法

セルフレビューを行ったうえで PR を提出します。 説明できないコードを残さないようにします。
PR Prefix ルール を統一し、Ask / Nits / IMO をタグ付けします。
テストケースを追加し、CI でカバレッジを監視します。

10. やること／やらないことを事前に明確化する

なぜ重要か

初めての Web フロント案件では、「設計・実装・デプロイ・仕様決めなど」全てを担当し、負荷が高くなりました。範囲を決めることでリスクが見えやすくなるかと思います。

具体的な方法

まず前提として、ちゃんとタスクを切り分けます。
新技術は 30 分のプロトタイプを作成して、粗見積もりを行います。
不確実なタスクには 1.5〜2 倍のバッファ を設けます。
毎週 見積もりと実績の差分 を振り返り、遅延要因を洗い出します。

11. プライベートとリフレッシュを大切にし、しっかり食事を取る

いつの間にかお昼が過ぎていてご飯が遅くなったりしてました。
昨日社長に健康は大事だからちゃんと食事しようと言われました。その通りです。
3年目はちゃんと健康も意識します。

なぜ重要か

健康はパフォーマンスの土台です。疲労した脳はバグを生みやすくなります。

具体的な方法

カレンダーに私用時間をブロックします。（例：19:00–22:00 を家族／趣味タイムに設定）
週 1 回デジタルデトックス を行い、スマホ・PC から離れます。
四半期ごとに連休を予約し、先に休暇を確保します。
ストレスとムードをスマートウォッチで可視化します。
週 2 回の運動と 3 食の食事 を習慣化します。

おわりに

2 年目はアプリ開発に加え、フロントエンドという未知の領域にも挑戦し、多くの失敗と学びがありました。
ここで挙げた 11 のポイントを 3 年目も意識的に実践していきます。
この記事が読者のみなさんのヒントになれば幸いです！