上司としての役割

最近は、部下のプログラミングを直接指導する機会が減っているが、昨日はパフォーマンスチューニングのために処理の並列化(マルチスレッド化)を、ペアプログラミングにより一時間半ほどで行った。JavaではなくC++なのでコードの修正は多少手間ではあるが、短時間に終えることができた。実際の作業は、リファクタリングと言っても良い内容であった。

作業手順は、口頭で事前に伝えていたのであるが、頭の中で理解しているプログラムの詳細な修正方法は担当者で異なっていたようである。実際に修正方法の詳細を指示しながら目の前でプログラムを修正させることにより、私が意図していた修正方法を理解してもらうことができた。

私の考えを口頭で聞いただけで、担当者が同じ修正方法を必ずしも正しく理解できなかった理由は、

• 私が普通に行っている「C++での内部クラス定義によるエンクロージングクラスと内部クラスのインスタンス間での密な関係を利用した設計・プログラミング」を、担当者が行ったことがなかった。
• そのため、口頭で聞いただけでは、その設計方法を頭に浮かべることができなかった。

実際、今回の修正方法は、色々な方法で説明するよりも、実際にコードを修正させて目の前で見せることで一回で理解できる。

[今日の教訓]

• コードレビューやペアプログラミングなどにより、部下のプログラミングのサポートのために私自身の時間をもっと多く費やすことで、知識の伝達を行う必要がある。
• 一方で、私が普通に行っているが開発者全員が理解していない事柄は、文書化して教育する必要がある。

コメント 2

自分が標準で考えているコーディングルール（技術）についての伝達・文書化の重要性は少し前に感じました。
私の場合はJDBCコネクションの例外処理なのですが、意外とデコンストラクトに頼っていてちゃんとｃｌｏｓｅしないのですね。
ちゃんとやらないとコネクションが残存してしまうケースもあるのに・・・。

当たり前だと思っていた処理が誰もやっていないのに驚きました。
by たーとる (2007-12-07 08:31) 

自分では当たり前だと思っても、実は、それはどこかで自分も学んだことだったりします。しかし、自分も学んで身に付けたことであることは、忘れてしまうのが普通だと思います。だから、初心者が知らないのは当然だと思うのですが、開発経験が長い人は知っているだろうと期待してしまいますね。

でも、実際は、その人も自分で色々な学習を行ったり、どこかで誰かに教えてもらったり、あるいは書籍を通して学んだりしなかったら、知らなかったりする訳です。
by yoshiki (2007-12-09 08:32)