続・属人化を避ける - Qiita
このQiitaは、マサカリや編集リクエスト歓迎です。まだドラフトチックなので、不適切な表現などあるかもしれませんが、よろしくお願いします。 前回書いたQiita: 属人化を避けるの反響が大きかったので、各種コメントへの返信を兼ねて、いろいろ書きます だいじなこと 「アイデアを出すこと」と「コードを書くこと」は別 コードを書く際は、必ず属人化を避けるべきです。一方で、アイデアを出す際は、これは属人化というより個人の才能に依ります。いわゆる、スティーブジョブズのようなカリスマは、この「アイデアを出すこと」に特化した人物です この、「アイデアを出すこと」が脱属人化によって取り締まられてしまうのだけは絶対に避ける必要があります アイデアマンとコーダーの分離 一般に、アイデアに優れたメンバーがいた場合(Aさんとします)、Aさんはコーディングよりアイデアを出すことに集中すべきです。このとき、Aさんの仕
属人化を避ける - Qiita
属人化の理由 個人の問題 手抜きやバグを隠す たとえば、仕様書外の動作を実装し、それをプロジェクトで利用する 解雇されないための保険的行動 チームの問題 マニュアルを作る文化の欠如 他人のタスクに対する無関心 他人の監査なしにプロジェクトを更新可能 どうやって属人化を避けるのか 間違った対策 ○○さん以外にもマニュアルなしで操作できる人間を育成 育成した人が全滅すればやっぱり同じ状況 全員がすべてのプロジェクトに精通するとかはムリ 正しい対策 モジュールごとに仕様書を用意 間違って使うことが難しい仕様とする 即ち、仕様書を読まなくてもある程度正確に使える お互いにコードレビューさせる 具体的にはどうすれば良い？ テスト・仕様書・利用例 テストは仕様書のベースとなる 仕様書を見れば、深い動作がわかるようになる 仕様書を読まなくても、利用例を見れば使える 全員がテストできる環境を作る 前提条件
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
