LoginSignup
263

More than 5 years have passed since last update.

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

属人化って?

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

例えば…

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

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

用語

用語 説明
プロジェクト チーム全体で進めるもの
タスク 個人またはチームの一部で進めるもの
モジュール プロジェクトの断片で、タスクは基本的にモジュールを作る

属人化の理由

個人の問題

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

チームの問題

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

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

間違った対策

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

正しい対策

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

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

テスト・仕様書・利用例

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

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

  • 前提条件の少ないテスト
    • たとえば、「テストしようと思ったら、DBが初期化されてなくてテストできなかった!」を避ける
    • この時、「データベースくらい自分で初期化しろ!」ではなく、テスト内で自動的にDBやテーブルを生成させるようにする
    • 一般に、テストは単体テストであるように作ること(依存性や、環境の前提条件が可能な限り少ない) (2017/10/23追記)

 

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

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

  • コードレビューのルーチンワーク化
    • あるモジュールをレビューする人が複数存在する環境
  • プロジェクトやモジュールのmasterブランチへのアクセス権を限定し、マージの際に品質チェックが入るようにする
  • このタイミングで、仕様書外の動作を弾くことができる (2017/10/23追記)

やってはいけないこと

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

 

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

 

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

こっちも読んでね

続・属人化を避ける

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
263