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

　最近の経済ニュースを見ていると、不況が続くのかこれから良くなるのかいまいちピンと来ない感じがまだまだします。就職・転職の状況においても同じで、エンジニアかどうかにかかわらず非常に厳しいと思います。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の普及具合も比べ物にならないぐらい違います。すべてを同列に比較することはあまり意味はありませんが、本質部分はなんら変わっていないと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

■エンジニアの矜持

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

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

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

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

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

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

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

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

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

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

■経営者の悩みと思惑

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

■何が足りないのか

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

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

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

　名前だけ見るとふざけているようで、とても硬派ではないのですが、この「にゃん太郎」という名前はわたしの奥さんが実際にわたしを呼ぶ時に使っています。付き合い始めた頃からなので、すでに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でもソフトハウスでも自社で開発を行うところはフレームワーク専用部署（チーム）があっても良いんじゃないでしょうか。ゲームを作るソフト会社ではグラフィックや音楽など自作のツールやフレームワークを使って開発するとよく聞きます。出来合いのツールやフレームワークではなかなかかゆいところまで手が届かないからでしょうが、これは一般的なフレームワークを使った開発をする場合にも言えると思います。

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

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

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

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

　少しご無沙汰しています。

　今回からまた新しいシリーズです。ソフトウェアに関係する事柄のあれこれについて書いてみたいと思います。3回程度の予定です。

　今回はコーディング規約についてです。コーディング規約がどんなものかはプログラマやSEなどを経験していれば知らない人はまずいないと思います。会社としてきちんとドキュメントになっているところもあれば、部や課、プロジェクト単位で適用している所もあるようです。

　ただ、わたしの経験では、なぜか、なかったところの方が多かった気がします（気がするというのは実際はあったが見たことがなかっただけかもしれないので。もっともそれじゃないのと同じですが）。

　現在のわたしの状況に関しては、「なかった」ので、わたしが作ってメンバーに周知しています。わたしが作るコーディング規約に関しては基本的にA4用紙に1枚程度の量で、そんなにきつく縛っていません（たぶん）昔ほどコーディング方法がリソース不足や速度低下に直結しないので誰が見ても（＝多少スキルが低い人が見ても）分かりやすくコーディングしてね、程度のものです。でも、案外「分かりやすく」っていうのがクセ者だったりします。

■管理者の立場から見たコーディング規約

　わたしは世のマネージャクラスの人がどの程度メンバーのリソースを見ているのかは分かりませんが、わたしはテスト工程の前に動作チェックを兼ねながらメンバーのコーディングチェックをします。プロジェクトが大きいと不可能でしょうが、わたしの場合は幸か不幸か規模的には大きくないので丁寧に見ても2、3日程度で完了します。

　自社プロダクト製品で、しかもリリース後は次バージョンのプロジェクトが走り始めます。開発メンバーが同じなら問題ないですが、違ったり外注したりすると、見にくいコーディングが存在した場合、担当者がそこを理解する時間が余計にかかるため、できれば統一してスッキリさせたいという思惑があります（実際はスッキリしていても多少時間はかかるでしょうが）。

　また、複雑なコーディングはバグを内包しやすくなります。実際、どのレベルが「複雑」かというのは担当者の感覚によるところが大きく、自分のプログラミングスキルの高さを誇示したがる人ほど短縮したコードを記述したがる傾向があります。しかも、それが「当たり前」のような顔をしているので管理する方からすると冗談ではありません。

　そう考えると、管理者から見るとコーディング規約は「必要」だといえます。

■プログラマから見たコーディング規約

　プログラム開発におけるコーディングは「道順」と同じで出発地（仕様書）から目的地（プログラム完成）までの道筋を作成するものです。当然、そこがプログラマの腕の見せ所であり、表現するところになります。例えば、分岐する場合（状況によりますが）if文かswitch文か、ループの場合はfor文かwhile文か、いくつか選択肢が出てきます。コーディングは極論してしまえばそういった制御文や関数を組み合わせて水が流れるごとくスムーズな処理（組み合わせ）を考えることがある意味醍醐味だといえます。

　昔はインプットとアウトプットさえ守られていれば中身を問われることはあまりありませんでした（わたしだけ……かな？）そういう意味ではコーディング規約は手枷足枷となる可能性があります。

　プログラムが好きな人はよく「美しいコーディング」を追及するといいます。わたしも兼業PGなのでそれは理解できます。省略した形が美しいかどうかは分かりませんが、それでも我流だと美しい以前に分かりづらいものになってしまいがちです。これも美しいという基準が担当者の感覚によるところが大きいからです。

　プログラマの仕事は、究極的には設計書通りにバグなしで早く動作する（ストレスがない動作をする）プログラムをコーディングすることだといえます。

　ここに生産性を加えて考えるなら我流でもかまわない（生産性は慣れた方法が一番効率が良い、と考えるため）でしょう。いちいち気にしていたら進まないばかりか手戻りもありえます。慣れないとそこにバグを作り込むことも考えられます。

　そう考えると、プログラマから見るとコーディング規約は「ない方」が理想といえます。

■コーディング規約の問題点

　さて、ここからが本題です。

　わたし自身、コーディング規約は必要か？ と聞かれれば「おそらく必要」と答えます。

　特にシステム完成後のメンテナンスを自分でやるならともかく、完成後は他者がメンテナンスすることの方が確率的にも高いと思います。そういう面から考えても一定のルールがないと読みづらいソースコードは保守性が悪いです。保守性が悪いと機能追加も行いにくく、追加や変更を行う事で新たなバグを生み出しかねないからです。

　いろいろな職場を経験してわたしが感じるコーディング規約の一番の問題点は「コーディング規約が存在してもあまり守られていない」ことです。

　まるっきり無視ではないのですが、コーディングチェックしていくと段々モラトリアム状態になっていくことが分かります。ようするに最初は守ろうと思うのですが、スケジュールが進んで切羽詰まってくると取りあえず完成を目指すためにコーディング規約が置き去りになり、そのままになってしまうのです。

　コーディング規約にも問題が存在する場合があります。

　コーディング規約は大別すると言語仕様に関係するものとそうでないものがあります。例えば命名規則なんかは基本的に言語仕様にあまり関係ありませんが（言語によっては大文字、小文字などの使い方に慣習がありますが）、以前書いた例外なんかはJavaなどにはあってもC言語ではありません。確かにC++、Java、C#などは言語の仕様は非常によく似ていますが、それぞれ考え方などは微妙に異なっています。そう考えると今の時代、コーディング規約を細かく策定するならば、頻繁にメンテナンスしないとすぐ時代遅れの使えないコーディング規約になってしまう可能性があります。極端な話、何十年も同じコーディング規約をメンテナンスせず使い続けるには無理が生じます。

　ソースコードの性格を考えると、基本的に「見やすい」コーディングをプログラマは考えるべきだといえます。ソースコードはあくまでもプログラムを理解しやすい方法（高級言語）で記述しているに過ぎません。ビルドしてバイナリ（細かく言ったらキリがありませんが、ここではJVMや.NETで動作するものも含みます）を作成して初めて「動く」プログラムになります。リソース不足や速度がハードウェアやOSで吸収できるのならば、ソースコードはそれに甘えてしまうことは決して悪いことではないと思います。むしろ甘えられなくなった時にこそ本当にプログラマの腕の見せ所であり、その時にコーディング規約を守れないのならソースコードにコメントを残してコーディングすることは必要でしょう。システムの動作パフォーマンスを満たさなければそれは本末転倒ですから。

　そう考えると、コーディング規約というのは意外と扱いが難しいものだといえます。

■どこまで規約にするか？

　コーディング規約を作るのは一般的には「保守性」や「可読性」を上げるためです。確かに統一した方が見やすく、一定品質のソフトウェアが期待できるのは間違いないと思います。では、一体どこまでを「規約」にするか？ が問題になってきます。

　コーディング規約は普通、「命名規則」「コーディング規則」「禁止事項」の3つに大別されると思います。わたしは主に「コーディング方法」と「禁止事項」をメインに考えています。「命名規則」がないわけではありませんが、これは慣習的な要素が強いと思うので、確認事項的に明記します。

　それぞれ、わたしがいつも考える規約を作るうえでの基準は、次の通りとなります（あくまでもわたし個人と職場が基準ですので、どこでも当てはまるとは考えていません。また、言語はJavaやC#を想定してください）。

【命名規約】

　「変数」「定数」「関数名」「クラス名」「空間名」「ファイル名」などがあると思いますが、基本的にそれ「らしい」名前なら良いと思っているのであまり書くことはしません。なぜなら、言語ごとに暗黙の了解があり、プログラム的にもループ変数などはi、j、k……がある意味デフォルト的でもあるので改めて書くかどうかはメンバーの経験で考えます。定数が大文字ってのも同じでしょうか。

　命名については担当者によって考え方にやや幅があります。こだわる人は「関数名はこうあるべき」「クラス名はこうあるべき」などきちんと自分で考えたルールがありますが、こだわらない人は本当に「適当」です。私の経験で関数を「func01()」「func02()」……、変数を「wk01」「wk02」……と付けていた人がいました。なぜ、そうしたか聞いてみると「考えるのが面倒だから」「プログラムの動作には関係ないから」だそうです。逆にこういうメンバーばかりならある程度規約が必要かもしれません。

【コーディング規則】

　コーディング規則は主にインデントやかっこの付け方でしょうか。わたし個人では、かっこの付け方と分岐命令（if文）について明記します。

・かっこ

　かっこ（中かっこ）については制御文や処理の後で改行するかしないかだと思いますが、わたしは改行させます。理由はわたしが見やすいから（笑）。隙間が多く、1行のボリュームが少ない方が分岐やループではかたまりができて見やすいです。あと、印刷するとあれこれメモ書きがしやすいのもあります。

・分岐命令

　if文の事ですが、if文には2つの規約を明記します。1つは「条件式は比較演算子で比較すること」です。語句だけ見ると当たり前なんですが、以下のコーディングを推奨します。
　　if(flag == false)
　　{
　　　// 処理
　　}

　実際は「flag == false」じゃなくて「!flag」だけでもOKですが、パッとみてどっちか区別しやすいように記述させます。当たり前ですが、ビルドするとどっちも同じバイナリができあがります。

　もうひとつは「絶対に通らない処理は作らない」です。言葉にすると至極当然ですが、これは以下のようなコーディングを想定します。

　　if(flag == true)
　　{
　　　// 処理１
　　}
　　else if(flag == false)
　　{
　　　// 処理２
　　}
　　else
　　{
　　　// 処理３
　　}

　どう考えても「処理3」は通りません。boolが一番分かりやすいので例を挙げましたが、整数型などでも時々「通らねぇだろ、これ」と思うコーディングがあります。例外でもそうですが「念のため……」というコーディング（らしい）です。念のためというのはあくまでも例外であって、true/falseしか条件がないのに3つ処理が用意されている事の方が不自然です。ただ、最近この「念のためコーディング」が増えてきたのは間違いなく、そういう意味で私は最近規約にしてあります。

【禁止事項】

　わたしの場合、ボリューム的にはここが一番多いと思います。プロジェクトに合わせていろいろ考えますが、大体以下のような感じになります。

• グローバル変数は使用しない
• クラスのメンバ変数はpublicにしない
• ハンガリアン記法は使用しない
• ローカル変数の使い回しはしない（ループ変数など）
• 例外をパラメータチェックに利用しない
• gotoは使用しない

　こんなところでしょうか。最後の「goto」はメンバーが若ければあまり書きません。というのはイマドキの若い者はそもそも「goto」を使わないプログラムが普通であり、わざわざ禁止事項にしなくてもまず出てこないからです（知らない人も意外と多い）まぁ、年齢が高くてもJavaやC#を普通に使っていればまずgotoに出合うことはないと思います（Javaってサポート外だったっけ?）C言語ではたまに見かけます。

　個人的には「goto」は嫌いではないのですが（BASICの「GOTO」やアセンブラのジャンプ命令に馴染んでいたので）それはそれ、仕事は仕事なので。

　「ハンガリアン記法」は割合最近書くようになりました。Microsoftでも昔はWinAPIやMFCでは当たり前のように用いていましたが、現在（.NET Framework）では使用しない事が（MSDNで）明記されています。変数名で変数の型が分かるのはC/C++でポインタを使うと便利なのですが、JavaやC#では確かに必要なさそうです。わたしの場合は良くサフィックスをつけ忘れるのでどちらかといえばハンガリアン記法はニガ手な方でした。

　あとはよく言われていることなので特に問題はないと思います。

■大事なのは……

　結局、コーディング規約というのは「みんなが分かりやすいコードを書く」ための知恵だといえます。私はコーディング規約を「最低限のお約束」だと認識しています。本来はほとんど必要のない項目かも知れません。でも、仕事でプログラミングする以上、「人のためにコードを書く」ことが必要だと考えています。つまり、作成するのは自分でも、使ったりメンテナンスする人は他の人なのでその人たちのために「分かりやすく良いコード」を書くことが大事だと思います。

　個人的にはそれが明確になればコーディング規約は必要ないかも知れないとは思いますが、現状では最低限の規約だけはメンバーに提示することは必要だと考えています。もっとも、ダメなコーディングはソースコードレビューで直させるので、最終的には手間が掛からないだけで同じかもしれません。

　次は、フリーソフト・オープンソースについてです。以前、さらっと書いた記憶はありますが、ちょっとこの2つをわたしなりに掘り下げたいと思います。

　タイトルを見たらだいたい何のことかは察しが付くと思いますが、今回はそんな話。初めて書くエンジニアらしい話題かも。

■例外の違和感

　わたしは、前にも少し書きましたが、エンジニアとしては「ハードウェア設計→アセンブラ→PL/I→C言語→VC++→Java→.NET（VC#）」……こんな感じで（途中、細かい物は端折ってますが）来ています。普通のソフトウェアエンジニアの人と違うのは、ハードウェア設計が始まりという点でしょうか。なんだかいい感じにソフトウェアの変遷の歴史みたいです。

　最近は公私ともにVC#が多いです。動かす分にはかなり簡単にコーディングできますし、.NETもハードウェアの高速・大容量化に伴い非常に実用的なレベルになっています。仕事ではVC#とJavaが今は多いです。

　ただ一点、どうしてもなじめない部分があります。それは、

　例外処理が多くね？

と感じる点です。Javaと.NETでは若干、例外の考え方が違うのでひとくくりにはできませんが、何にしても多いと感じます。C++でもありますが、あまりコーディングに埋め込んだ記憶はありません（それはそれでいいのか、とも思う）。

　確かにJavaやVC#は言語と実行環境がセットになっているので、そういう意味では言語仕様がそうなっていても不思議じゃないのですが、やはりわたしは違和感を感じます。それはナゼかといえば……

　例外は本来、起こってはいけないこと（のはず）だから、きちんと設計して例外が出ないようにすべきではないのか？

と考えているからです。うーん、思い切り古い考えでしょうか？ まぁ、VC#の場合はこう言い切ろうと思えばできないこともないと思うのですが（あくまでも言語仕様として、ですが）、Javaの場合はIOやデータベースアクセスなどはthrows/try～catchが必須（検査例外）なので、イヤでも例外処理が必要となります。

　現場で実際に使っている人は分かっていると思いますが、この例外処理のおかげで意外と「止まらない」ソフトのコーディングが容易になっています。アセンブラやシステムソフトでスーパバイザモードで動くソフトのプログラミングをしてきた人間からすれば、いきなりどこかへ暴走してしまうより全然良いのですが（比べる対象が違いすぎ）、そういうプログラミングをしてきた（古い）エンジニアは、やはり「何なんだ」と思ってしまいます。まぁ、実際は例外という名のエラー処理機構なんでしょうけど。例外っていう名前が大げさなだけかも知れません。

■例外について考えてみる

　Cの場合、例外処理は言語仕様として存在しません（C++はあります）。Javaや.NETから習い始めれば例外処理は当たり前なのかも知れませんが、アセンブラやCから始めていくとtry～catchにはやや違和感があります。わたしだけかも知れませんが。

　Cの場合、例えばIOで何か起こった場合、ポインタ（ハンドル）はnullが返ってくることが多いので、例外で止まるということはありません（違う理由で止まることはあり得ますけど）。それに、変数も型はありますが、所詮中身はバイトコードなので、文字だろうが数字だろうが自分の想定した結果にならないだけでお構いなしです（それはそれでいいのか？）。

　そもそも例外のイメージって、メモリアクセス違反とゼロ除算ぐらいしかパッと思い浮かばないのですが、突き詰めてしまえば「例外」＝「エラー」なので、どうしても「例外が発生しないようにすべき」と考えてしまいがちなんです。

■では、いかに例外をつかうか

　Javaと.NETでは少しだけ例外の扱いに違いがあります。知っていると思いますが、Javaは基本的にエラーを例外で返すことを推奨しています。.NETは業務エラーに関しては例外ではなく戻り値で返して、システム／アプリケーションエラーは例外を使いましょう（ちょっとニュアンスが違うかも知れませんが）とあります。

　優秀なエンジニアはこの違いを解釈してコーディングします。ダメなエンジニアは分かっているつもりで適当にコーディングします。ちなみに、スキルの低い人ほど設計思想が違うからといって、なぜかおかしなコーディングします（後述）。

　アンチパターンを言い出すと、これも宗教論争に発展しそうなので、わたし個人の方針としては.NETの業務エラーのみ戻り値で行うことと、例外をパラメータチェックに利用しないことだけを徹底させます。

　基本方針は、やはり例外がなるべく出ないような設計、コーディングすべきということです（しつこいですか？）。ただし、I/Oやデータベースアクセスなどは相手がどうなるかまでこちらで関知できないので、そういう部分はちゃんと例外として処理させるべきでしょう。安易な例外処理はかえってシステムの動作をおかしくする危険性をはらんでいます。また、例外発生時にきちんとした処理をしないと、障害発生時の原因究明に支障が出ます（あたりまえだけど、意外と分かっていない人が多い）。

　Javaや.NETの例外クラスは感心するぐらい系統化されていて、ちゃんと設計すれば何が起きても取りあえず処理の継続は可能ですし、原因追及も意外と容易になります。特に、Cのようにポインタを比較してnullなら……なんてことをしなくても、try～catchで実装しておけば例外がスローされた時点ですぐに例外処理ができるところなんかは、便利でいいなぁとつくづく思います。

　ただ、わたしが感じるのは、「try～catch」を「例外が発生してもエラーを出させないための機構」と勘違いしているエンジニアが意外と多い、ということです。

■業務エラーを考える

　Javaの場合、エラーを例外で処理することにより、表に出てくる戻り値はすべて正常な処理になるので、想像するよりもきれいなコードを書くことができます（あくまでも主観）。まぁ、どんな風に処理しても、センスのある人ならきれいにコードを書くし、なければ汚いコードになるのですが。

　.NETの場合は業務エラーは戻り値で、とあります。ようするに、ビジネスロジックとしてのエラーはメソッドの戻り値でやれや、ということなのですが、時々この切り分けが難しいケースがあります。

  try
  {
    num = Int32.Parse(入力データ);　// VC#
    // num = Integer.parseInt(入力データ);　こっちはJava
  }
  catch(Exception ex)
  {
    // 例外発生時（入力データが半角数字以外の時）の処理
  }

　ここで問題になるのが「入力データ」です。フォームから入力したデータが文字列だったら明確な「業務エラー」だといえます。しかし、ファイルから読み込んだデータだった場合、通常は想定外の文字列が入る訳はないので、エラーになった場合は業務エラーではないといえます（設計上、ファイルから読み込むデータが半角数字以外も想定される場合は、上記のようなコードを書くのが間違っています。ただし、読み込んだ後に半角数字だったら、という場合はありですが、今回はそこまで深読みしません）。

　先ほど、「例外をパラメータチェックに利用しないこと」と書きましたが、入力データがフォームからの入力だった場合はtry～catchで囲まずに、事前にバリデーションなどでチェックしておくことが正解です。そうすればおのずと「業務データ」は例外で処理しなくても済みます。心配性の人はチェックした上に上記のようなコーディングをします。理由を聞くと「万が一、何かあったら……」といいますが、万が一を考える前にしっかりテストする方が重要じゃないの、とわたしは思います。この考えがテストをおろそかにする第一歩です。

■これはあかんだろう

　わたしが見てきた中で間違っていると思われる例外処理の仕方を少し紹介します。実話なので取りあえず笑って反面教師にして下さい。

1. 例外握りつぶし（ASP.NET/VC#）

　Webアプリケーションの案件の場合、顧客から「エラーが出ても画面にエラーを表示して止めないで、処理を続行してください」という要求をされることがあると思います。わたしも当然、言われたことはあります。ただ、この言葉だけを鵜呑みにしたケースを見て「何だ、これは！」と思わず叫びそうになったことがありました。思い切り火を噴いていたプロジェクトに入ったのですが、コードを見ると例外処理に限らず、あちこちのコードが適当に動くように書いてあるので、途中で修正をあきらめました。

　だいたい、察しは付くと思います。こんなコーディングしているメンバーがいたら早めに教育しましょう。無理だったら外しましょう……。

  try
  {
    // 何らかの処理
  }
  catch
  {
  }

　まず、catchに何も記述していないので（こういうことができない仕様にすれば良いと思うんだけど）、処理で例外が発生すると思い切りスルーします。もう何があってもお構いなし。例えばデータベースから条件が合うデータを読み込んで表示する場合、画面に1件も表示されなければそれは本当に1件も引っかからなかったのか、それとも例外が発生して表示されていないのか分かりません。しかもログに記録している訳でもないので、何が何だかわかりません。

　本人に聞いてみると、「エラーを表示して止めるなと言われたので」と当たり前の顔をして言いましたが、例外処理のほぼ全部がこんなコーディングなので、動かしてみるともうむちゃくちゃでした。ちなみに不備を指摘したら逆ギレして「.NETはそういう設計思想なんです！」「お客様の利便性を考えたらこれが一番じゃないですか！」と言われて、どう言い返せば良いのか分かりませんでした。利便性も何も、そのお客様からクレームが一杯上がっていて、わたしが手伝いに入っているのに……おいおい。

2. 意味不明のフラグ（ASP.NET/VC#）

　処理が正常かエラーかをフラグにセットして、それぞれ該当する画面に遷移させようとする処理だけど、本当に例外処理を分かっているよね？ って疑うコーディングです。フラグにするか例外にするか、どっちかにしたらって感じです。

  bool flag = true;  // 処理判定フラグ

  try
  {
    // 何らかの処理
    //
    if (何らかの処理 == 正常)
    {
      flag = true;
    }
    else
    {
      flag = false;
    }
  }
  catch (Exception ex)
  {
    // スタックトレースをログへ書き出す
  }

  //
  // 処理
  //

  if (flag)
  {
    Response.Redirect("~/True.aspx");  // 正常終了時
  }
  else
  {
    Response.Redirect("~/False.aspx");  // エラー終了時
  }

　最初見た時は「ああ」ぐらいしか思いませんでしたが、よく見たら「えー！」というコーディングでした。実際、解説するのもアホらしいのですが、これは「何らかの処理」で例外が発生しても正常終了時の画面が表示されます。

　こうなった理由を聞いてみると、初めはtry～catchなしでコーディングしていたら、テストで例外が発生したので急遽、例外処理を付け加えたとのこと。何も考えず取って付けた例外処理は例外ではなく論外です。

3. 不必要なthrows（Java）

　ダメというよりは「良くないんじゃない？」という例かな。個人的には「ちゃんと理解してる？」と疑ってしまうコーディングですが、まぁほとんどの場合は保険も兼ねてコーディングしていると思います。わたしは反対ですが（笑）。

  void read_data() throws FileNotFoundException, IOException;

　「FileNotFoundException」は「IOException」のサブクラスなので、普通は以下のように書きます（よね？ 少なくともわたしはこう書きます）。

  void read_data() throws IOException;

　「FileNotFoundException」を明示的にthrowsしたいのならば、考えられる他の「IOException」のサブクラスの例外と組み合わせて使うことが望ましいかな。でも、たくさん書くなら「IOException」でいいんじゃない、とわたしは思うんだけど。

4. 結構多いアンチパターン

　目に付くのが「finallyブロック内でのreturn」です。どうしてかといえば、例外発生時に例外情報を捨ててしまうからです。文法的には間違いではありませんし、例外でなければ問題ないです。でも、例外発生時に何とかするために例外情報を使うのに、その情報を捨ててしまったらなんの意味もないです。ちなみに、個人的にはあまりreturnが多いコードの書き方は好きじゃないです。

　あとはcatchのところが全部「catch(Exception ex)」になっているケースです。処理したいのは分かるけど、やっぱり発生する可能性のある例外毎にキャッチしましょう。手抜きは良くないです。

■なぜこうなるのか

　教えてもらうにしても学ぶにしても、例外を後回しにしていませんか？ 設計やコーディングを見ていると、ちゃんと考えて例外処理をしているな、と思えることは少ないです。例外を正しく考えて設計できる人にテスト仕様書を書かせると、それなりのクオリティのものを作ってくれます。それだけいろいろなことを想定できるからなんでしょう。特にJavaの検査例外は強制なので、開発環境やコンパイル時にエラーが出るために「仕方なく」付け加える人もいるのではないのでしょうか。スタックトレースがうざいっていうのは論外です。

　動けばよし、ではダメで、例外処理（try～catch）を取って付けたようなコードは、逆におかしな処理を生み出します。必要なところにはちゃんと設計した例外処理を書き、不安だったらまず処理を見直すところから始めましょう。間違っても「念のため」とかやり出すと例外処理だらけになってしまい、本当に例外が発生したら収拾つかなくなります。

　わたしは設計思想やコーディングの美しさは基本的に「どうでもいい派」です（でも、見やすくないと困るとは思いますが）。確かにJavaや.NETなどでいろいろ決まりはありますが、それよりは「エラーを正しく処理すること」と「例外が出ないようなコーディングを考えること」が一番だと思っています。思い込みだけで設計・コーディングしても、要求されたニーズを満たせるとは限りません。

　お客様に言われても、ウラではちゃんと処理すべきですし（ログを出さないなんてもうダメを通り越して素人以下と言われても仕方ありません）、流れを止めてでも「エラー」にすべき時はちゃんと理由を明確にしてお客様と交渉すべきです。エラーをリカバリできるシステムなら問題ないですが（そういうシステムは作ったことがあるので）、そうでなければ確実に欠陥品ができあがります。言われたまま鵜呑みにしてシステムを作ることは、素人にだって今はできます。

　次は「教育」をテーマに書こうと思ってます。最近、コラムのネタがいろいろな人と被っていますが（苦笑）。……それはそれで考えながら書こうと思います。わたしは、職業エンジニアには教育が必要だと考えています。子供と一緒で、何も教育しなかったらまともなエンジニアにならないとさえ思ってます。

　次のコラムでまた一区切りにしたいと思います。

　ソフトウェア開発の最終工程は「テスト（試験）」です。ここをパスすれば、製品またはお客様に納品出来る品質だと一般的にはいわれます。

　ところで、テストエンジニア（以下、TE）って、いつごろ派生したエンジニアなんでしょうか？

　というのは、わたしがエンジニアになったころは、そういう担当？はなかったと記憶しているからです。せいぜい「テスター」と呼ばれる人たちがテスト仕様書を元にチェックするぐらい。初めて聞いたのは組み込みソフトの開発現場からそういう要求があった時かな。今から10数年前です（この話は後から出てきます）。

　テストは、「単体テスト」「結合テスト」「総合テスト」と段階を踏んで実施します。会社によっては多少言葉が違うかもしれませんが（結合テストと総合テストを一緒にしてしているところもあります）だいたいこんな感じでしょうか。

　誰が実施するかも会社によって考え方は異なります。一番多いのは「単体テスト」はPGで、「結合テスト」「総合テスト」はSE主導で、PGや他のグループから少し人を借りてやることが多いようです。組み込み機器はある程度動作してからTEを導入するケースが多い。TEがいても通常PGもテストしていると思います。テストはある意味「責任の担保」なので作った人（主にPG）に責任を持ってもらうという考え方もあるようです。

　ただ、最近はシステムが複雑化しており、例えば携帯電話では機能は増えるわ納期はないわといった事情だと、どうしても予定がずれ込んで、最終工程のテストがおろそかになりがちです。結局、ある程度デバッグできた所からテストしてもらいバグ出ししながら進める方が効率が良くなります。本当はこのような考えは品質保証の点から言うと良くないのですが、第三者（開発担当者以外）にテストしてもらうこと自体は個人的に賛成です。

■本当のテストができないエンジニア

　わたしは、基本的に単体テストの仕様書はPGに、結合テストや総合テストの仕様書はSEに担当させます。最近、レビューして感じるのはテストに対する認識が甘いことです。前にも書きましたが、とにかく「動くこと」が頭の中では最優先なので、テスト仕様書も動くことしか考慮していません。

　ひどい仕様書になると、わたしはそれを見るだけでプログラムの構造が理解できます。そう、あくまでもプログラムに沿って正しい動作の検証しか書かれていないのです。わたしから見れば、そんな仕様書作るだけムダだと考えているので、レビューの時にはかなり厳しく意見します。

　テストの基本は正しい操作で正しく動作することを確認することだけではありません。逆をいえばそれは当たり前の話で、単体テストの段階でデバッグレベルのバグがあっては正直困ります。イレギュラーな状況、例えば不正な入力データ、サーバーの停止、ネットワーク障害、非常識に大きいファイル入力、めちゃめちゃなキー操作……など、挙げればキリがありません。こういう時にシステムがどのように動作するのかを検証するのが、テストの目的だといえます。

　あくまでもユーザーが利用することを前提に、システム（機器）が異常終了やフリーズすることを避けるために行うのであって、間違ってもプログラムが正しく動作することを確認するためではありません。マニュアルに沿って正しく動作することは当たり前です。

■複雑化するシステム、潜在化するバグ

　業務システムは多種多用なミドルウェアが、組み込み機器も汎用的なOSの派生であるWindows MobileやLinux、最近ではiPhoneやAndroid等も出てきてシェア争いを繰り広げています。一昔前（今でもだと思いますが･･･）は組み込みOSはリアルタイムOSとひとくくりで呼ばれていた気がします。今ではWebアプリだろうがデスクトップアプりだろうが組み込み機器だろうが同じような開発環境、同じような手法で開発が可能になっています。

　どのシステムも一昔前のような「シングルタスク」のOSではないので、高速、高機能な反面、プロセスの実行順序（優先順位）やメモリ配置・配分などすべて時々の状況に合わせてOSが調節してくれます。

　これはソフトウェアを作るという意味においては大変ありがたいのですが、逆をいえば、個々のプログラムがどの様に動作するかを決められないと言うことになり、コードの書き方によっては自分達が意図しない動作をします。時には再現性が低いバグもあります。何回か実行するとバグが出るが、その回数も条件もまちまちなケースです。

　最近の携帯電話でも発売直後に不具合が発生することは決してまれではありません。昔は回収しましたが、今は端末が自分自身のファームウェアを書き換える機能を持っているので回収しなくても済みますが、これも複雑化するシステムや機能の副作用だといえます。

■テストエンジニアに向いている人は？

　一般にソフトウェアテスト呼ばれる物は「ホワイトボックステスト」と「ブラックボックステスト」に分類されると思います。わたしは、ホワイトボックステスト（カバレッジ）は、PGが責任を持ってやるべきで、「ブラックボックステスト」はTEが行うものだと考えています（あくまでもわたし個人の考えです）。

　エンジニアは知識と経験をバランス良く積んでいくことが理想だと思います。知識に偏ると頭でっかちなエンジニアになり、応用が利かなくなります。経験だけではアーキテクチャーが古くなり、設計時に支障が出ます。

　しかし、TEは以下の項目については他のエンジニアよりも長けている必要があると思います。逆にプログラミング技術は基本的なものだけ理解していれば良いと思います。

• システム全体を正しく把握できること
• ドキュメントの行間が読めること
• 恣意的にKY（空気読まない）なこと

　例えば、携帯電話で考えてみます。携帯電話の基本的な動作はキャリアによって決められています。電話がメインなのでメールを入力している途中など、着信があればどんな操作よりも着信動作が一番優先になります。メール着信はおそらくその次ぐらいでしょうか。

　プログラム的には割込動作なのですが、テストではそんなもの目に見えないのでTEは「電話の着信は最優先」「メール着信はその次」と考えます。切断（終話）ボタンを押すと必ず待ち受け状態（画面）になり、長押しすると電源オン・オフします。これら全体の動作を把握することがまず第一歩です。PGは機能単位で切り出すので、全体動作（結合・総合テスト）でどうなるのかを考慮しません。逆を言えば、仕様書段階で考慮しなくても良いようにしてあるのが普通です。ですから、他の担当者の機能についてはあまり詳しくない（関知しない）のが普通でしょう。

　通常、マニュアルには正しい操作方法や、してはいけないことが書かれています。仕様書も処理方法やエラーなどが書かれていると思います。TEはここから「暗黙の了解」を読み取ることが必要になります。何故かと言えばユーザーは「マニュアル通りに操作するとは限らない」からです。例えば、携帯電話で、通話の最中に「メニューキー」を押すとどうなるか、切断（終話）キーを押すと通話が終了するが、長押ししたらどうなるかなどはあまり書いていないと思います（実際はキャリアの方でどのように動作させるか決めてある）でも、書いていないからとテストを怠ると、発売後にユーザーが通話中に何気なくメニューキーを押したら電源が落ちた……なんてことになりかねません（あくまでも例です）これがタイトルに書いた「最後の砦」の意味です。不具合が発生してから「やってなかった」ではその砦は何の役にも立ちません。

　本当にKY（空気読めない）では困りますが、テスト中はKY（空気読まない）がベストだと考えています。試験は製造工程とは別のラインで行うのが普通です。納期が迫ってくると現場の雰囲気もピリピリしてきてテストしてても「バグが出ないといいなぁ」と言う感じになってきますが、TEはこういう時こそどんどんバグを発見して欲しいと思います。バグなんてそういう時に出るものですし。バグが出て文句言うエンジニアは文句をいう前にバグを出さないソフトウェアを作るべきであって、バグを発見してもらったらむしろ感謝するべきです。

　先ほども書きましたが、「最後の砦」である以上、妥協も温情も許されません。品質保証のためには厳しすぎるぐらいがちょうど良く、それができないならテストエンジニアは務まりません。リリース後の不具合は「しょうがない」ではなく、人災だと考えるべきです。

■テストエンジニアを育ててみた

　わたしは、コラムの第3話で登場した上司にテストチームを作るからその連中を教育して欲しいといわれたことがあります（いまでもあるかはわかりませんが）。背景は組み込み機器（携帯やカーナビなど）の高機能化と開発期間の短縮があります。また、開発する側としても、ソフトウェアの開発とテスト専属チームによる品質保証で仕事を取りやすいと言ったメリットがあります。当時、この話をもらった時はすでに案件（携帯電話のテスト）があって、嫌でもやらなければならない状態でした。いつものことでしたが……。

　チームは女性ばかり3名で新人から5年程度のエンジニアでした。当然、テスト専属なんて経験はありません……って、わたしにもありませんでしたが。

　取りあえず、経験から方針と納品方法（テストをやった、だけではさすがにお金はくれないでしょうから）を決めました。テストはマニュアルを元にしたブラックボックステストで、ビルド別に最低3回行ないます。（それ以上は別契約）検査項目書（検査仕様書）はデータベース（この時はMicrosoft Access）で作成し、レポート印刷を可能としました。納品物はデータベースファイルと印刷したレポートです。

　わたしはデータベースの作成と検査項目の作り方をメンバーに教え、あとはリーダー予定の女性と2人で打ち合わせに行ったりしてました。あとはレビューなどで指導しました。自分では手探りでしたが、わたしが関わった最初と、その後2回検査を請け負った結果では発売後に不具合が出なかったのでまずは及第点かと思いますが、わたしのキャリアの中で唯一「良かったのだろうか？」と今でも考えることのある案件です。

　ちなみに携帯電話の場合、昔は地域によって会社が分かれていました。この場合「ローミング」があるのですが、社内でテストできないので、車でエリア外まで行ってテストしたこともありました。あと、困るのは「非常電話」です。いわいる「110」や「119」ですが、こればっかりは実際にテスト出来ないので、網シミュレーターを使いました。

■あなたは本物のエンジニアか？

　何回かに分けて今のエンジニアの問題点など書いてみました。PM、SE、PG、TE、他にもまだ役割はありますが、WindowsのクライアントOSですらかなり複雑なものになっており、作るソフトウェアの規模や種類によらず1人でプロジェクトを遂行するのは期間的にも難しくなっています。

　わたしは、エンジニアは自分の与えられた役割の中でベストパフォーマンスを発揮できる人だと考えています。SEだろうがPGだろうが関係ありません。スキルだけでも経験だけでもなく常に全体を考えて欲しいと思います。

　複雑化するシステムの中では大変だと思いますが、みんなが本物のエンジニアを目指せば、きっとデスマーチも失敗プロジェクトも減り、少しはこの業界を目指す人も増えるのではないのでしょうか。若いエンジニアが自由に活躍できる業界になることを期待したいです。

　次からはエンジニアを取り巻く環境をメインに進めようと思います。具体的にはビジネス、経営、職場や雇用、そしてお金です。エンジニアはこれらのことを、あまり自分に関係ないことのように捉えがちですが（フリーの人はそうでもないと思いますが）これからはそうも言ってられない状況になると思います。スキルだけでは生き残れる保証もありません。それにはまず、自分たちの取り巻く環境を知り、考えることから始めましょう。

　わたし自身は、ほとんど勉強しないガキでした。と、いうよりは、好きなことだけ勉強してきた感じでしょうか。だから学校の試験も科目によって成績が良い科目と悪い科目がハッキリしていたし、受験勉強に至ってはする気なんかさらさらありませんでした。唯一の受験だった高校の時も、自分の実力を考えて入れそうな公立学校を選びました（もちろん、電気回路の勉強がしたかったのでそれは外さず）。

　性格的に、疑問を持ったら自分で納得できるまでとことん追求するので、興味があることは勉強会に行く前に基本的に自己解決することがほとんどです。

　それでも他の人はどう考えているのか知りたい時があるので「勉強会に参加したい」と思うことはあります。でもなかなか行けません。理由は、スケジュール調整がつかないため、地方都市在住なので参加するためそれなりに費用がかかるためです。独身時代はまだしも、結婚してから、自分で自由に使えるお金なんてほとんどありませんから（涙）。

　逆に、年齢も30歳を超えたころから、少しずつ「勉強会」を開いて欲しいという要望がちらほらあります。自社や派遣先で行うこともあれば、ユーザー側からの依頼もあります。プログラム技術もあればネットワーク技術も。スケジュールさえ合えば断る理由もないので開催します。

　せっかくなので、わたしの開く勉強会のことを書こうと思います。

■教えませんよ

　わたしの勉強会は、基本的に教えません。スタンスは「考えよう」です。資料はA4で1ページから多くても2ページ、1コマ45分で構成します。長いと間延びするので、通常は何コマかに分け、休憩を入れながらやります。

　資料はだいたい「図」です。文字だけと言うことはあまりなく、せいぜい表ぐらいでしょうか。とにかく「読ませない」ことを大前提とします。やってみると分かるのですが、案外普通に資料を作るより難しいんですよ。

　前にも書きましたが、最近のエンジニアの傾向として、想像力が乏しく、すぐに答えを求めたがります（あくまでも傾向です）。特に真面目なエンジニアは「予習」してきます。

　図を多くすると、たいていの人はそれを見ながらいろいろ考えます。正確には想像するんでしょうか。とにかく（字がほとんどないから）読めないので、見て考えざるを得なくします。予習してきてもあまり意味がありません。暗記するだけの予習は不要だからです。

　とにかく、考えて覚えてもらう事を第一にします。

■シナリオを作る

　映画やテレビドラマなどは「起承転結」や「序破急」という方法でシナリオを作成します。日常のように何も起こらないと見ててもつまらない（飽きる）から、ストーリーに波を起こして視聴者の意識をドラマに向けさせるようにすることです。

　勉強会も同じで、こちらから一方的にアクションを起こしてもだんだん飽きてきます。そもそも「勉強会」なので、基本は双方向です。上手に双方向に持って行けるようにシナリオを作成します。

　資料として渡した図表を使い、1つずつ説明、質問、回答を繰り返します。このとき、ホワイトボードなどに一切何も書きません。せいぜい用語の漢字を書くぐらい。参加者1人ひとりが自分でメモします。特に最近は自分で字を書く機会も減っているので、とにかく参加者が聞き取り、考え、書き、ときどき意見を言うにします。順番はランダムにします。端からだと自分の順番が何となく分かるので。ここでドキドキ感を演出します。

　言語などの場合は演習を入れます。演習もただ、考えて作るだけでは面白くないので、お題を出して作成してもらい、何人かの人にそれを発表してもらいます。それを材料に全員で良い部分、悪い部分などを討論します。ここで気づいたと思いますが、これはソースコードレビューです。経験の浅いエンジニアがいる場合、必ずやらせます。つるし上げることが目的ではありません（当たり前ですが）。

　目指すのは、自分の考えたコードを人に説明できること、人から自分のコードの良い点、悪い点を指摘してもらって、それを経験として生かしてもらうことです。逆に、見ている側には1人1カ所以上、意見を言う義務を課します。良い点でも悪い点でも構いませんが、必ず理由を添える事を条件にします。ただ単に「汚い」「見にくい」「遅い」「いいんじゃない」だけではダメです。

■分かった気にはさせない

　わたしもそうですが、どこかに研修などで話を聴いて帰ってくると、どこか分かった気になります。でもこれは気のせいです。数日もすればまた元の業務の中で忘れてしまいます（聴いたことが即、業務に関係ある場合は別でしょうが……）。それよりは何となく分かったけど、どこか少し引っかかる状態にしておくのが一番だったりします。気になるぐらいにしておく方が後から考えるようになります。人によっては気持ち悪いらしく、後日聞いてくる人もいます。そうなれば、まず成功だといえます。

　勉強会はどんなものであれ、受け身では「へぇー」で終わってしまします。その時は良いのですが、後が続かないと意味がありません。感動は一時期でしかありません。積極的にメモし、考え、自分から質問するぐらいのめり込んだ方がどんなものでも自分の「スキル」の一部になると思います。

　少しでも参考になれば幸いです。わたしもたまに出かけていろいろいな勉強会に行きたいなぁ。これが結構刺激になるんですよね。

■偉大なるマイクロソフト帝国

　見出しに関しては、完全に羨望と嫉妬と皮肉です。わたしはもともとアンチインテル、アンチマイクロソフト、アンチ巨人でした。でも、今は仕事でインテルCPU搭載のWindowsを使用しています。開発環境もVisualStudio。家でも同じで、いじるために買ったゲーム機もXBOX360です。唯一のプライドがMacでしたが、そのMacも気がつけばインテルCPUで接続しているキーボードとマウスはマイクロソフトです。もう、アンチ巨人以外は完敗です（笑）。

　マイクロソフトのカンファレンスに、1度だけ参加したことがあります。ハッキリとした記憶はありませんが、確か.NET戦略を発表した前後だったと思います。でも、どちらかといえば不良エンジニアのわたしには、あまり面白い内容はありませんでした（だからあまり記憶に残っていない）。

　でも、1点だけ憶えていることがあります。それはマイクロソフトが定期的にOSやオフィスなどビジネスの基幹部分を、定期的に新しいものをリリースしているから、あなた方のような開発者に仕事があるのですよ、というような言葉でした。とにかくすごい自信と傲慢に満ちた言葉ですが、あらためて考えてみるとあながち間違っていないのが恐ろしいと感じました。当時はまだ現在のようないわいるオープンソースみたいなものはあまりなかった（と感じています）ので余計に思います。

　次回はまた元のシリーズに戻します。エンジニアの問題シリーズの最後はテストエンジニアと品質保証です。コラムニストにも何人かいらっしゃいますが、テストエンジニアが優秀だと、品質向上が望めますが、その反面、SEやPGからは予期せぬバグが出ることになり、人によっては戦々恐々です。わたしは以前、テストエンジニア部隊を立ち上げたことがあります。その時の話も含めて、書こうと思います。

　プロローグで書いたように、わたしは立場的にはPMです。正確にはPM相当でしょうか。SIerではないので（受託開発はやりますが）、顧客からの要求というものはほとんどありませんが、規模は大きくないので企画や開発計画から設計、間に合わないと思えばプログラムも組みます。営業からの要請があれば資料も作ります（実際はなくても作っていますが）。責任がついてまわるのでPMですが、実際は何でも屋です。

　わたしのことはさておいて、一般に上流といえばPMやSEでしょうか。SEは「上流SE」なんていうこともありますが、今回は言葉はともかく、要件から機能設計段階までを担当するエンジニアを対象にして「上流エンジニア」で統一することにします。それ以外は一般エンジニアとします（下流という表現は好きじゃないので）。

注意！

　今回も以下の文章はあくまでわたし個人で感じていることであり、大多数のエンジニアについていっているわけではありません。それを理解して読んでください。

■誰が火をつけるのか

　プロジェクトが火を噴いてデスマーチになるケースは、残念なことに決して少なくありません。デスマーチまで行かなくても「やべー」と思うことは上流エンジニアをやっていればよくあることだと思います。それだけ今のシステムは複雑になっています。

　工程的に「要件」「設計」「製造」「試験」と段階を踏んだ場合、デスマーチになる要因はどこの工程にも潜んでいますが、確率から言えば「要件」と「設計」部分が大半だと思います。ただ、「製造」と「試験」の段階で表面化する事が多くて、スケジュール的に一般エンジニアの人たちがその犠牲になります。

　これを踏まえて考えると、一般エンジニアの人が上流エンジニアの人たちに文句を言いたくなるのは当然だといえます。上流エンジニアのプログラムに対する理解度が低いため、設計の精度が落ちているのです。

　システム開発全体で考えた場合、上流と一般では必要とされるスキルが異なります。上流ではプログラミングスキルよりはコミュニケーションスキル（顧客から要望を聞いて要件を確定させるのに必要）やリーダーシップ、業務知識、そして全体像を把握するためのIT関連全体の知識が必要となります。ソフトウェアという部分を切り出せば、広く浅く知識が求められます。一般の場合は設計されたものをプログラムに落とし込むので、言語やプログラミングスキルが必要となります。反面、自分の範囲以外は分かっているのが理想ですが、必須まではいきません。つまり狭く深い知識が求められます。

　この両者の違いがお互いに理解されないからか、プロジェクトに火がつき始めると、どこからともなく上流は一般エンジニアのスキル不足を責め、一般は上流エンジニアのプログラムに対する理解の低さを責めます。客観的に見ると非常に不毛な争いとなり、論点がズレ始めます。

■ベストよりベターを目指せ

　これは全体の要件をまとめるときに必要な考え方だと思っています。一生懸命なPMほど顧客満足度の向上を目指してよりベストな選択を模索します。方向としては決して間違っていないと思いますが、ボランティアならともかくビジネスですので、どこかで妥協点が必要です。

　社会情勢もあり、最近ではIT関連の設備投資はかなり鈍いです。ただ、システム化は必要なのでニーズは必ずあります。その時、ネックになるのはやはり「費用」です。顧客側からすれば少しでも安く、SIer側からすると少しでも高く、この点だけは必ず反目します。だから、顧客側は費用対効果が一番高そうなところで、SIerは機器のグレードやオープンソース、必須以外の機能削減を行い、お互い妥協点を探ります。これがベターです。

　PMにはもう1つ考慮する点があります。それはメンバーへの配慮です。納期までの期間が短いと、それだけでデスマーチになりかねません。少なくともそこは何とかすべきです。顧客と上手に駆け引きできないPMはそれだけでプロジェクトを破綻させかねません（顧客の言いなりになりかねないため）。このあたりが一般エンジニアと大きく異なるところだと思います。

■プログラミングスキルは磨け

　PMにプログラミングスキルは不要かと聞かれれば、わたしは迷わず「ノー」と答えます。よく考えればこれは当たり前のことで、業務手順を最終的にプログラムロジックに落とし込むわけですから、そのプログラムを知らないと、とんでもない要件や設計が出来上がります。しわ寄せは言うまでもなくPGへ行きます。無理なことは逆立ちしても無理です。

　わたしは要件や設計をしながら絶えず頭でロジックに落とし込む作業をします。お客様と話をする時も、よく頭の中でロジックを組みながら話をします。やっていることはPMやSEですが、考えていることは常にPGです。要するに打ち合わせが終わっているころには、ほぼ方針がきまり、設計が終わると頭の中ではロジックができている状態になります。ですから後からSEやPGが「これは無理です」と言ってきても、やり方や方針をきちんと伝えられます。これができなくなるとSEやPGの負担が増えます。方向性を間違うと品質は確実に落ちて、その責任は結局PMに来ます。

　正直、いまのSEやPGを見ていると、前回書いたようにやや想像力が乏しいと感じます。ついでに柔軟性もあまりなく、なぜか若くても頭がガチガチの人が多いです。でも、だからといってそれを言ったら軋轢を生みます。ですからプロジェクトを成功に導くためには、PMがそれを理解してそれなりに対応すべきです。当然、全員がそうではないので、メンバーのスキルや性格に応じて上手に導いてやることが必要不可欠です。そのためにプログラミンぐスキルは必要だと言えます。プログラムを理解できないPMをPGはあまり尊敬しません。

　よく、システム化に際して保守性（運用性）を理由に自分のスキルの低さを隠すPMがいます。保守も運用もシステム化の一部であり、開発の延長線上なのでPMの立場からするとおざなりにはできません。でも、だからといって何でもWebアプリ、顧客が知らないからVB6、誰も理解できないからSQLは簡潔に……うんざりです。プロを自認するならベターで選択した要件をベストなスキルで完成させるべきだと考えています。安易に楽な方に逃げても顧客の求める品質には届きません。遅かったらスケールアップだなんて、素人でも考えつきます。それで済めばシステム要件なんて決める必要ないです。最初からハイパフォーマンスなマシンにすれば良いだけですから。

　もし、顧客がどうしても、と言うなら、メリットとデメリットを並べて、それでもと言うならそういう選択もありだと思います。でも、本来はシステム化することによって得られるメリットが少しでも減るのなら、PMは顧客にそれを訴えるべきです。運用が不安ならきちんと運用手順を示して教育するべきだし、保守性がと言うならやはり資料を作成して教育すべきです。その手間をPMが惜しみ、安易に妥協して後から追加料金を取るのは悪徳商法となんら変わりません。SEやPGに高スキルを要求するなら、PMはそれ以上に高度なスキルを持つべきです。コミュニケーションスキルとリーダーシップだけでは顧客満足度を上げることは到底無理です。

■理屈だけではプロジェクト管理はできません

　最近はプロジェクト管理やソース管理、バグトラッキングなどが容易にできるツールがたくさん、しかもオープンソースで手に入ります。それに伴いプロジェクト管理の本なども出てきて、個人的にはいい時代になったと思います。

　でも、これらのものが便利すぎるあまり、PMが管理に対して過剰になりすぎる傾向が見えます。これらはツールなので手助けと考えるのは良いのですが、必須と考えると非常に窮屈です。言ってしまえば理屈だけで管理しようとします。

　「管理」するにあたって一番ネックになるのは何だと思いますか？ 実は「人間」だったりします。どんなにいいツールを使っても、どんなルールを作っても、それを履行する人間がいい加減だったら何の意味もありません。管理はさせるものではなく、するものです。そのための手助けをツールに委ねます。

　最近のシステムは複雑化しています。なかなか一筋縄では開発はできませんし、管理も大変です。そのためにいろいろな手法やツールが考え出されているのですが、管理の根本部分を置き去りにしてしまうため、それがすべての至上主義になってしまいます。

　本当はツールなんて何でも構わないと思います。ちゃんとPMが「管理」できれば。

　プロジェクト管理の基本だと思っているのですが、（少なくともわたしは）進捗は必ず自分の目で確認します。人間誰しも怒られたくありませんし、保身を考えます。そうすると自己評価が非常に甘くなり、進捗報告でも隠します。特に今は「分からない」と言い出せないエンジニアが増えているので余計です。後になって結局「できていなかった」となるとデスマーチに突入する可能性大です。これは本人も悪いのですが、管理しきれないPMの責任でもあります。

　PMはプログラムの細かい部分はPGの仕事であって、PMの仕事ではないと思っている人も多いでしょう。でも、それとプログラミングスキルは別の話になります。実際、細かい部分を知らないと何かあった時に対処できません。わたしは途中経過でプログラムを動作させておかしいところは必ずコードを調べ、担当者に聞いて修正をお願いします。全部を闇雲に見るのは現実的ではないので、担当者単位で差分を取るようにしています。

　ちなみに、不可解なコードを見つけても担当者に聞きます。あら探しはしませんが、見つけてしまっては放置できません。前回も書きましたが、頭ごなしにダメ出ししても絶対に受け入れてくれないので、まず意図を聞いてその上でマズかったらどうしてマズいのか話した上で修正してもらいます。PGは自分の範囲で仕事をします。でも、時々他に影響が出そうなコーディングをする時もあります。分業なので、何でも管理してダメ出しするのは逆にPGやSEのやる気を削いでしまう危険性があり、注意が必要ですが、ダメな所はダメと言わないとそのエンジニアのためにもなりません。逆に時々、褒めることも忘れずに。

　わたしは仕事をする時は常に楽することを考えます。これはサボることではなく、負担を減らすことを意味します。その上でいつも後輩に対して自分と同じレベルかそれ以上にスキルを引き上げることを考えています。時々、手柄を独り占めしたくて自分の技術を教えたがらない人がいますが、わたしは非常にもったいないと思います。周りのメンバーのスキルが上がれば、それだけ自分の負担が減って、結果的にプロジェクトはスムーズに回ります。技術なんて大事にしていてもすぐ古くなりますし、これだけ情報が溢れていれば誰かが公開してる可能性の方が高いです。

■エンジニアの前に人同士

　最近の20代から30代はキレやすい、って記事が出ていました。でも実際は、下から上までそれこそ老若男女問わずイライラしている人が多いと感じます。電車に乗っても車の運転しても、余裕のない人が増えたと実感します。

　プロジェクトもそうです。わたしは、エンジニアは技術的なことで議論したりケンカするのは良いことだと思っています。でも、それを人間関係に持ち込むのは良くないと思います。要するに、本当の喧嘩はマズいですが、切磋琢磨は必要だと考えています。

　確かにPM、SE、PGで立場が違うので、それぞれ思い通りにいかないとイライラするでしょう。本当はそうではなくて、相手の立場を考えて行動することがプロジェクトの炎上を防ぐ一番の近道だと思っています。わたしはPG、SE、PM、どれも経験しているので、どれが偉いとか思うのはナンセンスだと考えています。どのポジションでもそれぞれに悩みも誇りもあります。ですから、相手を責める前に、まず相手を理解するようにして欲しいと思います。

　PMでもプログラム経験が浅いならまず自分で組んでみることです。いかに今のシステム開発が複雑なのか理解できるでしょう。SEはどうしてPMがこのような要件で設計するのか考えてみてください。機会があれば一緒に顧客との打ち合わせに参加させてもらうのをオススメします。PGなら自分で機能だけ見て設計してみてください。プログラム技術だけでは難しいことがよく分かると思います。

　1人で完遂できるプロジェクトはごくわずかだと思います。いろんな立場の人が参加しているにはそれなりの理由があります。自分だけがつらい思いをしていることはまずないので、それを常に頭に入れて自分が持っている最高のパフォーマンスを発揮できるように頑張って欲しいものです。それがこれからエンジニアを目指す人を増やすための原動力だと思います。

　次はちょっとこのシリーズはお休みして、せっかくお題をもらったので勉強会やカンファレンスについて少し書こうと思います。