実施経緯
今まではエンジニアの方々が枠を作って、その中で業務をしていました。しかし、今回はタスクを受けてから自走する部分が多く、多少なりともエンジニア業務の真髄を体験しました。整理、アウトプットも兼ねてまとめてみようかと思います。また最後に自分なりのマニュアルを作成してみました。
タスクを受けてからの大まかな流れ
1 タスクを与えられる
2 ビジネス側から仕様書・ワイヤーが届く
3 エンジニアの目線でそれに対して提言していく
4 それをもとに工数を見積もっていく
5 実際に開発スタート！
自分で考えて、やってみたこと
- 与えらてたタスクをざっと聞いて、実装方法がイメージする
- ビジネス側からの仕様書やワイヤーをみて、UI・UX的な部分をイメージする
- 実装に必要な機能を洗い出す(ex 検索機能 登録機能 編集機能 ダウンロード機能...)
- そこから実際に時間を割り振りする(ex 検索機能 1day, 登録機能 2day....)
- 開発スタート！
=> 結果 爆死
なぜ爆死したのか
1 実装に必要な機能を洗い出しきれていなかった
2 エンジニアの目線で提言できず、機能を最適化することができなかった
ex 機能の必要性、DB設計による制約など..
3 時間の割り振りがアバウトすぎた
4 期待値で考えてしまった
5 詰まったときに時間をかけすぎてしまった
6 実装機能の参考ページがたくさんありすぎて惑わされた
自己(事故)分析
1・2番は圧倒的に想像力や経験が不足している
対策
それが全てだが、不足していると言っても意味がないので今できることとして
似たようなツールやサービスを調べて、実際に触ってみる
3・4番は実装機能の概算を誤り、期待値で時間を割り振ってしまった。一度詰まってしまうと、崩れてしまう。
対策
機能を調べる過程で仕様技術や経験に基づき、期限日から逆算して割り振っていく。これくらいできるだろうとう甘い考えはすてる。自ずと自らを殺しめることになる。
5番は上司への情報共有不足。
対策
時間を決め、コミュニケーションツールを使って報告する
日報などで一日の流れを報告する
6番は優れた記事を選別する能力
対策
基準を設ける
新しめの記事 -> いいねの多い記事 -> 英語の記事(stackoverflow...)
google の拡張機能を上手に使う
ato ichinen: 一年以内の記事を優先して出してくれる。
自分のルールを決める
1 仕様理解
2 不安な箇所、疑問点はここで一度解消
3 その後タスク分解と見積り
4 それらを振り返り、不安であればもう一度相談
=> 意外と自分で気づけない箇所も多いから機会があればレビューを受ける方が良いかもしれない
5 実装しやすい場所から取り掛かる
6 実装を終えて、見積もりとのブレを分析する
7 作業に詰まったら 1h粘る -> 相談 -> 1.5h 粘る ->相談 と時間を決める
8 エンジニアの方々も作業をしているため、質問にも優先度をつける
ex) 口頭 or slack or プルリクで重要度をわける
9 プルリク時は細かくを意識、10ファイル変更は避けていきたい。いや避ける。
10 日報は次の日に書く。前日の振り返り、見積もり分析と本日のタスクを記載
=>これは日報と言えるのかわかりませんが..
最後に
マニュアル作成とQiitaのようなpublicな場所で公開したことで、強い拘束力が生じます。私のような。割と口だけで終わってしまうタイプは、こういった試みは効果的だと思います。
自分の仕事の型を見つけたり、見つめ直したりするにはとてもいい方法だと思います。ぜひ一度マニュアル化、もしくは従来自分の型などを整理してみてください。
できればみなさんの仕事の型やマニュアルなどがありましたら、コメントしてくださると嬉しい限りです。
参考
初心者エンジニアにおすすめしたい「進捗どうなった？」と言われないための仕事の進め方
https://qiita.com/soyanchu/items/d1cb9785fc211941a009