仕事の進め方（Web系エンジニア）
チーム内で仕事の進め方について話す機会があったのでまとめたみた。
大切にしてるコンセプトは
「集合知を活かして非効率な仕事の発生確率を下げ、その結果みんながハッピーになるための時間を増やす。」
前提
目指している方向
- 各自が判断してガツガツ仕事をこなせるチーム
- 全てチーム内で判断するのは現実的ではないので、あくまで自己組織の範囲がちょっと広い状態
- 1から10までマネージャーに聞かなくても仕事を進められる状態にしたい
という前提条件。
結論から書くと、
いくつか案を出して比較検討。レビューを入れて集合知の良さを活かす。
というのが大切。
実装はレビューが入りますが、そもそも その実装で筋が良かったんだっけ？ ってことが意外に抜け落ちます。
思いついたから比較検討せずに実装。ってことをやってしまうと、
工数がかかったり、機能追加・実装・テストがしづらい構造になったり、後から結局作り直しを検討せざるを得なくなります。
その結果、無駄なことに時間を取られる確率が高くなる。
もしくは言われたことだけやるケース。
担当者が、他の人(Aさん）が言ったことをそのまま間に受けて進めると、
Aさんが気づかない設計の穴・思った以上に実装難易度が高かった・・・
などに気づかずに進めてしまうケースがあります。
この場合は長考するケースも多く、 かけた労力/時間の割りにプロダクトへの貢献が小さい ・・・ってことに繋がってしまいます。
そうなると、せっかく使った時間がもったいない。
仕事の進め方に気をつけるだけで、たくさんの時間が生まれます。
そして心に余裕が出来、成長スピードが加速。
プロダクトへの貢献も大きくなります。
というわけで、まとめた仕事の進め方はこれ。
# 設計・検討フェーズ - 実現したいことを把握する - 設計案をいくつか出す - それぞれの案のメリット・デメリット、実現できること・できないことを洗い出す - それぞれの案の工数を洗い出す（期間・時間/日数） - 上記の案を複数人で検討 - 複数人で設計の穴を見つける - 複数人で「実はxxxを解消したら第三案が一番いいのではないか？」的なことを考えてみる - どれにするか決める（工数・筋の良さ・実現可能性・メンテコストなどを考慮）
※複数人で考えるかどうかはタスクによります。
ボタンの位置修正だったり、簡単・個人が判断しても構わないものとかはサクッとやっちゃえばいいので。
※技術的な検証が終わらないと分からないこともあると思うので、
検証タスクに時間がかかるようなら、それは方針を決める前に別タスクとして調査するのかなと。
（例えば、Pub/Sub使った方が良さそうなんだけど、使ったことがないのでどれくらいの工数になるか分からない。なので取りあえず触ってみる・・・とか）
仕事の進め方について話す機会があったのでまとめたみた。
大切にしてるコンセプトは
「集合知を活かして非効率な仕事の発生確率を下げ、その結果みんながハッピーになるための時間を増やす。」
前提
目指している方向
- 各自が判断してガツガツ仕事をこなせるチーム
- 全てチーム内で判断するのは現実的ではないので、あくまで自己組織の範囲がちょっと広い状態
- 1から10までマネージャーに聞かなくても仕事を進められる状態にしたい
という前提条件。
結論から書くと、
いくつか案を出して比較検討。レビューを入れて集合知の良さを活かす。
というのが大切。
実装はレビューが入りますが、そもそも その実装で筋が良かったんだっけ？ ってことが意外に抜け落ちます。
思いついたから比較検討せずに実装。ってことをやってしまうと、
工数がかかったり、機能追加・実装・テストがしづらい構造になったり、後から結局作り直しを検討せざるを得なくなります。
その結果、無駄なことに時間を取られる確率が高くなる。
もしくは言われたことだけやるケース。
担当者が、他の人(Aさん）が言ったことをそのまま間に受けて進めると、
Aさんが気づかない設計の穴・思った以上に実装難易度が高かった・・・
などに気づかずに進めてしまうケースがあります。
この場合は長考するケースも多く、 かけた労力/時間の割りにプロダクトへの貢献が小さい ・・・ってことに繋がってしまいます。
そうなると、せっかく使った時間がもったいない。
仕事の進め方に気をつけるだけで、たくさんの時間が生まれます。
そして心に余裕が出来、成長スピードが加速。
プロダクトへの貢献も大きくなります。
というわけで、まとめた仕事の進め方はこれ。
# 設計・検討フェーズ - 実現したいことを把握する - 設計案をいくつか出す - それぞれの案のメリット・デメリット、実現できること・できないことを洗い出す - それぞれの案の工数を洗い出す（期間・時間/日数） - 上記の案を複数人で検討 - 複数人で設計の穴を見つける - 複数人で「実はxxxを解消したら第三案が一番いいのではないか？」的なことを考えてみる - どれにするか決める（工数・筋の良さ・実現可能性・メンテコストなどを考慮）
※複数人で考えるかどうかはタスクによります。
ボタンの位置修正だったり、簡単・個人が判断しても構わないものとかはサクッとやっちゃえばいいので。
※技術的な検証が終わらないと分からないこともあると思うので、
検証タスクに時間がかかるようなら、それは方針を決める前に別タスクとして調査するのかなと。
（例えば、Pub/Sub使った方が良さそうなんだけど、使ったことがないのでどれくらいの工数になるか分からない。なので取りあえず触ってみる・・・とか）
