第21話 生産性向上に見る「エンジニアの矜持」（前編）
前回のコラムは長い間コメントいただき、ありがとうございました。最後の方はちょっと趣旨とずれたかな、と思えたのと、レスすると今回のコラムのネタにかぶりそうだったのであまり書けませんでした。すいません。ある意味、今回も続きみたいなものなのでまたコメントいただけたら、と思います。内容は相変わらず極端ですが、そこはご容赦を。
タイトルを見て分かるとおり、長くなってしまったため、今回は2部構成にしました。このコラムだけでコメントをもらっても、次の内容の兼ね合いもあってなかなか返しにくそうなため、今回はコメントを受け付けません。次回はいつも通り受け付けるので、最後まで読んだ上でまとめてコメントをいただけるとありがたいです。
さて、1月のお題は「生産性向上のしかた」ですが、実は以前のコラムでも少しだけ触れています。内容的には、「エンジニアはコスト意識を持って、生産性の向上に努めるべきだ」というような感じのものです。大なり小なりエンジニア側からすると、コスト意識やスキルの研さんをもって生産性を向上させることができると考えているのではないのでしょうか。
この考え方は、エンジニアとして非常に正しいと思います。
しかし、実際はなかなか難しいのが現状だと思います。新人の頃は「あれもこれも」なんて考えながらがんばれます。しかし、ある程度仕事を任されて、責任も少しずつ出てくると今の仕事を無難にこなすことで手一杯になり、やがて、必要以上のスキルの習得やコスト削減の意欲が失われていきます。職場やプロジェクトにもよりますが、残業やデスマーチが多いところでは生産性（＝利益）を上げるために、おそらく「残業」や「給与」がカットされているところが多いと思います。
一般論ですが、生産性は平たくいえば「インプットに対してどれだけのアウトプットを出せるか」の指標です。本来は経済的な指標なので、どれだけのコスト（リソースや期間も含む）で、どれだけの売り上げがあるかを表すものと思います。
ソフトウェア開発と言う行為で考えれば「効率」の方が言葉としては合いそうですが、インプットは「人（人件費）」と「経費」と「開発期間」になります。アウトプットはその結果の売り上げでしょう。結局、どれだけ人や経費、開発期間を減らせるかが生産性を上げるためのカギになります。
ちなみに、エンジニア視点で考えるとなかなか思いつかないのが「アウトプット」の部分です。生産性を単純に向上させるなら、売り上げアップを考えることも「あり」なのです。むしろ経営者はここをまず考えます。売り上げアップが望めないなら今度はコスト（インプット）の部分を削ろうとします。
整理すると、ソフトウェア開発において生産性を向上させるには、
- 人件費を下げる
- 開発メンバーを減らす
- 開発期間を短くする
- 経費を減らす（広告費や設備費など）
- 売り上げを増やす
となります。人を減らすことは、製造業では基本的にそのまま戦力ダウンになるのですが、ソフトウェア開発では効率を上げることができれば、戦力ダウンに繋がらない特殊な事情があります。もっとも簡単にできれば誰も苦労はしないのですが。
売り上げを増やすこと以外は、やろうと思えばなんとかできることだと考えられますが、（良い悪いは抜きにして）、さすがに計画して簡単に売り上げが増えることは考えにくいため、結局、生産性向上のためには「インプット」を少なくすることが現実的といえます。
生産性を主眼に据えて考えた場合、エンジニア側の考え方と経営者側の考え方があります。わたしが掲げている「ソフトウェア開発の明るい未来」は、この両者の考え方の相違が暗いものにしていると考えています。
生産性はいいかえれば「利益が出るための組織なのか」ということになります。（あくまでも経済的な指標なので）開発効率と置き換えても指標基準が違うだけで意味合いは同じですが、本来は両方が同じベクトルで考えて行くべきものだと思います。ですが実際は逆の方向を向いているように感じます。しかも基本的に「エンジニア ＜ 経営者」という力関係があるために、バランスが取れなくてエンジニア全体の質が平均するとなかなか上がりません。
一番バランスが取れるのは、エンジニアがそのまま経営者になることです。エンジニアとしても仕事をしている会社役員やフリーランスの方がそれに当てはまります。それは、コスト削減やスキルアップの重要性も、売り上げアップの必要性も認識しているからです。逆にどちらが欠けても成り立たなくなる危険性も分かっているのでサラリーマンエンジニアよりも間違いなくシビアなため、総じて開発に対する意識は高いです。
ただ、業界を構成している大部分はあまりエンジニアの重要性が分かっていない（であろう）経営者とある程度収入が安定しているサラリーマンエンジニアです。この両者がもう少しきちんと「あるべきエンジニアの姿」を考えないと生産性の向上も業界の発展も難しいと感じます。
今回はそれぞれの立場から生産性の向上について考えてみようと思います。両者における共通のキーワードは「開発環境」です。
■エンジニアの矜持
エンジニアを主体に考えて生産性を向上させる場合、エンジニアひとりひとりがまず経費などのコストを減らす努力をすることです。金額はともかく、これはどんなエンジニアでも頑張ればできると思います。大企業になると、1人当たりのコストをちょっとでも削るとそれでかなりの額になります。その上で、業務に必要なスキルを日々磨くことだと思います。わたしはひとりのエンジニアとしてそうありたいと思いますし、後輩もそうであって欲しいと願います。
わたしがエンジニアになった頃はまだパソコンもあまり普及していなかったので「特別な職業」と周りから思われていました。実際、ソフト開発の敷居も個人では高く、ある程度好きな人でないと独学で学ぶのは難しい時代でした。人材不足もあり、各メーカーではとにかくエンジニアを「増員」することに躍起になり、未経験者もとにかく教育しました（経験者の方が少なかった）エンジニアの高度成長期と言えたかもしれません。
ところがハードやソフトも高価なものから安価になり、使う人も専門の人から一般の人に広がったことにより、ソフトウェア開発も仕事ではなく趣味で、しかも仕事と同じレベルに近い環境でできるようになりました。ソフトウェア開発を行う人が仕事か趣味かを問わず同じようにできるようになったのです。
そうすると、アマチュアレベルの職業エンジニアもスーパーエンジニアクラスの趣味エンジニアもそれなりに増えてきます。すると、商売としてもまた趣味として自分が便利になるものを作りたいという要求（欲求）が徐々に広がってきます。それを受けて開発ツールが少しずつ進化していきます。
趣味で使えば楽しく作れて思い通りに動くソフト、仕事でプロが使っても耐えうるぐらいに高機能なソフトの両方のニーズがひとつになるとVBのような非常に高機能な開発環境が出てきます。そして、ソフトウェアに対する欲求はそのまま生産性の向上にも繋がっていきます。
ここにインターネットの普及が加わり、情報検索や情報発信がそれこそ地域や国境を越えて行えるようになりました。開発者自ら情報発信を行うため、開発環境（ツール）を使ったサンプルや使い方などの情報が誰でも検索できるので、そのすそ野は広がりました。各々が便利にするための無償ツールやフレームワーク、ライブラリもたくさん開発されました。商用ソフトウェアを開発・販売する所でさえ、現在はそうしたものにも一部お世話になっていると思います。これはソフトウェア開発の「生産性」向上のための手段といえます。
現在ではソフトウェア開発という行為も「プログラマ」と言う肩書もすでに特別なものではなく、むしろ興味があれば誰でも行えるものであるといえます（規模の大小や品質の問題はありますが）。
特別なことではなくなったため、生産性に関していえば、エンジニアのスキルアップ以外でも向上します。必要な機能がすでに実装されているフレームワークやライブラリ、それらを容易に組み合わせてデバッグ・テストができる開発ツールを使い、初歩的なプログラミング技術とツール類の使い方がわかればそれで開発期間は短縮できます。フレームワークやライブラリ、開発ツールが安価、もしくは無料なら同時に経費も削減できます。
生産性向上だけを考えれば、エンジニアのスキルは「考える」ことではなく「上手に使う」ことを優先した方がおそらく早いです。皮肉なことに、手を加えるところが少ないエンジニアの方が、何でも自作できるスキルの高いエンジニアよりも生産性が上がります。
こういう現状では、なかなかエンジニアの矜持を保つことは難しいかも知れません。
■経営者の悩みと思惑
昔からIT業界では人材不足と言われてきました。ソフトウェアを始め、システム開発自体は基本的には大きなプロジェクトだったので元となるメーカーや大手SIerでは1カ月以上かけてエンジニアを教育して現場に投入しました。端末などが一般的なものではないのが普通だったので、教育をする必要もあったでしょう。
ところがハードもソフトも安価になってくるといろいろな所でIT化が進んできました。大きなプロジェクトもありますが、小さなプロジェクトも増えてきました。プロジェクトが増えると相対的に人手も必要です。この先ずっとプロジェクトがある訳でもないため、人件費の兼ね合いでプロジェクトの請け負い元で全員雇用する事はできません。そのため、派遣やフリーのエンジニアが増えてきました。どこも人手不足だったので派遣構造が2重、3重、それ以上になることは、今も当たり前にあります。
昔は本で勉強することができましたが、COBOLやPL/Iなどは自宅で試行錯誤まではまずできませんでした。そのため、教育を受けるか経験がある程度ないと派遣先でも仕事ができませんでした。
ところが、今は自宅でも簡単に試行錯誤ができます。この頃は試行錯誤どころか正解まで探せば出てきます。つまり、業務経験があまりなくても教育を受けていなくても少しの興味とやる気でエンジニアになるのは可能になりました。足りない業務経験や教育のデメリットを開発環境とインターネットの情報で補完してしまえるのです。
経営者の優先事項はまず「利益確保」です。どんな仕事でも運転資金は必要ですし、それは額の多い少ないはあっても「無限」ではありません。やはり利益を上げていかないといつかは倒産し、そこにキレイごとは通用しません。そのため売り上げアップと生産性の向上は必ず考える必要があります。
しかし、経営者視点で考えるとエンジニア任せの「生産性向上」はある意味リスクとなります。よほど信頼があるなら別ですが、例えばあてにしていた人が急に退職したり、怪我や病気などで仕事ができなくなったり、難しい技術を使った仕事が来たり、エンジニアがなかなかスキルを磨こうとしなかったり……不安要素は挙げればキリがありません。
そういう意味で経営者はなるべく優秀な技術者を必要なだけ集めようと考えるのは自然だと思いますが、なかなか理想通りのエンジニアが必要数集まるのは大手企業ならともかく、中小零細企業では非常に難しいことです。それは安定性の面と待遇の面で大手にかなわないからです。わたしもこの問題は非常に悩んだ記憶があります。
そのために、経営者はエンジニアのスキルによらない生産性の向上を考えます。元々、教育したりするのはスキルの偏りを減らして平均化することにあります。決してエンジニアのスキルアップを期待している訳ではなく、１人に負荷をかけずに全員で同じようにできるようにするためのいわばリスクヘッジ的な要素が強いです。とにかく1人欠けても業務が継続できて、補充要員も教育して戦力になるように考えます。
これが、開発環境やフレームワークなどが高機能になったおかげで、リスクヘッジの仕方が変わってきました。「スキルアップをしてきたエンジニアしかできない開発」から「誰でも簡単にプログラムが組める高機能な環境での開発」へと変わってきたのです。これが顕著に分かるのが「教育」です。大手は別として、中小零細企業ではあまりプログラミング教育をしなくなりました。スキルアップのための啓蒙などもあまりなく、プログラミングですら入社前にある程度勉強してこい、と言う程度です。逆をいえば、プログラミングがすでに一般的だともいえます。
経営者からすると、時間をかけてスキルアップさせてきた社員がある日突然辞めたりしてダメージを受けるよりは、それ以外の要因で生産性が向上できればそっちを選択することは当たり前だと言えます。これはエンジニアが、会社の財産から使い捨てに変わったことを意味します（ちょっと極端に言い過ぎですが）。
そう実感するのはエンジニアの給与が残業を含め、あまり上がらなくなったのと、開発期間が段々短くなっていることです。とにかく目的のソフトウェアを早期に「完成」させることが一番重要になっているのは間違いありません。経営者が長期的な展望よりは目先の利益を考えるようになっている証拠でしょうか。不況になるとますますこれに拍車がかかると思います。
■なぜ、生産性は向上しないのか
ソフトウェア開発環境が高機能化してくると効率が上がるため、本来は生産性も向上します。実際、高機能化のメリットの1つが生産性向上のため、これは本来、エンジニアにとっても経営者にとっても非常に良いことであるはずです。
ベテランエンジニアになればなるほど実感していると思うのですが、その割に生産性が上がったとか実感はあまりないと思います。むしろそういう面では何も変わっていない気がしていると思います。実感できるのは、おそらく原因が分かりづらいトラブルが増えたこととコーディング量が減ったことぐらいでしょうか。おそらく「減った」ものより「増えた」ものの方が多いと思います。
その一番の理由が、エンジニアのスキル不足を開発環境やツールなどが必要以上に補っている点です。スキルの高いエンジニアが利用すると非常に効率は上がると思いますが、高性能がかえってアダとなり、スキルの低いエンジニアが適当にやってもまず動作することが多いため、自分がそれなりにデキると錯覚しやすいです。特に最近は「ググる」ことでほぼ解決できます。
錯覚してしまうとエンジニアはスキルアップをなかなかしません。それは自分でその必要性を感じなくなるからで、その結果、エンジニアのプライドだけが高くなり、スキルと評価は上がらなくなります。
ソフトウェアを「作る」ことはスキルがあまりなくてもできるようになりました。でも、内部構造や動作するしくみを「調べる」ことはそれなりにスキルがないと今でもできません。つまり、作ること自体は減ったのですが、それ以外の「調べる」ことが逆にできなくなったために、結果として生産性が思うように上がらないとわたしは考えています。
■何が足りないのか
後編では、どうすれば「幸せ」に生産性を向上させることができるのかを、わたしなりに考えて書きたいと思います。個人的にはただ生産性を向上させればそれで良いとは思っていません。その辺りを考えてもらえたらいいな、と考えています。
良かったら後編も読んでみてください（続く）。