このQiitaは、マサカリや編集リクエスト歓迎です

属人化って？

「○○さんがいないとプロジェクトが進まない！」という状況

例えば…

• ある手続きについて、マニュアルがない、仕様書もない
• マニュアルなしで操作できるのが○○さん一人

より強い表現をすれば、○○さんが任意にプロジェクトの進行を止められる状態

用語

属人化の理由

個人の問題

• 手抜きやバグを隠す
  たとえば、仕様書外の動作を実装し、それをプロジェクトで利用する
• 解雇されないための保険的行動

チームの問題

• マニュアルを作る文化の欠如
• 他人のタスクに対する無関心
• 他人の監査なしにプロジェクトを更新可能

どうやって属人化を避けるのか

間違った対策

• ○○さん以外にもマニュアルなしで操作できる人間を育成
  • 育成した人が全滅すればやっぱり同じ状況
  • 全員がすべてのプロジェクトに精通するとかはムリ

正しい対策

• モジュールごとに仕様書を用意
• 間違って使うことが難しい仕様とする
  • 即ち、仕様書を読まなくてもある程度正確に使える
• お互いにコードレビューさせる

具体的にはどうすれば良い？

テスト・仕様書・利用例

• テストは仕様書のベースとなる
• 仕様書を見れば、深い動作がわかるようになる
• 仕様書を読まなくても、利用例を見れば使える

全員がテストできる環境を作る

• 前提条件の少ないテスト
  • 「テストしようと思ったら、DBが初期化されてなくてテストできなかった！」を避ける
  • この時、「データベースくらい自分で初期化しろ！」ではいけない
  • テスト内で自動的にDBやテーブルを生成させるようにする

• モジュール化
  • モジュール単位でリポジトリが存在し、モジュール単位でテストが可能
  • プロジェクトのIssueやPull Requestsが混雑しなくなる
  • 気楽に問題を報告できるし、問題の原因がどこにあるかを特定しやすい

相互にチェックしあう体制

• コードレビューのルーチンワーク化
  • あるモジュールをレビューする人が複数存在する環境
• プロジェクトやモジュールのmasterブランチへのアクセス権を限定し、マージの際に品質チェックが入るようにする

やってはいけないこと

• 仕様書やマニュアルの確定
  • これらもしっかりとVCSで管理し、問題点を共有
  • コロコロ変わる仕様書はダメだが、全く変わらない仕様書は負の遺産を生みだす
  • 仕様書も、悪いと思ったら悪いといえるようにしよう

• 仕様書が大量に存在 (読むのが大変)
  • 間違って使うことが難しいようにする
  • モジュール間でインターフェースを統一
  • 利用例を充実させる

• プロを使わない
  • すなわち、「質問するな、調べろ」が徹底されてしまうのはよくない
  • 属人化の排除を行う目的は、「誰でも、ある程度の短時間で理解ができる」状況を作ること
  • ある程度調べて分からなければ、やはりその道のプロに聞くべき