このQiitaは、マサカリや編集リクエスト歓迎です。まだドラフトチックなので、不適切な表現などあるかもしれませんが、よろしくお願いします。
前回書いたQiita: 属人化を避けるの反響が大きかったので、各種コメントへの返信を兼ねて、いろいろ書きます
だいじなこと
「アイデアを出すこと」と「コードを書くこと」は別
コードを書く際は、必ず属人化を避けるべきです。一方で、アイデアを出す際は、これは属人化というより個人の才能に依ります。いわゆる、スティーブジョブズのようなカリスマは、この「アイデアを出すこと」に特化した人物です
この、「アイデアを出すこと」が脱属人化によって取り締まられてしまうのだけは絶対に避ける必要があります
アイデアマンとコーダーの分離
一般に、アイデアに優れたメンバーがいた場合(Aさんとします)、Aさんはコーディングよりアイデアを出すことに集中すべきです。このとき、Aさんの仕事は利用例や仕様書の概要を組み立てることです。一方、この利用例や仕様書の概要をもとにプログラムを作成する際、Aさんはアイデアを出すことに集中しているので、主にほかの人が担当することになります。このとき、コードを書く人が先の属人化を避けるためのプロセスを実行するべきといえるでしょう
もちろん、Aさんはアイデアだけ、BさんはAさんのアイデアを実現するだけ、という風に完全に分離しろというわけではありませんが…
アイデアを出すことは属人化していいの？
はい、構いません
アイデア生成プロセスはむしろ個人のスキルなので、このプロセスを脱属人化させてはいけません。その代わり、アイデアから生まれた製品は脱属人化を図ってください。ただし、チームとしてアイデアを出すことが仕事の場合（例えばコンサルティングファームに所属している場合など）はこの限りではありません
では、どのようにプロジェクトを回すのか
ここからは、理想論がある程度混ざってきますので、皆さんの環境に応じて適宜読み替えてください
1. アイデアを持ち寄る方法を設ける
良い考えは共有されるべきです。とりあえず批判を抜きにして、個人個人が「こうするべき」と思ったことを持ち寄ります。会議を開いたり、もしくは、githubなどのProject機能を用いて共有します。このとき、細かい仕様書は確定させず、どのような使い方ができれば便利かを重視してください
2. 利用例が定まってから、仕様書を固める
カリスマ的アイデアにせよ、普遍的アイデアにせよ、利用例(入力と出力の概要)をさらに精錬し、仕様書(契約プログラミングにおける、前提、不変、事後条件を定義)とします。この段階は、メンテナンス性を高め、属人化を弾くことを意識します
(2017/12/15 編集リクエスト適用 不変を普遍と書く恥ずかしいミスをしてました)
さらに、テスト駆動開発を採用している場合は、この段階でテストコードを書きます。テストコードは「利用例」をもとに、予測される動作を網羅的に記述します
3. 仕様書が固まったら、それに従うようにコードを書く
仕様書外の動作や、契約が満たされないことは言語道断ですが、そもそも仕様書通りに動かすことが難しかったりする場合は1か2に戻ります。決して、仕様書通りに動かせないからといって自分で仕様を変更してはいけません
コードは疎結合性を守り、必ずテストを実行してください。テストが用意されていない場合は、ここでテストを書きます
4. コードが完成したら複数の他人にコードレビューをしてもらう
このプロセスによって属人化を完全に排除します。レビュワーはコーディング規約はもちろん、疎結合性および仕様書との適合性について検証をする必要があります
もちろん、完成前にレビューをしてもらっても構いません