プロジェクトリーダはコードの読み書きできれば良いか

「コーディング技術にこだわり過ぎると～」の反省会 - プロマネブログ

コーディング技術にこだわり過ぎるとITエンジニアの地位は向上しない - プロマネブログ

そいえば、上記記事のブコメ欄でいただいたコメントの中で考えてみたいなと思うコメントがあったので、記事でまとめてみようかと。

どっちにしてもコードが読み書きできない人はソフトウェア開発に関わっちゃいけませんので、その辺何卒よろしくお願いします。

考えてみたいのは上記コメント。異論はないのですけど、プロジェクトリーダ(以下、PL。プロジェクト進行の話が中心なので、広義のプロマネって言うと話がごっちゃになるので)はコードの読み書きできるぐらいでいいのかってのはあります。

知っている限りのPL連中は、往々ソースの読み書きできます。

もともと、プログラミングやったこと無いって人もいると思いますけど、門前小僧習わぬ経を読む、ではないですが、長くコードに触れた生活してると、基本的な読み書きならまあできるって人は案外多いです。

※とは言え、世の中を見渡したとき全くコードをさわれないってPLみたことあるので、全員が全員ではないと思いますけど。

てなわけで、「単にソースを読み書きできる」ってレベルなら大体満たしている場合が多いのが現状。でも、これがかえって落とし穴となるんじゃあないかなって思います。

オッサンがネットなどの事例含め、ほうぼうで過去見たことがあるアンチパターン。

構造化オブジェクト指向言語　クラスや継承といったオブジェクト指向の要素は全くなし。美しく構造化されつつも、オブジェクト指向言語で書く必要あるのだろうかっていう不思議なコード
ヒント句まみれのSQL　oracle旧バージョン時に作成した過去のソースの再利用のためなんだろうけど、ヒント句以外の解決法もあったんじゃないかな。てか、コストベースオプティマイザが無駄になって可哀想。
テーブルキューイング　昔キューイングソフトが高価だったころの名残らしいのですが、試行錯誤の結果だろうけど、変に複雑になってるような。トラブルのもとにも。。。

他にもありますけど、まあとりあえず３つだけ。

いずれも、言語やミドルウェア等のパラダイムの変化に追い付いてないんだろうなあって感じです。

これらを引き起こすPLは以下のいずれかの問題を抱えていると感じます。

PLの技術力不足。なまじコードの読み書きができるものだから、とりあえず知ってる知識で動くアプリ作るほうに注力してしまい、考えなしに微妙なアーキテクチャを選択、微妙なソースを量産してしまう。過去に作成したパラダイムシフト前のコードがあると、これを転用しようみたいな意見も出てきてさらに複雑な事情となってしまう。。。
PLのコミュニケーション能力不足。メンバーが把握していた設計上の問題点を拾い上げられない。ひどい場合は、自分の知識不足を棚にあげてメンバーの提言を拒絶する。
PLのメンバー調整能力不足。自身、メンバーのスキルに不安があれば、技術支援メンバーなど追加しなければならないのに、それを認識できない、または怠っている。アーキテクト作れる人間が不在だと悲劇が。。。

結局のところ、PL自身の技術力とそれをカバーするマネジメント能力が両方不足しているとき、ダメコード生成に繋がるのかと思います。

この謎コードの存在は、保守性を下げ開発生産性を低下させ、余計な開発コストを生むこととなります。

プロマネは「原価計算を取り戻せ」 - プロマネブログにも書きましたが、日々の生産性向上はプロマネの仕事。これをサボっているのとおんなじですね。