プロフェッショナル職としてのエンジニアの働き方
 |
「納品」をなくせばうまくいく ソフトウェア業界の“常識”を変えるビジネスモデル 倉貫 義人 日本実業出版社 2014-06-12 |
IT業界でSIerとして従事しているものとしては、本書のタイトルを見た時
「ん？どういうこと？」というのが第一声でした。
どういう事かというと、従来のシステム開発とは顧客企業との契約において
基本的に「納品」を前提とした受託開発が基本だからです。
なので、本書のタイトルにある「納品をなくせば」というところに
非常に引っかかりました。
ただ、本書を読み進めていくと著者が主張したい事、やってきたこと、
これからやっていきたいことが非常に明確になっています。
本書を手に取るきっかけになったのはPMシンポジウムでの著者の講演です。
この講演で主張されていた内容を詳しく知りたいと思い、本書を購入しました。
本書にはIT業界のビジネスモデルの問題点から、エンジニアキャリアについて
まで書かれており、個人的には非常に有益な一冊でした。
最近ではフルスタックエンジニアが重宝されていますが、本当のプロは
本書で述べられているような事業にも踏み込むエンジニアなのかもしれません。
■IT業界の問題
システム開発やソフトウェア開発において受託開発と言えば、「一括請負」という
契約形態が一般的です。
一括請負には「要件定義（何を作るかを決める）」作業がまず必要になります。
著者はこの「先に要件定義をする」ことに対して、以下のような問題があると述べています。
いったん要件定義が固まれば、当面の間はそれでよいかもしれませんが、ソフトウェアが
出来上がる頃には市場環境が変わってしまい、使いモノにならなくなるリスクもあります。
しかし、一括請負で受託している開発会社にとっては「納品すること」がゴールなので、
極端なことを言えば、納品後にそのソフトウェアが使えるモノであろうがなかろうが
知ったことではありません。
ちょっと極論のような気がしますが、まったく外れてはいないとは思います。
先に要件定義をすると確かに決まった要件を実現する事に注力します。
その間の市場変化をずっと追っかけるわけにはいかない（変化に弱い）ので、
基本的にはその後の変更を作成中のシステムに取り込む事はできないのが現実です。
また、IT業界は多重請負の構造なので、「一括請負」契約にしてしまうと
どうしても高くなります。
その原因が「バッファ（余裕）」です。
元請け（一次請け）、下請け（二次請け）、孫請け（三次請け）と続く多重構造の
中で完成責任がある「一括請負」の場合、各社がバッファを積みます。
その積み重ねの金額がシステムの開発費用になるので、顧客企業から見ると
「なんでこんなにかかるの？」ということになります。
■納品のない受託開発とは
現在のシステム開発に関する問題点を解決する手段の1つとして本書で
あげられているのが「納品のない受託開発」です。
この開発手法の特徴は「顧問エンジニア」という関わり方です。
この特徴は、
・月額定額の受託開発
・成果契約の受託開発
・顧客のパートナー
というものです。
つまり、弁護士や税理士など士業と同じように専門家として
顧客企業に関わり、一緒にビジネスを作っていくという関係を作るというものです。
顧客企業がやりたい事業に本当に必要なシステム（ソフトウェア）は何かを
一緒に考え、必要なものだけを作る（不要なものは作らない提案をする）。
そして、小さく作って少しずつ育てていく。
プチCIOのような関わり方です（CIOなのに設計〜運用までやってしまう）。
具体的な事例も含めて本書には記載されているので、詳細は本書をご覧ください。
■これからのエンジニアのあり方
「納品のない受託開発」を実現するためにはかなりハイスペックなエンジニアが
必要になります。本書では採用に関する部分で必要な素養を以下のように記載しています。
T：テクニック（読みやすいプログラムが書ける、安定した運用の基礎知識をもっている）
I：インテリジェンス（顧客と一緒にビジネスを考える）
P：パーソナリティ（得意分野があり、チームワークを重視する）
S：スピード（素早くプログラムを作れる／直せる）
これらの素養を持ち合わせた人がこの開発手法を実現できる人材とのこと。
はじめからすべてを持ち合わせた人などいないので、採用してからどのような
システムで教育をしていくかということも本書では記載されています。
個人的には上記で挙げた要素は今後すべてのエンジニアに求められていくのでは
ないかと感じています。
金融機関のオンラインシステムなど大規模なものは別ですが、ビジネス環境変化が
激しい中、必要なシステムを作るためにはどうしてもビジネスに対する知識が必須です。
そして、スタートアップ企業などは分業制（設計と開発と運用など） を敷かずに
どんどんトライ＆エラーでまわしていくことになるため、一人でいろんなことが
できることが求められます。
そうなると「私は設計しかできません」「私は開発しかできません」「私はマネジメントしかできません」
なんて言ってられない状況になります。
プロのエンジニアであり続けるためにはビジネス／技術への知識と経験、そして
「作れること」が重要になってくるのではないでしょうか。
■編集後記
非常に刺激的な一冊でした。
いままで自分がやってきた開発手法とは違う新しい考え方を得られたと共に、
これから自分が磨かなければ行けないものが見えた気がします。
やはりエンジニアたるもの作ってナンボですね。
■関連エントリー
コメント