はじめに
私は某SIerでSEをやっています。最近開発案件(メンバ5名程度)のプロジェクトリーダーを任されていて、そこで運用しているプロジェクト基本ルールについて、結構よさげだったので考えとともに共有してみたいと思いました。
当たり前のことかもしれませんが、頭の整理程度に書いていきたいと思います。
背景
プロジェクト基本ルールを定めた理由としては以下があります。
メンバそれぞれに方針の話をするのが面倒(あたりまえ)
当たり前ですが、明言されていないプロジェクト方針は質問されます。
決まっている方針は、何度も説明する羽目になりますし、決まっていない方針はその場で決めて進めますが、忘れてしまっておりバラバラな指示を出して方針がぶれます。
ルールを明文化することで属人化を防ぐ
今のプロジェクトは、メインで開発していた人がプロジェクトを抜けてしまっております。また、その人の中で持っていて明文化されていなかったルールがあり、現在それを想像して理解するフェーズが発生しています。これはかなり無駄なので今からでもルールを明文化しようと思いました。
SIerのプロジェクトは人を入れ替えることも多々ありますので、極力俗人化されている知識が無い方が良いです。
タスクのフローを用いて、誰がどこまでやるかを定義する
これを決めることで、誰がどこまでやって、次に誰に渡すのかを定義しておきます。そうすることで、誰にも割り当てられていないタスクがなくなります。
メンバのタスク実行速度アップ、適切に処理させる
メンバからこんな声がありました。
「聞くほどのことではないと思ったので、迷ったが聞かなかった」
こういった迷いに無駄に時間を費やしていたり、聞かずに誤った処理の仕方を行っていて手戻りになるといったことが起こります。ルールを明文化することでこれらも対処でき、結果的にメンバ全員のタスク速度アップ、適切にタスク処理をさせられます。
ルール一覧
※基本方針として、以下2点を常に意識
- アクション後はチャットで共有する
- 常にどこかに記録を残す(会話だけで終わらせない)
読み込み資料一覧
プロジェクト参画後に最低限読み込む資料を決めておきます。
どこまで読めば、読み込みタスクは完了するか、頭に最低限入れておく知識を本ルールで縛るイメージです。
スケジュール管理表更新ルール
SIerのプロジェクトではWBSやEVMでタスクとスケジュールを管理しがちです。
これをどういった頻度でいつ更新するのかを明言しておきます。
また、どこにスケジュールを記載するかも一緒に記載しておくと楽です。
プロジェクト内での質問起票ルール
基本的にプロジェクト内での話はどこかに記録をとり、同じ質問を繰り返さない、ほかのメンバに展開する、といった意識をすることが大事だと考えます。
私たちのプロジェクトでは、質問票を使用し以下のフローで運用しています。
- 質問者は質問表に起票
- プロジェクト用チャットでリーダに共有
- リーダが誰が回答者か判断
- プロジェクトメンバ内で回答可能なら質問票に回答
- 他ならリーダが聞きに行き質問票に回答
- リーダが質問者に回答済みであることを報告
- 質問者が回答を確認し、完了ステータスとする
成果物作成後手順
※完了、レビュー中などのステータスはEVM or WBSで管理されているものとします。
※レビュー指摘は指摘管理表で管理されているものとします。
- 成果物作成者はEVM or WBSの該当タスクステータスを「成果物作成完了」とする
- 成果物配置場所(メンバ全員がみられる場所)に成果物を配置
- プロジェクト用チャットでレビュー担当者に成果物と成果物配置場所について連絡
- レビュー者レビュー実施
- レビュー後、指摘管理表に指摘を記載
- 成果物作成者にプロジェクト用チャットで報告
- 成果物作成者は指摘管理表の指摘対応を行う
- 完了したら、成果物作成者はEVM or WBSの該当タスクステータスを「作成完了」とする
設計書修正手順
- プロジェクト用チャットでどの設計書を修正するか報告
- 設計書修正を行う。（どこを変えたかわかるように色を変える）
- 同じ色で該当箇所がわかるように改版履歴を記載する
- プロジェクト用チャットでレビュー者を立て、レビュー実施
さいごに
上記のような基本ルールを運用することでメンバからは「迷いがなくなりスムーズにタスク実行ができるようになった」という声があったのでやってよかったなと思います。
ルールを明言するだけで効果があるならやらない手はないのでは？
今後明言すべきルールがあれば追加していきたいと思います。
あたりまえのことしか書いてませんが、誰かの参考になれば幸いです。