GitHub
プログラミング
環境構築
プログラミング教育
新人プログラマ応援
More than 1 year has passed since last update.

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


属人化って?

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

例えば…


  • ある手続きについて、マニュアルがない、仕様書もない

  • マニュアルなしで操作できるのが○○さん一人

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


用語

用語
説明

プロジェクト
チーム全体で進めるもの

タスク
個人またはチームの一部で進めるもの

モジュール
プロジェクトの断片で、タスクは基本的にモジュールを作る


属人化の理由


個人の問題


  • 手抜きやバグを隠す

    たとえば、仕様書外の動作を実装し、それをプロジェクトで利用する

  • 解雇されないための保険的行動


チームの問題


  • マニュアルを作る文化の欠如

  • 他人のタスクに対する無関心

  • 他人の監査なしにプロジェクトを更新可能


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


間違った対策


  • ○○さん以外にもマニュアルなしで操作できる人間を育成


    • 育成した人が全滅すればやっぱり同じ状況

    • 全員がすべてのプロジェクトに精通するとかはムリ




正しい対策


  • モジュールごとに仕様書を用意

  • 間違って使うことが難しい仕様とする


    • 即ち、仕様書を読まなくてもある程度正確に使える



  • お互いにコードレビューさせる


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


テスト・仕様書・利用例


  • テストは仕様書のベースとなる

  • 仕様書を見れば、深い動作がわかるようになる

  • 仕様書を読まなくても、利用例を見れば使える


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


  • 前提条件の少ないテスト


    • たとえば、「テストしようと思ったら、DBが初期化されてなくてテストできなかった!」を避ける

    • この時、「データベースくらい自分で初期化しろ!」ではなく、テスト内で自動的にDBやテーブルを生成させるようにする

    • 一般に、テストは単体テストであるように作ること(依存性や、環境の前提条件が可能な限り少ない) (2017/10/23追記)



 


  • モジュール化


    • モジュール単位でリポジトリが存在し、モジュール単位でテストが可能

    • プロジェクトのIssuePull Requestsが混雑しなくなる

    • 気楽に問題を報告できるし、問題の原因がどこにあるかを特定しやすい




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


  • コードレビューのルーチンワーク化


    • あるモジュールをレビューする人が複数存在する環境



  • プロジェクトやモジュールのmasterブランチへのアクセス権を限定し、マージの際に品質チェックが入るようにする

  • このタイミングで、仕様書外の動作を弾くことができる (2017/10/23追記)


やってはいけないこと


  • 仕様書やマニュアルの確定


    • これらもしっかりとVCSで管理し、問題点を共有

    • コロコロ変わる仕様書はダメだが、全く変わらない仕様書は負の遺産を生みだす

    • 仕様書も、悪いと思ったら悪いといえるようにしよう



 


  • 仕様書が大量に存在 (読むのが大変)


    • 間違って使うことが難しいようにする

    • モジュール間でインターフェースを統一

    • 利用例を充実させる



 


  • プロを使わない


    • すなわち、「質問するな、調べろ」が徹底されてしまうのはよくない

    • 属人化の排除を行う目的は、「誰でも、ある程度の短時間で理解ができる」状況を作ること

    • ある程度調べて分からなければ、やはりその道のプロに聞くべき




こっちも読んでね

続・属人化を避ける