株式会社PRUMのmasaです。
今日は、主に開発タスクを前に手が止まってしまう初心者エンジニアの方に向けて、「タスク分解」を軸にした進め方を解説します。
不確実性の高い開発現場でも、タスクを小さく分けて考え、早めに手を動かし、60点でもアウトプットすることで、不安をコントロールしながら着実に前進できます。
「タスク振られたけど何から始めればいいかわからない…」と感じている初心者エンジニアの方をはじめ、これからエンジニアを目指される方にも参考になると思います。少しでもヒントになれば嬉しいです。
なぜ新しいタスクを前にすると手が止まるのか？
そもそも、なぜ僕たちは新しいタスクを前にすると焦ってフリーズしてしまうのでしょうか？それは、開発の現場が常に 不確実性 と隣り合わせだからです。
システム開発には「やってみないとわからない」という不確実性が常につきまといます。全く同じものを同じ条件で作ることはほとんどないため、途中で予想外のトラブルが起きやすいです。
それに加えて、仕事である以上は「予算」「人数」「納期」という限られた枠の中で結果を出さなければならないという制約があります。
「納期に間に合わなかったらどうしよう」「自分のせいで遅れたらどうしよう」というプレッシャーと、「やってみないと分からない」という不安。これらが合わさることで、初心者エンジニアの思考はタスクの前で停止しがちになります。
1. 解けるサイズまでタスクを分解する
この 不確実性 という魔物を攻略するために、現場の先輩たちが呼吸するのと同じ頻度でやっていることがあります。それが タスクの分解 です。
現場で使う技法：WBS（Work Breakdown Structure：作業分解構成図）
大きな目標を小さく分解して、自分が「今日何をやればいいか」わかるレベルまで落とし込んだ図のことです。やるべきことの明確化、作業の漏れやダブりがないかチェックすることなどに役立ちます。
例えば「商品検索APIを作る」という大きな塊のままだと、何をしていいか分かりませんよね。僕も最初、同じところで止まりました。
だから、中学生でも「今日何をすればいいか」が分かるレベルまでタスクを小さく分解します。
例えば、こんな風に分解します。
- 仕様書を読んで、検索に必要な条件（キーワード、価格帯など）を書き出す
- データベースのどのテーブルに商品データが入っているか確認する
- データを取得するためのSQLを書いて、ツール上で試しに実行する
- ログに出力して結果を確認して検証する
どうでしょうか？「APIを作る」より、ぐっとハードルが下がったと感じませんか？
タスクを分解することで、「何から手をつければいいか」がはっきりし、迷わず一つずつ進められるようになります。
これでもまだ大きな塊なので、最初はここからさらに、実際にプログラミングするレベルの内容まで落とし込むことが大切です。
2. 早めに手を動かす
この時おすすめしないのがずっと基礎知識の勉強などインプットばかり続けて、手を動かさないことです。これをすると一向に開発が進まず、最悪納期遅れになりかねません。とはいえ、当然ベース知識が0だと手を動かすのも難しいです。
そのため、以下を自分と約束します。
-
基礎知識などのインプットを2時間以内にすると決める
-
それ以降は手を動かすことに集中する
そうすることで、「動きながら考える」ことができます。
いくら基礎知識などインプットを10時間しても、プログラミング中には必ずと言っていいほど10時間勉強したこと以外の問題に直面します。これは経験上、間違いなくそうだと言えます。
だったら、ベースの知識だけ比較的少ない時間でインプットし、あとは手を動かしながら考える、とした方が効率的にタスクをこなせますし、自分の成長スピードも早いです。
3. 60点でいいから、一回出してみる
初心者エンジニアの頃にやりがちなのは、「完璧にしてから先輩に見せよう」とすることです。
「まだコードが汚いから」
「エラーが出ているから、直るまで相談できない」
そのように一人で抱え込み、時間が経ってから「実はあんまり進んでいません…」と報告する。実は僕もこれを3年前は何回もやらかしました。
プロジェクトにおいて、できるエンジニアは以下4つの戦略を駆使してリスク回避します。
リスク回避の4戦略
-
回避：そもそもトラブルになりそうなことはやらない
（例：使ったことのない難しいライブラリは避けて、実績のある簡単なものを使う、誰にも迷惑かけないように一人で完璧な知識をつける） -
軽減：問題が起きても影響が小さくなるようにする
（例：テストコードを書いて、バグをリリース前に見つける、問題を早めに洗い出す） -
転嫁：自分で抱えず、別の人やサービスに任せる
（例：サーバーの管理を自前でやらず、AWSなどのクラウドサービスを使う、先輩に一部手伝ってもらう） -
受容：問題が起きる前提で、あらかじめ準備しておく
（例：不具合が出たときのために、すぐ元に戻せるようバックアップを取っておく）
完璧主義な人は、リスクを 一人で100%「回避」 でなんとかしようとしますが、これは危険です。特に初心者エンジニアの方は純粋な方が多いので、「役に立ちたい」「忙しい先輩に迷惑かけたくない」などの気持ちから、この100%「回避」型になりがちです。
初心者エンジニアは 軽減 と 受容 を意識することが大切だと思っています。
自分一人では分からないことがあると覚悟を決めて受け入れ（受容）、ダメージを小さくするために早めに着手して早期にバグや自分で解決できない点を見つけます（軽減）。
つまり、 60点でいいから一回出す 出すことが大切です。
「ここまでは分かりました。でもこのエラーの原因が絞りきれず、詰まっています」
この状態でプルリク（コードのレビュー依頼）を出していいと思ってます。完璧じゃなくていいので、60点で出して、先輩のアドバイスをもらって後で直すほうが圧倒的に早いです。そうした方が最終的に自分もチームもハッピーになると思います。
さいごに
あなたがタスクを小さく分解し、60点で早めに報告・相談をしてくれること。それは、教える先輩にとっても、チーム全体にとっても、何よりの「安心感」に繋がります。
まずは10分だけ、目の前のタスクを分解して小さな一歩を踏み出してみましょう。焦らず自分のペースで一個ずつ潰していけば大丈夫です！
PRUMのエンジニアの95%以上は未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
▶ コーポレートサイト
エンジニアの方に役立つ記事をまとめたサイトも運営しています。もしご興味あれば覗いてみてくださいね。
▶ エンジニアに役立つ記事サイト