プロマネブログ

とあるSIerでプロマネやっているオッサンです。主にシステム開発ネタや仕事ネタ、気になった三面記事ネタの解説なんかしてたりします。

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

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

 

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

 

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

 

プロジェクトリーダに必要となる技術はコード読み書きできればOK?

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

 

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

 

 

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

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

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

 

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

 

 

パラダイムから外れた謎コード生成

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

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

 

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

 

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

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

 

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

 

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

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

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

 

ちなみに、オッサンの事例

参考までに。

オッサン自身、メンバー統率するに当たってリーダが技術面でも会話できなきゃ話にならんって思想なので、マネジメントだけでなく技術力も鍛えるようにしてます。

 

そんなこともあり、かれこれ小学生時代にLOGOに触れて以降、プログラミングは趣味で、技術研鑽かねて自宅サーバ上にウェブアプリ作って公開したりしてます。

ここ数年はAWS上でサーバ立てたりしてるんですけど、Hadoop とか、自宅サーバではまかないづらい様なものも比較的簡単に動かせるんですよね。

新し物好きとしては、いろいろ遊べて助かるって感じです。

 

実際に触って、動かして、アプリやサービス創ってみて、といろいろやってはいるんですけど、まあ、仕事に応用できるのが一割もないのが寂しいとこです。。。

※費用は自分の持ち出しだし。。。

 

そういった意味ではプロマネみたいに直接開発をしなくなった人間は、技術研鑽はよっぽど好きじゃないと続けられないよなって感じます。

 

f:id:getlife:20140210003817p:plain

※参考までに、作成したサービスの稼働状況。カネがないのでt1.microで月数万UUの処理をさばいてます。極力ディスクアクセスを行わないようにしており、処理のほとんどがオンメモリで完結するようにしてます。

 

まとめ

毎度のごとくだらだら書きましたが、今回の内容をまとめると以下の通り。

  • PL はコードの読み書きができるだけではなく、きちんと使いこなせる位の技術力を持つべき。
  • それが出来ないのであれば、チームとしてケアできるようキッチリとマジメントするべき
  • AWSなど周囲の環境は整って来てるのだから、プロマネもいろいろ技術に触ってもいいんじゃあないかな

 

いずれにせよ、チームとして活動する以上、プロジェクト解決のための技術力をどのように確保するか、プロマネは考えるべきだと思います。

 

個人的には開発の現場に「過去の事例」を絶対視する風潮があると不味いと思います。確かに過去の事例は便利なんですけど、度が過ぎると思考停止となってしまい、新しい技術の拒絶と謎コードを生み出す元凶となりうるんじゃないかなと思います。

 

※便利なだけにバランスの取り方はいつも悩みます

 

以上

 

 

よくわかるAmazonEC2/S3入門 ―AmazonWebServicesクラウド活用と実践 (Software Design plusシリーズ)

よくわかるAmazonEC2/S3入門 ―AmazonWebServicesクラウド活用と実践 (Software Design plusシリーズ)