ソフトウェア開発に幸せな未来はあるのか

　最近の経済ニュースを見ていると、不況が続くのかこれから良くなるのかいまいちピンと来ない感じがまだまだします。就職・転職の状況においても同じで、エンジニアかどうかにかかわらず非常に厳しいと思います。IT自体はニーズがあるので、業界自体がすぐにどうこうというのはないでしょうが、それでもこの機会にある程度、淘汰は進むと思います。

　こういう時は、人件費を減らすためにプロジェクトのメンバーを減らすことも多々あると思います。減らした状態で何とかプロジェクトを乗り切ると、今度はそれが「デフォルト」になり、減ることはあっても増えることは少なくなるでしょう。もっとも、メンバーや管理者の能力に左右されるので一概に人数で割るのも非常に乱暴ですが、仕事が減らなくても単価が安くなるのはあると思うので、経営側としてはこの機会に見直しを考えても不思議ではなく、自然なことだと言えます。

　前回と前々回にも少し書きましたが、開発環境はシステムを「作る」と言う部分においては格段にイージーになっています。開発を巡る環境は「設計」→「作る」→「テスト」においては非常にシームレスになりつつあります。設計についてはある程度経験も必要でしょうが、それ以外は逆に新しい環境に馴染んだ（馴染みやすい）若手の方が生産性は上がるのではないかと思えます。後は保守だけですが、これはある程度経験が必要だとは思いますが、同じ環境（システム）を永遠に使い続けることは100％ないのと、時間的余裕は開発に比べると作りやすいため、世代交代しやすいと思います。これから先はもっと簡単になることも考えられますので、職業エンジニアの敷居は低くなるでしょうし、単価も地位も一般職並みになるかも知れません。

　先々の予想は別にして、何が言いたいのかといえば、これからは若手だけでなくベテランも同じようにリストラされてしまう可能性が高いのではないか、ということです。ある程度の経験は必要でしょうが、ただ経験が長いというだけでは生き残れない時代がそこまで来ていると思うべきです。すべて若手では難しいかも知れませんが、ベテランの数を減らすことはあり得ると思います。

　その上で、これからも「ソフトウェアエンジニア」を仕事としてやっていきたい人に対して「そのために考えなければならないこと」を少し書こうと思います。一般論もありますが、基本的にわたしの経験がベースになっています。これがすべてでも誰にでも当てはまるものとは限りません。そこはある程度考えてもらえれば幸いです。

■わたしはどうかと言えば……

　わたしがソフトウェアエンジニア（以下、単にエンジニアと呼びます）なのは、好き嫌いではなく単に「向いている」と思うからです。経験があることもありますが、ソフトウェア開発は特別好きでもなく、嫌いでもありません。仮に今よりも「稼ぎの良い」、もしくは「やりたいことができる」仕事があれば（できれば）おそらくエンジニアには未練はないと思います。現実にはわたし個人で面倒見ているお客さんがいますので、何のかんの言ってもまだまだエンジニアであるとは思いますが。

　わたし自身、実はエンジニアになりたいという願望は全然ありませんでした。将来の夢も小中学校では「漫画家」、高校では「小説家」やバンドをやっていたので、そのまま音楽関係とか。たまたま作った映画で面白さにハマり、今でも映画を作りたいという願望はあります。でも、家庭の事情で夢を追うことは難しかったので、20歳になって現実的に職業を選んでエンジニアになりました。もっとも最初はあまりソフトウェア開発が得意ではなかったのでハードウェア設計で就職しましたが、すぐにソフトウェア開発の方に配置転換されました。

　でも、性格的に「向いている」ということは昔から自覚してました。それは小さいころから好奇心が旺盛で、「ラジオはなぜ声が出るのか」「カセットテープはどうして録音や再生ができるのか」「レコードはどうして音が出るのか」「なぜテレビは人が動いているのか（笑）」など、とにかく疑問を考えるガキでしたから。

　結果的にテレビ以外は家のものをほぼ分解した記憶があります。テレビは当時は非常に大きくて（足がついていた）高価だったので、さすがに自粛しました（もっとも学校のテレビを分解しようとして怒られましたが）。ファミコンも買った当日に本体もコントローラーもカセットも分解しました。分解しても構造が分かる訳ではないので、そこから勉強して高校に入る頃はひと通り構造は理解していました。ですから、わたしの小学校の卒業アルバムの巻末にある「わたしの20年後の理想と現実」には、以下のように書いてあります。

　理想「売れっ子漫画家になる」

　現実「漫画家の才能に限界を感じてエンジニアになる」

　思いきり正解です。

　若いころはある程度「こうしないとダメだ！」みたいな強迫観念に近い思い込みはありましたが、今ではある程度仕事、と割り切ってやっています。あまりソフトウェアやスキルだけに固執すると進まないのと、理想が高過ぎると自分を追い詰めてしまうからです。コラムのサブタイトルに「No Plan」とありますが、あまり役割にこだわらない姿勢が長続きする秘訣かなとも思います。

■エンジニアとして生き残るための術

　ソフトウェア開発は人によって「向き・不向き」や「センスの有無」は確かにあると思います。ただ、それと仕事でエンジニアになれる・なれないは関係ないと思っています。センスも才能もないよりはあった方が良いに決まっていますが、それは本人次第でカバーできると思います。基本は他の仕事と同じで「やる気」と「努力」です。

　ここからは完全にわたしの経験に基づいた考えです。それが正しいかどうかは分かりませんが、参考になる部分はあると思います。先輩エンジニアのアドバイスだと思って読んでみてください。

（1）役割にこだわるな

　ソフトウェア開発に転向して約1年は、ほとんどプログラムを書いたことがありませんでした。大規模プロジェクトのいろいろなグループを束ねるチームだったので、打ち合わせの段取りしたり、資料を作って配ったり、困ったことが起こったら関係各所にお願いしたり、テストするための環境を作成し……などでした。場合によっては資料のコピーのため一日中コピー機の前にいたこともあります（自動給紙、自動ソートしてくれるので、本当に見ているだけでした）。さすがに「プログラマ」になったのに、プログラムを組むことがあまりできなかったので、ある日直属の上司にかみついてしまいました。「プログラムを作らせろ！」って。胸ぐらまで掴んでしまいました。取りあえず、上司の取りなしでその場は収まりましたが、若かりし頃の一番の失敗でした。今でも思い出して反省しています。

　この職場では、結局これが理由で辞めざるを得なくなりました。

　今の時代、開発環境（言語）といろいろなフレームワークやライブラリのおかげでコードを書く量がけた違いに減ってます。開発するシステムにもよりますが、SE/PGという枠組みも段々曖昧になっており、どちらかといえば、単価を決めるための肩書になっている感じがします。ソフトウェアを作る＝プログラマという感じもしますが、わたしはこれはナンセンスだと思っています。設計でも製造でもテストでもそれなりのスキルと経験は必要ですし、これからはどれでもOKという人でないと段々と淘汰されていく可能性もあります。

　いや、こだわることができる環境ならこだわっても良いと思います。でも、例えば、今までプログラマだったのに「明日からテストチームね」といわれたり、設計だけやっていたのに別なプロジェクトでプログラム作成がメインになったり、プログラマだがいきなり設計だけになったりする可能性もあり得ます。その時にいやいやではなく、進んでやるようにして欲しいのです。

　わたしは上記のいずれの例も体験しています。だからPMになった今でも設計・プログラム・テストすべてのノウハウを持っていますので、役割分担しても自分が主導になってプロジェクトを仕切ることができます。ヤバい点が出てきても、割合早めに対策して潰すことができます（最悪自分で潰せる）。そして何より自分もプログラマとして参加できます（笑）。そうやって考えるといろいろ経験するもの非常に楽しいと思いますし、どれかをやれ、と言われても対応できるのでリストラという面ではリスクは減るかも知れません（会社があれば、ですが）。以前のコラムに書きましたが、これからはどんな役割でもできるような人を求めてくる可能性が高いと思います。それはその方が「使い勝手」が良いからです。

（2）失敗を恐れるな

　社風や先輩エンジニアにもよるんでしょうが、若いうちはとにかく失敗することをオススメします。絶対に失敗しろという訳ではなく、なにかする時に「これやって失敗したらどうしよう」と考えるならやってしまえ、ということです。アホみたいに何も考えずやるのはダメですが、一度や二度は失敗がないとなかなか成長しません。わたしは、20代に何回か大きい失敗をやらかして「始末書」を何度か書きました（ここでは具体的に書けませんが）。

　失敗した時はまず謝罪します。その上で、どういう考えで失敗したかを考察して書き出してみます。重要な失敗なら多分始末書か顛末書を書かされると思うので、その時に書きます。大事なのは隠さないことと繰り返さないことです。ベテランだったら許されないことも、若手の時にはわりあい寛容に見てくれる場合が多いです。ソフトウェア開発の基本は「トライ アンド　エラー」です。とにかく前向きにやりましょう。

　わたしは若い部下には「失敗したら俺が責任取るから、とにかく何でも考えてやるように」と言うようにしています。頭の中であれこれ考えても進みませんし、やってみないと自分の糧にはなかなかなりません。当然、こっちも触ってはいけない所だけはきちんとガードして監視しますが。

（3）基礎を覚えろ

　パソコンなんて今も昔も規模が異なるだけで基本は同じです。昔のパソコンがあるならそれで勉強するのも手ですが、いまなら「大人の科学 vol.24」がオススメです。4ビットマイコンが付録でついていますが、本当に基礎的なことが体験できます。

　わたし自身はこの程度なら自分で設計できますが（元々それが仕事だったので）、スペックが非常に限定的なので勉強には良いと思います。

　今の高級言語（この言い方もあまり最近はしませんが）とは非常にかい離しているように感じますが、突き詰めればやってることは同じなので、CPUの仕組みやレジスタ、メモリやアドレスマップなどは頭に叩き込んでおけば、後はそれを広げて行くだけです。実際はI/Oなども複雑に絡んできますが、落ち着いて考えれば多分理解できると思います。

　今のCPUは非常に高性能ですが、昔のパソコンのCPUなんかは掛け算や割り算の命令がなかったのでそこから工夫が必要でした。今はあまりビット演算とか使いませんが（使う必要がないことが多いのが多分正しいでしょう）、中でどうやって動いているかが分かればソフトウェアに対する考え方もまた少し変わると思います。

（4）言語にこだわるな

　プログラマのスキルは、プログラム言語ではありません。言語はあくまでもソフトウェアを動かすための方法の1つであって、すべてではありません。わたしは、プログラマのスキルは「いかに要求された条件でアルゴリズムを組み立てるか」だと思っています。細かい部分では特定の言語でしかできないこともありますが、極端な話、Javaでプログラムは組めるけどC言語では組めない、というのでは生き残ることは難しいかも知れません。アルゴリズムさえできれば後は指定された言語でコーディングするだけです。経験がないよりはあった方が良いですが、なくても努力次第でいくらでも習得は可能だと思っています。わたしも3日もあればだいたいのことは理解する自信はありますし、1週間もあればそれなりにできる自信はあります。

　どんな言語にも得意・不得意な分野がありますし、またSQLのような目的に特化した言語もあります。ある程度システム設計を行うには、案件の規模や予算でどんな環境や言語で開発するかということが重要になってきますので、いろいろ経験することはそういう部分では非常にプラスになると思います。言語を中心にするのではなく、アルゴリズムを中心に据えるようにしてください。

　そう思うのは、VBのようなイベント駆動型の言語での開発が多くなったことと、前項でも触れましたが、基礎的なことがあまり重要視されないからか、最近のエンジニアにはアルゴリズムを考えることがあまりうまくないのと、同期・非同期処理やマルチタスク処理の考え方がうまくできない人が多いように感じます。だからスタンドアローンで動作させた時や1つ1つの処理は動いても同時処理をさせるととたんにおかしな動きをすることが多々あります（わたしの周りだけでしょうか？）。

　あまり言語に縛られてソフトウェアを考えてしまうと、逆に自分のスキルの幅を狭める結果になります。

（5）独立するか、出世を目指せ

　ソフトウェア開発にはなぜか「出世」はPG→SE→PM→管理職という流れが一般的にあります。大きい組織（システム）になるとPGとSE/PMが完全に分離していてそれぞれの中でリーダーや係長・課長なんていう所もあると思います。

　イメージ的に「PG＝プログラム作成」「SE＝設計」「PM＝プロジェクト管理」が定着しているからか、「プログラムを作ること」にこだわる人の中には頑固に「SE」以上にはならない（なりたくない）という人もいます。この意見は一見正しいようにも見えますが、組織の中では逆効果の場合もあります。

　これはPGとしてどう、というより組織人としての「常識」が疑われてしまうからです。会社は大きくなればなるほど同じ所に同じ人を留めないようにします。ある程度たてば人を回すようにして、組織を活性化させようとします。そのため、SEやグループリーダー程度はある程度経験があれば普通は誰でも回ってくると思って良いと思います。わたしは本当にエンジニアとして生き抜くためには「出世」をオススメします。SEになることが出世か？ と言われればちょっと疑問もありますが、一般的に肩書としてPGからSEになると対外的に「単価」が上がるので、そこは建前だけでも出世と言えると思います。

　なぜ、出世を勧めるかといえば、その方が自分にとってやりたいことをできる可能性が広がるからです。さすがにいつまでもPGと同じことはできませんが、SEになってもプログラムを作ることは可能ですし、PMだって工夫すれば、わたしみたいに兼業でPGもできます。むしろ今の方が好きな部分だけつまんでいる感覚もあるので、管理という頭の痛い仕事の良い気分転換になっているような気もします。責任は増して、その分プログラムを組む以外の仕事が増えますが、そういう仕事を効率的に行う方法を考えることによって自分に余力が生まれますし、毎日の作業にメリハリが付きます。

　「それでも俺の職場では……」とおっしゃるなら独立を勧めます。独立すればプログラムを組むことが必要とされるのが多いからです。とはいうものの、若いうちから「明日から独立だ！」といってもそれは無謀なので、何年かかけて計画すると良いと思います。独立とは自分のやりたいことができる反面、自己責任の世界です。才能があれば儲かるでしょうし、自分からアクションを起こさなければ何もできません。最初の数カ月は収入がないでしょうから（一般に会社は支払いが1カ月以上先なので）、貯えも必要です。自分に売りがなければ仕事も来ませんし、コネも最初は必要だと思います。ですから貯金と勉強（独立したら勉強どころではなくなる時もあるので）、人脈を広げましょう。そうすればプログラマで一生やっていけるかも知れません。会社によっては何年か勤務すると独立を支援してくれる所もあります。実力があって初めて支援してくれるので、そういう会社を探して頑張ることも良いかも知れません。

（6）会社はアテにするな

　昔は「社員＝家族」という意識が社員にも経営者にもあったのですが、この頃はそんな雰囲気もあまりしなくなりました。

　預貯金では資産形成が難しいため、それ以外の資産運用方法がたくさん普及し、個人投資家やデイトレーダーも増えてきました。そのため、大企業ではモノ言う株主の増加で社員よりも株主に向いてしまっている感じはします。株主も、成長よりも利益確保がメインなのでちょっとでも業績が落ちると、やれ「経営陣辞めろ」や「リストラしろ」と叫び、少しでも利益が出たら「株主にもっと配当しろ」となります。個人経営者でもやはり先々が不透明なので、給料やボーナスの還元よりは貯め込むことを優先します。すべてがそうではありませんが、それでも社員の優先順位がやや低くなったような気がします。

　そういう意味では、雇用形態にかかわらず、労働者がこの先も同じように働いていける保証はありません。建前上は解雇は簡単にできず、労働基準法も労働者にかなり有利ですが、実際は労働基準監督署もそれほど強制力は持っていません。また、簡単には解雇ができないので、結局は一時帰休や自宅待機で人件費を抑えたり、少し仕事が増えても新たに雇用することによって今度仕事がまた減った時のリスクの方が大きくなるので、採用もできなくなります（このあたりが今の就職難だともいえます）。

　個人的には会社がなくなることは、社員としても経営者としても経験しているので、決して会社に過剰な期待はしていませんし、明日会社がなくなっても良いように考えて働いています。派遣として従事している人（正社員として雇用されて派遣されている人も含む）は、なおさらそう考えないと本当に生活の糧や基盤をいきなり失いかねません。そうなると希望の仕事（エンジニア）につくという選択肢は事実上なくなります。生きるためにどんな仕事でも受け入れなければ、住む所すらままなくなり、それができないなら路上生活か生活保護となります。預貯金や頼る身内がいないと、這い上がることも困難です。

　会社は社員1人1人の事情まで考慮してくれません。そういう意味では、自己防衛は絶対に必要で、仕事も会社のために頑張るのではなく、自分のために頑張るようにして、それ以外に個人的なネットワークを作ることも心がけましょう（当然、会社の仕事は絶対おろそかにしないように。それでは本末転倒なので）。わたしが独立を勧めるのはこういう事情があります。今日が正社員でも、明日も正社員とは限りません。今月給料があっても来月にあるかは分かりません。スキルアップもそういうことを考慮して行うべきでしょう。

（7）好きなことは趣味でやれ

　一口に「ソフトウェア」といってもけっこう幅広くあります。ハードもWindows、Mac、UNIX/Linuxなど、ソフトもWebアプリやデスクトップアプリ、言語もC/C++やVB、JavaやPHPなど、どれを挙げたら良いかキリがありません。

　長年やっていると多分一度は経験すると思うのですが、仕事でやってる以上、時々面白くない仕事もあります。これは仕方ないことですし、どうしても好きなことだけで仕事がしたいなら、自分で会社作ってソフトウェアを開発し、販売するしか方法はありません。

　かれこれ18年ぐらい前の話ですが、後輩のA君と一緒にUNIXでC言語を使った他メーカーの機器と通信するためのプロトコルを作る仕事をしていました。ある日の打ち合わせであまりコーディングが進んでいないことが分かったので「何で？」と尋ねてみました。すると「（仕様が）抽象的すぎてよく分からないから」といわれてしまいました。あー、わたしが悪いんだ……、なんて思いながら自分の仕様書を見直してみると、そんなに抽象的な感じはしません。

　仕方ないので「どこがどのように抽象的で分からないの？ 説明するし、書き直すから」って言っても答えがありませんでした。しばらくして「僕は本当はこんなプログラムが作りたかったわけじゃないんです」と意を決したように言い出しました。当然、わたしは「え？」とあっけにとられましたが、気を取り直して「どんなプログラムが作りたいの？」って聞き直したら、

　「ゲームが作りたかったんです！」

　と、きっぱり言われてしまいました。いやー、そういうソフトを作っている会社ではないので、そういうことをはっきり言われても正直どうしようもありません。仕方ないので、「でも、こんな簡単なプログラムも組めないのにゲームなんて作れるの？」と言ってしまいました。

　彼の言い分もちょっとだけ分かります。就職してプログラマになったけど、作るソフトがおそらく「面白くない」んだと思います。その頃はまだWindowシステムも一般的ではなく、パソコンもUNIXマシンの端末として使用していただけなので、文字だけで本当に地味でした。作っていたのもプロトコルなので、画面表示などはあまり関係ないですし。ある意味、理想と現実のギャップに悩むんだと思います。

　でも、仕事なのでそこに好き嫌いを持ち込むのは良くありません。やはりお金をもらっている以上、プロとして自覚し、やりたいことがあったら趣味で自宅などでやりましょう。幸い現在は当時と違い安価でたいていのことは自宅でもできると思います。

■好きだからこそ

　わたしが就職した20年前と今では社会情勢もITの普及具合も比べ物にならないぐらい違います。すべてを同列に比較することはあまり意味はありませんが、本質部分はなんら変わっていないと思います。

　プログラミングが好き過ぎて、他の人のコードが稚拙に見えることもあるでしょうし、自分の持てる技術をフル稼働して開発に貢献したいと思うでしょう。でも、現場が求めているのはそれだけではありません。一定の基準に沿って同じような品質でシステムの開発が行えるエンジニアを求めています。それには技術的なスキル以外も必要です。

　本当にエンジニアで生き抜きたいなら、固定観念は捨てて、柔軟に取り組む方が恐らく良いでしょう。それは妥協ではありません。仕事は別で趣味でプログラミングも良いと思います。ソフトウェア開発のスキルはプログラマでもプログラミング技術だけではもはや不足でしょう。ネットワークやシステム構築方法もある程度知る必要があります。そういう現状を踏まえると、わたしは「何でもできなければ（やろうとしなければ）エンジニアとして生き残ることは難しい」と思っています。

　ひとりよがりにならず、バランス良くスキルを磨いてお客様から「必要とされるエンジニア」を目指して欲しいと思います。それがこれからエンジニアで生き抜くために必要な考え方だと思います。

（今回も長かったですね……読んでいただき、ありがとうございます）

　前回はどちらかと言えば「お金」に主眼を置いて生産性について書いてみました。それは仕事である以上、避けて通れないのと、エンジニア側と経営者側で生産性の向上の考え方が異なることを示すために、あえて、そのようにアプローチをしてみました。

　ただ、実際のソフトウェア開発でいわれる生産性は、「どれだけ効率よく目的のソフトウェアを完成させるか」という意味で使われることが普通だと思います。今回はそちらも含めて生産性の向上を考えてみたいと思います。

■いま一度、生産性を考える

　生産性の向上を目指すのは「利益を上げる」ためというのは、おそらく誰しもが理解していると思います。同じソフトウェア開発でも趣味やオープンソース・フリーウェアのような作成することでは、収益の発生しないものでは、生産性の向上を考えることはまずありません。好きなものを好きなペースで好きにこだわることが第一だからです。フレームワークやライブラリを使うことはあるでしょうが、それは生産性が目的ではなく、こだわる必要がない部分だからであり、生産性はあくまでも経済活動が前提といえます。

　生産性の向上は、基本的にエンジニア側と経営者側が同じ方向を目指していないとうまく行きません。同じ方向を向いて、生産性の向上を考えれば、それはお互い「幸せ」な生産性の向上になります。ところが、同じ方向に向かないと、それは「不幸な」生産性の向上に繋がります。

　経済活動が前提となる以上、世の中の経済状況も関係してきますが、現状では総じて「不幸な」生産性の向上を行っているところが多いように感じます。これが最終的にエンジニアの質が低下していく要因の1つと考えられます。誰しも頑張れば認めて欲しいですし、ボランティアではないので生活することもできませんから。

■生産性の向上が図れないワケ

　昔から情報処理業界は人材不足が深刻でした。人が多くても生産性は上がりませんが、少なくても当然、生産性は上がりません。今は人が足りないというよりは仕事が足りない状況にあるのでそういう話はあまりないのですが（むしろ派遣やフリーランスの人は余っている感じがします）、これを解消するためのアプローチは昔から考えられてきました。

　1つはとにかくエンジニアを養成する、ということです。大学や専門学校、職業能力訓練校、それ以前の中学・高校まで、段階に応じて情報処理教育を行い、その中で適性のありそうな人を開拓します。これは現在でも行われていますが、学校教育だけではなかなか現場に対応したエンジニアを教育するのは無理なので、あくまで「基礎」的な教育を行います。全員とは行きませんが、段階を踏んで行うので現場で数年もすればそれなりのエンジニアになるでしょうが、学校で教育したからといって、そのままエンジニアになるのかといえばそうではありません。

　そこで今度は「ソフトウェア開発」の敷居を低くすることが考えられました。つまり、専門的な知識が必要なエンジニアが足りないのなら、専門的な知識がなくても開発できるようにすればいいのでは、というアプローチの仕方です。今のように探せばどんなソフトウェアでもありそうな時代になったのはこのアプローチが成功しているといえます。

　昔はパソコンでも「OS」を買うという発想がありませんでした。今ではアプリケーションやゲームを買えば対応OSがあると思いますが、昔はワープロにしろゲームにしろOS上で動作するのではなく、独自に動作していました。ですからパッケージには今のような対応OS（WindowsXPなど）が書いてあるのではなく、機種名が書いてありました。ソフトウェアを作るにはまず特定のハードウェアを理解しないとできないので、開発できるエンジニアが非常に限られていました。それをOSや開発ツールが吸収してしまい、徐々に開発するために必要な最低要件を減らすことができました。この流れは今でも続いており、最終的には誰でも簡単にできるようになると思います。

　どちらかといえば、相反する2つのアプローチによりソフトウェアを「作る」ことに対しての問題はほぼ解消しているといえると思います。しかし、一方がスキルを身に付けさせる方法に対して、もう一方は、スキルがなくてもできるようにしたために、現場ではスキルの格差が生まれてしまいました。通常、スキルのある人が難しそうな部分を担当し、スキルの乏しい人が簡単な部分を担当します。

　つまり、スキルのある人に負荷がかかることになります。これがまず生産性の向上が図れない理由の1つだと思います。良くあるのが、開発も終盤に入るとスキルの乏しい人から段々とヒマになっていきます。そうなるとテスト工程の準備や簡単な手伝いがメインとなり、なかなかスキルアップが期待できません。

　以前に、スキルの乏しい若いメンバーに勉強も兼ねて難しい所を一部担当させたことがあります。最初はやる気を出していろいろ調べたり、聞いたり、サンプルを作ってみたようですが、基礎的な知識があまりないため進まず、本人はやって行けないと自信を失ってそのまま辞めてしまいました。いろいろヒントを出してもあまりピンと来ないようでした。このことがきっかけでエンジニアの教育についていろいろ考えるようになりました。

　ソフトウェアのように、階層構造に分けて目で見えないロジックを考える仕事は、いきなりスキルが身に付くことも見るだけで盗むことも難しいでしょう。「学問に王道なし」とはよくいいますが、基礎から順番に積み上げて行かなければいずれ行き詰ってしまいます。それは業界にとっても会社にとっても、そしてエンジニアにとっても不幸なことです。

　開発環境やフレームワーク、ライブラリが中途半端にエンジニアのスキル不足を補ってしまう現状が結果的にプロジェクト内でのバランスを崩し、せっかくの機能も生産性の向上につながらないと言えます。

■エンジニアに不幸な「生産性の向上」

　経営側だけが自分の考えだけで生産性の向上を考えた場合、エンジニアにとっては不幸な結果になることが多いと思います。特に経営者がエンジニア出身ではなかったり、エンジニアを経営資源の1つとしてしか考えていない場合はそういう傾向になりやすいです。

　経営者が「利益」を追求することは当たり前です。ボランティアではないですし、儲けがなければ会社を経営しても辛いだけです。社員の給料も売上（利益）があって初めて出せるのであって、そのために生産性を考えるのは何ら悪いことではありません。

　会社経営を行う場合、長期的な目標と、目先の短期的な目標を立てるのが普通です。大企業で良く「経営五カ年計画」と言われるようなものを作るのはそれに当たります。ただし、企業規模が小さいと、あまり長期的に経営を考えることは少なく、目先のことで手一杯になる場合が多いです。ソフトウェアを開発する場合、ソフトハウスやSIerは基本的に開発が終わってから初めて利益（入金）になります。

　SIに関しては工事進行基準の対象にもなったのでフェイズ単位での支払いもありますが、長期で展望するためには開発中も給与などの人件費は先払いになるため、それなりに資金が必要となります。中小のソフトウェア会社を名乗る会社に派遣業務が多いのは、これが関係してきます。自社開発だけで人件費が賄えない時は、派遣で毎月収入がある方が会社として経営しやすく、エンジニアの雇用も守れます。前回書いたように元々「特別な職業」という認識があったのでエンジニアの単価もそれなりに高かったのもあります。

　利益を考えたら、ソフトハウスでは短期間でできるだけたくさんのソフトを販売して売り上げを上げることであり、SIerならたくさんのプロジェクトを短期間で納品することが一番といえます。（ここには営業は考慮していませんが）そのことから、利益を上げるには生産性の向上を常に求めることが必要となります。

　経営者が生産性の向上を考えるのはあくまで「利益」優先です。エンジニアをないがしろにしているとはいいませんが（いないと生産活動ができないので）、エンジニア個々のスキルや負荷に関してはあまり考慮していません。

　納期も基本的に顧客の希望が第一です。そのため、エンジニアに対しては負担を強いることになります。また、それでも足りない時はコストカットやリストラも視野に入ってきます。経営者からすれば給与を払っているのでスキルアップのために努力することは当然だと思っていますし、相手がある以上、多少厳しい納期でも相手の意見がまず第一だと思うでしょう。どんなに画期的な製品を作っても、「売れてなんぼ」です。

　しかし、開発環境が高機能になったおかげで開発の敷居が下がり、それにより少し事情が変わってきました。ソフトウェア開発が一般的になった分、ユーザーもある程度ソフトウェアを作れるようになり、場合によっては少し踏み込んで話をしてくるので（これぐらいはできるハズだよね、みたいな）、感覚的には特別なものという認識があまりなくなりました。そのため、エンジニアに技術的なスキルを求めるのではなく、とにかく完成させることができるだけのスキルしか要求しなくなります。ですから、技術的な教育には費用も時間もかかるため、あまり関心がなくなります。

　経営者はエンジニアが考えるよりはるかに厳しい立場です。決してふんぞり返っているだけではありません。最終的なクレームも損害もすべて背負うため、現場のデスマーチ以上に辛いと思います。エンジニアのスキルアップがどうでもよいわけではなく、利益を得るためのトレードオフになっているだけで、そこはエンジニアの良心に期待するしかないのもあります。わたしも経験ありますが、「もうちょっと分かってくれよ」と思ったことは何度もあります。

　ただ、不幸なのはエンジニアが頑張っても利益が上がる保証がないのと、利益が上がってもなかなかエンジニアに恩恵が感じられないところです。エンジニアが苦しい思いをして生産性の向上に努力しても報われないと感じるため、それが続くと結局、スキルアップの努力は続かなくなりますし、さらなる努力を求められると退職も考えるようになります。

　ここで社長のねぎらいがあるとか、利益が上がった場合は還元してくれるとか、ある程度目に見えて経営側も苦しいけど一緒に頑張ろうという姿勢が伝われば、エンジニアもそれなりに理解してくれると思います。しかし、口だけで利益がないから仕事が遅いとかいわれ、社長が高そうな車なんか乗っていたら、それはエンジニアにとって不幸でしかありません。

　エンジニアもまずそれなりに会社の財務状況を把握した上でどうやって生産性を上げるのかを考えることがこれからは必要だと思いますし、経営側も財務状況をある程度公開した上でどれだけ利益があがればそれを還元できるかを明確にするべきです。お互い同じ目標に向かえるように経営側が仕向けてやれば、みんな頑張るでしょうし、それこそ「それにはまず技術が必要だ」と説けば社員も少しはスキルアップを考えると思います。

　高度成長期はとっくに終焉し、ただ「みんなで頑張ろう！」というだけではもう誰も頑張れません。

■先輩エンジニアの役目

　ハードウェアやソフトウェアの基礎技術はすでに確立されていて熟成されています。反面、応用技術は常に進化して、その流行り廃れは非常に早いです。昔は基礎技術から順番に追わないとソフトウェア開発はできませんでしたが、今は土台となるOSの開発環境と最低限のソフトウェア知識があれば事足りるようになりました。知識を「ゼロ」ベースから考えた場合、今の方がはるかにソフトウェアの生産性は上がっていると思います。職場では応用技術がメインのため、先輩から継承されるのはその職場で必要な応用技術がほとんどだと思います。

　しかし、実際にプロジェクト全体としての生産性を上げるには基礎技術の習得と継承が必要だと思います。それは前回も書いた通り、トラブルがあった時の調査や、複雑な処理を実現したりするためです。基礎があっての応用は新たな応用に繋がりますが、基礎がない応用は、新たな応用にはなかなか繋がっていきません。

　今のようにいろいろな情報が溢れていて、複雑なソフトウェア体系の中ではこれからエンジニアを目指す人が地味な基礎技術を習得するだけの理由を見つけるのは難しいと思います。それこそ先輩エンジニアはまず基礎技術を後輩に継承していくべきだと思います。それにより先輩エンジニアも忘れない様に再確認できます。

　いろいろコメントもいただきましたが、わたしは何もすべてのブラックボックスの中身を知る必要もこじ開ける必要もないと思っていますし、生産性や採算に見合うなら使うことは間違っていないと思っています。商用製品であれば、開発元に対応してもらえばそれはそれで良いと思います。その上で、作れるなら作った方が……とは考えています。しかし、いざとなったらこじ開けてでも原因を探るぐらいの気概と何とか調べられる程度の基礎技術は必要だと思います。

　直してもらうにしてもある程度「ここが悪い」といえなければ「仕様」といわれるかもしれません。その重要さが分かっているから、後輩の教育には基礎的なことを理解してもらえるように努力します。ひょっとしたら必要ないかも知れません。でも、いつか必要になった時に1つでも解決するための「武器」になればそれで良いのではないのでしょうか。エンジニアの矜持とはそこにあるような気がします。

■「当たり前」なことは1つだけ

　生産性の向上はある意味、いままでもそしてこれからもエンドレスなテーマとして続いていくでしょう。多分、ゴールはないでしょうし、そのためのアプローチはこれからもいろいろな方面からあると思います。ひょっとしたら開発ツールすら必要になり、マウスで数回クリックするだけでアプリケーションが作れるようになるかも知れません。

　エンジニアとしてこれからも飯を食っていこうと考えるなら、まず「当たり前」なことはほとんどないと考えましょう。会社も、仕事も、給料が出ることも、働く現場があることも、すべて自分以外の人が頑張っているから、今の自分があるのです。エンジニアにとってたった1つの「当たり前」とは「技術を常に磨くこと」、これだけです。

　どんなに便利なツールを使っても、それを作るのはエンジニアですし、使うのもまたエンジニアです。便利さにあぐらをかかないで勉強することは必要ですし、その大切さを伝えるのもまたエンジニアの役目です。この継承がうまく行けば、おそらく開発現場の不均衡な負荷は減り、少しは明るい未来が見えて来ると思います。

　生産性の向上は1人ひとりのエンジニアの自覚と矜持が一番効果的だと思います。わたし自身はこれからもそう思って自己研さんと後輩の指導をしていきたいと思っています。技術で語りあいができるのは、本物のエンジニアだけですから。

　前回のコラムは長い間コメントいただき、ありがとうございました。最後の方はちょっと趣旨とずれたかな、と思えたのと、レスすると今回のコラムのネタにかぶりそうだったのであまり書けませんでした。すいません。ある意味、今回も続きみたいなものなのでまたコメントいただけたら、と思います。内容は相変わらず極端ですが、そこはご容赦を。

　タイトルを見て分かるとおり、長くなってしまったため、今回は2部構成にしました。このコラムだけでコメントをもらっても、次の内容の兼ね合いもあってなかなか返しにくそうなため、今回はコメントを受け付けません。次回はいつも通り受け付けるので、最後まで読んだ上でまとめてコメントをいただけるとありがたいです。

　さて、1月のお題は「生産性向上のしかた」ですが、実は以前のコラムでも少しだけ触れています。内容的には、「エンジニアはコスト意識を持って、生産性の向上に努めるべきだ」というような感じのものです。大なり小なりエンジニア側からすると、コスト意識やスキルの研さんをもって生産性を向上させることができると考えているのではないのでしょうか。

　この考え方は、エンジニアとして非常に正しいと思います。

　しかし、実際はなかなか難しいのが現状だと思います。新人の頃は「あれもこれも」なんて考えながらがんばれます。しかし、ある程度仕事を任されて、責任も少しずつ出てくると今の仕事を無難にこなすことで手一杯になり、やがて、必要以上のスキルの習得やコスト削減の意欲が失われていきます。職場やプロジェクトにもよりますが、残業やデスマーチが多いところでは生産性（＝利益）を上げるために、おそらく「残業」や「給与」がカットされているところが多いと思います。

　一般論ですが、生産性は平たくいえば「インプットに対してどれだけのアウトプットを出せるか」の指標です。本来は経済的な指標なので、どれだけのコスト（リソースや期間も含む）で、どれだけの売り上げがあるかを表すものと思います。

　ソフトウェア開発と言う行為で考えれば「効率」の方が言葉としては合いそうですが、インプットは「人（人件費）」と「経費」と「開発期間」になります。アウトプットはその結果の売り上げでしょう。結局、どれだけ人や経費、開発期間を減らせるかが生産性を上げるためのカギになります。

　ちなみに、エンジニア視点で考えるとなかなか思いつかないのが「アウトプット」の部分です。生産性を単純に向上させるなら、売り上げアップを考えることも「あり」なのです。むしろ経営者はここをまず考えます。売り上げアップが望めないなら今度はコスト（インプット）の部分を削ろうとします。

　整理すると、ソフトウェア開発において生産性を向上させるには、

• 人件費を下げる
• 開発メンバーを減らす
• 開発期間を短くする
• 経費を減らす（広告費や設備費など）
• 売り上げを増やす

　となります。人を減らすことは、製造業では基本的にそのまま戦力ダウンになるのですが、ソフトウェア開発では効率を上げることができれば、戦力ダウンに繋がらない特殊な事情があります。もっとも簡単にできれば誰も苦労はしないのですが。

　売り上げを増やすこと以外は、やろうと思えばなんとかできることだと考えられますが、（良い悪いは抜きにして）、さすがに計画して簡単に売り上げが増えることは考えにくいため、結局、生産性向上のためには「インプット」を少なくすることが現実的といえます。

　生産性を主眼に据えて考えた場合、エンジニア側の考え方と経営者側の考え方があります。わたしが掲げている「ソフトウェア開発の明るい未来」は、この両者の考え方の相違が暗いものにしていると考えています。

　生産性はいいかえれば「利益が出るための組織なのか」ということになります。（あくまでも経済的な指標なので）開発効率と置き換えても指標基準が違うだけで意味合いは同じですが、本来は両方が同じベクトルで考えて行くべきものだと思います。ですが実際は逆の方向を向いているように感じます。しかも基本的に「エンジニア ＜ 経営者」という力関係があるために、バランスが取れなくてエンジニア全体の質が平均するとなかなか上がりません。

　一番バランスが取れるのは、エンジニアがそのまま経営者になることです。エンジニアとしても仕事をしている会社役員やフリーランスの方がそれに当てはまります。それは、コスト削減やスキルアップの重要性も、売り上げアップの必要性も認識しているからです。逆にどちらが欠けても成り立たなくなる危険性も分かっているのでサラリーマンエンジニアよりも間違いなくシビアなため、総じて開発に対する意識は高いです。

　ただ、業界を構成している大部分はあまりエンジニアの重要性が分かっていない（であろう）経営者とある程度収入が安定しているサラリーマンエンジニアです。この両者がもう少しきちんと「あるべきエンジニアの姿」を考えないと生産性の向上も業界の発展も難しいと感じます。

　今回はそれぞれの立場から生産性の向上について考えてみようと思います。両者における共通のキーワードは「開発環境」です。

■エンジニアの矜持

　エンジニアを主体に考えて生産性を向上させる場合、エンジニアひとりひとりがまず経費などのコストを減らす努力をすることです。金額はともかく、これはどんなエンジニアでも頑張ればできると思います。大企業になると、1人当たりのコストをちょっとでも削るとそれでかなりの額になります。その上で、業務に必要なスキルを日々磨くことだと思います。わたしはひとりのエンジニアとしてそうありたいと思いますし、後輩もそうであって欲しいと願います。

　わたしがエンジニアになった頃はまだパソコンもあまり普及していなかったので「特別な職業」と周りから思われていました。実際、ソフト開発の敷居も個人では高く、ある程度好きな人でないと独学で学ぶのは難しい時代でした。人材不足もあり、各メーカーではとにかくエンジニアを「増員」することに躍起になり、未経験者もとにかく教育しました（経験者の方が少なかった）エンジニアの高度成長期と言えたかもしれません。

　ところがハードやソフトも高価なものから安価になり、使う人も専門の人から一般の人に広がったことにより、ソフトウェア開発も仕事ではなく趣味で、しかも仕事と同じレベルに近い環境でできるようになりました。ソフトウェア開発を行う人が仕事か趣味かを問わず同じようにできるようになったのです。

　そうすると、アマチュアレベルの職業エンジニアもスーパーエンジニアクラスの趣味エンジニアもそれなりに増えてきます。すると、商売としてもまた趣味として自分が便利になるものを作りたいという要求（欲求）が徐々に広がってきます。それを受けて開発ツールが少しずつ進化していきます。

　趣味で使えば楽しく作れて思い通りに動くソフト、仕事でプロが使っても耐えうるぐらいに高機能なソフトの両方のニーズがひとつになるとVBのような非常に高機能な開発環境が出てきます。そして、ソフトウェアに対する欲求はそのまま生産性の向上にも繋がっていきます。

　ここにインターネットの普及が加わり、情報検索や情報発信がそれこそ地域や国境を越えて行えるようになりました。開発者自ら情報発信を行うため、開発環境（ツール）を使ったサンプルや使い方などの情報が誰でも検索できるので、そのすそ野は広がりました。各々が便利にするための無償ツールやフレームワーク、ライブラリもたくさん開発されました。商用ソフトウェアを開発・販売する所でさえ、現在はそうしたものにも一部お世話になっていると思います。これはソフトウェア開発の「生産性」向上のための手段といえます。

　現在ではソフトウェア開発という行為も「プログラマ」と言う肩書もすでに特別なものではなく、むしろ興味があれば誰でも行えるものであるといえます（規模の大小や品質の問題はありますが）。

　特別なことではなくなったため、生産性に関していえば、エンジニアのスキルアップ以外でも向上します。必要な機能がすでに実装されているフレームワークやライブラリ、それらを容易に組み合わせてデバッグ・テストができる開発ツールを使い、初歩的なプログラミング技術とツール類の使い方がわかればそれで開発期間は短縮できます。フレームワークやライブラリ、開発ツールが安価、もしくは無料なら同時に経費も削減できます。

　生産性向上だけを考えれば、エンジニアのスキルは「考える」ことではなく「上手に使う」ことを優先した方がおそらく早いです。皮肉なことに、手を加えるところが少ないエンジニアの方が、何でも自作できるスキルの高いエンジニアよりも生産性が上がります。

　こういう現状では、なかなかエンジニアの矜持を保つことは難しいかも知れません。

■経営者の悩みと思惑

　昔からIT業界では人材不足と言われてきました。ソフトウェアを始め、システム開発自体は基本的には大きなプロジェクトだったので元となるメーカーや大手SIerでは1カ月以上かけてエンジニアを教育して現場に投入しました。端末などが一般的なものではないのが普通だったので、教育をする必要もあったでしょう。

　ところがハードもソフトも安価になってくるといろいろな所でIT化が進んできました。大きなプロジェクトもありますが、小さなプロジェクトも増えてきました。プロジェクトが増えると相対的に人手も必要です。この先ずっとプロジェクトがある訳でもないため、人件費の兼ね合いでプロジェクトの請け負い元で全員雇用する事はできません。そのため、派遣やフリーのエンジニアが増えてきました。どこも人手不足だったので派遣構造が2重、3重、それ以上になることは、今も当たり前にあります。

　昔は本で勉強することができましたが、COBOLやPL/Iなどは自宅で試行錯誤まではまずできませんでした。そのため、教育を受けるか経験がある程度ないと派遣先でも仕事ができませんでした。

　ところが、今は自宅でも簡単に試行錯誤ができます。この頃は試行錯誤どころか正解まで探せば出てきます。つまり、業務経験があまりなくても教育を受けていなくても少しの興味とやる気でエンジニアになるのは可能になりました。足りない業務経験や教育のデメリットを開発環境とインターネットの情報で補完してしまえるのです。

　経営者の優先事項はまず「利益確保」です。どんな仕事でも運転資金は必要ですし、それは額の多い少ないはあっても「無限」ではありません。やはり利益を上げていかないといつかは倒産し、そこにキレイごとは通用しません。そのため売り上げアップと生産性の向上は必ず考える必要があります。

　しかし、経営者視点で考えるとエンジニア任せの「生産性向上」はある意味リスクとなります。よほど信頼があるなら別ですが、例えばあてにしていた人が急に退職したり、怪我や病気などで仕事ができなくなったり、難しい技術を使った仕事が来たり、エンジニアがなかなかスキルを磨こうとしなかったり……不安要素は挙げればキリがありません。

　そういう意味で経営者はなるべく優秀な技術者を必要なだけ集めようと考えるのは自然だと思いますが、なかなか理想通りのエンジニアが必要数集まるのは大手企業ならともかく、中小零細企業では非常に難しいことです。それは安定性の面と待遇の面で大手にかなわないからです。わたしもこの問題は非常に悩んだ記憶があります。

　そのために、経営者はエンジニアのスキルによらない生産性の向上を考えます。元々、教育したりするのはスキルの偏りを減らして平均化することにあります。決してエンジニアのスキルアップを期待している訳ではなく、１人に負荷をかけずに全員で同じようにできるようにするためのいわばリスクヘッジ的な要素が強いです。とにかく1人欠けても業務が継続できて、補充要員も教育して戦力になるように考えます。

　これが、開発環境やフレームワークなどが高機能になったおかげで、リスクヘッジの仕方が変わってきました。「スキルアップをしてきたエンジニアしかできない開発」から「誰でも簡単にプログラムが組める高機能な環境での開発」へと変わってきたのです。これが顕著に分かるのが「教育」です。大手は別として、中小零細企業ではあまりプログラミング教育をしなくなりました。スキルアップのための啓蒙などもあまりなく、プログラミングですら入社前にある程度勉強してこい、と言う程度です。逆をいえば、プログラミングがすでに一般的だともいえます。

　経営者からすると、時間をかけてスキルアップさせてきた社員がある日突然辞めたりしてダメージを受けるよりは、それ以外の要因で生産性が向上できればそっちを選択することは当たり前だと言えます。これはエンジニアが、会社の財産から使い捨てに変わったことを意味します（ちょっと極端に言い過ぎですが）。

　そう実感するのはエンジニアの給与が残業を含め、あまり上がらなくなったのと、開発期間が段々短くなっていることです。とにかく目的のソフトウェアを早期に「完成」させることが一番重要になっているのは間違いありません。経営者が長期的な展望よりは目先の利益を考えるようになっている証拠でしょうか。不況になるとますますこれに拍車がかかると思います。

■なぜ、生産性は向上しないのか

　ソフトウェア開発環境が高機能化してくると効率が上がるため、本来は生産性も向上します。実際、高機能化のメリットの1つが生産性向上のため、これは本来、エンジニアにとっても経営者にとっても非常に良いことであるはずです。

　ベテランエンジニアになればなるほど実感していると思うのですが、その割に生産性が上がったとか実感はあまりないと思います。むしろそういう面では何も変わっていない気がしていると思います。実感できるのは、おそらく原因が分かりづらいトラブルが増えたこととコーディング量が減ったことぐらいでしょうか。おそらく「減った」ものより「増えた」ものの方が多いと思います。

　その一番の理由が、エンジニアのスキル不足を開発環境やツールなどが必要以上に補っている点です。スキルの高いエンジニアが利用すると非常に効率は上がると思いますが、高性能がかえってアダとなり、スキルの低いエンジニアが適当にやってもまず動作することが多いため、自分がそれなりにデキると錯覚しやすいです。特に最近は「ググる」ことでほぼ解決できます。

　錯覚してしまうとエンジニアはスキルアップをなかなかしません。それは自分でその必要性を感じなくなるからで、その結果、エンジニアのプライドだけが高くなり、スキルと評価は上がらなくなります。

　ソフトウェアを「作る」ことはスキルがあまりなくてもできるようになりました。でも、内部構造や動作するしくみを「調べる」ことはそれなりにスキルがないと今でもできません。つまり、作ること自体は減ったのですが、それ以外の「調べる」ことが逆にできなくなったために、結果として生産性が思うように上がらないとわたしは考えています。

■何が足りないのか

　後編では、どうすれば「幸せ」に生産性を向上させることができるのかを、わたしなりに考えて書きたいと思います。個人的にはただ生産性を向上させればそれで良いとは思っていません。その辺りを考えてもらえたらいいな、と考えています。

　良かったら後編も読んでみてください（続く）。

　あらためて書きますが、わたしのエンジニア歴は20年です。20年前といえば、バブルの末期だったと記憶しています。世の中が好景気だったので、学歴が低いわたしでも就職で苦労した記憶はありません。今の若い人から見たらうらやましいというか信じられないと思います。

　エンジニアとしても「ハードウェア設計」から始まり、プロジェクト規模も大規模（都市銀行）から1人でデバイスドライバ作ったり、PG、SE、 PMどれも経験しましたし、正社員、派遣、フリー、経営者（起業）すべて経験しました。プロジェクト自体の失敗はあまりないですが、起業は多分失敗しました（それでも懲りずにまたやりたいと思っています）。

　いろいろな立場でいろいろな規模のプロジェクトを経験してきたのですが、ここ最近は昔と違い、エンジニアの気質が変わってきたと感じます。これは若いエンジニアだけはなく、それなりに経験のあるベテラン領域のエンジニアも同様です。

　ターニングポイントはおそらく「インターネットの普及」だと思います。ブロードバンドが安価になり、職場でも家庭でもインターネットに接続できるようになりました。これから先エンジニアになる若い人は、物心ついた時からすでにインターネットは当たり前だった、という時代も、遠からじくることは確実です。前のコラムでも少し触れましたが、エンジニアは非常に便利なツールを手に入れた代償に大切な「何か」を失ってしまいつつあると、現場を見てて感じます。

　今回はその「何か」を考えながら、あらためて先輩エンジニアはこれから何を若いエンジニアにしていくことが必要なのかを書こうと思います。

■お腹いっぱい

　わたしが初めて買ったパソコンはシャープの「X1」でした。スペック的には（憶えている範囲なので違っていたらゴメンなさい）CPUはZ80Aの4MHz、メインメモリは64KB、VRAMはI/O空間にマッピングされていたのでメモリとは別に48KB、漢字は別売りの「漢字ROM」がないと表示されず、フロッピーどころか記憶メディアはカセットテープという今では考えられないスペックです。当時はOSなんて知らなくて付属のBASIC（ハドソン製のHu-BASIC）で遊んでました。容量単位なんかは間違いか？ と思えるほど少ないです。

　ゲームソフトはそこそこありましたが、当時高校生のわたしに買えるはずもなく（それにゲームならファミコンの方が、という感じでした）、例えばワープロとかそういうソフトもなかったので（そのうち出てきましたが）「ベーマガ」（あえて略称で。分かるに人はなつかしいと思います）という雑誌に載っているプログラムリストを自分で打ち込んでは改造しながらプログラムを学んで行きました。

　そのうち、BASICでグラフィックツール（お絵かきソフト）を作ったのですが、どうしても満足できなくてそこで初めて「マシン語」を使いました。つまり、紙にアセンブラをコーディングし、命令変換表を使って自分でマシン語に変換し（ハンドアセンブル）それをBASICのpoke命令を使って指定アドレスに1バイトずつ丁寧に格納するプログラムを作ります。当然、コーディングミスやタイプミスなんてのはあるのですが、デバッガなんてものもなく「実行」→「暴走」→「チェック」の繰り返しで、非常に気の長い作業を延々やってました。自分の欲しいソフトはすべて自分で作るしかなかったので、その過程でハードウェアの非常に低レベルな所から掘り起こすクセがつきました。そうしないと、なかなか希望するものが作れなかったのです。

　今はネットや雑誌などから作る気なら、開発環境も言語も容易に手に入ります。それ以前にたいていのソフトは誰か作っていることが多いので、探すだけで手に入ることも多いと思います。つまり、昔は欲しいソフトがあれば作るしかなく、満足するにはいろいろ調べて細かいことまで知らないとソフト開発もできなかったのですが、今はそんな必要もなく便利な開発環境やツール、フレームワークが大量に存在します。技術的にもソフトウェア的にも昔は飢えた状態でしたが、今は「お腹いっぱい」の状態なので、今のエンジニアはそれらを便利に使うことを考えれば良くなってます。

■インターネットの功罪

　今と昔の状態を比較して「だから今のエンジニアはダメなんだ」と短絡的にいう気はありません。確かに、昔は資料もツールもないので何でも自分で調べて自分で作るしかありませんでしたが、逆に今はハードもソフトも複雑に絡んで動作しているため、昔と同じようにやるのは基本的に無理といえます。

　仕事に至っては、いろいろなツールやライブラリ、フレームワークをいろいろ検討して、一番効率的にプロジェクトが完了する方法を予算と期間を考慮して実行するのが普通だと思います。職業エンジニアの場合、会社や顧客はスキルを要求するのではなく、会社は短期間にプロジェクトを完了させられることを、顧客は期間内に希望通りのシステムをトラブルなくできあがることを要求します。裏を返せば、スキルではなく、ごまかすことさえできれば成立してしまいます。フレームワークやライブラリを使うと手を入れるところが少なくなるので、それこそ小手先のスキルで仕事的には成り立ってしまう可能性はあります（良い悪いは別として）。

　そうはいっても、インターネットが普及する前までは今のように誰でも簡単に……でもなく、メーカーのツールやライブラリも高価だったので会社で購入し、それをそれなりに研究して使うことも多かったと思います。資料などを社内で蓄積していき、先輩が後輩を指導しながらエンジニアを育てていく環境があったように思います。

　インターネットは、確かに情報ツールとしてもまたコミュニケーションツールとしても革新的なものをもたらしました。しかし、その裏では本来対面で話すべきことすらメールで済ましてしまったり、先輩も後輩もググることの方を優先してしまい、後輩が先輩に聞いたり、先輩が後輩を指導したりといった職場やグループ内でエンジニア的なコミュニケーションがなくなりつつあります。そのため、コードの意味も分からず「動くから」「使えそうだから」といった何となくフィーリングでスキルと経験を積み重ねています。これは若いエンジニアだけではなくベテランのエンジニアにもいえることです。

　便利なツールが、エンジニアとしての「つながり」を断ち始めているとも取れます。ITエンジニアは元々コミュニケーションが苦手な人も多く、それも拍車をかけていると言えます。わたしの職場でもそうですが、下手すれば1日中職場内で会話しないこともあります。これは昔はなかったと思います。

■エンジニアはすでに育たない

　極論で申し訳ないですが、これからはエンジニアはなかなか自分から育つということは難しいと思っています。

　ソフトウェア開発の軸が「作り出す」から「上手に組み合わせて使う」にシフトしている現状では、最初に述べたとおり基礎技術はすでにお腹いっぱいです。そのうえで行うので、自分からわざわざ下のレイヤー（ハード、OS、ライブラリ、フレームワーク）のことを調べて学ぶ必要もないからです。わたしが知っている若いエンジニアにはビックエンディアンやリトルエンディアンがすでに死語になっている人もいます。確かに日常ではあまり使わず、バウンダリの位置がおかしくてエラーになることもまずないでしょう。逆にWebアプリでは「デザイン」のスキル（というかセンス）が要求されるでしょう。

　まわりの状況が満たされている。そして、技術の移り変わりが早いため、じっくり取り組んでやるよりは新しいことを常に試行錯誤することを求められるので、スキルの考え方が少し昔とは違います。また一口にソフトウェアといっても、昔とは比べものにならないぐらい範囲が広いため、すべての技術を習得するのもすでに不可能といえます。そういう中で新人エンジニアが自分から必要な技術をあれこれ学習して育つのは難しいと考えます。

　そういう意味では、先輩が後輩エンジニアを育てる「環境」を意識して作ってやらないとそれができない職場やグループはいつか機能不全に陥る可能性をはらんでいると思います。派遣エンジニアなら、後ろ盾を失えばそれで職業としてエンジニアをあきらめざるを得なくなってしまいます。前は「プログラマ35歳定年説」なんてありましたが、今は職場を見るとエンジニアの平均年齢は確実に上がっており、下からの底上げが必要な会社もあるんじゃないでしょうか。

■結果がすべてとは限らない

　世の中、だんだんと結果「のみ」が求められて来ています。仕事においては昔からそうなのですが、最近は早期に出すことを要求されています。政権交代が起こって約4カ月ですが、テレビのワイドショーなどでタレント司会者が分かったような顔で「国債発行して借金増やすの？」「こども手当はどうなの？」「ムダ遣い、天下りはどうなの？」と矢継ぎ早に攻め立ててあたかも庶民の代表、正義の味方みたいな振る舞いをし、野党は「政治とカネの問題を追及する」といっています。たかが4カ月で今まで戦後積み重ねてきたシステムが変えられるはずも借金を減らせるはずもなく、マスコミもウケだけを狙って政権のミスを誇張していきます。

　われわれ国民も、国債発行や増税はイヤだけど、景気は良くして欲しいと各々自分の都合のよいことだけを主張しています。そんな世の中だからどこにも余裕がなく、閉塞感だけがまん延しています。これでは誰も前向きに頑張ることなどできなくなってしまいます。

　IT業界では、せめて若手に対しては結果だけではなく過程も大切にしてあげないと、本当に「横着」なエンジニアがたくさん出てきます。

　若いエンジニアに経験を積ませてスキルの研さんを促すのは大切です。未熟なエンジニアに結果だけを求め、できなかったら責めるような業界では未来は明るくなるはずもありません。

　特にこれからは本格的に平成生まれ、ゆとり教育世代が社会に出てきます。考え方も状況も昔とはまるで違うのでそれを踏まえて若いエンジニアの質が上がるようなもっと「育てる」環境作りが必要だと思います。

　ググって、自分が理解していないコードをコピペすることはかまいませんが、そこで終わってしまうようなエンジニアではなく、それが良いのか悪いのかを試行錯誤しながら正しく理解できるようなエンジニアを育てることが業界全体を明るくするのではないのでしょうか。プログラムを作るエンジニアではなく、「プログラムを考えるエンジニア」を目指して欲しいと常々考えています。

　会社としては、とにかく仕事をこなして収入を確保しないと屋台骨が揺らいでしまうため、今は育てるどころか新入社員も採用できない状況にありますから、今の若いエンジニアやエンジニア志望の人には気の毒な部分があります。厳しいですが、若いエンジニアにはめげずに頑張って欲しいと思うのが先輩としての願いです。

　みなさま、新年明けましておめでとうございます。硬派担当のにゃん太郎です（笑）。今年もわたしの考えを述べつつ、みなさまといろいろ意見交換ができると幸いです。本年もよろしくお願いします。

　名前だけ見るとふざけているようで、とても硬派ではないのですが、この「にゃん太郎」という名前はわたしの奥さんが実際にわたしを呼ぶ時に使っています。付き合い始めた頃からなので、すでに10年以上になります。長いこと使っているので、時々外出先でも奥さんに「にゃん太郎」って呼ばれます（ぉぃ）。

　さて、今年の最初のテーマは「フレームワーク」です。最近のソフトウェア開発にはなくてならないものを通り越して当たり前になっています。フレームワークと呼ばなくても構造的にフレームワークになっているものもけっこうあります。わたし自身はシステム開発においてフレームワークの必要性というか有用性は理解していますし、先ほども書いたとおり、なくてはならないものだと思います。ただ、何でもかんでもフレームワークって言うのはソフトウェアエンジニアとしてはどうかと考えています。やや長いですが、お付き合い下さいませ。

■なぜ、フレームワークを使うのか

　フレームワークは「骨組み」という名前が示す通り、ソフトウェアを形成するベースとなる「枠」をあらかじめ構成したものです。骨組みといってもフレームワークによってその範囲はまちまちなので、汎用的なものから特定用途（Webアプリなど）や特定業務（金融など）、オープンソースから製品まで幅広く存在します。また、ライブラリ的なものから開発環境と深く結び付くものまであります。誤解を恐れず言えば、OS自体も本来はハードウェアが変わっても同じアプリケーションが動作することを機能の1つとして挙げられるため、アプリケーションから見た場合、一種のフレームワークとみることができます。ライブラリやクラス、Windowsではコントロールも場合によっては同じような使い方をします。そういう意味では割合、無意識のうちにフレームワークを利用しているとも言えそうです（ただし、ここではOSやライブラリなどを含めてしまうとかなり広範囲になるため基本的に一般に言われているフレームワークのみを扱います）。

　では、なぜフレームワークを利用するのでしょうか。理由は大きく分けて2つあると思います。1つは「生産性の向上」です。ソフトウェア開発をしていれば分かると思いますが、同じような処理を何度も行うことがあります。例えば、文字入力、画面表示、ウィンドウを閉じるなどです。特定業務だと同じような処理（計算式など）もあるでしょう。これらを1から開発した場合、ビジネスロジック以外の処理を相当量作成しなくてはなりません。組み込み開発のようにハードウェアがその時々で変わり、OSがない場合などは仕方がないのですが、パソコンなどの汎用機では現実的ではありません。わたしがソフトウェア開発の仕事を始めた20年前から「人材不足」と言われており、慢性的な人手不足を考慮すると、いろいろな方向性を持ったフレームワークが存在するのは必然だと考えられます。

　もう1つは「品質の向上」です。ソフトウェア開発を1人で行い、その人が一生メンテナンスするなら問題はないのですが、実際そんなことはありえません。あっても1人で開発するぐらいだと思いますが、それも現状では例外と言えます。複数の人間でチームを作って開発を行う場合、問題になるのがメンバーのスキルが平均化しないということです。

　これは「早い・遅い」だけでなく、バグが「多い・少ない」も関係してきます。ソフトウェアは関数レベルで考えると基本的に入出力が決まっていて、そこに至る過程を設計、コーディングします。作った本人以外は意識してコードを読まない限り、他人にはブラックボックスであることが多いと思います。そう考えると、コーディング量を極力減らした方が品質は安定し、向上が期待できます。特にコーディング規約や命名規則もある程度統一しているものが多いため、それに合わせたコーディングを行えば保守性も向上します。

　ソフトウェア開発においてフレームワークが有用でなくてはならないのは、おそらく誰しもが認めるところだと思います。

■フレームワークで生産性は向上するか

　まったく利用しないケースに比べたら、必ず向上します。例えば、Windowsのアプリケーションを作る場合を考えてみます。テキストエディタを開いてゼロからWindowsAPIを使用してウィンドウを作成する所から始めるよりは、ひな形のウィンドウをあらかじめ作成してもらい、そこにコントロールをパズルの様に置いて画面を作成し、必要な動作（ボタンを押した時など）を記述した方がはるかに早いでしょう。

　さすがに例が極端過ぎますが、もうちょっと一般的に「フレームワーク」と呼ばれているものについて考えてみます。

　「フレームワーク」と聞いてピンとくるものでおそらく多いのは、Windowsの「.Net Framework」ではないのでしょうか。Javaなら「Struts」とか、PHPなら「CakePHP」や「Zend Framework」、「Ruby on Rails」もそうでしょう。「O/Rマッピング」もフレームワークでしょうか。仕事でもプライベート（趣味）でもお目にかかる機会はかなりあると思います。商用では「楽々Framework II」や「オブジェクトワークス」なんていうのがあります。大企業がユーザーだと「オープンソースでは何かあった時、サポートはどうなるんだ」と考える所が日本では多いため（わたしの実体験です）、商用フレームワークを導入する余地はあると思います。言ってしまえば、コストを取るかサポート（これは企業から見た場合、信頼性と同じ）を取るかでしょうけど。OracleやSQLServerも多少はそういう側面があると思います。

　これらフレームワークを使った場合と使わなかった場合、生産性に大きな違いが出るのでしょうか？ わたしの経験上、そんなに差があるとは思えません。むしろ変わらない気さえします。

　単純にプログラムの「工数」は減ると思います。設計もかなりビジネスロジックに特化したものが書けると思います。でも、生産性はナゼかあまり上がるとは思えません。せいぜいテスト項目がやや減るので、その分別な検証ができるかな、という程度です。

　わたしの経験なのでひょっとしたら「いや、うちはフレームワークのおかげで生産性も品質もものすごく向上したぞ！」とおっしゃる方がいると思います。それはそれでけっこうなことだと思いますし、できればそうであって欲しいとさえ思います。

　現場の人に「フレームワークを使うんだから、納期短くても大丈夫だよね？」なんて言おうものならほとんどの人が「えー」と言うと思います（もっとも、使っても使わなくても短くなることには反対するでしょうが）。誰しもフレームワークを使うからといって、短期間に開発ができるとは思っていないからです。逆に新しい（自分が知らない）フレームワークだったら、かえって覚えるのに時間がかかるとさえ考えるエンジニアもいると思います。おそらく現場レベルでは「フレームワーク＝言語仕様」に近いイメージがあるんじゃないのでしょうか。これがわたしが生産性が上がらないと思う理由です。

■フレームワークを使う理由

　建前は「生産性と品質の向上」ですが、実際は「一から作るより楽だから」という答えが圧倒的に多いと思います。もうちょっと良い言葉にするなら「保守性も考慮して」でしょうか。個人的には免罪符のような気もします。

　ただ、それなりに理由があり、特に「どう考えても工期が短い場合」などは有用だと思います。わたしはフレームワークの利用を「悪い」とは思っていません。でも「楽だから」という観点から使うことはエンジニアとしてはダメだと考えています。補足しますが、「楽すること」が悪いのではありません。特に考えもなく目先の「楽」を考えることがダメだと言うのです。同じ「楽」を考えるならもう少し長いスパンで考えるべきです。

　エンジニアが同じような処理を1つにまとめて極力コーディング量を減らす努力をした上で「楽をする」と言うのは間違いではありません。それこそバグ修正や機能変更時にはそれが功を奏するでしょうし、ソフトウェア開発の基本です。本来、フレームワークというのはそのような観点に立った上で成り立っているハズです。それを理解した上で使用することは良いのですが、それを忘れて単純に「このフレームワークを使った方が早くできそうだから」と考えるのはエンジニアとしては失格です。結果として早くできないことも多いでしょう。

　わたしは仕事でソフトウェア開発を行う場合、他人（他社・他プロジェクト）が作ったフレームワークは生産性と品質の向上にはあまりつながらないと思っています。ウィンドウやボタンのひな形など共通処理には必要ですが、フレームワークを使用して開発するには複雑なシステムが多いからです。

■フレームワークの盲点

　フレームワークの多くは便利な機能と引き換えに開発者にいろいろな制限を強いることが多いです。一番多いのはコーディングスタイルでしょう。フレームワークの利点を生かすのと引き換えに開発者にはルールの順守を求めます。ルールが順守できるのであれば、フレームワークを利用するメリットは大きいと思います。ただ、ルールにはメリットだけではなくデメリットも隠れています。フレームワークを利用して生産性や品質の向上を図るのならば、このデメリットをきちんと把握する必要があります。

　「.Net Framework」を例に少し考えてみます。最近は仕事でよく使うのですが、ちょこちょこっとしたツールを作るには非常に有用だと思います。簡単なコーディングでかなりのことが短時間にできて、確かに生産性は高いと感じます。ところがそんな調子でそれなりの規模のアプリケーションを作るとけっこうハマります。一気に処理速度が落ちたり、例外の実装が適当だとアプリケーションが落ちたり、エラー時に止めるべき処理が止まらなかったり。そうそう、突然前触れもなくアプリケーションが終了してしまうことや、ダンプすら出ない時もあったので、障害の特定に時間がかかったこともありました。

　「簡単」なことのメリットは確かにあります。このメリットは単に動くものを作るならば意味はありますが、仕事ではそれだけではダメです。確かにメモリ管理の必要もあまりなく、使用するクラスやメソッドは分かりやすいです。ただし、それらがどのように動作しているかをある程度把握していなければ、アプリケーションの規模が大きくなるにつれて管理しきれなくなり、あちこちにほころびができます。「簡単＝楽」ではありません。

　フレームワークを使いこなすには、ある程度内部でどのような動作を行っているかを知る必要があります。ちなみに「.Net Framework」にもいろいろな資料があるので仕事で利用する人は一度読んでみることをオススメします。知らずに表向きの便利さだけでコーディングすることが、どれだけ危険かが分かると思います。キツい言い方をすれば、分からなければこれから先、エンジニアで生きていくのは難しいかもしれません。

■行儀のよいシステムはあまりない

　フレームワークを使ってしばしば思うのですが、自分が実現したい機能がどうしてもできない時があります。そういう時はフレームワークから外れて処理をカスタマイズすることがあると思います。以前も書きましたが、アメリカなどではパッケージソフトウェアを「カスタマイズ」することはまずありません。せいぜい機能追加程度です。フレームワークに対しての考え方も同様で、その枠内でできるように機能を実装します。システムを自分たちに合わせるのではなく、自分たちがシステムに合わせることが基本としてあるので、システム開発という面については非常に合理的だといえます。それができないなら一から設計することを考えます。

　対して、日本では大企業になればなるほど、システムを自分たちに合わせるようベンダなどに要求してきます。ベンダも商売なのでパッケージソフトウェアをベースにカスタマイズするか、一から構築するならフレームワークなどを使って構築しようとします。言いかえれば、使える所をなるべく使って工数をできるだけ減らし、その分、利益を上げようと考えるのです。これはこれで合理的に見えますが、ここに罠があります。

　システムに人間が合わせることは、人間にシステムを合わせるよりも遥かに簡単です。最初は使いづらかったり、誤操作もあるでしょうが、使っていけば、そのうち多少不便でも慣れてきて、それに合わせて業務を改善したりできます。不足分は追加でツール等を作るなどして補えます。でも、システムは自分では改善できません。必ず人が手順を確認して設計、製造、テストを繰り返して改善します。これが小規模ならいいのですが、場合によっては広範囲になることもあります。最初の青写真通りにシステム開発が進み、プロジェクトが終われば良いのですが、そんなケースはまれで、途中で何かしら問題が発生することが普通だと思います。そうなると工数を減らすどころか逆に増えて行きます。大なり小なりこの構造がいまだに変わっていないのでデスマーチや失敗プロジェクトはなくなりません。

　日本のシステム開発（商売）の考え方にはフレームワークやカスタマイズは合わないとわたしは思います。

■フレームワークがエンジニアをダメにする

　最初の方で、チームで開発を行う場合「スキル」のばらつきが問題になると書きました。スキルにばらつきがあるのは経験や思想も絡んでくるので仕事では仕方ないと思います。ただ、フレームワークでこれを解決しようと考えるならそれは誤りではないのでしょうか。

　大半のエンジニアはフレームワークの「使い方」はマスターしようと考えますが、フレームワークの「しくみ」をマスターしようとはあまり考えていないと思います。ブラックボックスはブラックボックスのままで開発を行います。先ほども書きましたがフレームワークの枠内で開発ができればそれでも問題は少ないのですが、現実問題としてフレームワークの枠内では処理しきれない機能を実装することは往々にしてあります。

　これをフレームワークのしくみを知った上で行うのと、知らずに行うのでは障害時にその差が出てきます。知らずに「できるから」とやってしまうことのリスクはかなり高いといえます。特にネット上にはその手の情報はたくさんあります。でもすべてが「正しい」わけではありません。「キーワードでググる」→「見つかって取りあえずコピペ」→「簡単な動作チェックでOK」→「これでよし！」とやってしまうエンジニアがいる以上、安易なフレームワークの使用は危険だといえます。

　「O/Rマッピング」についても同じです。データモデルに違いがある以上、技術的に「O/Rマッピング」というのは必然性があると思います。特に中小企業レベルでは予算や納期、データ量などを考えると非常に有用だと思います。RDBMSやSQLを知ってる人間が分かった上で使用する分には良いと思いますし、実際にわたしもある小規模企業のお客様のシステムを構築した時に使いました。でも、ここからデータベースを使ったソフトウェア開発を行ってしまうことは「O/Rマッピング」に過剰な期待を生む結果になりやすいです。つまり、無理してRDBMSやSQLを学ぶ必要はないんだと勘違いする輩が出てきます。そのままエンジニアとして経験を重ねて上流工程を行うと、規模によってはえらいことになります（そのあたりは生島さんのコラムの方を読んで下さい）。実際、そういうエンジニアのおかげで、火消しに入ったプロジェクトで作業に入る前にお客様に怒られたことがあります（けっこう理不尽だと思いますが）。

　フレームワークが悪い訳では決してなく、フレームワークを使うエンジニアが横着なのが悪いのです。作業が多いとか納期が短いとか理由はいくらでも付け足せますが、エンジニアという肩書きがあるなら最低限、フレームワークの構造や仕組みは理解すべきだと思います。生産性や品質の向上はそれを行ってこそ達成されると思うべきです。

■基本は自作で

　わたしは、フレームワークに関しては、自分たちで作ることをオススメします。SIerでもソフトハウスでも自社で開発を行うところはフレームワーク専用部署（チーム）があっても良いんじゃないでしょうか。ゲームを作るソフト会社ではグラフィックや音楽など自作のツールやフレームワークを使って開発するとよく聞きます。出来合いのツールやフレームワークではなかなかかゆいところまで手が届かないからでしょうが、これは一般的なフレームワークを使った開発をする場合にも言えると思います。

　フレームワークを生産性や品質の向上につなげるなら最初は大変でしょうが、ある程度時間が経つと逆に開発コストが下がると思います。会社の経営体力と採算分岐点にもよりますが、普通にやればエンジニアのレベルも同時に上がって行くので一石二鳥だと思います。これが目先の「楽」ではなく、長期的なスパンで考えた「楽」です。自作だと何かあっても調査や入れ替え、バージョン管理も容易になるでしょう。

　昔はフレームワークに良く似た考え方でライブラリ化、クラス化などが社内で盛んに行われていたと思います。最近ではツールやライブラリが市販されて時間と技術がお金で手に入るようになりました。そしてインターネットやオープンソースソフトウェア等の普及で情報もソフトも誰でも安価で容易に手に入るようになりました。

　それがあるからか、最近ではソフトウェア開発でも積極的にそれらを取り入れるようになり自社で技術の蓄積を行わない所も増えてるように感じます。たくさんの情報やソフト（商品）から選択肢が広がったのと引き換えにエンジニアは大事なモノを失った気がします。

　フレームワークを作るということはそれなりのスキルも要求されます。既存のものを利用するのもソフトウェア開発では重要だと思いますが、エンジニアである以上自分でできるだけ作る気概だけは失ってほしくはないものです。