自分より優秀な技術者に対してのレビュー

自分よりも知識がある技術者の生成物に対して、品質を保証しなければならない場合の対処方法を教えて下さい。

立場上、私よりも知識のある者が書いたコードを検収しなければならないのですが、彼のレベルが突出しているため、プロジェクト内で彼のソースを理解できる人がほとんど居ません。

プロジェクト内のレベルに合わせて、実装・設計共にシンプルにするように指示をしても、「こうすべきなんです」の一点張りで全く指示に従いません。

言っていることが正しい可能性もあるのですが、少なくとも私の技術レベルでは到底理解できません。せっかくのプロジェクトがスキルアップできるチャンスを潰したくないと言う思いもあるのですが、何かよい対処法はないでしょうか？

まとめると、

1. このままでは、彼のソースの品質を保証できない。少なくとも、彼が居なくなればソースをメンテできない。

2. かといって、せっかくのレベルの高い（かもしれない）技術を無駄にもしたくない

です。

No.11 ベストアンサー 回答者： GoF 回答日時： 2005/04/09 12:47

#6です。

>特に、マニアックなコードを書くプログラマ側を擁護する意見が少ないので、ありましたらお願いします。

自分も以前、コードコンプリートやデザインパターンなどを
読み、ある意味で難解なコーディングを書いていました。
(半年後に、やっと意図を理解されるような事もありました)

確かに、コードは「自分」では美しく見え、柔軟な仕様変更にも対応するのは間違いないのですが
その分 前知識がないものには非常に難解になります。
例えば、パッケージ、カーネル相当や標準ライブラリになるような未来に続くシロモノなら、問題ありません。
しかし、通常の請負のアルゴリズムは一期一会的なものになるかと思います。
忘れた頃に過去のプロジェクトの仕様変更・不具合がやってきます。
初見で高度なアルゴリズムをメンテできる人はいません。
二重三重アサインを続けていきます。
いずれ一人の力がいかに小さいかを痛恨するときが必ずきます。

そいう意味でも、現状を放置することは彼にも望ましくありません。
彼は、自分の確固としたテリトリを確保したいフェーズなんだと思います。
おだてて、なだめて 上手にステップアップさせてあげるべきだと思います。

小うるさかったら、すいません。

この回答へのお礼

> しかし、通常の請負のアルゴリズムは一期一会的な
> ものになるかと思います。

ご自身の体験談も踏まえてのご意見で、大変参考になりました。上手にステップアップするように導き、将来の力となるようにしたいと思います。

どうもありがとうございました。

お礼日時：2005/04/11 00:42

No.10 回答者： sha-girl 回答日時： 2005/04/09 11:17

>例えば、呼ばれているだけで処理はない空っぽの関数がたくさんあります。

将来の拡張性のためだそうです。
コードってC++あるいっはjavaでしょうか。
汎用的なクラスだとすると、オーバーライドできるように
仮想関数を作っておいたりとか？
(勿論そんな汎用的なクラスを作られてもドキュメントがないと誰も使えませんが・・・)

あとプロジェクトでコードを書くときの決まりごとってありますか？
例えば関数には必ず引数と概要のコメントを書いたり
ファイル名、変数名や関数名に命名規則を設け
コメントについても書式をプロジェクト共通する。
例えばCの関数なら
/*
　概要:ランダム数値の生成
　param pDouble:[in,out] aに格納された値を元にランダム数値を生成し上書きする
　戻り値:無し
　作成日:2005.04.09
　作成者:sha-girl
*/
void Fnc_Randam( int* pDouble){
　(略) // 2005.04.10 11th_style この部分の参照が不正だったので変更
}


>特に、マニアックなコードを書くプログラマ側を擁護する意見が少ないので、ありましたらお願いします。
マニアックなコードを書く人にとってはあまり自覚がないと思います。
だから擁護派が少ないのかと。私も書いてるかもしれないです。

No.9 回答者： t_nojiri 回答日時： 2005/04/09 08:26

>例えば、呼ばれているだけで処理はない空っぽの関数がたくさんあります。

将来の拡張性のためだそうです。

そういう関数でも、メモリが厳しいなどの条件だと呼び出した時点で、キャッシュに乗り切らない場合、I/Oが発生します。
そういうのは、追加しなくてはならない時に追加するもので、#ifdefなり使ってプリプロセッサで落として、必要ないときにはコンパイラに渡さないようにしなくちゃならんと思いますが・・・。

この回答へのお礼

その辺は言語や環境によると思います。

彼の技術が本当に優れているかと言う観点ではなく、このような場合にどう対処すべきかと言う観点でお願いします。

特に、マニアックなコードを書くプログラマ側を擁護する意見が少ないので、ありましたらお願いします。

お礼日時：2005/04/09 08:33

No.8 回答者： sha-girl 回答日時： 2005/04/08 15:48

言語レベルで理解できないのであれば、11th_styleさんの勉強不足。

言語レベルではなく、アルゴリズム的に複雑怪奇なことをしているなら、
その人が優秀という事に対して疑問。
勿論、複雑なアルゴリズムでないと実現できない場合は別です。
しかし、11th_styleさんは彼のレベルを高いと評価しているので、恐らく前者の方ではないかと思います。

ところでそんなに理解できないソースってどんなものですか、
インラインアセンブラ使いまくりのソースコードとか、、

オープンソースのソースコード、例えばzlibのコードとかみると
理解に苦しむ事は多々ありますが・・・・
でも実際それを使えばデータ圧縮できるわけですから関心します。
例えるならそんな感じでしょうか。
(zlib内でバグが発生しても対処は難しい・・・)


あまり反抗的なようですと技術力以前に問題があるのでは？？
ただ、その人抜きでプロジェクトがなりたたないのだとすると、
全体の技術力の底上げが必要でしょう。

この回答へのお礼

> ところでそんなに理解できないソースってどんなものですか、

例えば、呼ばれているだけで処理はない空っぽの関数がたくさんあります。将来の拡張性のためだそうです。

> ただ、その人抜きでプロジェクトがなりたたないのだとすると、
> 全体の技術力の底上げが必要でしょう。

これはないです。

反抗的ではあるのですが、反抗には相当の自信と根拠があるらしく、その言い分に聞く耳を持つ必要が本当にないのか、と思ってしまったわけです。

お礼日時：2005/04/09 07:48

No.7 回答者： matyrcry 回答日時： 2005/04/08 12:31

データフローとか基本的なコーディングの流儀について（暗黙のことも多い

ですが）あらかじめ指示が与えられるか、もしくは自分で資料を作成して提
出することのどちらかをを仕様に盛り込んでいるのが普通だと思います。
指示すると技術を生かせないのなら、本人に作らせるしかないですね。
フローチャートくらいからドキュメントを揃えていくのがいいんじゃな
いでしょうか。
ソフトは使い回し、焼き直しの固まりなんで、全くゼロの状態からドキ
ュメントを整備するとなると膨大な時間がかかりますが、どうせいつ
かは必要な作業なんで、良い機会だと思います。
他人が検証できないなら、自分で検証して保障するしかないんだし、
本人のスキルアップにもなりますよ。

この回答へのお礼

ドキュメントに関しては、時間の都合と言われています。今回は書かせてみることにします。

お礼日時：2005/04/09 07:34

No.6 回答者： GoF 回答日時： 2005/04/08 04:17

彼が、責任を取らなければいけない指示する立場の人間に反抗するのであれば

それを他人が理解できるような、詳細設計書の提出と
膨大なテスト仕様書を提出させるようにすればよいです。
コード内に、ちゃんとコメントを記述させるのも忘れずに。
さらに、彼以外で最も優秀な者たちへレビューを行うように
指示すればいいでしょう。

2つの選択肢が用意されます。
1) 膨大な努力をして、他人に自分の技術を教え込む
2) 妥協して、担当が理解できる範囲で「最大限」にこだわる
今のメンバのスキルには 2) で十分だと思います。

ちなみに彼のようなタイプはドキュメント作業を
大変嫌う傾向がありませんか?
それであれば、かなり有効な手段だと思います。

彼は、まさに
「ソフトウェア開発のダイナミズム」という書籍の
#13「部屋に閉じこもった男に注意しろ」に該当します。

群を抜いて優秀な書籍だと思うので、プロジェクトマネージャであれば
ぜひ購入して読まれることをお勧めします。

古いですが、amazonでもまだ取り扱っているようです。

この回答へのお礼

今回は、ドキュメント、コメント、テスト仕様書を用意させてみることにしました。彼はドキュメントはしっかり書く方ですが、今回はスケジュールの短さを理由に書いていません。仕様を満たす最終範囲を作るだけであれば、そこまできついスケジュールではないつもりでいます。

後、拡張のためと大量につけてあった未実装の関数を全て消すよう言ってみます。これは、未実装関数を残すならそのテスト仕様書も予め書いておくように、と言うことと天秤にかければ、消してくれるのではないかと期待もしています。

書籍も参考にしてみます。ありがとうございます。

お礼日時：2005/04/09 07:31

No.5 回答者： toshi7607 回答日時： 2005/04/08 02:07

彼のレベルが高いと思うのは、あなたの勘違いです。

優秀なプログラマは他人が理解しやすいようにプログラムを作ります。
プログラムの世界でもsimple is bestなのです。

この回答へのお礼

ここまでスパっと言われると、なんだかすっきりしますね(笑)。私もsimple is bestだとは思います。

お礼日時：2005/04/09 07:24

No.4 回答者： tintagel 回答日時： 2005/04/08 01:37

＞1. このままでは、彼のソースの品質を保証できない。

～
＞2. かといって、せっかくのレベルの高い～
この２つからリスクを考えれば悩む必要はないと思います。

１．は11th_styleさんは顧客または自社のプロジェクトに従事していると思いますが将来問題が発生したときの損害を考慮した場合に許容できますか？

２．は別の方法で要員のレベルアップは可能ではないですか？

技術は日進月歩です。
過去にはコンピュータの速度不足をコードで補う時代がありましたが現在は不要です。それから考えれば高度なコーディング技術も遠からず陳腐化するのは目に見えています。

今、本当に高度なコーディング技術は重要でしょうか？

（ちなみに本当に高度であれば誰も思いつかないが説明されれば誰でも容易に理解できるものですよ。）

彼は技術者の側面から考えた場合、恐らく自分の考えを他の人に理解してもらうことが苦手または面倒になっていないでしょうか？
（今の問題をクリアできるレベルまで達すれば頼もしい技術者となるのですが・・・）

今の現状でコードを作ってもらうのに問題があるならそれ以外の役目（ソースの品質向上やコードのレビュア）を担ってもらなどの方法も検討するのも良いかもしれません。

参考になるでしょうか？

この回答へのお礼

彼は自分の考えはよく説明してくれます。オープンソースのプログラムや設計に関する書籍を色々読んでおり、「～の～章に書いてあります」と根拠を言うのですが、私にはその引用先がわかりません。

私がレベルが低過ぎるか、もしくは、他人にわからせるところまで説明できるレベルには至ってないということかもしれません。

お礼日時：2005/04/09 07:23

No.3 回答者： yangwenli 回答日時： 2005/04/08 00:35

昔はこういう職人仕事も許されたんですけどね＾＾；

いまは、保守性を重視する時代なのであまりマニアックなコードは書かない流れになってますね。

昔と違ってあまりコーディング力がなくてもそこそこ動くものが作れる時代になったので、いまはシンプルな作りの方がいいと思います。

この回答へのお礼

こういう意見を聞きたかったです。

職人仕事に対して、昔はどのように品質保証していたのでしょう？　職人自身が保証するんでしょうか？

お礼日時：2005/04/09 07:17

No.2 回答者： t_nojiri 回答日時： 2005/04/08 00:22

個人でプログラム作ってるんじゃないんだから、他人がメンテ出来ないコードをそのまま出す時点で、わがままでしょう。

その人が一生メンテするプログラムなら、そのままでもいいですが絶対そんな事は無いので、新人や知らない人間が見てある程度見通しが付くようにソースにコメントなり、解説書作らせるなりしないと、その人が抜けた時点でプロジェクトのコアな部分がブラックボックスになります。

この回答へのお礼

ありがとうございます。

他の人員がレベルアップできれば、ブラックボックスにはならないのではと思っていたのですが・・・。

お礼日時：2005/04/09 07:16