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

　最近は暖かくなり、出かけるにも良い季節になりましたね。首都圏の方では電力問題も一段落したようですが、これから夏に向かってまた問題になりそうです。私の方は毎年恒例の花粉症です。去年は涙が止まらなくて苦労しましたが、今年は喉が痛いです。薬で何とか収まっていますが、鼻の方はあきらめてマスクしてます。

　さて、人間40年以上生きていると考え方がある程度固定化されてしまいます。ようするにあまり今の風潮に合わないのです。だからこそ「俺たちの若い頃は」とか「今時の若い者の考えは良くわからん」とか言ってしまいます。今、10代、20代前半の若い人もいずれ40代を過ぎた時に大半の人は分かると思います。私もそうでしたから。

　そういうことの比喩的表現として「頭が硬くなる」とよく言います。自分なりの価値観ができてしまうために、なかなか他の考え方が受け入れられなくなるんですが、特に仕事に関して普通はある程度経験してきた自負もプライドもあるため、気が付いたら部下や後輩に頭ごなしに押し付けてしまうこともしばしばあります。これが上手にできると「リーダーシップがある」と周りは評価しますし、下手だと「いばりくさって」と言われてしまいます。

　私も40歳を過ぎ、エンジニア歴も20年を超えています。「プログラマ35歳定年説」ではないのですが、私の同期でも仕事でプログラムを作る連中はあまりいません。せいぜい修正したりツールを作る程度でしょうか。管理職になった連中も多いのでもうそういう歳になったのだと実感します。

　そうは言っても、日進月歩の激しいこの業界、立場は別にしてそれなりに新しいことにもチャレンジして果敢に「攻める」ことをしないとおいて行かれるのは年齢や立場に関係ありません。おっさん年齢の人は意識しないとダメですし、若い人もぼーっとしているとすぐに40代になってしまいます。「光陰矢のごとし」とは良く言ったものです。

　そのためには時々自分の「思考回路」をメンテナンスする必要があると私は考えています。年齢が上がれば上がるほど意識してやる必要があるので、最近あんまり考えていない（惰性で行動している、という意味で）と思われる方はたまにはどうでしょうか？ 参考になるかはわかりませんが、少し私の例を紹介します。あまり真面目に考えずに、少し気楽に考えるのがコツだと思っています。

■好奇心

　私の場合ですが、年々衰えていくことがなんとなく実感できるのが好奇心と視力です。私はこの仕事が長いですが、視力はずっと1.5とかなり良い方でした。でも、最近はさすがに「老眼」気味です。電車とかで携帯をいじってふっと外の景色に目をやってもなかなか焦点が合いません。細かい字もちょっと離さないと厳しくなってきました。

　好奇心は新しいことになかなかときめかなくなったというか、何となく気乗りしなくなってきているのを実感します。一言で言えば「面倒」になっているんでしょうね。そういう人も少なからずいると思います。

　ですから、新しいものが出たら（出そうになったら）一通りどんなものかだけなるべくチェックするようにしています。

　ちょっと前ですが、「ニンテンドー3DS」が発売されました。やっぱり裸眼で3Dってどんなもんやろ？みたいな想像から食指が動いたのですが、取りあえず購入してしまいました（嫁さんに内緒で）でも、先ほど書いた視力の衰えも相まって、3Dゲームがかなり目の負担になる感じがしました。結局、3Dスイッチをオフにしていることが多いという、ちょっとトホホな結果となってしまいました。でも、設定画面を3Dにしているとなんだか新しいユーザーインターフェイスみたいでこっちは非常にお気に入りです（笑）。

　ちなみに後日、嫁さんに見つかってしっかりお説教されました。

■物事の見方

　よく、年寄りは「頑固」だ、と言われます。本人にその意識があるかは分かりませんが、これって知らず知らずのうちに自分もそうなっているのでは？ と感じることがあります。ですから私はどんな物事でもなるべく一方からだけではなく、両方の立場から考えるようにしています。

　携帯やスマートフォンを含めて最近はネットを利用する人がかなり多いからか、報道メディアもネットを意識しています。そのため、情報発信の仕方によっては世論がかなり一方的になることが多々あります。

　ブログなどの炎上や今回の震災、政局など。個人的には「そこまで書かんでも」という事柄が結構あるのですが、選挙の結果など見ると情報発信側の事情としてはそうもいかないんでしょうね、きっと。

　メールの返信も遅いと催促されることがありますが、世の中総じて「短気」になっているように感じます。物事にはすぐに結果が出ることとそれなりに積み重ねてから結果が出ることの2つがあります。何でもかんでも前者のように捉えてしまうのは個人的には不幸だと感じます。仕事でもそうですが、すぐに「OK」「NG」では何も解決しないように思います。

　人間は自分が基準であり中心です。それだけにこだわると「自己中」なんて言われますが、お客様だって開発メンバーだってそれぞれの立場と考え方があります。自分の考えと経験だけを押し付けてしまい、それに合わないと「ダメ」ではあまりに了見が狭すぎます。どんなことでも相手の意見を聞いて、相手の立場に立った上で自分なりにどうすれば一番良いかを考えることが「柔軟な思考」の第一歩だと思っています。

　それでも対立する時はお互い言いたいことを言うことも時には必要です。人間、言いたいことを言い尽くすとそれで少しスッキリしますから。でも、遺恨が残らない程度で……。

■想定外

　今回の震災でよく使われたフレーズですね。原発事故に関してはそれそこよく聞きました。でもこの言葉、ソフトウェア開発をしているとよく聞きませんか？ 私は良く聞きます（笑）。

　社内システムやSIではあまりないかもしれませんが、自社開発でパッケージソフトを作っているとそう思うことがままあります。基本的に不特定多数に向けて販売するので、サポートへの質問などでそれを実感します。ようするに実装した機能が自分たちの意図したことと違う方法で使われていてそれに対しての質問だったりすると「へぇ、こういう使い方もできるんだ」と自分が設計したことも忘れて関心してしまいます。実害のない？ 想定外ですね。

　私の経験上、よくあるのがサーバの負荷についてでしょうか。時々ヘルプで別のシステムを見たりするのですが、構築前に「期待通りのレスポンスをするには数台に分けた方が良いですよ」とアドバイスしてもたいていは1台で構築して四苦八苦していることが多いです。不況だからでしょうか、ねぇ。でも、使い物にならないシステムならそれこそ「無駄金」になると思うのですが。

　この場合、想定外なのは当事者たちだけで、私から言わせれば想定内です。データベースなどでも何も考えず操作しているようなケースも良く見かけますが、そうなると本当に人災だと感じます。

　設計する側も実装する側ももう少し「意図」を考えてやらないと炎上するプロジェクトだけが増えて行く気がします。そのためには構築するシステムの勉強は最低限、必要だと思うのですが。小規模ならともかく、ある程度の規模以上で好き勝手にSQLを記述しているのを見ると本当に倒れそうになります。

　私から見ると、構築するシステムの知識が乏しい人がやっていることが想定外です。

■美しいソースコード

　私はパソコンのBASIC（VBじゃない方）でプログラミングを始め、アセンブラで自分のスタイルを確立してしまいました。この頃はまだCPUレベルで掛け算や割り算はできませんでした。ハードウェアコントロールも単純でしたし。

　会社に入ってハードウェア設計からソフトウェア開発要員になってから初めて世に言う「情報処理の基礎」を教育されました（高校ではちょびっとやりましたが）言語もほとんどCOBOLでC言語が申し訳程度だったと記憶しています。COBOLはそれ以来経験ないですけど。

　仕事ではシステムに近いソフトウェアが多いこともあり、仕事でよく使うのはUnixのC言語かWindowsのVC++です。JavaやPHP、.Net（ASP.Net）なども少しは使いますが、今でも多いのはVC++です。

　今更ですが、C/C++はコンパイラ言語です。プログラムをコンパイルして出来たアセンブラをアセンブルし、最後にリンクします（ようするにビルドですね）そのため、昔からあまりソースファイルにはこだわりがありませんでした。今でこそシステムリソースが豊富にありますが、昔はメモリも少なく、フロッピーもまだまだ活躍していました。お世辞にもいいとは言えない環境で動かすため、コンパイルして出来たアセンブラを見てソースコードを修正したりもしました。ようするに見易さよりも実用性重視です。

　そのため、ソースコードはその手段でしかないので私の中では設計書と同じ「ドキュメント」の扱いで、コメントもそれなりに書き込んであります。昔のコンパイラには怪しいものもあり、ソースコード通りコンパイルしていないものもありました。それもあって私的には「ソースコード」がそのままイメージ通りのソフトウェアになること自体疑っているのかもしれません。

　で、ある日後輩に

　「にゃん太郎さんのソースコードって美しくないですね」

　と言われてしまいました。初めは耳を疑いました。「間違っている」でも「見にくい」でもなく「美しくない」って、何？ と。そして、コメントの書き方、if文の条件式の書き方、制御文の使い分けの仕方……など、御丁寧にダメ出しをしてくれました。

　if文なんかは私の場合、頭の中でどうやってコンパイルされるかを考えることが多かったので、見やすいとか分かりやすいっていうのは確かに二の次になっていることは多いです。少しでもメモリ使用量を減らし、少しでも高速なものを突き詰めることが多いので、すでに発想の原点が異なります。

　こういうのって言われないと分かりませんね。さすがに美しいコードまでは考えませんが、最近は見やすいコードを心がけるようにはなりました。

　PMが自分の作ったコードをレビューして後輩にダメ出しされると結構凹みますが、それが逆に「まだまだ若い者に負けんわ！」という意欲にはなります。立場上、それなりに勉強しておかないと「何言っているの？」と言われてしまうので、ある意味必死だったりします。

　あ、そこまでこだわるならC/C++じゃなくて、アセンブラの方が早いんじゃない？ と言うのはナシでお願いします。

■開発ポリシー

　オブジェクト指向がメジャーになる前からこの仕事をしているので、今日までいろいろな開発手法が出てきてそれを勉強しました。言語もいろいろ出てくるのでそっちもそれなりに勉強してメジャーなものぐらいならほぼ経験しました。

　ただ、個人的にはあまり手法や言語にこだわりがありません。極論すれば「オブジェクト指向？ アジャイル？ そんなものクソくらえだ！」というぐらいの考えはあります。誤解されるといけないのできちんと補足しておきますが、オブジェクト指向やアジャイル開発が「ダメ」なんじゃなくて、最終的に要求されるものが完成するならどんな方法も構わない、ということです。もっともオブジェクト指向やアジャイル開発の方が効率も良いので、結局そういう方向にはなってますけどね（そうならざるを得ない、と言った方が正しいかも）。

　ただ、「何が何でもオブジェクト指向だ！」とか言われてしまうと個人的には辟易してしまいます。「そうかも知れないけれど、そこまでこだわらなくても……」と思い切り引いてしまいます。

　方法論、と言ってしまえばそれまでですが、そこに「だけ」こだわってしまうと道を外れてしまい本末転倒になりかねません。いろいろな勉強をしつつ、良い所は積極的に取り入れてそこは常に試行錯誤するぐらいの感覚も必要かも知れないと考えています。結局、できたソフトウェアを使うのは自分じゃない訳ですし、商売も考えると人、時間、効率は常に追求しないと生き残れないと思いますから。

　基本的には「いいとこ取り」がポリシーなんですが（失敗も多々あり……）。

■昔取った杵柄

　今でも初めてJavaやOracleなどデータベースを触った時のことを思い出しますが……。

　先ほど書いた通り私はWindowsでの開発が長いため、ほとんど使用言語（開発環境）は「VC++/MFC」です。バージョンはVC++4の頃からなので結構長いお付き合いです。今でもVC++2008を仕事で使っています。

　さて、何を思い出したかと言うと、「null」と「true/false」です。今時こんなこと言うと「はぁ？」って言われそうですが、私は当時まで「null = 0」「true =1」「false = 0」と本気で思っていました。初めてJavaを使った時も当然、この考え方が頭にあってえらい目に合いました。おかげでその区別がきちんとつくようになりましたが。

　VC++って当たり前ですが、Microsoft仕様なので厳密な言語仕様とは異なります。そんなことは分かっていても普段は意識しないのでついつい「標準仕様」と勘違いしてしまいます。ようするに、習慣なので「これが普通」と考えてしまうんですよね。

　MFCですと標準で「NULL」やBOOL型の「TRUE」「FALSE」（すべて大文字）を使うことが多いと思います。そしてそれは#defineなどで以下のように定義されています。

　#define NULL 0
　#define TRUE 1
　#define FALSE 0
　typedef int BOOL

　nullはご存じのようにゼロではありませんし、true/falseもしかりです。当然、Javaやデータベースもそうなのですが、VC++/MFCばかりだとついつい混同してしまいます。そう思って実際にプログラムを組むとtrue/falseはコーディングの時にエラーになるので良いのですが、nullはミスが連発しました。

　長年やっているとついつい惰性になってしまうのは仕方ないとは思いますが、基本をおろそかにしているんだとこの時は猛反省しました。

■ググらないススメ

　私は昔から技術書が好きで結構買っていたのですが、最近はお小遣いが少ないのと置き場所がなくなってきたためにあまり買わなくなりました。古い本から少しずつ「自炊」しているので最近は少し余裕も出来ましたが、何より本を買わなくなった一番の理由は、

　「ググれば安くて早い」

　からです。これは最近のエンジニアでは普通だと思います（ネット環境があればですが）とにかく自分がつまずいたところはたいてい他の誰かもつまずくことが多いので、探せば疑問点はほとんど見つかります。英語圏まで広げれば何でもあるんじゃないかと思うぐらい。しかもソース付きで。

　でも、個人的にはプログラムを組む時にはあまり使わない方が良いと考えています。欲しい物を探したり、一番安いお店を探したり、旅行先の情報を見たりなどガイドブックや百科事典（辞書）的な使い方は良いと思います（仕事中はほどほどに）。でも、同じ感覚でソースコードをコピペするのは多分マズいです。あえて利点を探すなら効率的、でしょうか。

　この間、久しぶりに技術書がたくさんある本屋に行きました。少し見ない間に面白そうな本もたくさんあっていろいろナナメ読みして楽しんできました。でもそういう本って高いのが悩みなのですが、それでもやっぱり仕事でエンジニアをやっている以上は本から情報を仕入れる方が良いと感じました。

　Google検索はいわば「回答」が見つかります。テストのカンニングと同じでその場は何とかなりますが、結局自分で理解していないと後からそこが問題になることもあります。それに対して本は「How to」と「ヒント」が見つかります。つまり、自分がやりたいことがそのままの情報ではなく、それに近いことを手順を追って説明することが多いのです。そして自分で入力しながら（CD-ROMなどに入っている場合もありますが）確認するために「勉強」にもなります。何より「投資」も必要になるので、ある程度は真面目に読むでしょう。

　ググるなとは言いませんが、やっぱり自分で理解するようにしないとネット環境がないところで開発作業をすることになってから慌てるのは、結局自分です。

　Google依存はほどほどに。

■「考える」癖を身につける

　年齢が上がってくると言われるよりもいうことの方が多くなります。立場によってはかなり影響力もあるでしょう。でも、条件反射的ではなくて自分なりに考えて行動することは、逆に年齢が上がれば上がるほど必要になると思います。

　私は時々そういうことも思い出しながら、仕事をするように心がけています。

　今回の震災は、いろいろなところで「想定外」という言葉が聞かれました。地震や津波の規模、原発の事故など。これらはまだ収束したわけではないので、これ以上は申し上げられませんが、なるべく最小限で収まることを願うばかりです。

　うちの会社も本社は東京なのですが、電話で話をしたら余震でゆれるので落ち着かないと言ってました。こういう状況と計画停電もあってガソリンや食料品を買いに走る人がたくさん出るんだと思います。私はもう少し西なのですが、それこそテレビ以外はあんまり変化があるようには感じ取れません。ただ、コンビニとか行くと単1・単2電池だけは軒並み売り切れていました。懐中電灯とか点検するのはこういう時なので、それでかもしれません。ラジオなどで必要そうな単3、単4電池はなくなるほどでもなかったので。

　さて、阪神淡路大震災でもそうでしたが、自然の前ではわれわれはいかに無力なのかという事を改めて思い知らされました。そして今回はもう1つ、阪神淡路大震災ではあまりクローズアップされなかったものがあります。

　それは「電気」です。

　被災地が停電するのはあり得る話ですが、それ以外の場所でこれがクローズアップされるのはあまりなかったと思います。そしてその場所が「首都である東京及びその近郊」だったから余計でしょう。電車が間引きされたり、時間によって停電したり（しかもしないこともある）気が気でないと思います。そして原発の事故。どんな自然災害が起こっても安全だというスローガンが危うくなっています。

　思えばインフラもライフラインもそして生活も仕事も「電気」が一番ベースになっています。電車はその名の通り電気が必要ですし、ガスだって例えばお風呂を沸かす時、給湯器のところが多いと思いますので、電気がないと使えません。ガスにしろ、水道にしろ、ポンプなど、供給側も電気が必要なため、電気がないと供給できません。電話も光ファイバーやISDNの電話は使えませんし、最近の多機能電話機は電源が落ちると通話できません（ダイヤル回線であれば、電話線から供給される電力で電話はできますが、最近は基地局もデジタル化が進んでいるのでこの限りではないかもしれません）。

　何より、われわれの仕事は「電気」なしでは成り立ちません。良い悪いは別にして、タコ足配線状態の方もかなり多いと思います。「コンピューター、電気がないとただの箱」とはよく言ったものですが、バッテリーや自家発電ではたかが知れています。

　テレビやラジオ、ネットでは被災状況が報道などされていますが、たいていの被災者は電気も何もなく着の身着のままの人が多いでしょうから、本当に知りたい人が知りえないという何ともやりきれない状況ではありますが、それでもやるしかないのが現状です。

■危機管理

　報道されている政府や東京電力の対応を見ているといろいろな意味で想定外の事態が起こっていると推測されます。テレビではかなり批判的な意見が多いですが、個人的には良くやっていると思います。

　危機管理は基本的に経験に基づいてどうするかの行動指針が決められます。というのも経験しない「危機」に関しては管理どころか想像すらできないからです。現在の大地震のオペレーションはいわいる「東海地震」が起こることを予想し、阪神淡路大震災の経験がベースになっていると思われます。

　しかし、今回は広範囲で想定の倍以上の津波が押し寄せてきました。東北地方は日本海側、太平洋側問わず比較的地震が多く、近年でも中規模以上の地震が何度か起こっており、どちらかと言えば日頃の備えがしっかりした場所です。それでも海岸から数キロまで津波が押し寄せるとは想像すらできなかったでしょう。想定以上で建設された防波堤すらを軽々超えてしまっては、なすすべはありません。

　東京電力にしてもそうです。原発事故や計画停電、そして忘れてはいけない発電所や送電線の復旧など、現場レベルでは間違いなく右往左往しているはずです。確かに情報の素早い開示は必要だと思いますが、そうもなかなか言っていられない状況もあると思います。広報担当者の慌てぶりを見るとそれが良く分かります。

　プロジェクトでもそうです（やや強引ですが）。

　PMとしては進捗が遅れるであろう障害をいくつか想定してプロジェクトを計画します。しかし、想定外の事が起こると遅延し最悪デスマーチに突入します。こういう場合は情報伝達や意思疎通がだんだんうまく行かなくなります。これらは「誰が悪い」ではなく、「仕組みややり方が悪い」と私は考えています。人を投入して人海戦術で乗り切る、という事はこの業界では昔からありますが、指揮系統を再構築しないとまずうまくいきません。今回の震災で自衛隊を当初の2万人から10万に増やす事になりましたが、単純に増やせばスムーズに行くわけではないことは現状が示しているように思います。もっともこちらは増やさないとどうしようもないので、再構築しつつ、順次増やす方向に持っていくことがベストだと感じます。

■情報公開

　原発関係なんかは特にそうですが、地元自治体や報道機関などは情報が少なく、苛立っている様子がテレビを通して伝わってきます。

　プロジェクトでも順調な時の進捗はスムーズに出てくるのですが、そうでないとなかなか出てこなかったり隠したりする事がままあります。そうなるとPMとして確かにイラっと感じることはあるので、これも理解できます。

　ニュースキャスターや評論家の中には「なんで最初から半径30キロ以内の住民を避難せさせて原子炉に海水を入れないのか」と批判していることがありますが、それは無理でしょう。1つの事象に対して対策を行っても、次から次へ別な事象が起こっているため、リカバリに精いっぱいで発表も後手に回っています。避難にしても、受け入れ先の問題もありますが、何より最初から範囲を広げてしまうとそれが最悪の状態だと推測されてパニックの引き金になることも考えられます。このあたりは本当に難しい判断をしていると思います。

　適切な情報公開と下手な隠ぺいをしないことが、最悪の事態を回避する手段なのは事故でもプロジェクトでも同じです。

■原発について

　原発には昔から賛否両論があり、しかも日本だけではなく世界的であるため、今回の事故についてどの国でもかなり関心が高く、影響を与えています。

　原発は、極論すれば仕組みの違いはあれど「原爆」を抱えているようなものです。唯一の被爆国である日本には非核三原則というものがありますが、兵器ではないからと言っても「核」である事には変わりないので、安全性も含めて賛否両論あることは（特に地元周辺では）至極当たり前だと思います。

　今回の事故は、どんな自然災害でも安全と言われていた中で徐々に被害が広がる様相を見せています。現在進行形なのでこれ以上言及はできませんが、問題がないとしても水素爆発で建屋が吹っ飛ぶ映像を見たら誰でも不安になって当然だと思います。

　核燃料は有害なもので、何重にも対策を講じられているのはほとんどの人が知っていると思います。しかし、今回は本体そのものではなく冷却装置など付帯装置がトラブルで故障したことが発端です。私も原子炉はそうそう壊れないとは思っていましたが、まさかその周辺装置までは考えが及びませんでした。

　これから先、原発の建設・運用についてかなり否定的になってくると予想されます。特に今回と同じような古いタイプのものについてはこれからの運用にかなり反対されるでしょう。日本以外でもそういう流れができつつあります。

　ただ、ITエンジニアとしてはこのことを真剣に考える必要があります。

　日本ではほとんどが火力発電ですが、2割ほどは原子力発電です。電力需要は年々増加をしていますが、それに対応するには現状では原子力発電がおそらく必要です。火力発電は昔は石油がメインでしたが、最近では天然ガスが主流です。ただし、国土が狭くて資源に乏しい日本では安定的（量的にもコスト的にも）に供給できるのはおそらく原子力発電しかないと思います。ここまで高度情報化された社会では電気なしには成り立たないことは容易に想像できます。

　われわれITエンジニアは、電気がなければ仕事ができません。手書きで仕様書を書こうがノートにコーディングしようが動かすものがなければ何の意味も持ちません。そこには知識にもスキルにも価値はないに等しいです。

　自然エネルギー（風力、水力、太陽光）では安定供給は無理なので、それこそ全国的に計画停電になりかねません。とすれば選択は以下の2つぐらいしか思いつきません。

• 原子力発電は行わず、計画停電などを常態化しインフラも最小限に縮小する
• 今まで通り、原子力発電を安全性を高めながら推進する

　普段は壁にコンセントがあって、そこにつなくだけでコンピュータなどの電化製品が使えますが、その向こう側の事情についても人任せだけではなく自分でも考える必要はあると思います。個人的にはできれば原子力発電はない方が良いと思いますが、現状では今回の事を教訓にして安全性を高める方法を考えてまた再開して欲しいと思います。

　関係ないと思うなら一度、家のメインブレーカーを落として1日過ごしてみると良いでしょう。それだけでいかに電気に依存して生活しているかが分かると思います。それが何日続いても問題ないと思うのなら原発に反対する資格はあるでしょう。

■思いやりを持ってできることをやろう

　原発事故や計画停電で「何やっているんだ！」と思ってしまうかもしれませんが、最前線で早く何とかしようと思って頑張っている人はかなりたくさんいます。政府にしろ電力会社にしろ批判はまず後回しにしましょう。それは復興が軌道に乗り始めてからで良いと思います。今はとにかくできる人ができることを、その時の最善の方法で行って支援すればいいと思います。

　先ほども書きましたが、被害がなくても、いや被害がないならなおさらコンセントの向こうや電話線の向こう、道の先で頑張っている人達に対して感謝をすべきです。その上で直接助けられる機会があれば現地で頑張ればいいですし、そうでなければやれる範囲で構わないと思います。変に自粛ムードだけになってしまうと経済活動も停滞してしまい、それこそ復興どころではなくなってしまうかもしれません（大げさですが）。

　パソコンでプログラムを組んでいると何となく数人のグループや1人で仕事をしている気になってしまいますが、今最前線で頑張っている人がいるからこそわれわれITエンジニアは不自由なく仕事ができるんだと改めて実感します。

　最後に震災により、亡くなられた方々のご冥福をお祈り申し上げますとともに、被災された皆様やそのご家族の方々に対しまして、心よりお見舞い申し上げます。

　今年ももう2カ月が過ぎようとしています。早いですね（年だから？）。こちらのコラムは更新自体が久しぶり過ぎて、「はじめまして」と言っても通用するんじゃないかとさえ思います。

　あ、そんな中でもちょこちょこ古い記事にコメントをくださってありがとうございます。返信はできませんでしたが、よかったらまたよろしくお願いします（あんまり前のだと覚えていなくて返事をしないことの方が多いです）。

　近況ですが、仕事自体はそんなに忙しいわけではありません（ヒマではありませんが）。ネタもそれなりにあるのですが、プライベートがちょっと忙しくて、なかなかこちらのコラムまで手が回りませんでした。よそで執筆してたりしますが、こちらは仕事でした（会社外ですが）。もっとも、ITやエンジニアの類ではないので、特に宣伝などはしません（興味ないでしょうし）。

■されどPM

　仕事上では私はPMなのですが、エンジニアライフのコラムを読んでいると、PMはどちらかと言えばエンジニアの「敵」扱いされていることが多い気がします（フィクション含む）。まぁ、それなりに経験だとか年齢が離れているというせいもあってか、PMに上から頭ごなしに何か言われれば、そう感じてしまうこともあるとは思います。個人的には、上司なんてそんなもんだと思っていますが、私の若いころを考えてみれば、その気持ちは十分理解できます。

　私もいろいろなPMと仕事をしましたが、どちらかと言えば、神経質な雰囲気を漂わせる人が多かったと感じます。特に、プロジェクトが遅れていると、非常にピリピリムードになって、話し掛けられない感じとか。ただ、時々すごく大ざっぱ（に見えた）な人もいました。いつも「何とかなるか」って笑ってた人や、見た目や話し方が居酒屋の大将っぽかった人もいました。ただ、不思議なことに、神経質な人よりはそうでないPMの方が、案外スムーズにプロジェクトが進行しているように思います。

　私のように「成りゆき」でPMになる人はあまりいないと思います。エンジニアでたたき上げでPMっていうのも、おそらく少ないと思います（いるとは思いますが）。特に大企業なんかはそうですが、基本的に「将来はPM候補だ」と思われる新人が入ってくると、少しだけプログラミングを経験し、そこから少しずつ設計をして経験を積み、徐々にPMになるための教育なんか受けて……というのが多いと思います。会社の規模が大きいと、キャリアパスの形成がしっかりとしています。

　エンジニアとして就職した人は、PMのような管理職じゃなく、SEやリーダーとして、できれば現場でずっとプログラミングに携わっていたいという人が多いのかもしれません。私の同僚でも、現役エンジニアにこだわって転職した人が何人もいますし。

　私も、できれば毎日楽しくプログラミングしていられれば良かったなぁ、と思っているクチですが、まぁそこはサラリーマンの宿命で（家族もいるし）、そうそう拒否も退職もできないので、自分なりにマネジメントしてます。

　今回は、私の実体験を通して、PMの大変さを少しでも理解してもらえればと思います（誤解されてしまう可能性も否定できませんが）。

■権限と責任

　PMは通常「プロジェクトマネージャ」を指しますが、私の会社はSIerではなくソフトハウスなので、プロジェクトというよりは製品単位でマネージャが存在します。そういう意味では「プロダクトマネージャ（製品管理者）」と言った方がピンと来るのですが、まぁ、やること自体はそんなに変わりません（おそらく）。

　SIerと違うのは、特定の顧客（ターゲット）がいないことです。そのため、実装する機能に対する要望は、営業（販売店）を通したお客様の意見や、既存ユーザーの要望やクレームがメインとなります。

　うちの会社の場合、PMの権限はかなり強いです。新製品の企画を出すこともありますが、会社から決められる事は基本的に「ソフトウェアの種類とターゲット」だけです。種類とは例えば「ワープロ」や「表計算」みたいな感じです。ターゲットは個人か企業か開発ツールかなどです。それ以外についてはほぼPMが決定します。具体的には機能やプラットフォーム（とは言ってもほぼWindowsですが）、値段、スケジュールなどです。中堅以上のSIerと異なり、メンバーはまず10名以下です。他の製品も絡んでくることはありますが、1人で管理するにはまぁ、問題ないレベルだと思います。

　開発言語（環境）もほぼ自由です。極端な話、Excelのマクロ（VBA）だって構いません。C/C++だろうが、VBだろうが、Javaだろうが、どれでも特におとがめはないですが、あまり変なものだとツッコミは入ります。上司（役員）に必要性みたいなものを説明できないとさすがに却下されますが、そういうことはまれです。

　機能に関しては、初期バージョンはゼロベースから、バージョンアップ時はお客様の意見や営業の要望などです。時には上司から命令に近いものもありますが（他社で同じようなソフトがあった場合、そちらに実装されている目玉みたいな機能は入れろとよく言われます）、無理なものは無理なので、できそうなものをチョイスしながら決定します。この辺はSIerよりもかなり自由なので、結構気楽だと思います。

　こういう環境だと、一見ストレスがないように見えませんか？

　いやいや、権限があるということは、それに比例して「責任」が生じます。重大なバグの発生やリリース日が予定より遅延したりすると当然、責任を取ります。場合によってはいくらか罰金を給与（賞与）から引かれます。もっとも、逆にかなり予想より売り上げが上がると金一封がもらえます。売れないと営業からかなり突き上げられますし（モノが良くないと言われる）、売り上げ計画も立てるのですが、それが未達成だとやっぱり小言を言われます（さすがに罰金はないですが）。

　SIerのPMとは規模も役割も若干違うとは思いますが、そうは言ってもやはり権限と責任がそれなりにあることは間違いないと思います。

■誰が悪い？

　私のプロジェクトではまずないですが、プロジェクトが遅延した場合、誰が悪いと思いますか？ 実際の作業では、どこかが何らかの理由で遅れるのですが、責任という意味では当事者ではなくPMにあります。

　PMはプロジェクトを円滑に進めるためにマネジメントする立場だからで、本来は遅れそうな部分を事前に見つけてリカバリ（あるいはリカバリを考える）を求められる立場です。時には不可抗力なこともあるでしょうが、大概が人災なので、日々の管理は大切だと思います。

　ただ、PMも人間なので、遅れているメンバーに対しては正直、「ちゃんとやれや！（怒）」と心の中で責任転嫁していることが多いと思います（それぐらいは許して）。中には本当に責任転嫁しちゃう人もいますが、それはPMとしては失格です。

■基本は信用しない

　どこかのプロ野球チームの監督も言っていた気がしますが、私はプロジェクトメンバーに関しては「信頼はしても信用はしない」です。当然、仕事上の話であって、人間的に信用しないわけではないです。

　世の中にはいろいろなプロジェクト管理の手法や考え方があります。当然、私も本ぐらいは読んでいますし（教育は受けたことがないですが）、スケジュールもフェイズを区切って、プロジェクト管理ツールも使用しています。でも、それでプロジェクトが順調に進むなら苦労はしません。机上論だけではおそらくダメだと思います。

　メンバーは定期的に進捗報告しますが、私は基本的にそれをナナメに読んで、あまり信用しません。むしろ毎日メンバーが出勤する前に前日にコミットされたソースやその差分なんかをチェックします。これがおそらく、一番確実だと思うからです。

　メンバーのソースで気になるところやあまり進んでいないと、必ず朝のうちに直接話を聞きます。この時、スケジュールありきで話をするのではなく、エンジニア目線で話をすると、意外と納得してくれます。あとは、ソースレベルでチェックしていることが浸透すると、いい加減なコードや進捗報告を書かなくなります。逆に、私の書いたコード（前にも書きましたが、人的都合で兼業PMなので設計もプログラミングもテストも参加しています）も他の人がチェックしているので、時々突っ込まれたりします。

　「信用しない」というのは言い過ぎかもしれませんが、仕事なので、ある程度緊張感を持ってやることは必要だと考えてます。なぁなぁでもなく、ピリピリでもなく、ある程度「管理」しているということを認識してもらえるように常に考えています。

■役割を考える

　私はSE、PG、テスターという一般的な分け方は今どきナンセンスだと思っています。ウォーターフォールがどうとかアジャイルがどうとかではないのですが、フェイズごとに役割を割り当てると、エンジニアはなかなか全体が見えにくくなってしまいます。そのため、私のプロジェクトでは程度の差はあれ、基本的に1人が1つのモジュールに対して設計・実装・テストを行うように割り振ります（ただし、最終的な結合・総合テストはまた違う人を割り当てることはありますが）。

　そうすると、エンジニアのスキルが、ある程度平均化していきます。自分で設計や実装するからと言って好き勝手すると、他のところでも影響が出る可能性があるので、他のエンジニアからチェックが入ったり、他の人のソースを参考にしたりするようになります。

■無駄なことはしない、させない

　仕様書って、どの程度作ってますか？ SIerとかだと、仕様書は納品物の1つなので、状況によっては「お金をもらう」ための仕様書（＝あんまり役に立たない、取りあえずこういう設計したという証拠みたいなもの）が結構あると思います。

　最初はいいのですが、プロジェクトが段々大詰めになってトラブルとか遅延とか出てくると、仕様書は段々メンテナンスされなくなっていくことも多いと思います。私も経験上、「後々役に立たない仕様書だなぁ」と思ったことは何度もありました。

　私のプロジェクトの場合、基本的に「1機能：1～2ページ」が基本です。画面遷移などは、なかなかそれで収まらないことも多いですが、あんまり細かいことまでは記述しない場合が多いです。仕様書で、ある程度の動作や機能が把握できれば、後はソースコードを追う方が早いので、そこが基本線です。

　もっとも、ソフトハウスだからこそできると思うのですが、分厚いドキュメント作っても、後から見るのもメンテナンスするのも大変なので結局、細かい変更はプログラムだけで完結させることも多々あります。それが積み重なると、だんだん仕様書の意味がなくなってしまうので、それだけは避けようと考えています。全員が他人のソースコードを追うクセがついているので、コメントの書き方も意外とうまいです。多過ぎず、少な過ぎず、です。

　ドキュメントに時間を費やすより、プログラムを作って考える時間を増やした方が最終的には早いですし、何かあると結局プログラムを追いかけた方が効率が良いです。使われなくなる（使えない）ドキュメントを作るなら作らない方がマシだと、私は考えています（それじゃまずいので適当に自分でメンテナンスはしますが）。

■意外と気を使ってマス

　スケジュールはあってなきもの、なんて感じで、実際は予定どおりにいかないことも多いです。ですが、基本的にメンバーに責任を押し付けたりはしないようにしています。予定どおりにいかないと分かれば、負荷分散するようにして（そういう時はたいてい私自身がフォローしていますが）、怒ったり責めたりせず（時々、すごく腹が立つこともありますが）なるべく優しくするように気を付けています（今どきは怒鳴ってもあんまり効果なさそうですし）。

　あと、なるべく残業や休日出勤はさせないようにします。そもそもダラダラやってたら、能率だって集中力だって続くわけないですし。だったらオンタイムに集中して、終わったら帰った方が絶対にいいです。エンジニアの中には、残業や休出が自慢みたいな人もいますが、そんなの「私は時間内で仕事が終われない無能です」と言っているようなものです。それだからか、うちのメンバーは昼休み以外ほとんど休憩しません。そして定時後、1時間以内にはほぼ全員帰宅します。

　ちなみに私は率先して定時に帰ります（その分、早く出社しますが）。上司や先輩がいたらやっぱり帰りづらいでしょ？ それを言い訳にされるのもイヤなので、会議やお客様との約束がなければさっさと帰ります。

　プロジェクトってなかなか理屈だけではうまくマネジメントできないなぁ、といつも感じます。計画や手法、管理よりも、しょせんメンバーが協力してくれないと絶対にうまくいかないので、なるべく気持ちよく仕事を進めてもらえるよう考えています。

　とは言っても、やっぱりPMってうざいんだろうなぁ……（涙）。

　何かの縁があって私のプロジェクトに入った場合は、快く協力してください。

　最近の経済ニュースを見ていると、不況が続くのかこれから良くなるのかいまいちピンと来ない感じがまだまだします。就職・転職の状況においても同じで、エンジニアかどうかにかかわらず非常に厳しいと思います。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人ひとりのエンジニアの自覚と矜持が一番効果的だと思います。わたし自身はこれからもそう思って自己研さんと後輩の指導をしていきたいと思っています。技術で語りあいができるのは、本物のエンジニアだけですから。