感想: ITエンジニアとして生き残るための指南書。自分を守りアップデートするための18のテクニック。

ITエンジニアは共感し、学生は世知辛さが分かる書籍

本書は、IT業界で20年間働いてきた著者が、日本のIT業界で働く上でのテクニック(ノウハウ)をまとめています。30分で読めるシリーズの一つで、ページ数は50ページだけです。著者である平田 豊氏は、組み込み業界では有名で、「Tera TermのOSS化」や「Linux Kernel関連書籍の執筆」など、広範な活動をされています。

著者が述べる「日本のIT業界の世知辛さ」は、IT業界の人であれば、共感しやすいのではないでしょうか。私は、IT業界で働いて4年しか経過していませんが(2019年現在)、殆どの内容が共感できました。特に、以下の4点は直近の仕事と関係して、深く共感できました。

本書で重要な部分は、章末です。章末には、上記のような問題に、著者がどのように対処するかが記載されています。章末のノウハウに対して、同意するか、著者とは別の自分なりの解を見つけるかは、読者次第だと思います。著者自身も書いていますが、本書は「人生のヒント」なので、絶対的なものではありません。

まだIT業界がどんな世界か分からない学生で、この業界に興味がある場合、本書はオススメです。本書からIT業界(特に、組み込み業界)の駄目な部分を感じ取れます。

本記事の残りは、私が本書を読んで感じた事をまとめています。

　　　　　　　　　　　　　　　  　　　　　　　　　        

(IT業界は意外と)プログラムを書く量が少ない事

著者がプログラム作成時間の少なさを明言し、なおかつ残念に思っている記述には「すげー分かる」と嬉しくなりました。

筆者もそうですが、プログラミングをする姿に憧れて、プロのプログラマになりたくてIT業界に入ったわけですが、思っていたものと違ってソースコードを作成する作業が少なく、ガッカリしたものです。

平田 豊

私は、2015年に入社してから、2019年現在までの間に、5000Stepも実装していません。さらに、今より上の立場になると、顧客(上司)とメンバとの間での調整作業に追われ、実装する機会に恵まれなくなると予想しています。つまり、技術的なスキルを持ったエンジニアには成れず、将来的に転職が難しい立場になるしかないと感じていました。

しかし、著者も同じ立場(?)である事が分かると、励まされた気持ちになりました。また、この問題に対する著者のノウハウ(以下)が、私の導き出した結論とほぼ同等でした。つまり、割り切りと休日のアウトプットが大事。

　　　　　　　　　　            　　　　　　　　　　　　

工数不足

リーマンショック以前は、工数が余っていた(正確には余裕があった)という描写には、驚きました。2019年現在は、業界全体として工数が不足する傾向にあるようです。

著者は工数見積もりに関して、

1. 細かく作業分割
2. バッファとして、見積もりに”×1.5″
3. 見積りが多すぎると上司に指摘された場合、上司と戦え

と記載していました。

私は、この点(特に2.)に関しては、納得できませんでした(共感はしましたが)。前提ですが、私は仕事を出す側(支払いする側)として工数見積もりの確認をしており、委託先がバッファを必要としている事を理解しています。可能であれば、多めにバッファを渡してあげたい気持ちがありますが、上記の方法では渡せません。

その理由として、開発者が出した工数を1.5倍されていると、違和感を感じる(工数を意図的に増やした事に気づいてしまう)からです。バグがありそうなコードが臭うのと同じで、見積もり確認中に「あれっ？」と思います。その状態に陥ると、自社見積もり(作業を細かく分割して算出した工数。リスク工数込み)と、比較を始めます。比較が終われば、委託先の生産性低いな、と悪印象を持ちます。

N倍されると、どうしても見積もり工数が大きくなります。この状態は委託先にとって負け戦モードで、以下のように八方塞がりになります。

• 低い生産性の理由を委託先に確認                                        → 委託先が水増しを白状してしまう
• 委託先の水増しに気づいているが、上司にそのまま提出 → 上司に理由を問われ、私が説明できず、やり直し
• 委託先が強固な姿勢で水増しを認めない                            → 相見積もりコース 

私の中で、この工数不足(正確には見積もり)の結論がないです。作業工程を細かく分割すれば、見積もりが遅くなるし、正確性を求めるあまりに口頭発注に近い行為を委託先にさせてしまいます。かと言って、作業リスクを見積もる行為は不可能ですし、どうあるべきかを悩んでしまいます。予算は有限ですし……私だって、工数を気にしないで開発していただきたい。

追記: 本記事の公開後、「見積もり失敗リスクを発注側で受け持てば良いのでは?」とコメントをいただきました。優しい世界では、それが可能です。再契約に近い手順で、増額対応をします。しかし、現実的には、よく揉めます。特に、初期の契約から要件や前提条件に変更がない場合、「あの見積もり工数で出来るのでは?(そういう契約だよね)」と言うしかありません。

　　　　　　　　　　　　　　              　　　　　　　　　　

協力会社との共同作業が捗らない

協力会社の方は、単価が安いため、プロジェクトに複数名割り当てられる事が多いです。弊社だけの問題かと思っていましたが、著者も同じ内容を述べています。ここでの問題は、協力会社の方のスキルセットが作業内容とミスマッチしている事もありますが、私にとってはチームを築けない事です。

私にとってチームの理想形は、あるべき姿に対する共通認識があって、問題に対してメンバ全員で解決策を考えて、望ましくない事が起こった時に助け合えるような状態です。しかし、協力会社の方がいると、その状態に持っていけません。何故ならば、「協力会社の方は、言われたことしかしないから(契約上は、正しい行動)」です。

プロジェクトが回っている間は問題ないです。しかし、慢性的に回らないプロジェクトの場合、組織として解決して欲しい。著者は、別視点でこの問題を語ったため、直接的な解決策(ノウハウ)を述べませんでした。少し残念な点です。私は、この問題を解決したいため、別の書籍で模索してみます。