このQiitaは、マサカリや編集リクエスト歓迎です
属人化って？
「○○さんがいないとプロジェクトが進まない！」という状況
例えば…
- ある手続きについて、マニュアルがない、仕様書もない
- マニュアルなしで操作できるのが○○さん一人
より強い表現をすれば、○○さんが任意にプロジェクトの進行を止められる状態
用語
| 用語 | 説明 |
|---|---|
| プロジェクト | チーム全体で進めるもの |
| タスク | 個人またはチームの一部で進めるもの |
| モジュール | プロジェクトの断片で、タスクは基本的にモジュールを作る |
属人化の理由
個人の問題
- 手抜きやバグを隠す
たとえば、仕様書外の動作を実装し、それをプロジェクトで利用する - 解雇されないための保険的行動
チームの問題
- マニュアルを作る文化の欠如
- 他人のタスクに対する無関心
- 他人の監査なしにプロジェクトを更新可能
どうやって属人化を避けるのか
間違った対策
- ○○さん以外にもマニュアルなしで操作できる人間を育成
- 育成した人が全滅すればやっぱり同じ状況
- 全員がすべてのプロジェクトに精通するとかはムリ
正しい対策
- モジュールごとに仕様書を用意
- 間違って使うことが難しい仕様とする
- 即ち、仕様書を読まなくてもある程度正確に使える
- お互いにコードレビューさせる
具体的にはどうすれば良い？
テスト・仕様書・利用例
- テストは仕様書のベースとなる
- 仕様書を見れば、深い動作がわかるようになる
- 仕様書を読まなくても、利用例を見れば使える
全員がテストできる環境を作る
- 前提条件の少ないテスト
- たとえば、「テストしようと思ったら、DBが初期化されてなくてテストできなかった！」を避ける
- この時、「データベースくらい自分で初期化しろ！」ではなく、テスト内で自動的にDBやテーブルを生成させるようにする
- 一般に、テストは単体テストであるように作ること(依存性や、環境の前提条件が可能な限り少ない) (2017/10/23追記)
- モジュール化
- モジュール単位でリポジトリが存在し、モジュール単位でテストが可能
- プロジェクトの
IssueやPull Requestsが混雑しなくなる - 気楽に問題を報告できるし、問題の原因がどこにあるかを特定しやすい
相互にチェックしあう体制
- コードレビューのルーチンワーク化
- あるモジュールをレビューする人が複数存在する環境
- プロジェクトやモジュールの
masterブランチへのアクセス権を限定し、マージの際に品質チェックが入るようにする - このタイミングで、仕様書外の動作を弾くことができる (2017/10/23追記)
やってはいけないこと
- 仕様書やマニュアルの確定
- これらもしっかりとVCSで管理し、問題点を共有
- コロコロ変わる仕様書はダメだが、全く変わらない仕様書は負の遺産を生みだす
- 仕様書も、悪いと思ったら悪いといえるようにしよう
- 仕様書が大量に存在 (読むのが大変)
- 間違って使うことが難しいようにする
- モジュール間でインターフェースを統一
- 利用例を充実させる
- プロを使わない
- すなわち、「質問するな、調べろ」が徹底されてしまうのはよくない
- 属人化の排除を行う目的は、「誰でも、ある程度の短時間で理解ができる」状況を作ること
- ある程度調べて分からなければ、やはりその道のプロに聞くべき