ITエンジニアは技術だけやっていればいいとか思ってませんか？
技術力は確かに大事ですが、それだけで順分満帆な開発者生活がおくれているとしたら、その人は環境に恵まれているだけかもしれません。
人生が運ゲーって、嫌ですよね？ なので、自分が担当する新人には、習得した技術力を活かすために自身のマネジメントお願いしています（本稿では、これを「セルフ・マネジメント」と呼称します）。
すごく基本的なことなので、文書化するほどでもないかもですが、残念なことに自分が居た環境ではあまり耳にすることがなかったので、文書化してみました。
「セルフ・マネジメント」とは
簡単に言えば、数ヶ月先のゴールとマイルストーンを決めて、毎日その進捗チェックと調整をし続けることです。
夏休みの終わりまでに宿題を全部完了できるように「夏休みの計画」を立てるような感じ、といったところでしょうか。
なぜ「セルフ・マネジメント」が必要なのか？
具体的なメリットは以下のような感じです。
- 予定がクリアになり、タスクの実施に集中できる
- リーダーやチームメンバに対して、予定と現状のシェアが容易になり、理解や協力が得やすくなる
- 日々の報告や調整を通じて、スケジュール管理の精度が向上する
- 「自身の管理」で早期にマネジメントを経験することにより、将来的にPL等で必要になる見積もりやタスク管理の経験が積める
「自分の身を守るため」「味方を増やすため」というのも重要なメリットです。
「セルフ・マネジメント」の準備
まずはリーダー（トレーナー, 先輩, etc…）に「自分で計画を立てて自主的に管理したい」と伝えて、理解を得ることから始めましょう。
何かを始める前に、相手の理解を得て味方になってもらうのは、基本中の基本です。
計画の立て方
ここから先は具体的な例を交えて計画の立て方をイメージしていきましょう。
各Phaseで計画をリーダーに見てもらうと、手戻りが少なくて効率的です。
[Phase 1]
難しく考えずに、以下を設定してみましょう。
- ゴールと期間
- ゴールの到達に必要な大タスク
- 大タスクの大まかな工数
--- SAMPLE ---
[ゴール]
担当製品の開発に必要な知識を習得し、PG/PTからテスト実施までをこなせるようになる
[期間]
6ヶ月
[ゴールに到達するために必要な大タスク]
・ 担当製品のテストを独力で実施できる（1ヶ月）
・ 製品開発に必要なUNIX/Linux操作を習得（1ヶ月）
・ Windows/UNIX/Linux環境で製品ビルドおよびデバッグ操作ができる（1ヶ月）
・ 担当製品の開発に必要なC言語、SQL、シェルスクリプト、XMLの知識習得（1.5ヶ月）
・ 担当製品のソースを読み、機能A, Bの動作を理解して、簡単な障害修正のPG/PTができる（1.5ヶ月）
大タスクは2週間～2ヶ月くらいの粒度のものが扱いやすいです。
[Phase 2]
Phase1で立てた大タスクを1週間以内に収まるようにブレークダウンしてみましょう。
--- SAMPLE ---
・ 担当製品のテストを独力で実施できる（1ヶ月）
- 製品演習問1～20を実施（1週間）
- 製品演習問21～40を実施（1週間）
- N社実運用ケースのシステムを構築（1週間）
- N社実運用ケースのシステムテスト、修復、動作デモプレゼン（1週間）
これをやってみることで、未来の自分が何をやっているか、具体的なビジョンが見えてきます。
数カ月先の成長していく自分がイメージできて、ワクワクできるようなら完璧です。
[Phase 3]
直近1週間のタスクを1日単位にブレークダウンしてみましょう。
「製品演習問1～20を実施（1週間）」であれば、「4問/日」でも良いですし、緩急つけても良いです。
ポイントはあまり先の予定まで細かく決めないことです。
始めればわかることですが、すぐに計画の立て直しが必要になるはずなので、確度の低い未来の計画に時間をかけても無駄になります。
計画の運用
計画は作ってからが本番です。
毎朝、計画と進捗を照らし合わせて、必要に応じて調整していきましょう。
ここで抑えておきたいポイントは以下になります。
- 割り込み作業には柔軟に対応
- 期限が守れない場合、スケジュール全体を見直す
- スケジュールを見直す場合は、リーダーに合意を得る
- 遅延連絡は早いほどよい、気づいたら隠さず早めに相談
以下のようなことは、信頼を損ねるので気をつけてください。
・ 自分の予定だけを優先して、相談を突っぱねること
・ 予定をこっそり修正すること
・ 期限ギリギリになって、終わらないと伝えること
慣れないうちは、精度が悪いのは当たり前です。
遅延が見込まれる場合は「練習のチャンス」と思って、遅延理由とその後の対応策をセットで説明してみましょう。この経験が後の開発に活きてきます。
ここでの注意点は、残業グセをつけないことです。
怒られるのが怖くて無理な残業でカバーすることを覚えてしまうと、「脅せばいくらでも無理する人」という印象を相手に植え付けてしまうかもしれません。
まとめ
計画の運用と調整を繰り返すことで、「セルフ・マネジメント」が自然にこなせるようになると思います。
どうしても期間内にこなせない大タスクが出てきてしまった場合は、早い段階で切り捨てる勇気も必要です。この経験は実際のプロジェクトで、役に立つはずです（本当は役に立たないほうが良いのですが）。
最後に
みなさんが作り出す機能や製品を待っている人たちは、「予定どおり、望んだものが出てくるか」いつも不安です。
リモートワークが浸透した昨今、顔が見えない開発への不安がより強くなっているのではないでしょうか？
でも、彼らが本当に見たいのは、皆さんの顔ではなく「安心できる情報」です。
エンジニアの皆さんは「情報を扱うプロ」という意識を持って、まずは「見える計画」の作り方を習得していきましょう！