プログラム楽しみ编码的乐趣

ソフトウェア開発の名書

2011-11-12T22:59:00.002+09:00

SEの教科書　－　深沢隆司
ソフトウェア開発で伸びる人、伸びない人　－　荒い玲子
「要求」の基本原則　－　三宅和之＆岡大勝
ソフトウェア開発の名書を読む　－　柴田芳樹
SEは人間力　－　井上樹
Code Compelete
実装パターン
Clean Code
アジャイルソフトウェア開発の奥義

プログラマー”まだまだ”現役続行（柴田芳樹）

2011-11-12T22:17:00.002+09:00

プログラマー必読、管理職にならなくたっていい。

＝＝職人としての七つのレベル＝＝

■レベル１：初心者

　ソフトウェア開発を行うには、プログラミングの基礎知識やコンピュータに関する基礎知識が不足している。

■レベル２：見習い

　指導を受けながら簡単なプログラミングなどの実践ができる。

■レベル３：初級職人

　見習いレベルの実践ができるが、ときどき指導が必要である。

■レベル４：中級職人

　必要な技術を仕事の上で自然に自動的に使っている。

■レベル５：上級職人

　新たな技術を含めて自分で常に学習を行い、自然と実践できている。

■レベル６：名人

　技術を完全に消化していて、いつルールを破るべきか知っている。また、技術記事などを執筆している。さらに、中級職人以下の職人を上級職人にすべく、組織に対して教育・指導を行っている。

■レベル７：匠

　専門書を著作し、講演し、技術を拡張する方法を業界に問う。一方で、より良い方法で職人を育成するための方法も探究している。

→私のレベルは？　

　上級職人以上？

　但し、記事・本など書いてない、書くのが正直苦手です。→これから？

　プログラム好きで、オープンソースのFrameworkといつくかのアプリだけ作成しています。

＝＝現役続行に必要な七つの力

①論理思考力　　　　　　　　　　　⇒OK

②読みやすいコードを書く力　　　　⇒OK

③継続学習力　　　　　　　　　　　⇒OK

④コンピュータサイエンスの基礎力　⇒弱い

⑤朝型力　　　　　　　　　　　　　⇒弱い

⑥コミュニケーション力　　　　　　⇒OK

⑦英語力　　　　　　　　　　　　　⇒読むOK、聞くまあまあ、話す・書くだめ

【IT記事転載】プログラマで、生きている - 消えゆくコードに送る言葉を

2009-09-24T17:55:00.000+09:00

転載http://el.jibun.atmarkit.co.jp/hidemi/2009/08/post-4d2b.html

　昔、読んだ記事によると、プログラマは「バグ」よりも「仕様変更」に強いストレスを感じるそうです。

　バグは自分が悪いとあきらめもつきますけど、仕様変更ってのは天災みたいなもんで（←人災以外のなにものでもないけど）、いきなり襲ってきてせっかく作りあげたコードを潰してしまいますから、バグよりストレスだと感じる人が多いのは当然かと思います。

　仕様変更の何が大変って、頭の中で「うん、これはきれいにまとまった」と思っていたものを崩して、ロジックを作り直さなきゃいけないってことなんですよ。

　脳内できれいにルートがさだまっていたものを、方向転換するのは意外と大変です。

　プログラムを組み立てるまでに費やした時間と、同じだけの時間をかけて修正できるのなら話は別ですが、たいていの場合「すぐに直して」って言われますからね。

　あせって修正をした結果、古いルートと新しいルートが妙に交わって、バグの荒野に飛び出すこともしばしばです。

　仕様変更でつぎはぎした感が濃厚なコードをたまに読みますけど、ものすごくせつない気持ちになります。

　プログラマが苦労していることはよっくわかりますけど、もうちょっとていねいに直してあげて欲しいなあ、と思っちゃうんです。

　わたしはどうしても、一枚板から打ち出しました、って感じにしたくって、修正しなくてもなんとかなる部分まで手をいれたりすることがあります。

　それって意味のないこだわりにみえるかもしれませんが、わたしの経験からいえば意外と意味はあります。

　コードに妙な「継ぎ目」があったりすると、その後でさらなる修正を加えた際に「亀裂」になることがあるんですよ。

　ですので、仕様の変更や追加をする時は、できるかぎりコードをフラットな状態にすることに、わたしはこだわります。

　まあ、自己満足だといわれちゃえばそれまでなんですけどね。

　なら、仕様の削除はばっさり切り落とすだけだからそんなに大変じゃないだろう、というとそうでもなくて、意外に精神的なダメージが大きかったりします。

　「我ながらこのロジックはよく思いついたぞ」ってこっそり悦に入ってた部分が不要になっちゃって消さなきゃいけない時とか、ホンキでヘコみますよ。

　コードをテキストファイルとして残しておくことはできますけど、結局、誰にもつかってもらえないのでは「死んだコード」ですから、なんか亡骸を後生大事に抱えてるみたいで余計にさびしい、と思った時にいきなり思いついたわけです。

　コードのお葬式をやってみたらどうだろう！（←我ながらイタすぎる発想）

　「汝が0と1の海に還ろうとも、その魂は我がニューロンの内で生き続け、いつか、新たなるコードの礎となるであろう」（←もっと荘厳な弔辞絶賛募集中）とか言いながら、DELETEキーをポチッと押すのはどうだろう。

　それはいい。なんだか気持ちの切り替えが早くなりそうな気がする。

　……とかいう妄想で、ヘコんだ気持ちを盛り上げようとしている自分がいる……（泣）。

　なんかもう、自分でもバカっぽいって思いますけど、ちゃんと動いてるコードを捨てるのってホントにストレスになるんですよ。

　わたしが過剰反応なんですかねえ。はあ。

【IT記事転載】プログラマで、生きている - プログラマとSEのオブジェクト指向な関係

2009-09-24T17:48:00.000+09:00

転載http://el.jibun.atmarkit.co.jp/hidemi/2009/08/se-8a28.html

　IT業界にはさまざまな仕事がありますけど、わたしはプログラミングにしか興味がありません（←我ながらずいぶんと偏っている）。

　20代の頃に、SEという仕事はわたしには向かない、と思った主原因はそこにありました。

　システムをデザインするということにさっぱり関心がない自分に気づいていたので、こんな人間がSEになってもダメSEになるだけだろう、と思ったんですね。

　ユーザーさんのことを一番に考えるエンジニアになるべき論を読むと素直に感心しますし、それを実践していらっしゃるエンジニアを尊敬します。が、わたしはどうしても、どうすれば一番きれいなコードになるか、ということばかり考えてしまいます。

　じゃあ、ユーザーさんのことなんてどうでもいいのか、というとそうでもなくって、自分が書いたコードが誰かにとって便利な道具になってくれることはうれしいんですよ。

　「この子、こんなに優秀なんですよ～。こんなに役に立つんですよ～。こんなことまでできちゃうんですよ～」って自慢したいというか（←親バカ？）。

　ついでにいっちゃえば、わたしには「こんなプログラムをつくってみたい」という願望がありません。

　ただつくりたいだけで、何をつくりたい、というのがないんですね。

　以前は「C++でつくりたい」という最低限の希望ラインがあったんですが、それもいつのまにか崩れ去ってしまい、もはや夢も希望もなく白紙委任な状態です（笑）。

　できれば、背伸びしてようやくできるレベルのプログラムをつくらせて欲しいなあ、とは思いますけど。

　そんなわけなので、何をつくるか、というお題を与えてくれる会社は、わたしにとってとてもありがたい存在です。そして、どうせつくるんなら誰かに喜んでもらえるものの方がいいに決まってる、と思っているわたしにとって、わたしとユーザーさんをうまいことつないでくれるSEはとても大事な存在です。

　わたしほどSEの重要性を評価しているプログラマはいない……と言いたいところですけど、SEについてどう思っているか、という話題をプログラマ同士でしたことがないので、そこのところはよくわかりません。ヘタに話をふるとグチをきかされるだけで終わりそうで、こわくて（苦笑）。

　わたしが求めているのは、プログラマとSEの洗練された依存関係です。それぞれがさまざまな状況に適応する多相性を持ちながら、ゆるやかな連結を保ち、協調して動作する、洗練されたオブジェクト指向プログラミングのコードのような。

　そういう比喩でいうのなら、今の開発現場のほとんどは構造化プログラミング的なイメージがあります。

　それぞれがそれぞれに与えられた機能をきっちり動かすことだけが求められ、互いに依存しあわないように機能を分割しようとした結果、ユーザーさんの要求の多様化や技術の複雑化に対応しきれなくなっている感じです。それを、SEがよっぽどしっかりしてるかプログラマがよっぽど我慢強いかでなんとかしのいでいたりすると、どちらかに負担が偏ります。で、突然、どちらかがフリーズや熱暴走する大惨事が発生したりするわけです（笑えない）。

　SEとプログラマを「上下」の関係と認識することが、機能の関連性をおかしくしているんじゃないか、とわたしは疑っています。

　SEはユーザーさんに「その処理なら関数電卓で十分ですよ。いいのを知ってますから紹介します」とかいっちゃってもいいんです。それでユーザーさんが納得するのなら職責を果たしたことになります。

　けれどプログラマはそうはいきません。仕事そのものがなくなっちゃいますからね。それでも、SEがそう判断するのならプログラマは従うべきです。

　それは「上下」だからではなく、その判断を行う「職分」がSEの側にあるからです。それだけのことです。

　もっとも、職責をきちんと果たしていないSEにも従わなければいけない、とは思いませんので、SEと認めた人に対しては従うべき、と言うのが正確でしょうね。認めてもいないのに従うと「上下」の関係としか言えなくなってしまいます。

　そして、そういう関係を威圧的に押し付けることはプログラマをダメにするので、最終的にSEの不利益になります。それくらいのことがわからない人が、ユーザーさんの利益をはかれるとは到底、思えません。

　だからわたしは、プログラマに対して高圧的なSEを「ダメ*3SE」（＝「本人がダメダメなうえにプログラマをダメにするSE」）と呼んでいます。

　プログラマがHow（どのように処理するか）の部分を的確に処理できる能力を持てば、SEはWhat（何を行うべきか）の処理に集中できます。

　そんなシンプルな構造をベースにして、さまざまな問題を協調して処理していけばいいんです。むずかしいことなんて何もないと思いませんか？

　まあ、人間関係のむずかしさが簡単に処理できるか！と言われちゃったらそれまでなんですけどね。

　それにしたって、縄張りをがっちり決めて、ここに入るな、そこから出るな、なんて大人げないとしか思えないんだけどなあ。

【IT記事転載】プログラマで、生きている - プログラマの仕事ってどこからどこまで？

2009-09-24T17:43:00.000+09:00

連載http://el.jibun.atmarkit.co.jp/hidemi/2009/07/post-1ab6.html

　今いる会社の採用面接を受けたときに、社長と「プログラマの仕事ってどこからどこまで？」という話をしました。

　普通、面接で出てくる話題じゃないような気がしますが、わたしは社長に対して「定年までプログラマとして働かせろ」という要求を出していたので、それはとても重要な問題でした。

　社長とわたしの間で「プログラマ」の認識にズレがあったら、後々で大惨事を招くおそれがありますからね。給料の話の何倍も時間をかけた記憶があります。給料よりも大事な「待遇」の話ですから当然です（いや、給料も大事ですよ、社長！）。

　「とりあえずコーディングを仕事の中心にして欲しいです」

　「そりゃあそうだろうね。設計とかはやるの？」

　「クラスや関数の詳細設計とかは当然やります。手が足りない時は概要設計もやってましたし、テーブル設計もやりました。UML図の描き方も一通り勉強しました」

　「ああ、やっぱり設計はするんだ。よかった」

　「普通やりますよ。コーダーじゃないんですから」

　「コーダーって最近きかないよね。もはや死語なのかな」

　「そういえばいつからかきかなくなりましたね」

　わたしがこの業界に入った時、「プログラマ」の下に「コーダー」というポジションがありました。わたしも最初はコーダーでした。

　コーダーのお仕事は、プログラマが書いたフローチャート通りにコードを書くことで、上からもらったフローからはずれたコードを書くことは許されません。プログラミング言語の文法をマスターしていれば誰にでもできる仕事です。フローチャートに従ってひたすらコードを書くだけの仕事でしたけど、つまらなかったという記憶は残っていません。

　今のようにネットが普及している時代ではなかったので、プログラミングに関する情報は書籍と先輩方から拾うしかありませんでしたから、フローチャートも重要な教材のひとつでした。コーダーはプログラマになるための丁稚奉公、といったところですかね。

　「実は設計をやってもらえるのかを心配してたんだよ」

　「プログラマは設計もやるのがあたりまえなんじゃないんですか？」

　「おれもそう思ってるんだけど、プログラマはコーディングしかやらないって考えもあるみたいで」

　「プログラムのデザインはプログラマの仕事です」

　「うん。おれと同じ考えでよかった。安心した」

　いろいろと圧縮してありますが、そんな感じでプログラマの定義の一致を確認した結果、わたしは「永世プログラマ」（←カッコイイ言い方を模索してみた）として入社することができました。

　現状では、労働時間の8割くらいはプログラミングをしています。ちなみに、データの処理方法について検討し、クラス設計や関数設計を組み上げ、実際にコードを打ち込み、一通りの動作確認をするところまでが、わたし的なプログラミングの範囲です。

　簡単に言っちゃえば、仕様を受け取ってから仕様通りっぽく動いてますという形にするまで、ですね。付け加えると、「コーディング」と「プログラミング」は、わたしの中では同義です（←気分で使い分けてる）。

　あと、運用、保守を担当させてもらってるシステムでトラブルが発生したときに、ソースコードを読んで問題点を発掘したり解決策を検討したり、仕様の追加や変更を行う場合のコードの修正点をピックアップしたりするのも、今のわたしの重要任務です。

　それと、今の会社に入ってからは仕様検討にも口出しをするようになりました。

　「技術的にこういうことができるんだけど、この画面で使えばユーザーさんにわかりやすくなるんじゃないか」とか「ここをこんな風に変えてもらえれば帳票の出力スピードをあげられる」とかいったことですね。

　でも、それをどう活かすか（あるいは殺すか）は担当SEに任せます。わたしの提案が、ユーザーさんの意向や全体のシステムデザインとマッチするかを判断するのは、SEの仕事ですから。

　今の会社に入るまで、仕様に口を出すということをやってこなかったのは、口出しをしては「プログラマは黙ってコードを書いてろ」的なことを言われる、ということを何度か繰り返したためです。ずっと派遣社員という立場で働いていたので、そういうことを言われたら黙ってコードを書くしかありません。心の中で「もっといいやり方があるのに！」とつぶやきながら。

　プログラミング技術で解決し得る問題について、SEに提案を行うのもプログラマの仕事のうちだとわたしは思っていますが、そう考えるSEは意外と少数派のようです。「余計な真似をするな」と嫌がられることもしばしばでした。

　ダメSEほどそういう傾向が強いので、仕事ができないんならせめて助言を受け入れればいいのに、と思っていたんですが、多分、逆なんですね。周囲の助言を聞きいれないから、いつまで経っても仕事ができる人になれないんですよ、きっと。

　プログラミング技術をベースにしてシステムづくりに関わる技術者がプログラマだ、とわたしは考えています。

　ですから、プログラマが仕様について提案すること自体は、SEに対する越権行為だとは思いません。

　逆をいえば、会社や業界が言うところの「SE」であっても、プログラミングを基点にしてシステムづくりを考える人は、「プログラマ」と呼んでいいんじゃないかと思います。

　労働時間の何パーセント以上をプログラミングに費やしているからとかいうことではなく、思考の原点がどこにあるかでプログラマかそうでないかを判定する方が、わたし的にすっきりするというか腑に落ちるんですが、他の方々はどう考えているんですかね。

　とまあ、プログラミングが仕事の中心でなくてもプログラマと呼べる人はいる、と考えてはいても、わたしはやっぱりプログラミングだけしていたいです（苦笑）。なので、わたしの「プログラマでいたい」は「プログラミングだけをやっていたい」という意味です。

　わたしが定義するところのプログラマに比べて、わたしがやり続けたいプログラマの仕事はもっとずっと範囲が狭いわけで……なんか、自分で自分の意見を否定してるような気がしてきた……（←話がオチてないし！）。

【IT記事転載】プログラマで、生きている - オフィスをめぐる回遊魚の群れ

2009-09-24T17:37:00.003+09:00

転載http://el.jibun.atmarkit.co.jp/hidemi/2009/06/post-1c86.html

　前回、前々回とどうも話が長くなってしまったなあ、と思っていたところに「エンジニアとオフィス」というお題をエンジニアライフ様からいただきましたので、小話を少々。ちょっとテーマからズレてるような気もしないではないんですが。

　以前、大手旅行代理店のパック料金計算システムの仕事をしたことがあります。諸事情により、スタッフの大部分が客先に常駐して仕事をすることになったんですが、これが度重なる仕様変更で絵に描いたようなデスマーチになってしまいました。IT業界とはまったく無縁の人たちが働くオフィスでのデスマーチは、精神的にかなりハードでした。なにせ、どんなに精神的に余裕がなくても、常にお行儀よくしていなければなりませんでしたから。

　お客様のオフィスは、ビルのワンフロアを借り切ったかなり広いもので、ほとんどパーテーションらしきものがなく、端から端までがよく見通せる状態になっていました。そのフロアのすみっこにわたしたちの作業スペースを確保していただいたんですが、マシンが置いてある場所はなぜか作業スペースとは反対側の端でした。

　2つの場所はほぼ対角線上にあるので、移動するにはフロアの真ん中をつっきるのが一番速いんですが、お客様が仕事をしていらっしゃるところにずかずか踏み込むことは許されません。わたしたちは毎日、何度もフロアの外周を往復するはめになりました。

　毎日10人以上のエンジニアがつめていて、ピーク時は20人くらいいたんですが、それだけの人数がフロアの周囲をぐるぐるとめぐるわけです。かなり目立つ存在だったでしょうね、きっと。

　常駐生活が2カ月を超えた頃だったと記憶していますが、その旅行代理店の女性社員さんたちとランチをご一緒する機会がありまして、その時にこんな話をききました。

　「わたしたち、あなたの会社の男の人たちを“回遊魚”って呼んでるのよ。ほら、フロアの周りをグルグル回ってるとこが回遊魚っぽいでしょ？」

　なるほどうまいことを言う、と感心しました。

　オフィスをめぐるノートパソコンと仕様書とプリンタ用紙を抱えた回遊魚の群れ。きれいといえばきれいな表現でしたが、さらにその続きがありました。

　「それに、朝、待ち合いのソファのとこでゴロンとなってるとこが、市場のマグロみたいだったのよ」

　旅行代理店なので、フロアの一角には一般客用の待ち合いスペースがあり、そこにはソファが並べられています。社員の方々がいない時間帯ならそこで仮眠をとってもいいという許可はもらっていたんですが、どうやらデスマにくたびれきった連中が規定の時間までに退去できず、爆睡しているところを女性社員に発見されてしまったらしいです。朝、会社に来てみたらマグロたちが横たわっていたんですから、そりゃあビックリしたことでしょう。

　しかし、掟破りをした連中を責めることなんてできません。皆、疲れ果てているんです。お客様の前で体裁を整える余裕がもうないんです（涙）。てか、わたしもマグロの群れの1匹だと知ってて、なぜそういう話をするんですか、お姉様方（もしかして遠まわしなクレームだった？）。

　旅行代理店のOLさんたちはとてもクールでした。疲れきって死んだ魚のようになってる連中に対して同情なんかしやしません。ただ、別種の生物をながめて、ものめずらしく思っているだけです。個体識別ができていないから数人がマグロに見えれば他の連中も皆「マグロ」。その中でわたしはかろうじて「女の人」と認識されているようでした。

　マグロは眠っている間も泳ぎ続けるとききますが、24時間体制で働き続けている連中にその例えはちょっとムゴい……、と同情できるのはわたしが当事者だからで、彼女たちの側にいたら「なんかよくわかんないことやってくたびれてる集団がいる」と思っていたのかもしれません。

　例えばリフォーム工事とかだったら、目に見える形で仕事が進んでいることがわかりますけど、システムが組みあがっていく過程なんて彼女たちには見えないんですから。わたしたちがつくったシステムをいずれ彼女たちが使うことになるはずなんですけど、その時には制作者はいなくなってるわけですし。

　心が折れかけてる男連中にこの話をしたら心が複雑骨折しそうで、さすがにその件はわたしの胸にしまっておきました。明け方にソファで寝ている連中をみつけたら、たたき起こして作業スペースに移動させた方がいい、とリーダーに忠告するくらいのことはしましたけど。

　それにしても「回遊魚」というとちょっと涼しげな感じがするのに、「マグロ」になると途端に情けないイメージになりますよね（マグロの漬け丼は好物ですが！）。

　自分の会社を離れて、お客様のオフィスで働いている男性の皆様。そこで新しい出会いを期待するのなら、決して人間以外のタグをつけられるようなまねをしてはいけません。たいがいの女は一度定義付けをしたら、その後に実体がどのように振る舞おうと、その定義を書き換えるようなことはしません。

　「男の人」でいたいのなら、がんばって見栄をはってくださいね！もっとも、そんな余裕がある状態を「デスマーチ」とは呼ばないでしょうが。

【IT記事転載】プログラマで、生きている - プログラマなんかで終わりたい

2009-09-24T17:37:00.001+09:00

転載http://el.jibun.atmarkit.co.jp/hidemi/2009/06/post-3b92.html

　職業をきかれると「プログラマ」と答えます。疎そうな人に対しては「コンピュータ関係」と言いますが。ここ数年、同年代で「プログラマ」を名乗る人には出会っていません。プログラマの「定年」、過ぎちゃっていますもんね。

　かなり前のことになりますが、わたしが仕事をしているすぐ近くの席で、他社の方が2人で仕事をしていらして、先輩らしき男性が後輩らしき男性に向かって「こんなこともできないようじゃいつまで経ってもプログラマ止まり」だぞ、とよく言ってらしたんですよ。

　で、わたしはそういう言葉を聞くたびに「プログラマ止まりでいいじゃん」と心の中で反論していました。

　状況もわからない他社の方々のことなので、「もしかしたら後輩がSE志望で、先輩はそれを知っていてそういう励まし方をしているのかも」とも思ったんですが、どうしても「プログラマ止まり」とか「プログラマなんかで終わりたいのか」とかいう言葉を聞くたんびに腹が立ってしかたなかったわけですよ。

　そうだよ、わたしはプログラマなんかで終わりたいんだよ、それがどうした！（←今も変わらぬテンションで怒り続けている）

　正社員として入った会社を20代後半で辞めて、新たな働き口を模索した時、わたしは派遣社員の道を選びました。当時はちょうどバブルがはじけた頃で、採用環境が厳しかったというのもあったんですけど、それよりも「正社員になっちゃうと出世しちゃう」（＝SEにさせられる）ということの方が大きかったんです。

　この業界で正社員として年を重ねていけば、それはもう確実に出世させられます。だけど、上の方々の仕事ぶりをみながら「あれはどうもわたしには向きそうにない」と思っていたんで、どうしてもそのルートには行きたくなかったんですよ。

　つまり「SEになりたくない」という気持ちが、わたしにプログラマの職を存続する道を求めさせ、「派遣なら出世しない」という安直な発想で、正社員ルートを降りて派遣社員になったわけです。

　今、派遣という働き方についていろいろ言われていますけど、わたしはその選択は成功だったと思っています。なにせ、リーダーが気に入らなかったら、最長でも3カ月我慢すれば辞められます。正社員だと上司は自分で選べないですからね。担当SEがひどいと、プログラマは大惨事です。身体か精神のどちらかもしくは両方を病みます。実際、わたしも何度か病みかけました。仕事を辞めたらまず病院通いしないと、と思っていた症状が、辞めた翌日に全快した時には、人間の身体ってスゴイ、と思いましたよ。

　プログラマという仕事が嫌いじゃなかったので、それを続けていたわたしでしたが、35くらいになってようやくこれを一生の仕事にしようと決意しました。キャリアプランは若いうちに立てておけ、とよく言われていますが、わたしは完全に出遅れていました。

　しかし、決意したのはいいものの、1つ不安がありました。

　ある程度この業界で仕事をすれば、プログラマのままでいる、ということが意外に困難だということは誰にだってわかります。いわゆる「プログラマ軽視」の考え方ですね。人によっては「プログラマ蔑視」くらいまでいってるんじゃないかと思います。

　35にもなって「プログラマ止まり」というのは、能力もしくは人格になんらかの問題を抱えているに違いない、という思い込みを持っている人たちは、わたしなんか相手にしません。そこまでいかなくても、無駄に年だけ重ねてるプログラマなんじゃないか？という疑いを持つくらいのことは、普通のマネージャだってするでしょう。正直いって、年くってるのに仕事ができない人、って相当扱いづらいですからね。

　とすると、仕事ができる人、と相手に思わせないと、派遣として仕事を続けるのは大変なんじゃないんだろうか？ではどうすればいいかと考えた時、ふと思いついたわけです。

　「SEなんかもったいなくてやらせられない」と思わせるくらい、プログラマとしてのスキルを積み上げればいいじゃん！

　実に単純な考えです（笑）。でも、それ以外の答えはないと思ったので、手始めに言語の幅を広げることにしました。プログラマの仕事は言語指定ですから、言語を1つでも多くマスターすれば、それだけ仕事の口が広がります。それに「がんばります。まだまだやれます」と言っても簡単には信用してもらえません（わたしだったら信用しません）。

　35を過ぎても新しい言語を覚えている、という事実が経歴書に書き込まれていれば、この人は新しい技術を覚える能力と気力を持っている、と判断してもらえるんじゃないかと考えたんです。

　というわけで、知らない言語の仕事もにっこり笑って引き受けるようになりました。たいていの人は経験のない言語の仕事をしたがらないので、わたしがどの言語の仕事もあっさり引き受けるようになったら、プログラマのやりくりに四苦八苦しているマネージャは、喜んでいろんな仕事を持ち込んできました（0.5人月分くらいの細切れ仕事のために経験者をひっぱってくるのは大変らしいです）。

　慣れない言語で締め切りに追いまくられるのは精神的にかなりハードでしたけど、新しい言語を覚えること自体は楽しかったので、なんとか乗り切りました。

　そんなこんなで40になった時に、正社員になるための活動を始めました。いろいろとありまして、派遣社員のままだとこれから先は厳しいと思ったんですね。職探しをする前に、会社の規模も形態も一切気にしない。プログラマを続けさせてもらえるならどこにでも行こう、と決めました。

　「プログラマ止まり」ルートの一点狙いですよ。あちこちに経歴書を出しまくりました。業務経験のない組み込み系にまで出しましたからね。ホントに手当たり次第でした。

　しかし、40になってもリーダー経験ゼロの経歴書が悪かったのか、「定年までプログラマとして働かせろ」（←さすがにもうちょっとボカしてましたけど）と書いたエントリシートが悪かったのか、はたまた別の問題か、書類選考ではじかれまくりました。

　でも、わたし自身はそんなにへこたれてませんでした。

　いくらなんでもこの業界がそんなに一様であるわけがない。プログラマを大事な資産と考える会社が絶対にあるはずだ。

　わたしはそう信じていたので、あせらずいつまででも探し続ければいいだけだ、派遣で生活できてるんだから問題はない、とものすごく簡単に考えていました。

　そんな就職活動の結果、入社して今も勤めている会社は、わたしが入社した当時、社長を含めて全部で3人でした。わたしが4人目です。今はもうちょっと増えてますけど。

　面接の時に、定年までプログラマとして働かせてもらうことが入社の条件だ、としつこくアピールしたところ、社長がそれを快諾してくれたので入社を決めました。社長はわたしの「どのチームでも一番コード量が多くて、一番残業時間が少なかった」という言葉で採用を決意したそうです。そこんところをエントリシートに書いておけば、他の会社も釣れたかもしれない（笑）。

　ちなみに、会社の主要言語はVisual Basicで、当時のわたしは未経験だったんですが、「Visual C++とExcel VBAができるんならすぐにできるようになるだろう」と判断してもらえました。両方とも35を過ぎてから会得した言語なので、言語拡大戦略は間違っていなかったようです。

　「プログラマ止まり」と言われますけど、プログラマに止まっている余裕はありません。新しい言語は次から次へと現れるし、せっかく覚えた言語はちょっと目を離した隙に改訂されて別物になっちゃうか廃れるかだし、仕様変更とバグの襲来はやむことがありません。

　そんなものたちと定年まで格闘し続ける覚悟があって、プログラマであり続けることを望むのなら、必死で「プログラマ止まり」のルートを探してください。

　プログラマでい続けるキャリアパスがない、なんてことはありません。見えにくいことは確かですけど。

【IT記事転載】プログラマで、生きている - 職場と言語を流浪して四半世紀

2009-09-24T17:32:00.001+09:00

転載http://el.jibun.atmarkit.co.jp/hidemi/2009/05/post-9527-1.html

　はじめまして、ひでみと申します。プログラマやってます。

　エンジニアライフのコラムニスト様たちのコラムを読んでいたら、突然「わたしも書きたいかも！」とか思い立ち、そのまんまの勢いでコラムニストに申し込んでしまいました。思いつきと勘だけで生き延びている女です。

　更新ペースはだいぶのんびりめになると思いますが、よろしければおつきあいくださいませ。

　今回、お初なんで経歴なんぞを書いてみることにしました。ちゃんと書くと長くなりすぎますので、とりあえずプログラミング言語遍歴を中心に……。

　高校3年になって、いよいよ将来のことを真剣に考えなければいけないことになった時に、「コンピュータ業界に入る」と決めて専門学校に入りました。

　コンピュータに興味があった、なんてことはまったくなかったです。専門学校に入るまでコンピュータの類に触ったことがなかったので、好きも嫌いもあったもんじゃありません。

　周囲にコンピュータに関わっている人も皆無で、予備知識ゼロでこの世界に突入しました。知ってるコンピュータの名前は「HAL」（from 『2001年宇宙の旅』）だけ（←実在しないです。念のため）。専門学校の入学案内書を読むまでコンピュータなどというものはどこかの研究所かSFの世界にしか存在しないと本気で思ってた、ぐらいの状態でこの業界に飛び込んだわたしはかなりなチャレンジャーだった……。

　専門学校に2年通ってFORTRANを覚え、卒業後はFORTRANの仕事をしつつ、当時はプログラマの基礎教養と言われていた BASIC（←Visual Basicにあらず）を覚え、その後「FORTRANの仕事が少なくなってきたから」とか言われてC言語を覚えさせられました。

　で、プログラマとしてそこそこ使える人になってきたかな～と自信がつきだした頃、いろいろとトラブルがあって会社を辞めました。その後、オペレータ的な仕事とヘルプデスク的な仕事をやってみたんですけど、両方とも数カ月で辞めるという惨事に。

　1年の間に3回も退職するというなかなかハードな現実に直面し、3カ月くらい半ひきこもり状態になったんですけど、さすがにそのままだと生活できなくなるので、派遣社員としてプログラマ職に復帰しました。

　それ以降、現在に至るまで、プログラマの仕事しかやっていません。

　派遣社員になってからはずっとC言語で仕事をしていたんですけど、ある日、いきなりC++のプロジェクトに放り込まれました（C++の存在そのものも知らなかったのに！）。

　最初は「オブジェクト指向」という、それまでになかった概念の理解にかなり苦労したんですけど、一度納得してみたらC++はとてもおもしろい言語で、コードを書くのがめちゃめちゃ楽しくなっちゃって、コーディングが「仕事」から「趣味」にシフトしてしまいました。できるだけ長いことこの仕事を続けていきたいなあ、と本気で思い始めたのはこの頃です。

　そんなC++耽溺時代（？）に、JSPのプロジェクトのテストを手伝う機会があり、Web言語に興味が出たので、遊びでHTML/JavaScriptを覚えました。

　それでもやっぱり本妻さんはC++よね～とか思っていたんですが、ある日、課長と課長代理と主任が3人そろって「Javaを覚えてくれないか」とか言い出し、わたしは「この歳になって新しい言語を覚えるのイヤです～」と言って断りました。派遣社員なのに役職付きの正社員の依頼を断るあたり、我ながら強気だったなあ（苦笑）。

　わたしはC++より美しい言語はないと固く信じていたので、他の言語にうつるのがイヤだったし、先輩方から「プログラマ35歳定年説」なんて言葉を聞いて育ったもので、その「定年」の歳になって新しい言語を覚える気力がなかったんですよ。

　とはいっても、上の方々に逆らい続ける気力もなかったので、しかたなくJavaの勉強を始めたところ、ちょっとてこずりはしたものの、仕事で使えるレベルになんとかこぎつけました。

　この一件は、まだまだプログラマのままで働いていける、という自信をわたしに与えてくれました。目指せ、定年までプログラマ！（笑）

　Javaをマスターして以降、新しい言語を覚えることが楽しくなったわたしは、頼まれたらどんな言語でも引き受ける！という姿勢にシフトし、5年くらいの間に、Python、Excel VBA、Visual C++、SQL、JSP/Servletを覚えました。

　なんかもう完全なよろずやです。しまいには1つのプロジェクトで5つの言語を使う、なんていうわけの分からないことになってました（便利に使われすぎだよ、自分）。

　職場と言語を流浪し続け、今の会社に正社員として雇われたのは3年くらい前です。入社してからVisual Basic、ASP、ASP.NETが使えるようになり、現在はVisual Basic三昧な日々を送っています。

　そんなこんなで、18歳で専門学校に入ってから、気づけば四半世紀、コンピュータと付き合っているわけで……はしょりまくって経歴を書いたつもりなのにこんだけ長くなるわけです。

　就職した時に「男女雇用機会均等法第一世代」と呼ばれたんですけど、今や「アラフォー世代」とか呼ばれるらしいですよ。なんだかなあ。ちなみにバブルに浮かれていた記憶はさっぱりありません。どうやら、デスマーチをしている間に通り過ぎていたらしいです（泣）。

　夢とか希望とか目的とかがあったわけじゃなく、消去を繰り返したら残ってた、という理由だけで選んだ職業です。何度も辞めようと思って、「ちょっと待て、今さら他の仕事で今以上に稼げるか？」と考えて思いとどまるということを繰り返してきました。

　それでも、今のわたしはプログラマという仕事が大好きです（なんだか小学生の作文っぽい）。

　これまで、与えられた仕様をプログラミングするだけの仕事を、ひたすら続けてきました。

　これからも、それだけの仕事で生き延びていくつもりです。

　今のところは、ね。

【ＩＴ記事転載】下流から見たIT業界 - プログラミングはコミュニケーションだ

2009-09-24T17:25:00.000+09:00

転載http://el.jibun.atmarkit.co.jp/karyu/2008/11/post-b93a.html

　この業界で長年仕事をしていると、ほれぼれするようなソースコードを見ることがあります。

　JR系列のSIerに呼ばれて、とある業界団体が管理する観光スポット紹介サイトの改修を手がけたことがあります。PC用、携帯用のページはすでにあるから、それに加えてPDA用のページを作るというプロジェクトでした。面白みのない地味な印象のサイトでしたが、ソース解析を進めていくと、なかなか面白い仕組みになっているのがわかってきました。ブラウザからのリクエストが全部同じURLへ集まるようになっているのです。そのURLで呼び出される Servletが、要求されたページの種類ごとに別のURLにディスパッチするようにできている。

　これは有効な方法だと直感できました。まずなんといってもサーバ側のクラスが構造化されます。画面の要求する機能とは別の論理でクラスを構成することができる。それにサイトのURLを一元的に管理できます。ブラウザがアクセスする窓口が一箇所に絞られるのですから、リクエストを管理しやすい。セキュリティの面でも有効である。つまり今で言うところのMVCパターンで作られていたのです。まだStrutsが一般に知られる前でした。Javaの WebアプリケーションがJSPコードをHTMLの間にソースコードを埋め込むという形で作られるのが一般的だった時代です。これは勉強になる仕事だと思いました。

　しかしこのプロジェクトは突然打ち切りになってしまいました。きっとPDA用のページを作っても誰も読みに来ないだろうと判断されてしまったのでしょう。惜しかったけれど、結果的には私にとって勉強しただけ得になりました。ソースにはPGの名前と作成した会社の名前が記されてありましたので、いつか一緒に仕事をしてみたいなと思って会社名を手帳に控えておきました（いまだにそういう機会はありませんが）。ネットで調べると、横浜にある会社です。もしかしたらJR系の会社かもしれません。そうだとしたら、さすがはJR、グループ企業まで技術レベルが高い。

　こんな思い出話から始めたのは、べつにJRをヨイショすることが目的ではありません。この時のソースコードからは、それ以上に重要なことが読み取れたからです。

●プログラミング作業はチームワーク

　MVCパターンは、サイトで使うJavaクラス全体の大枠となるパターンです。これを採用しているということは、プログラミング作業の前に各PG がこのパターンの有効性を納得し、それに合わせて各クラスを実装したということを意味しています。つまりこのソースはPGの綿密な連携作業によって作られたということです。

　それまでプログラミング作業は個人技の世界でした。COBOLでは原則的にSEが仕様を切り分けました。切り分けられたモジュールは完全に独立した世界ですので、PGはプログラムを他人と共同して作るということはありません。C言語では1個のソースからは1個のプロセスが生まれるので、ほぼ完全な独立性を持っています。これを分けてプログラムするのはけっこう難しいことで、1人で作りこむには大変だからといって、作業を分担することはあまりしません。VBアプリケーションは断片化したソースコードが複雑に絡み合っているので、これも作業を分担するのはなかなかに難しい。そのためC言語やVBの開発では、特定のPGに過重な負担がかかって、工程が遅れるということが頻繁にありました。

　ところがJavaはインターフェイスを境にPGの作業をあらかじめ分担しておくことができます。そうすることで得られるメリットは計り知れなく大きい。

●インターフェイス概論

　ここでJavaを知らない人のために「インターフェイス」の説明をしておきましょう。Javaのソースコードは「クラス」と呼ばれる単位に分けて書かれます。クラスには「メソッド」が定義され、その中にそのクラスが持つ機能を具体的にコーディングします。実際にプログラムが作動するときは、このクラスをもとにメモリ空間にインスタンスを必要な数だけ作る、これがコンピュータを動かす実態になるわけです。インターフェイスはメソッドだけ定義したクラスのようなものです。これを使うときには、このインターフェイスをもとにしてクラスを作って動かします。

　いわばインターフェイスとは、形だけ作った中身のないクラスのようなものです。こんなものがどうして必要なのか疑問に思われる方も多いかもしれません。わたしも始めのうちはどのように使えばいいかわかりませんでした。それがようやく理解できたのは、Javaの仕事をするようになって1、2年してからでしょうか。

　インターフェイスとは要するに「接合面」なのです。ロボットを開発するとします。胴体と腕を分担して開発することになりました。まず最初にすることは何でしょうか。接合面の設計です。接合部分の形、寸法、信号端子の種類、電圧、信号体系等々。これらをあらかじめ決めておけば、胴体を作るチームと腕を作るチームは、互いに相手のことを知らなくてもそれぞれの部分の開発に専念することができます。また接合面の規格を守っていれば、別の腕を付け替えることもできる。合体ロボットのように次々とアイテムを変更することも可能です。すなわちインターフェイスは部品を規格化するのです。これを有効的に使うことで大規模システムは整理され、分担して作りやすくなりますし、開発後のメンテナンスも容易になります。

　ですから大規模なシステムでは、何よりも先にインターフェイスを設計することが重要なのです。開発が進んでからでは、インターフェイスを適用するのは極めて困難です。あらかじめ全体の構成を見渡し、規格化できるパターンがあったら、そこにインターフェイスを作っておく。そうすれば複雑なシステム全体が部分部分に分けやすくなり、ロジック自体がパターン化されて、コーディングの量自体も減ります。できれば基本設計の段階でインターフェイスを決めておきたいところなのですが、このことについては十分理解されているとはいえないのが現状です。

●コミュニケーションの必要性

　話題をもとに戻しましょう。実装作業の分担の話でした。個人で作ることができる機能はおのずから限界があります。機能の規模が大きくなればなるほどバグの数は増えていきます。ですから1つの機能を分担して作ることは、大規模アプリケーションを作るときの必須の条件なのです。さらに開発の状況に合わせて人的資源を機動的に使うことができるようになる。ユーザーの気まぐれで急な仕様変更があっても、柔軟に対応できる。すなわちJavaにおいてはプログラミングとは個人技ではなく、綿密なチームワークを必要とする共同作業に変わったのです。

　私がこれまでの開発経験から考える理想的なシステム開発の現場は次のようなものです。5人から10人までのPGがチームを組み、机を並べている。そばにはいつでも使える会議スペースがあり、ホワイトボードが用意されている。開発が始まると、まずクラス構成を綿密に打ち合わせる。ホワイトボードに絵を描きながら、ああでもないこうでもないを繰り返し、やがて総員納得の上で全体のクラス構成を決定し、実装の技量にそってコーディングを分担する。コーディングが始まっても、いつでも必要があればすぐチームミーティングを持つ。システムの変更事項はそこで周知徹底する。こんな開発体制を組めたなら、どんな大規模システムの実装が来てもこわくはありません。

●開発の現状は

　しかしWebアプリケーション開発の現場は、たいていの場合これとはほど遠い現状にあります。PGはたいてい別の会社から呼ばれてきて、互いに交流はありません。配属された先のSEのいうことを聞かなければならないことになっています。PG同士でミーティングを持ったりすると、何かと誤解されます。またPGは個人で仕事をすることが多く、共同して仕事をするという経験が少ないので、他人の意見を積極的に聞こうということもありませんから、その仕事はなおさら孤立したものになります。

　頻繁にミーティングを開いて打ち合わせをするのはSEさんたちですが、プログラミングをあまり知らないSEは、ユーザーの要求を実装者に伝えるだけの単なる「御用聞き」になってしまいがちです。業務の内容に合わせてクラスを設計するなどという高等技術は身についていません。ミーティングは、プロジェクトマネージャから進捗を問いただされ、仕様変更があったことを上意下達的に言い渡されるだけの場になっています。クラス構成を話し合うとか、さっきも触れたインターフェイスを作るとか、テストプランを練るとか、そういったソースコードの品質にかかわる話し合いが行われることはほとんどありません。このような体制で作られるプログラムがオブジェクト指向であるわけはありません。画面からのリクエストごとに1メソッドが動き、そのメソッドに一切合財の機能を盛り込んでしまう、ということになります。

●ウォーターフォール型開発とアジャイル開発

　これまで大規模なソフトウェアが作られる場合、基本設計で大まかなことを決め、機能をいくつかのブロックに分け、細分化するごとに仕様の詳細を決めていくというトップダウンの設計手法がとられてきました。水が下に流れるように設計が進められるということから、これをウォーターフォール型の設計といいます。細分化されたプログラムが相互に関連を持つことがあまりないCOBOLのようなシステムならこれは有効です。しかしオブジェクト指向のJavaはそういうわけにはいきません。これではクラス設計をするPG（あるいはSE）のところに来る前に仕様が断片的になってしまいます。設計者がその能力を持っていても、これでは実力の振るいようがありません。

　ウォーターフォール型の開発がJavaに向かないことは、すでにだいぶ昔から指摘されてきたことです。アメリカではその反省から、PG相互のコミュニケーションを密接にし、開発のスパンを短く繰り返すことで、実装者とユーザーの距離を短くし、ユーザーの気まぐれな要求変更に対応しようという手法が開発されました。これをアジャイル開発といいます。この開発方法の有効性はすでに実証されています。にもかかわらず日本ではこの開発手法が行われることはめったにありません。

　その理由はよくわかりませんが、次のようなことが考えられます。まず日本のユーザーにはドキュメント信仰があります。ソフトウェアはただでさえブラックボックスになりやすく、ブラックボックスになったら最後、改修も再利用もできなくなると信じられています。だからドキュメントはできるだけ詳細に残してもらいたい。アジャイル開発ではどうしてもドキュメントは軽視される傾向にありますので、ユーザーには不評なのかもしれません。

　しかし実際には、詳細すぎる設計書などシステム開発では無用の長物。ソースコードさえきちんと管理されて残っているなら、そのシステムはブラックボックスでもなんでもないし、きちんとしたスキルのある技術者を呼べば、システムは必ず生き返ります（問題はその様な技術者をどうやって調達するかということになります）。

　もう1つは、アジャイル開発は「管理しにくい」と思われているからではないでしょうか。アジャイル開発は、開発技術者が直接ユーザーから要望を聞いたり、技術者同士で頻繁にミーティングを行います。現場から遠ざかって技術に疎くなったPMは、これらのミーティングを仕切りきれません。設計会議から疎外された管理者は「下っ端が集まって造反をたくらんでいるのでは」と不安になりがちです。ましてやアジャイル開発で鍵を握るのは、これまで冷遇してきたプログラマ、会社では要らないからできるだけ外注で調達してきた職種です。自社の請負業務が全部外注の人間で決定されるとなったなら、おもしろかろうはずがない。

●大事なのはコミュニケーション

　別にアジャイル開発を導入しなければならないというのではありません。プログラミングで重要なのはコミュニケーションです。PGは端末に向かって黙々とコーディングとバグ取りをしていればいいというのは昔の話です。理想的なプログラミングは、ちょっとコーディングをしていたかと思うと、立ったり座ったり、同僚と話をしたり、はた目から見ると、まるでまじめに仕事をしていないかと思われるかもしれません。しかし実際には彼らは仕事の上で重要な情報やアイデアの交換をしているのです。こうしてコミュニケートすることで、仕様に対する誤解を修正し、設計過程で見逃した不整合を見つけやすくなります。また、自分のソースコードに対して他人の批評を受けることで、わかりやすく利用性の高いコードが作られていきます。他人と話し合うことで新しい発想も生まれてくる。解けなかった問題が解けてしまう。まるで大学のセミナールームか、工業高校の実習室のような雰囲気、それこそが高い生産性を実現する作業環境なのです。Javaのようなオブジェクト指向言語では、他人が作ったソースコードをいかに有効に利用することができるかが生産性向上の鍵になります。プログラムのような形のないものを相互に利用し合うには、このような気軽で親密なコミュニケーションのできる環境、人間関係が何よりも必要なのです。

　まあ、実際このような開発をしたことがあるわけではありません。日本のソフトウェア開発現場は、さきほども述べたように、このような雰囲気とは対極的な環境にあります。だだっ広い部屋の一角に端末がところ狭しと並べられ（最近は机1つさえ満足に与えてもらえません。折りたたみテーブルにいくつも端末だけ置いて、ほとんど肘を突っつきあうような場所で何カ月も作業させられます）、それぞれ別の会社から派遣されたPGが、それぞれ隣の人の名前も知らずに（ときどき隣の人は日本語を話せないこともある）、与えられた仕様書を黙々と実装しているだけ。こんなタコ部屋現場が多いのではないでしょうか。

　プログラミングの現場でコミュニケーションが足りないのは、もちろんSIerの管理方法にだけ原因があるわけではありません。技術者の方にも責任があります。概して腕のいい技術者ほど寡黙なものです。口を動かすより手を動かして、自分で結果を出すのに夢中になるので、チームワークをおろそかにしがちです。それに熟練したPGは独学でスキルを身につけてきた場合が多く、教えたがりなわりには、進んで他人と情報交換をしようとしない。その点では学校でプログラミングを勉強してきた人間が多いアメリカとは土壌が違うのです。日本のPGがいきなりアジャイルな開発環境に放り込まれても、きっととまどうばかりでしょう。

●もっとおしゃべりしましょう

　このような現状を変えていくのは、やはり管理者の責任であり、年配者のつとめでしょう。プログラミング作業でのコミュニケーションの重要性は、アジャイル開発、ウォーターフォール型開発にかかわらず有効です。このコラムをお読みのあなたがPMならば、毎日ミーティングを開くばかりでなく、頻繁に PGの肩を叩いて声をかけてあげてください。最初は内心いやがられるかもしれません。しかし相手が自分の仕事の内容に親身になって関心を持ってくれているのだとわかれば、やがて態度は変わってきます。声をかけるときは単に進捗ばかりに関心を持ってはいけません。プログラムの中身についても突っ込みを入れてみましょう。未熟なPGなら足りない部分を指導してあげてください。優秀なPGならたいてい自分の作品について自慢したいところを持っていますので、そこをほめてあげてください。また、彼らはプロジェクトについていいアイデアを持っていたりします。それを会議の場では言い出せずにだまっていたりします。それを吸い上げるのにもいい機会です（もちろんこれらのためにはPMがプログラミングについて熟知していなければならないのですが）。とにかく重要なことは、少しでもコミュニケーションの頻度を上げることです。

　コミュニケーションが増えれば、必ずプロジェクトにプラスになります。一見むだ話に見えるかもしれませんが、それが目に見えないところで効果を持ってくるのです。過去に失敗したプロジェクトのことを思い出してください。それは開発者全員が押し黙り、互いに背を向け合ったような、沈滞したプロジェクトではありませんでしたか？メンバーが死人のように口をきかず破滅に向かって進んでしまうので「デスマーチ」というのです（ちょっとちがうかも？）。

　若いPGの皆さん。もっとおしゃべりしましょう。ひとりで黙々と開発する時代は終わりました。わからないことは積極的に他人に質問しましょう。知っていいる人はたいてい教えてくれます。教えてくれないのは、答えを知らないからです。IT業界は技術革新が早いので、知識が古びるのも早い。ですから知っている人は、その知識が古びないうちに教えなければ結局、損をします。だから技術者はたいてい「教えたがり」です。そしていつか自分が質問される立場になったら、こころよく教えてあげてください。そんな小さな心掛けが、やがては業界を変えていく力になるかもしれないのです。

【ＩＴ記事転載】下流から見たIT業界 - 反アウトソーシング

2009-09-24T17:24:00.000+09:00

転載http://el.jibun.atmarkit.co.jp/karyu/2008/10/post-8428.html

●わたしと派遣業

　わたしはこの業界で20数年働いていますが、派遣と外注はどの会社でも一般的に行われていました。最初に入った会社の最初に配属された部署では、開発作業に携わっていた人の半数以上は外部から派遣されてきた人たちでした。明らかにプロパーの社員より技量が上で、開発の主力は派遣技術者が担っていました。給与や福利厚生の面では当然差があったわけですが、管理者もこれら派遣技術者は丁重に扱っていましたし、仕事の上ではほとんど外注もプロパーも区別されていなかったといっていいでしょう。

　にもかかわらず、わたしはこれら派遣技術者という身分には偏見を持っていました。当時「プログラマ35歳定年説」というものが噂されていました。派遣労働に支払われる契約料は一定で低く抑えられているので、年齢が上がって給料が上がっていくと派遣会社はその従業員の給与を支払うことができなくなって、会社を辞めさせられるというものです。この説を真に受けていたわけではありませんが、派遣社員という身分は何かと不利なように思えて、最初の会社を辞めた後もずっとプロパー社員で働けることにこだわっていました。

　契約社員で派遣されて働くようになったのは、30歳過ぎてからでした。いざそうなってみると、肩の荷が落ちて、さっぱりしたような感じがしたものです。まず何といっても仕事に集中できるようになりました。電話を取らなくなりましたし、その他の有象無象の雑用から解放されました。ある程度仕事を選ぶこともできましたので、キャリアも自分で組み立てることができるようになりました。わたしはCOBOLからBasic、C言語、VB、Javaの順で言語を乗り換えてきましたが、こんなことも正社員で雇われていたら難しかったことでしょう。いまでは何であんなことにこだわっていたのだろうかと思います（注1）。

●アウトソーシングは正しい戦略か？

　派遣の仕事にもいろいろあるでしょうが、少なくともシステム開発では、派遣は必ずしも不利な労働ではありません。この仕事は専門性が高く、技能が高度に規格化されていますので、一定のスキルのある技術者はどの職場に行っても即戦力として通用します（少なくとも実装作業の場合）。また、その業績が派遣先で正当に評価されれば、気持ちよく働くことができます。技術革新のスピードが速いため、絶えずキャッチアップのための努力をする必要がありますが、その自信さえあれば、わたしのように何の後ろ盾もない個人事業主でも、それ相応の年収を稼ぐことができます。

　しかし、2000年ころからでしょうか、この業界の状況が変わってきました。わたしがこれまでこのコラムで書いてきたように、技術自体は日進月歩で進歩しているのに、それが現場の生産性に結びつかなくなってきたのです。大量のマンパワーがむなしく費やされ、技術者への負担は「3K」とまでいわれるようになっている。業界の技術は空洞化し、資源が偏って配分され、技術に対する軽薄な侮りと忌避が蔓延（まんえん）しています。

　どうしてこんな状態になったのでしょう。わたしはこれまで「下流」の位置から、つまり現場の作業のやり方や管理方法からこれらの構造的問題を説き起こしてきました。前回は SE／PG分業からソフトウェア開発作業の現状を分析しました。もちろん、この分業をなくせば問題がすぐ解決する、というわけではありません。原因は SIerが業務の一部、あるいは全部を外注するという経営方針を採っていることにあるのであって、SE／PG分業は業務を外注する範囲の目安として使われていたにすぎません。現在ではPGはおろかSEですら、建設作業員のようにプロジェクトごとにかき集められるのが普通になっています。SIerはなぜ業務を外注するのでしょう。このことを根本的に考え直さなければ、IT業界の技術空洞化の問題は解決できません。

　しかし、このような意見には強硬な反対論があります。IT業界の多重請負構造は、アウトソーシングを活用した経営戦略として有効かつ必要なものであって、IT業界には必然的な産業形態であるとする意見です。コンサルタントは、これに賛同する方が多いようですが、はたしてアウトソーシングはIT企業には必要不可欠な戦略なのでしょうか。そもそも経営戦略として継続できるものなのでしょうか。今回はこのことに焦点を当てて考えてみたいと思います。

●アウトソーシングを流行らせたのは？

　「IT」という言葉と同様に、「アウトソーシング」という言葉も最近になって使われ始めたものです。いったい誰が使い始めたのでしょう。断言はできませんが、どうやら1990年代後半に旧通産省官僚が、アメリカの産業構造の変化を手本にして、日本の経済競争力の増強を図るため使い出した言葉のようです。

　近くの区立図書館で「アウトソーシングの時代」（注2）という本を見つけました。編著者はわたしと同じ1959年生まれの、旧通産省のお役人さんです。この本はアウトソーシングの啓蒙書として書かれていて、その主張するところは、およそ次のようなものです。

　日本の企業のアウトソーシングはおもにコスト削減などを目的とし、外注先もグループ企業に限るなど、消極的で身内優先なものにとどまっている。このため、アウトソーシングを利用して効率化するという面ではその効果は限定的なものにとどまっている。これに対してアメリカなどのアウトソーシング先進国では、自社の経営資源を本業に集中するために積極的に社外のサービスを利用し、外部委託を戦略的に利用して新規事業に果敢に乗り出すなどの「攻めの経営」が根付いている。このままでは日本の企業は、やがて経営資源の活用の点でアメリカに遅れをとり、大競争時代を生き残れないであろう。

　こうした主張の上で、著者はアウトソーシングの利用を3つの段階に分けて説明します。まず第1段階はコスト削減を目的とした短期的利益の追求として始められます。例えば、給与計算業務や福利厚生施設の運営など。わたしたちの情報システム部門も、この目的で外部委託されるようになりました。それがやがてアウトソーサーの専門性を吸収して自社の業務に活用するようになる。これが第2段階。第3段階になると、外部の専門性を積極的に活用して新規事業に乗り出すようになる。この段階の企業戦略は利益の追求ではなく、創造性追求型となり、発注側と受注側の間にはよりいっそう緊密な戦略的提携関係が構築されることになるだろう、とのことです。

　いかにも旧通産省の官僚さんらしい考え方です。先進的で、頭がよくて、理想主義的で、大所高所からの視点で、あるべき産業界の姿を分かりやすく生き生きと描いてみせる。そして悲しいかな、全体が見えていない。そのため常識的なことを見落としています。落ちついて考えてみればすぐ分かることです。アウトソースされた業務はいったい誰が担うのでしょう。

●アウトソーシングを基本から考える

　企業はなぜ自社の業務を外部に委託するのでしょうか。例えば、会社のトイレ掃除は社員にやらせません。外部の清掃会社に委託します。これは、人件費の高い自社社員にそんな雑用をさせるのは不経済だからです。それならばSIerはなぜPG作業をアウトソーシングするのでしょう。プログラミングは雑用ではありませんし、単純労働でもありません。この答えは前々回簡単にご説明しましたが、もう一度詳細に考えてみましょう。

　まずこちらのページを見てください。こちらに書かれているのはCVP（Cost Volume Profit）図といって、企業の利益設計をする上で基本中の基本となるグラフです。変動費で代表的なのは材料費、固定費を代表するのは工場などの設備費ですが、人件費も後者として扱います。見慣れない人には少々分かりにくいのですが、企業活動が得になるか損になるかの分かれ目である「損益分岐点」が、経費に占める変動費と固定費の割合で変わることはお分かりいただけると思います。固定費の割合が大きい「工場生産型」の事業では、売り上げが伸びた場合の利益が大きいけれど、損益分岐点は高く、売り上げが伸びない場合の固定費の負担が大きい。一方「アウトソーシング型」の事業では、損益分岐点が低いので比較的小さな売り上げでも利益が出ますが、売り上げが伸びても利は薄い。いわば前者はハイリスク･ハイリターン型、後者は安全経営型といえます。このため、コンサルタントは企業に経営の安定化を図るために、アウトソーシングを勧めるわけです。なかでも情報処理業務はその代表選手で、わたしたちIT業界がおまんまを食べられるのも、コンサルタントの方々があちこちでコンピュータ業務のアウトソーシングを薦めてくれるからにほかなりません。

●アウトソーシングの果てに、100年前に逆戻り

　しかし、ちょっと考えてみてください。一般顧客がコンピュータ業務をアウトソーシングするのは分かります。しかしその外注を受ける側、SIerが生産をアウトソーシングしたらいったいどうなるでしょう。元請けは下請けに外注します。下請けもまたその下請けに発注する。企業規模が小さければ小さいほど安定経営を志向するものです。そうしてツケを回していく果てに、固定費を実際に負担してプログラムを作るのはいったい誰になるのでしょう。究極の下請け業者、すなわち契約社員、派遣労働者なのです。

　これこそがいまIT業界で――いや、IT業界に限らず日本の産業界全般で起こっていることなのです。企業は正社員を減らして契約社員を雇う、あるいは派遣業者から人員を派遣してもらう。これは企業にとっては固定費を減らして経営を安定させるのに役立つでしょう。しかし、これは単に売り上げの増減によって生じるリスクを労働者に転嫁しているだけです。労働者は原理的にアウトソーシングすることはできない（生活費は究極の固定費です）わけですから、このリスクから逃れることはできません。すなわち、仕事が忙しいときには死ぬほど働かされて（場合によっては残業代が出ないこともあります）、仕事がなくなったらすぐクビになる。景況の波を一番弱い立場の労働者が直接かぶってしまう。今日の雇用問題の大部分がここにあるのです。

　その昔、産業革命が起こったばかりの資本主義経済の初期には、工場労働者が同じ立場に置かれて悲惨な生活を強いられました。当時は12時間労働が一般的で、文字通り夜明けと同時にたたき起こされ、日が沈むまで働かされたのです。仕事がなくなると容赦なく馘首（かくしゅ）されました。これらの悲惨な状況を改善しようとして、血みどろの労働運動や階級闘争を経て、労働法が制定され、行政によって労働者が保護されるようになったわけです。ところが 1980年ごろから、いわゆる「規制緩和」「構造改革」の名のもとにさまざまな修正が加えられて、次第に骨抜きになってきました。「社会のニーズに合わせて制度を柔軟に運用する」という名目で、1日8時間の労働という原則も崩されています。それどころか「サービス残業」などという違法行為まで横行している。まるで100年前に戻ってしまったかのようです。

　アウトソーシングがその本来の目的にではなく、派遣労働と結びついて労働者保護制度の抜け穴に使われていることが明らかです。件の旧通産省のお役人さんには、このことが予想できなかったのでしょうか。概してお役人さんは考え方がタコツボ的で、自分の属するセクション以外のことは見えないとよくいわれますが、それはこのアウトソーシング論にも当てはまるでしょう。アウトソーシング論それ自体はいかにも立派な議論かもしれませんが、一般勤労者のことはまるで考えられていません。まるでそれは他省の管轄だからどうでもいいといわんばかりです。お役人さんには全体が見えているようでいて、実際にはぜんぜん見えていないのです。

●「三丁目の夕日」

　彼らが見落としていたことは他にもあります。それは、彼らが槍玉に挙げる日本的経営の閉鎖性、グループ企業内で受注しあう身内主義的傾向にも、経済構造として一定の合理性があったということです。

　かつては日本にも「町工場」というものがいたるところにありました。今も住宅街に工場が隣接しているところはありますが、昔に比べるとずっと少なくなっています。映画「三丁目の夕日」にそのころの街の風景が再現されていますね。当時は全国に零細企業が無数にあって、大企業から注文を請けて生業を立てていました。日本の産業は少数の大企業と、無数の中小企業に二極分化していて問題であると、社会科の時間に習ったものです。これらの町工場は従業員を雇い入れ、高価な機械設備などを負担していたのですから、相当ハイリスクなビジネスをしていたわけです。平気だったのでしょうか。

　平気だったのでしょうね。こういった町工場の経営者の多くが職人上がりだったと思われます。職人は熟練労働者ですから、けっこう安定した身分だった（注3）のですが、それでも一部の職人は金をためて自分の工場を持ちました。それは、そのことが「出世」であるばかりではありません。売り上げが上がれば、利の厚い、儲かる商売だったからでしょう。大企業は豊富な資金力によって新製品を開発し、常に新しい需要を開拓してくれます。その下請けをしていれば一定の売り上げは期待できます。売れることが確実ならば、「工場生産型」事業は魅力的な商売です。彼らはハイリスク・ハイリターンの事業をあえて引き受けました。彼らの気概のおかげで、大企業は固定費を削減することができ、職人は安定して仕事にありつけたのです。

　もちろん、こういった町工場の経営者はリスクに鈍感だったわけではありません。彼らは売り上げの変動を抑えるために、注文をくれる大企業の「子会社」になることで、親会社から安定して受注し、かつ親会社の信用を背景に銀行から融資を受けることができました。いわゆる「系列」の形成です。大手銀行が乗り出せば、信金や信組も寄ってくる。系列に食い込めない企業は、苦しいけれどいわゆる「町金」の高利融資で急場をしのぐ。中小企業の売り上げ増減のリスクは、大小の金融機関によって支えられたのです。こうしてこれら町工場の経営者の努力が日本の高度経済成長を下支えし、日本の技術力を世界的なブランドへと高めました。

●アウトソーシングの正体

　ところが1980年代から1990年代にかけて「規制緩和」が叫ばれはじめると、こうした日本的な経営が非難の的になりました。大企業中心の「系列」が日本の産業の高コスト体質を維持しているとされたのです。たしかに規制緩和のおかげで「価格破壊」が起きて物価は下がりました。しかしその代わり、深刻な雇用問題を抱え込むことになってしまいました。日本はアメリカの真似をして「アウトソーシング」を取り入れることで、閉鎖的な企業系列を破壊しましたが、同時に中小企業の安定受注の構造も壊してしまいました。

　本来なら金融機関がそれによって増えたリスクを支えるべきところでしょうが、折から起こったバブル崩壊による金融危機で銀行にはそのような余裕はありませんでしたし、元から不動産を担保にした融資による安定経営に慣れてきた銀行には、中小企業の小口融資を詳細にリスク査定する能力などなかったことでしょう。その結果「貸し渋り」や「貸しはがし」が横行しました。こうした中小企業の金融環境の悪化に対して行政的あるいは制度的な保護措置がとられてもよかったと思いますが、それさえもなかった。大手金融機関には破格の救済措置がなされたのに、中小の弱者には「自己責任」の原則が押し付けられたわけです。

　金融の支えをなくした中小企業は、設備投資を抑えられて技術革新から取り残され、発注会社の値引き圧力に抵抗できず、やむなく廃業するか、違法すれすれの外国人労働者を雇うか、人件費の安い海外生産にシフトすることを迫られました。その結果、日本の産業技術が空洞化し、製品の品質劣化を招き、食の安全まで脅かされるようになる。これが「アウトソーシング」の正体です。

●得をするのは誰？

　と、また少々挑発的な書き方をしてしまいました。

　アウトソーシングを喧伝した旧通産省のお役人さんたちには、もちろん日本の産業を空洞化させる意図はなかったでしょう。よしんばそのような懸念はあったにしても、日本の経済にはそれを補って余りある利益がもたらされると信じていたのでしょう。それは例えば、M&Aのような形で経営をドラスティックに転換させることで、経営の合理化を果たし、企業価値を高める――すなわち株価の上昇で実現される。株価が上がれば消費も増えて、それが景気を刺激して労働者の所得も上昇する。たぶんこのようなヴィジョンを描いていたのでしょう。

　しかし、わたしのような「下流」にいる人間からしてみると、これらの話は、現実からあまりにも迂遠な夢物語に思えます。企業の業務をレゴブロックのようにつけたりはずしたり、犬の子をやり取りするようにトレードしたりすることで、企業価値は果たして上がるものでしょうか。それは単なる市場の幻想であることを、わたしたちはITバブル崩壊やライブドア事件のときに痛感したのではなかったでしょうか。製品は誰かが作らなければ売ることはできないし、会社のトイレは誰かが掃除しなければならない。アウトソーシング推進論は、こんな単純なことをどこかに置き忘れてきた主張に思えます。

●こまった「市場」信仰

　さらにアウトソーシング論で問題なのは、市場原理の過大評価です。

　企業が自前で、あるいはグループ企業内で製品やサービスを調達する場合、そこには市場原理が働かず、コスト高になってしまう、それが消費者に転嫁されてしまうというのが、アウトソーシング推進論の論拠の1つです。ご存じのように、この理論は市場経済の価格決定作用を企業内部に持ち込んで、コストの適正化を図ろうという考え方です。その背景には、市場原理が発注する側にも受注する側にも公正公平で、合理的な価格を導き出してくれるという前提があるわけですが、そんなことは実際にはまずありえません。このことは下請け業者の立場で営業に歩いたことがある人ならば身をもって知っているはずです。

　アウトソーシングでは、発注する側と受注する側が対等の立場にあることは極めてまれです。価格の決定権は発注側にあるのが普通で、資金力のない受注業者は固定費の負担に堪えきれませんから、注文主の価格設定に従わざるを得ません。もしこれを対等にしようとするならば、受注側は資本を増強し、営業規模を拡大して銀行融資を呼び込み、マーケットシェアを獲得する必要があります。それからでなければ、対等の価格交渉には望めません。しかしそうすれば、この受注業者は巨大な固定費のリスクを抱え込むことになります。結局その業務をもっと小さな会社に丸投げすることになるでしょう。これでは間に余計な会社が 1つ入っただけで、状況は何一つ変わりません（注4）。このようにして、アウトソーシングは必ず「外注／下請け」の関係になります。「アウトソーシングの時代」の著者のいう「戦略的提携関係」が自然に形成されることは考えにくいのです。

●アウトソーシングで品質低下

　市場原理の過大評価はもう1つの弊害をもたらします。一企業の内部で物が生産される場合、その生産に必要な資源配分――すなわち予算配分は、直接の管理の下で評価されます。しかしアウトソーシングの場合、市場原理が働きますから、原価が正当に評価されない可能性がある。すなわち生産者に対する適切な資源配分が保障されないのです。受注業者は競争を勝ち抜くためなら何でもします。例えば見えないところで手抜きをして納品する。そうなっては大変だから、発注側は綿密なテストを行わなければならなくなる。そのテストに膨大なコストが発生する。これでは何のためのアウトソーシングか分かりません。

　市場原理は万能ではありません。業務の発注者と受注者が公平になるのは、金融のリスクサポートが適性に働いて、受注側が設備投資や営業力を強化して市場競争に見合う原価を実現できる場合だけです。それが実現されない場合、受注者は受注業務の品質を下げざるを得ない。発注者は品質のコントロール手段を失い、品質は急速に劣化していく。日本の高品質製品の代名詞だったソニーが、安易なアウトソーシングを推し進めた結果、外注部品の劣化を招き、「ソニーは買うとすぐ壊れる」とか「ソニータイマー」と呼ばれて大いに面目をつぶしたことを忘れてはなりません。

●アウトソーシングしていい場合といけない場合

　また話が長くなりました。そろそろまとめに入りましょう。

　わたしはここまでアウトソーシングの欠点ばかりあげつらってきましたが、もちろんアウトソーシングそのものを否定するわけではありません。世の中には外部委託したほうが合理的な業務もたくさんあります。大型汎用機で行うデータ処理業務はその典型例の1つで、1970年代から専門業者が成立してきました。OAが普及した後も業務アプリケーションを内製するケースは少なく、業者に委託する場合がほとんどです。そもそもIT業界自体がアウトソーシングを前提に成長してきた業界です。前述したように、コンサルタントがその受注営業の最前線に立っていてくれたわけで、その意味でコンサルタントがアウトソーシング論に肯定的なこともうなずけます。

　しかしそれは、ユーザーが自分たちにできない業務を外部の専門家に委託する場合の話です。専門家であるはずのSIerが自社の経営の都合で業務を外部委託していたらいったいどうなるでしょう。前述のとおり、コストばかりを重視した「市場原理」が災いして、品質をコントロールする手段を失い、テスト工程の費用がいたずらに拡大します。結局は逆にコスト増になる。そればかりではありません。景況のリスクが末端の技術者にしわ寄せされ、「女工哀史」や「蟹工船」の時代に逆戻りしてしまいます。「3K」と呼ばれるのもむべなるかな。これでは労働者のインセンティブは甚だしく損なわれ、業界全体に長期的な悪影響を及ぼすでしょう。アウトソーシングの結果、技術が空洞化する問題については前回、前々回に書きましたからもういいでしょう。ソフトウェアの開発自体はアウトソーシングに適した業務ですが、それを分割してアウトソーシングすることは、多くのリスクを発生させ、長期的に会社に不利益をもたらします。

　そもそもアウトソーシングのデメリットについては、わたしがこんなところでいちいち説明するまでもなく、専門家が「コスト面のみに着目した安易なアウトソーシングは、“戦略なき外注”となり、最適なITガバナンスが失われるリスクがある」とすでに指摘していてくれています。こちらをご覧ください（それにしても、この手の専門家はどうしてこんな分かりにくい言葉で説明するのでしょう。わたしも今回以上のことを書くために勉強するまで、このページを理解できませんでした）。

●会社のトイレは誰かが掃除しなければならない

　結論を言いましょう。「下流」の目から見ると、現経済産業省のお役人さんが勧めるアウトソーシング論は、企業の業務を細分化してトレードしやすくするという効果を狙ったものでしかないように思えます。これは投資家目線で見れば、投資対象として合理化された望ましい姿かもしれませんが、実際に現場で働く立場からすると、多くの場合さまざまな障害を作り出し、結果的に投資対象としての企業価値を損なってしまう、不合理極まりない戦略です。アメリカではこんな手法で見かけ上の企業価値を向上させ、株価で儲けるというビジネスが流行っていたようですが、こんなことをすれば生産の実態にかかわりない投機的投資が横行するのは当然です。このマネーゲームの報いがいま起こっている金融危機ではないでしょうか。

　もうそろそろ、アメリカの真似をするのはやめにしましょう。

●企業家の精神に立ち戻れ

　SIerのみなさん。もっと自信を持ってください。みなさんの業界はハイテクの先端にいる業界ではなかったでしょうか。多少の売り上げ増減のリスクなど吹き飛ばしてしまえるような技術革新が日夜生まれている業界ではありませんか。

　MicrosoftだってGoogleだって、つい最近までみなさんと同じような中小企業だったのですよ。彼らがベンチャーから世界的な企業にのし上がるまで、わずか数年しかかかりませんでした。もちろん彼らのまねをしろというのではありません。ライブドアの堀江元社長のように、形だけまねをしてスベった人はたくさんいます。

　わたしが言いたいのは、ITは少ない投資で多大な利益を上げることができるビジネスだということです。その事実を見据えれば、設計／実装技術者の人件費など物の数ではありません。かつて日本の高度成長を支えた「町工場」の経営者などよりもはるかに好条件に恵まれているはずです。

　きちんとリスクを負担して、でっかく儲けましょう。固定費をけちけちして喜ぶのは、リスクをぜんぜん理解できない銀行の営業マンだけです。彼らは担当する企業が安定して利益を上げてくれればいいと思っているだけです。彼らのいうことを真に受けて不用意なアウトソーシングに走ったら、あなたの会社の技術は完全にスポイルされます。むしろ彼らに、こう力説しましょう。

　「うちの技術者は天才ぞろいだ。うちは金のなる木を持っているんだ。あんたはそれを伐れというのか。とんでもない！」

（注1）しかし、わたしのようなケースはやはり稀なのでしょう。世の中、悲惨な条件で働いている派遣社員の話をよく聞きます。ITの会社だと思って契約したのに、回ってくる仕事はデータ入力のオペレータ作業ばかり、そのうち30歳も過ぎると仕事を回してもらえなくなってしまった。いまさらPGにしてくれる会社もない。このような派遣社員使い捨ての例はいくらでも転がっているでしょう。学校でプログラミングを勉強するか、最初の会社できちんとした教育を受けることは、この業界で生き残っていくには重要なことです。

（注2）村上世彰編著、日経BP社、1999年

（注3）もと旋盤工の作家、小関智弘が書いていますが、腕に自信がある労働者はけっこう気位が高く、少しでも条件のいい仕事先を求めて、ちょくちょく仕事先を変えていました。市場価値のある技能を身につければ、たいした貯えがなくとも生活困窮に至らないという見通しがあったわけです。いつの時代も同じですね。

（注4）われらがIT業界では、実際にこの戦略をとって急成長した会社があるようですね。どことはいいませんが。

【ＩＴ記事転載】下流から見たIT業界 - IT業界のシュールな現実（3）

2009-09-24T17:23:00.000+09:00

転載http://el.jibun.atmarkit.co.jp/karyu/2008/09/it-3-b6a8.html

　数年前（もうかなり古いことなので恐縮ですが）、ある大手SIerでのことです。

●ありがたいお話

　突然Webアプリケーション事業部長が話をするから、下請けを含めた開発者全員、会社の大会議室に集まるようにと言い渡されました。大学の大教室のような広い会議室で待っていると、年のころは60歳近く、小柄でやせていましたが重役クラスと思しき事業部長が1人出てきて、講壇に上がり、話し始めました。

　話の内容はこうです。わがWebアプリケーション事業部は発足以来、時代の波に乗って高収益を上げてきた。しかしこの数カ月その勢いがなくなっている。個々人の仕事ぶりも沈滞しているではないか。これはいったいどうしたことだ。

　わたしもその職場では組織上の問題があると思っていたところでした。さすが大企業、問題をいち早く認識している、と感心したのはそこまで。あとがいけない。その事業部長の見解は、要するにわたしたち開発者の自覚が足りないということでしかありませんでした。それで終わるならまだよかったのですが、その事業部長、司馬遼太郎を引き合いに出し、東西の文明論にまで発展した話を、延々2時間しゃべり続けました。わたしたちはスケジュールの遅れにやきもきしながら、その事業部長の教養あふれる話をありがたく拝聴させられたのです。

　課長の月曜朝礼ではありません。歴史小説をネタにした素人文明論など、いやしくも200人にもなる事業部のトップが話すことではないでしょう。この長ったらしい訓話の目的が何だったのかはっきりわかりません。もし事業部の収益が低下気味だというのなら、それは事業部長がハッパをかけるようなことで解決できるような話ではありません。きちんと原因を究明すべく人を使って調べさせ、分析結果を元に組織変更なり作業手順変更なりの対策を検討した上で周知実行する、というような話です。事業部長がこれでは会社の品格が疑われるでしょう。

●これで本当に「大手」？

　わたしにはこの大手SIerの事業部が、規模ばかり大きくとも、実質的な管理能力は大変貧弱で、中小SIerと同じレベルだったように思われます。おそらくこの教養のある事業部長さんの実質的な手足になるスタッフはごくわずかだったのでしょう。実際のプロジェクト管理は下請けから派遣されたPM 任せにしていました。事実上プロジェクトを「丸投げ」していたのです。いくら人数規模が大きくても組織としてきちんと管理されていなければ、それは単なる群集に過ぎません。

　そもそも「大手」というのは一体何なのでしょう。ユーザーはどうしてアプリケーション開発を「大手」に発注するのでしょうか。技術力に対する漠然とした期待があるから？それもあるでしょう。しかしそれよりも何よりも大手には資金力があります。システムを開発するために集めた技術者にはまず給与を支払わなければなりません。そのためにSIerは銀行からお金を借りるのですが、当然大規模な開発には多額の資金が必要となります。そのような多額の資金を借りる信用力は中小 SIerにはなく、結局規模の大きい開発案件は大手が受注することになります。このとき大手元請に期待されているのは開発のリスクを負担すること。例えば、開発費が予定をオーバーしても、それをユーザーにも下請けにも及ぼさないことです。ある開発で生じた損失は別の開発の収益で補えばよい。数ある受注案件を総合してプラスになれば、個々の案件のリスクは解消できる。それでこそ、ユーザーには安定してアプリケーションを供給することができ、開発者は安心して仕事ができるのです。大手SIerの存在意義は根本的にここにあります。

　この仕組みは一見うまくいっているように見えます。ITという新しい事業にベンチャー企業も意欲的に投資してくれるでしょうが、やはり安定的に設備投資するのは大手企業です。大手はやはり大手に仕事を依頼する。中小SIerはそこから仕事を請けた方が、自社で直接受注するより営業経費もかからないでしょうし、開発費用の超過も負担してもらえるでしょう。Webアプリの開発はまだ開発ノウハウの少ない分野ですから、何が起こるかわからない。「よらば大樹の陰」というわけです。大手SIerがプロジェクトを「丸投げ」しても、開発リスクを負担するなら少しも不当なことではないし、利ざやを取る権利は十分にあります。

　しかし実際にはこのビジネスモデルは正常に機能していません。というのもソフトウェアの開発では製品品質を評価することが困難だからです。

●ソフトウェアには形がない

　これが建物とか機械のように形があるものならば、製品評価はそれほど難しいことはありません。注文住宅がイメージどおりにできていれば、注文主は満足するでしょう。自動車は人を乗せて走ることができれば、完成品であることがわかります。しかしソフトウェアは形がありません。そのよしあしは使ってみないとわからない。そのうえアプリケーションはつねに特注品（パッケージで売られているソフトはわたしたちが作っているのではありません。あれはCDや DVDの生産ラインが作っているのです／注1）。要件定義の行き違いから、思わぬところで作り直しを要求されるかもしれません。だからPMは設計作業に時間をかけます。Webアプリの場合、設計書は事実上この注文者との間に交わす製品評価の約束書きのようなものです。それでもPMが最終的にでき上がるソースコードを想定し、それにかかる作業を見積もることができるなら、さして支障はないのですが、不幸なことにPMがJava（あるいはPerl、PHP、.NET）の実装を知らない場合（Webアプリの PMはCOBOL開発のPMが横滑りしてくることが大半でした）、設計作業は必要以上に膨れ上がってしまうことになります。PMにも製品が「見えない」わけですから、「見える」ようにするために設計工程にお金と時間を費やす。注文する方もその方が安心できる。だから設計工程はなかなか終了しません。その結果設計工程が必要以上に膨らんでしまうのです。

●どうしてそんなに長々と設計を？

　この大手SIerで起こっていた問題は、まさしくそれだったと思います。わたしが参加したのはそこが抱えていた案件の1つ、某新聞社の読者サービスサイトの開発でした。すでに実装作業を目前にしていて、そのマネジメントをしてくれというのです。実装はそれまで設計してきたSEが引き続き行うことになっています。そういうことならそれまでそのチームを率いてきたPMがメンバーの力量を知っているわけですから、自分で直接管理するのがベストですが、なにか別の仕事があるのでしょう、作業工程の管理ならわたしにも多少心得がありましたのでお引き受けしました。

　ところがスケジュールを見て驚きました。それまで設計に半年かかってきた来たものを2週間で作れというのです。わたしの経験に照らしてみると、2 週間で実装できるものに半年も時間をかけるのはナンセンスです。設計に半年かかったシステムは、実装にも半年以上かかります。ところが話を聞いてみると、重要なのはサイトの記事を管理する機能で、この部分にはパッケージのフレームワークがあるから大丈夫だというのです。半信半疑で資料を調べてみると、たしかにそういう機能は用意されています。パッケージの設計思想が古く、MVCパターンを想定していないのが不満ですが、たしかにこれなら2週間で（実際には 3週間かかりましたが）できそうです。しかしそれならなぜ半年も設計期間が必要だったのでしょうか。

　わたしがPMなら、最初に一部分を手分けして実装してしまいます。そうすれば技術者は製品のパターンを理解しますから、ほかの部分の設計に時間がかかるようなことはありません。実装に1週間（5日間）かかる機能は3日以内で設計できるでしょう。このPMはそれをしませんでした。自分がわからないことを部下にさせるのは（たとえ部下がそれに習熟していても）不安なことです。それゆえ部下の作業をコントロールするために、またあとで元請から責任を問われないために、必要以上に設計工程に時間をかけてしまったのでしょう。いずれにしても彼は設計工程に無用の人的資源を費やしたことになります。

　この傾向はこの会社の他のプロジェクトでも起こっていたと思われます。それは製造費用の上昇となって事業部の利益を圧迫したでしょう。事業部長が出張ってハッパをかけにきたのも、開発費がいたずらに上昇しているのが数字に表れたからだったと推測します。

●これって職場いじめ？

　ちなみにこのプロジェクトでのわたしの仕事は散々でした。工程に余裕がありませんでしたので、実装作業にむだが出ないよう毎日ミーティングを開いて進捗を管理したのですが、それが厳しすぎると思われたのか、SEの1人から猛烈に反発されました。技術的には不安のある人でしたが、そのチームでは1番の年配者で、職場では発言力がありました。進捗会議ではわたしに反抗的な態度を見せ、陰にまわってはわたしの悪口を言っていたようですが、こちらは新参者のPM代理、自分の権限もはっきりしていなかったので、手の打ちようがありませんでした。わたしを雇ったPMも何もいいませんでした。ともかくも実装作業が終わり、わたしはプロジェクト管理からはずされることになりました。やれやれ、これでプログラミングに戻れると思ったところ、いきなり契約を打ち切られてしまいました。理由ははっきりしません。PMからは何も説明がありませんでした。そのときは人間関係のトラブルがマイナスに評価されたからかと思ったのですが、どうやら単にプロジェクトに人手が要らなくなったから、不要の人間から切るということだったようです。

●泣きを見るのは外注PG

　コンビニの「名ばかり店長」に見るように、権限のない管理職は悲惨なものです。この会社のプロジェクトはまだ幸せな方でした。PMが自分の裁量で人員を増やす権限を与えられていたのですから。PMにそういった権限のない場合、またそういった予算のないプロジェクトの場合、事態は悲惨なことになります。しかもその被害は下流の実装技術者が受けやすい。各工程で起こる問題は、例えば人的資源の不足であったり、現場技術者の怠慢であったりしますが、PM はこれらをそれぞれの工程で解決するようなことはあまりしません。スケジュールの遅れにして先延ばしします。増員が無理でも時間の配分は自分の判断で簡単に裁量できるからです。人は自分の自由になる方法で問題を解決しようとするものです。それがたとえ一時しのぎに過ぎないとしても。問題が先送りされた結果、実装工程がひどい労働条件になっても、元請から文句をいわれなければ自分の責任ではない。そして元請は作るものだけ作ってくれるなら文句はいわない。泣きを見るのは外注PG、ということになります。

●本当はすごい実装工程

　こんな理不尽な理由から過酷な条件を突きつけられても、これまでPGが何とか耐えてきたのは、技術革新のおかげで実装工程の生産性が日夜向上してきたからです。JavaによるWebアプリケーションでいえば、IDEツールとしてeclipseが無料で利用できるようになり、Struts、 Springなどの優秀なフレームワークがオープンソースで供給されたことなどによって、実装工程は格段の進歩を見ました。それがなければWebサイトの実装を2週間で仕上げろというような無理な注文には対応できなかったことでしょう。

　しかしこのことは「上流」からは見えにくい。eclipseもStrutsも実装者がネットで手に入れたフリー（無料）の資源ですから、コストの要素として意識されないのかもしれません。ふつう技術革新は生産工程にプラスになると考えられていますが、実際はそんなに単純ではありません。逆に全体の生産コストを増やしてしまうかもしれない。「無理を承知でPGにやらせてみたらうまくいってしまった。ラッキー♪」で終わってしまったら、そのPMはこまったPMです。

●技術革新の落とし穴

　本来、技術革新は工程ごとの資源配分とともに評価されなければなりません。ある作業で生産性が上がっているとしたら、それは何が原因でそうなっているのか。それは持続するのか。そのことで生じた利益はコストに正しく反映されているか。そういった分析をしなければ正しいマネジメントとはいえません。この場合、実装工程で生じた余裕が設計工程でむだに費消されてしまっているので、全体のコストが下がらないし、逆に上昇してさえいるのです。

　さらにこの状況を助長しているのが、大手が受注して下請けが生産するというIT業界の産業構造にあるのです。先ほどふれましたように、IT業界ではどうしても大手SIerに受注が集まってしまう傾向がある。というのもソフトウェアの開発は事前にコストを見積もるのがむずかしい。くり返しになりますが、わたしたちが作っているものは「特注品」です。しかも実装にどれだけの時間がかかるか、わたしが自分で作る場合でも正確な数字は出せません。まして実装作業はPGの技量に大きく左右されます。PMはそれを無理やり「人月」ではかって見積もりますが、開発の規模が大きくなるにつれてその誤差は拡大するでしょう。この誤差がもたらすリスクは中小SIerの経営を揺さぶります。それで中小SIerは大手から仕事をもらうようになる。

●まちがったビジネスモデルがもたらす悲劇

　しかしこのビジネスモデルでは、元請SIerからはコスト発生の構造が見えなくなります。元請は案件の受注を増やして見えないリスクを吸収しようとする。それを下請けSIerにばら撒くようにして作らせるわけで、当然個々の案件については目が届かなくなる。下請けの言うとおりに開発費を支払うのだけれど、それが有効に使われていない。たとえていえば穴の開いたバスタブにお湯を張ろうとしているようなものです。

　こんなことをいうと誤解されそうでいうべきかどうか迷うのですが、「下流」のわたしが見るところ、Webアプリの開発はもっと少ない工数で開発することができます。わたしにはソフトウェアの「形」が見えるのでそう思うのです。そして設計工程の人員を減らし、ユーザーとプログラマが直接対話して仕様を作っていけるような開発体制を作れば、その工数はもっと減らすことができます。

　しかしこれはリスクが低くなるということではありません。ソフトウェアの開発リスクはその作業の特性上、下がることはありません。ただそれはお金に換算して負担すべきものではないのです。例えばリスクを絶対に予測できないビジネス、鉱山業や石油採掘ならこのモデルは有効でしょう。大鉱業資本は、有象無象の山師が持ち込む投資話にいちいち耳を傾けお金を出してきました。その投資の多くがむだになったことでしょうが、そんなむだがなければ今日わたしたち人類が利用できる地下資源の多くは発見されなかったことでしょう。しかしソフトウェア開発はそうではありません。リスクをお金で解決しようとしても、余分な投資は本来流れるべきところに流れず、要らぬところに流れてしまうのです。

●これはPMの責任ではありません

　このようなことをいうと、PMにすべての責任があるように聞こえるかもしれませんが、私は決してそういうことを言いたいわけではありません。PM はたんなる労働者にすぎません。PMは雇用主、注文主の求めに従って作業を配分し、経済原則に従ってアウトソーシングしているだけなのです。問題は仕事の性質に適合しないプロジェクト管理が、業界の構造によって維持されてしまっていることにあるのです。

　リスクは本来それを負担できる人が負担し、評価しなければなりません。今のビジネスモデルを維持していこうと思うなら、元請は生産工程に目を光らせ、個々に発生した遅滞の原因を突き止め、工程の誤りを是正していかなければなりません。そうしなければリスクの原因はいつまでも解決されず、IT開発はいつまでもハイリスクな事業にとどまるでしょう。リスクの芽は小さなうちに摘み取ってしまう。そうすればそのリスクは次からは予測可能になる。そのようにして管理を洗練していくことこそ本来あるべきビジネスの姿ではないでしょうか。

　件の事業部長にはこのようなことをするどく指摘してもらいたかったのですが、どうも教養がじゃましたようですね。

●現代の若者は大志を抱けるか

　わたしたちのIT業界は技術進歩の激しいところです。半年前の新技術はもう古いものになっています。技術の進歩は作業工程の生産性を大きく塗り替えます。このことはプロジェクト管理の面から見れば、たぎった溶岩の上にいるのと同じです。プロジェクト管理はそのことに敏感でないと、プロジェクトを大きくゆがめます。われわれの業界は、すさまじい技術革新による生産性向上にもかかわらず、「3K」と呼ばれて若い人に敬遠されています。生産技術の革新が生産現場の労働条件の改善に結びつくどころか、逆に悪化させている場合、それはなによりもまずプロジェクトの管理に問題があると考えるのは常識ではないでしょうか。ところがこの常識がこの業界では通用しない！

　大手SIerの経営者は「10年は泥のように働け」などという前に、このことを考えてほしいものです。

注1：この見解には異論をもたれる方も多いでしょう。最近は「ソフトウェアプロダクト」なる概念も提唱されていますが、この考え方は生産性向上という面においてはあまり効果をもたらさないように思います。これについてはいずれ私見を申し上げようと思います。

【ＩＴ記事転載】下流から見たIT業界 - IT業界のシュールな現実（2）

2009-09-24T17:22:00.000+09:00

転載http://el.jibun.atmarkit.co.jp/karyu/2008/09/it-2-38cf.html

　さる官公庁のシステム開発に参加したときのことです。基幹システムをダウンサイジングするという話でした。不勉強な私ですら名前を聞いたことがある有名なシステムです。元請は超大手SIerです。私はその3次請け業者の面談を受けました。技術的に高度なことを矢継ぎ早に質問されてたいへんな面談でしたが、とりあえず合格したようで、来月から来てくれといわれました。

　現場に行くと、大部屋に100人以上の人が机を並べていました。官公庁がユーザーであるせいか、空調が高めに設定してあって（いわゆる「クールビズ」です）やたら蒸し暑い。部屋の途中に衝立があって、向こうは2次請けの会社が入っている。私がついた担当SEは、その2次請け会社の人たちにたいへん気を使っていました。ほとんど鼻息をうかがうくらいです。衝立のそのまた向こうに衝立があって、その向こうには元請会社が入っているようですが、こちらはもう“殿上人”のような扱いで、口をきくのも畏れ多いといった様子でした。エンドユーザの官庁職員には結局会うことはありませんでしたが、もしその姿を見たらきっと目が潰れてしまったことでしょう。

　およそ官尊民卑を絵に描いたような雰囲気でした。それでもきちんとした開発が進んでいるならいいのです。ところが開発の実態はじつに奇怪なものでした。

　今回もまた基本設計がない。全体のスケジュールはなく、いつ完成させるのかもはっきりしません。それも単に資料がないというレベルの話ではなく、このプロジェクトがいつ始まったのかすらまったく不明でした。システムの全体像を示す資料はなく、誰がプロジェクトの責任者なのかもわからない。開発するシステムのハードウェアスペックはおろか、開発言語も不明なのです。どこからかC言語を使うといった不気味な声すら聞こえてきます（もちろんこれはC言語を貶めているのではありません。大規模システムにC言語を使うリスクについては理解してもらえると思います）。

　このような状態で詳細仕様書を作れという。どうやって？発注会社の担当者からざっとした話を聞いて、それを文書にまとめればいいといわれました。不条理なことですが、IT業界ではよくある話です。しかし担当者の説明を聞いても、どうしても要領を得ない。自分でも仕様を理解していないのか、それとも不用意に仕様を決めて責任を取らされるのを恐れているのか、言葉の端々を濁しながら、口の中でぶつぶつとつぶやくように話します。1時間聞いても仕様はぼんやりしたまま。

　そのくせこれまたレビューが半端ではない。官公庁に収める文書だからでしょう。それこそ句読点のうちかたから、フォントの大きさ、数字の全角半角までうるさく詮議されます。そのくせ内容についてはほとんどかまわない。第一にそれが作るべき仕様書かどうかもはっきりしません。私がその仕様書を手渡されても、それによってどんなソースコードを書けばいいかさっぱりわからないという代物です。

　そんな仕様書1枚が完成するまで半月以上の時間がかかります。書くこと自体より、むしろレビューに時間がかかる。まず担当者のSEがチェックする。その注文が入って修正する。その段階をクリアするのに2、3度レビューをする。そのたび議事録を書く。それだけでも結局1週間かかってしまう。さらに 2次請け担当のレビューが入る。修正して際レビューを待つ。ところが今度はいつまでたってもレビューの日程が決まらない。たなざらしになっている間に別の仕様書が注文されて書き始め、なんとなくそのままになってしまう。だれかPMになって督促するわけではないから、だれも文句をいう人はいない。

　そんな仕様書の1つで、入力項目としてコードが必要になりました。基本設計書がないので、誰かに聞くしかありません。担当SEにきくと、彼は驚いたことに「それは詳細設計で決めてくれ」といいます。まるで｢そんな失礼なことを元請に聞けるか！｣といわんばかり。彼の理屈では、コードなどのような細かい仕様は詳細設計で決めることだ、というのです。コード設計はシステムの根幹にかかわる重要な事柄です。それを一詳細設計者が独断で決められるわけがありません。「できません」と拒否すると、担当SEは憤然としながら、それならばその部分は自分で書くからといって引き取りました。後で彼が書いた内容を見ると「周囲の状況に合わせてコードを選ぶ」といった、まるでお役人のごまかし答弁のような記述がしてありました。これで私はもう何をいう気もなくなってしまいました。

　いったい私を呼びつけて私に何をさせたいのか、さっぱりわからない開発でした。同じように詳細設計要員として技術者が机を並べていましたが、その人たちも何をさせられているのか要領を得ない様子でした。どうやら私たちを割り当てようとしていた開発にGOサインが出なかったらしいのです。それをさいわい、暫定3カ月の契約期間が来たところで、こちらから契約を打ち切らせてもらいました。

　後から思うと、まるでカフカの不条理小説のような開発でした。

　コード設計を詳細設計者に任せたことからも3次請けSIerのSEのレベルが極端に低いことがわかります。何カ月も設計作業を続けながら、基本設計1つ作っていない2次請け業者も同様です。ユーザーの要件定義が固まらないのをいいことに、基本設計のカットアップを引き伸ばしていたのでしょう。スケジュールは遅れているけれど、詳細設計工程が始まったから、その要員を集めてしまう。詳細設計から先行開発させて、それをボトムアップでつめていけば、基本設計も固まるだろうといった、ほとんど倒錯的な開発方針をもくろんでいたのかもしれません。

　なんという税金の無駄使いでしょう。今日国会では財政再建の議論がなされていますが、私が見たのも国の財政赤字が生み出されている現場の1つだったのでしょう。この国が陥っている病の根深さを痛感しました。

　しかし、それよりもなによりも、このような開発体制でいったいどのような品質のソフトウェアができ上がったことか、そちらのほうがはるかに心配です。おそらく最終的には膨大な量の設計書が書かれたことでしょうが、ユーザーに理解させることを主目的にした、プラットフォームの物理的条件を無視した設計ですから、そのままでは実装作業には使えません。結局は誰かがそれを見て実際の作業に合わせた設計をしなおしたことでしょう。その工程にしっかり工期と予算がとってあればいいのですが、それすらなく、すぐ切り詰めた工期で実装作業が始まったとしたら……。

　それはもはやブリューゲルの「バベルの塔」の絵にあるような、巨大で、統一性がなく、何のために作られたのかすらわからない、人間の倨傲を象徴するようなシステムになってしまったでしょう。

　先日、そのようなシステムの末路をうかがわせるような話を聞きました。

　新しい仕事の面談にいったときのことです。

　ある公益法人の基幹システムの保守運用の作業を頼みたい。JavaのWebアプリケーションで、かなり大規模だという。それがトラブル続出で、恐ろしい事態になっている。具体的な作業の内容はおもに電話対応と原因究明だが、システムの利用者数が多いので、電話対応係は事実上コールセンター業務のようになっている。原因究明係は不具合を大まかに分析するだけで、改修はほかの業者に依頼することになるのだが、それだけでも月200時間を越える作業量になってしまう。

　面談担当者は以上のような説明をした後、せかせかした口調でこういったものです。「ついこのあいだ、また担当者が辞めていったので、その補充をしたいのだが、一度この仕事を始めたら最低2年間は続けてもらいたいので、十分考えてから返事をしてくれ。」

　これはもう「保守運用」のレベルの話ではありません。このシステムはまだ完成していないというのが正しい判断でしょう。そもそも保守運用を外注の人間に任せること自体がすでに異常事態なのです。

　JavaによるWebアプリケーションは、J2EEによって大規模なシステムを構築することができます。これが今日Javaが広く普及した要因の一つでであることは、いまさらいうまでもありません。しかしそれを使う側は――少なくとも日本のIT開発者はその使い方を誤ったようです。必要性の少ないドキュメント作成に不条理なほど莫大なマンパワーをつぎ込んだ挙句に、肝心のソースコードの品質劣化を招き、総開発コストを予算オーバーにしたばかりでなく、保守運用にも多大なリスクを残した。一方、ダウンサイジング需要が終わってSIerに残ったのはスキルの乏しい大量の技術者。自社だけでは保守運用に当てる人材すら手配できないありさま。

　未熟な技術とマネジメントで巨大なアプリケーションを開発してしまった結果です。誤った方法によってすでに作られてしまったソースコードの量を想像すると、気が遠くなりそうです。

　しかも多くの企業、官公庁ではそのことをまだ「失敗」だと認識していない。本来ならシステム改修のためにきちんとした予算を組まなければ直らないものを、運用保守のレベルで解決させようとする。その結果現場の技術者に多大な負担がかかっているのです。こんな現場に配属された技術者は人身御供にされたようなもの。IT業界はますます「3K」の職場と呼ばれ、優秀な人材が逃げていくことになるでしょう。

　もっともこのような大金をかけたシステム開発が失敗だったと認めるような判断は高度に「経営的」な判断でしょうから、私も軽々しいことを勧めたくはありません。開発が「失敗」だとしたら、その責任はだれが取るのかという問題も発生します。私は毎月のようにマスコミを騒がす「システム障害」のニュースを聞いて、経営陣の複雑な胸中を忖度（そんたく）し、些細なバグが社会的な大事故につながらないことを祈るばかりです。

【ＩＴ記事転載】下流から見たIT業界 - IT業界のシュールな現実（1）

2009-09-24T17:21:00.000+09:00

転載http://el.jibun.atmarkit.co.jp/karyu/2008/09/it1-054e.html

　これから申し上げるのは、わたしが実際に仕事の上で経験したことです。これらは今日のIT業界の病根の深さを示すものです。

　とある会社のシステム開発に呼ばれていったときのことです。まず見せられたのは画面見本でした。すでにHTMLで詳細な画面が作られています。画面数が多く、画面上の項目数も多い。これは相当意欲的なシステムだと思われました。これを実装できるなら、きっと充実した仕事になるでしょう。

　ところがいつまでたっても開発が始まりません。誰がプロジェクトを管理しているのかもわからない。誰もスケジュールをはっきり説明できません。おまけにドキュメントサーバのどこを探しても基本設計書がありません。業務フローもなければシステム構成図もない。膨大なER図だけが公開されていて、ときどき修正されているらしい。

　いつまでも遊んでいるわけにはいかないからと、詳細設計書を先に書くことになりました。基本設計書がないのに詳細設計が書けるか！普通の人なら驚くでしょうが、この業界ではよくあることです。IT業界の技術は日進月歩で、プログラミング工程はたいへん生産性が向上しています。製造工程であまったマンパワーを設計工程に回すために、詳細設計書はPG自身が書くことは珍しくありません。基本設計書が変更になれば、当然その設計書も手戻りになりますが、遊んでいるよりはいい。

　いやだったのは、それにもかかわらずこってりとレビューをすることです。いったい何を根拠にレビューをすればいいのでしょう。チェックするところといえば、段落はさげてあるかとか、句読点は打ってあるかなどといった形式上の瑣末事です。それもすぐユーザーから仕様変更が伝えられて書き直しになる。またレビューのやり直し。文書直して、アポとって……。

　しばらくそんな不毛な作業を繰り返しているうちに、上流で何が起こっているか次第にわかってきました。元請SIerがユーザーと揉めていたのです。元請は見積もりを誤ったのか、機能が多すぎるので削ってほしいといっているらしい。ユーザーは受け入れたくないし、何より元請業者の開発方針に不審を抱いているようでした。いつまでたっても納得できるような基本設計が出てこない。SE、PGをたくさん集めたけれど、仕事はしていない。きっとユーザーには人手不足を理由に人間をかき集めただけで、管理する能力もなく遊ばせていると見えたことでしょう。

　上流でことが進まないなら、せめて下流ではこの時間を利用して開発準備を進めていたいところですが、それもどうも怪しい。そもそも先行してコーディング作業に入ることが禁止されていました。個々のプログラマにソースを任せてしまうと、どんな勝手なソースを作るかわからないからというのでしょう。いくつかのパラメータを入れればスケルトン（プログラムの原型）を作るツールを作って、それを使うことを義務付けようとしていたのです。ところが何度見ても出力されるスケルトンの構造がわからない。おまけにそのツールの動作が不安定だし、操作方法が意味不明だし、しょっちゅう手直しが入るし、これなら Eclipseでコピーして作ったほうが早いと思われました。ただ若手の新しがりのSEの自己満足のために作られたようなツールでした。

　そのうえプロパー社員SEの技術レベルは悲惨なものでした。わたしが下についたSEはやたら威張っていました。年のころは30歳前半だったでしょうか。わたしは彼が何か具体的な成果物を作っているのを見たことがありません。単にわたしの詳細仕様書に対する「お目付け役」だったように思えます。まあ、下の人間は上の人間が何をしているのかは理解できないものです。何かしていたんでしょう、きっと。

　あるとき彼は、わたしが書いた仕様書にテーブルの検索条件が書き込んであるのを見つけて烈火のごとく怒り出しました。

　「SQLを設計する前に報告するようにといったでしょ！」

　その声の大きいこと、周りにいた人たちが驚いて振り向いたくらいです。

　要するにその部分は自分が設計するつもりでいたのを、わたしがさっさと書いてしまったので怒り出したのです。あとから知ったのですが、そのSEは SQLしか知りませんでした。つまり自分もきちんと詳細設計ができるところを見せつけて、わたしを恐れ入らせようとしていたのです。

　まったくバカなSEもいたものです。SQL設計など下流に任せておけばいいものを。テーブルの検索条件だけははっきりイメージすることができるので、そこだけは人任せにできなかったのでしょう。人を使うことの基本ができていない。やがて何度かやり取りするうちに、わたしの管理をするのに飽きたのか、異動願いを出して、先述のスケルトンツールを作る部署へと移っていきました。そんなスキルでそこの仕事が勤まったかどうか知りません。

　わたしにはこのSIerが、社員の技術を空洞化させてしまった典型的なケースに思えます。ソフトウェア開発の業界では、PGよりSEのほうが単価が高いので、SIerは自分の社員をできるだけ早くSEにしようとします。そのためSIerにはSEがたくさんいますが、実装技術が未熟な人も多い。わたしを担当したタカビーなSEのように、すこしばかりSQLをプログラミングしたというだけでSEの業務につかされるケースも出てきます。彼らがしてきた仕事はといえば、ほとんどが仕様書作成。わたしはあまり役にも立たない仕様書作りなどまともな仕事だとは思わない（失礼！でもそう思う理由はあるのです。いずれ説明したいと思います）のですが、それだけを専門にしてきたSEはそれが正しい有意義なシステム開発の手法だと思い込んでいます。それを2、3年も続ければ、当然自分はさらに上流工程で仕事ができると思い込んでしまう。それが出世だと思い込んでいるし、そうしないと自分はいつまでもつまらない仕様書書きを続けさせられることになる。件のSEからは、実装作業に対する根拠のない侮りと、強烈な功名心と自分の置かれたポジションについての不満しか感じられませんでした（真の技術者はあまりポジションには執着しないものです。自分の技術が自分の価値を決めるのだと知っていますから）。

　ユーザーとの間に起こったトラブルも、SIerの基本的なプロジェクト管理能力、設計能力に対する不信が大きな要因だったと思えます。IT開発の基礎体力であるプログラミング技術がなくなると、プロジェクト管理ができません。というのもプロジェクトの管理には実装作業の豊富な経験が必要だからです。仕事を適正に分担すること1つにしても、PG各人の技量を詳しく知らなければできません。未熟なPGはちょっと複雑な仕様にぶち当たっただけでプレッシャーに負けてしまったりします。ですからPMはSE、PG全員をよく知っているベテランがなるのが望ましいのですが、最近は若手社員がなることすらめずらしくはない。人の入れ代わりが激しいので、プロパー社員の絶対数が少ないのです。PMは、たとえば工期の遅れを取り戻すために臨時に作業者を増員するなどの権限が必要な「管理職」、おいそれと外注するわけにも行きません。その結果、経験不足を承知で若手社員をPMとして登用しなければならないのです。若手PMがすべて無能だとは思いませんが、SIerのプロジェクト管理能力を低下させる構造的要因の1つであることはまちがいありません。

　最近ネットで検索すると、ユーザーとSIerの間に信じられないような揉め事が生じたという記述を目にします。わたしたち実装屋には上流で何が起こっているかよくわからないのですが、下流から実際の開発体制を見ていると、そんなシュールな噂がいちいち納得できてしまうのです。恐ろしい話です。

【ＩＴ記事転載】下流から見たIT業界 - 業界人のにおい

2009-09-24T17:19:00.000+09:00

転載http://el.jibun.atmarkit.co.jp/karyu/2008/09/post-8cbd.html

　初めまして。職歴20数年のプログラマです。ときどきSEもやります。

　IT業界でいわゆる下流工程（「下流」とは最近なんともいやな言葉になってしまいました）で長年プログラム製造の仕事をしてきました。ソフトウェア開発の現場に近い位置に身をおいていると、この業界がとんでもない構造的問題を抱えていることがよくわかります。

　IT関連のブログというと、書いているのはたいていがコンサルタントやITライターの方など、「上流」工程におられる方々が多いように思えます。これらのブログも非常にためになるのですが、わたしがふだん思っていることとはだいぶものの見方、考え方がちがっているように思えます。「問題はそんなところにあるんじゃないよ」とか「実態を知らないんじゃないか」と思うことしきり。

　「もの言わぬは腹ふくるるわざ」と申します。王様の耳の秘密を知ってしまった床屋のような気分。葦の茂みに穴を掘って「王様の耳はロバの耳」と思いのたけを叫んでみたくなります。さいわい＠IT自分戦略研究所がわたしに意見発表の機会を与えてくださいました。＠ITに感謝しつつ、ここでわたしなりの問題提起をして見たいと思います。しばしおつきあいのほどを。

　とはいうものの、最初から固い話ではじめるのもなんですので、ちょっと感覚的な話から始めましょう。お題は「におい」についてです。

　どんな仕事についている人も、その仕事独特のにおいがあるものです。街を歩いていて、突然歩道の横にワンボックスカーが横付けして、中から機能的でカジュアルな格好をしたお兄さんがはじけるようにして飛び出してきて、てきぱきと後ろのドアを開け、荷物を降ろし始めたなら、それは十中八九TV業界の人です。彼が引き出すのはカメラの三脚、ジュラルミンケース。そうしている間に、別のスライドドアからはカメラをひざに抱いたおじさんがちょっと重々しく出てきて辺りを見回し、助手席からは女性ディレクターが出てきて仕切り始めるといった寸法。わたしはこの業界の人たちと一緒に仕事をしたことがあるので、においでわかります。

　また法曹関係の人々も一種独特な雰囲気を持っています。大きな書店の法律書のコーナーに行くと、そこにいるのはきまって地味な背広を着て、黒いかばんをさげた男性の方々。せかせかした感じがしないのは、きっとあまりスケジュールに縛られない生き方をしているからでしょう。なかにはすっかり頭の禿げた年配の方もいらっしゃいますが、齢はとっても勉学心旺盛なことが背中でわかります（不思議なことに、こういうところではあまり女性を見かけないような気がします。「辣腕の女性弁護士」というイメージはテレビドラマの見すぎでしょうか）。

　さて、本題のIT業界人のにおいですが、一時期、誰が見てもはっきりわかるにおいをさせていたことがあります。1980年代後半、パソコンの普及とともにコンピュータ関連の書籍がにわかに書店の棚にのさばり始めたころ、その棚の間にたむろしていたのは、年のころは20代後半から30代、しらっぱけたジーンズによれ気味のトレーナーを着、時に髪の毛は寝ぐせのまま、身なりに関心がないというスタンスがあまりに自然に身についたお兄さんたちでした。

　なにやら留年学生風でもあり、かといって暇をもてあましている風でもなく、ひとつ仕事に打ち込んでいるという凄みがどことなく伝わってくる。周囲の人にはほとんど関心を払うようすがなく、表情に喜怒哀楽も見えない。ただじっと本の背表紙を眺めては、頭の中で筋道だった考えを高速で展開しているように見える。

　彼らはプログラミングの魔力に取り付かれた人々でした。キーボードを叩きまくり、複雑なロジックを組んではほぐし、ほぐしては組む、そんな作業を長時間続けてきたことが、ほとんど体臭となっていました。ひとつところをじっと見つめる癖は、CRT画面を眺め続けたためでしょう。無表情に見えるのは、プログラムが思い通りに動いたという、自分にとっての人生最大の喜びが、他人には説明のできない、また説明する必要を感じないものだったからでしょう。

　そう、この時代IT業界（当時はまだ「IT」なんて言葉はありませんでしたが）を代表していたのは、いわゆる正統派「ハッカー」気質の人々でした。1980年代後半16ビットパソコンとMS-DOSという組み合わせが急速に世界中に広まってきたころ、それまで8ビットマシンの上でホビーのなかに閉じ込められていた個人のプログラミングの才能が、安価に提供されたビジネス向けパソコンというプラットフォームの上で華々しく展開されていったのです。これらの才能が数々の優れたアプリケーションソフトに結実し、やがてインターネットを媒介にして相互に結びついて、Linuxをはじめとするオープンソースのコミュニティを形成するのです（きっとトーバルズ氏もスティーブ・ジョブズ氏も、強烈なハッカーのにおいをさせていることでしょう。お会いしたことはありませんが）。

　しかしこんなハッカーのにおいをさせる人々は、書店からいつの間にか姿を消してしまいました。彼らはいったいどこに行ってしまったのでしょう。ネットがあるから、もう情報を書籍に頼る必要はなくなったのでしょうか？いえいえ、まとまった知識を得るためには書籍のほうがはるかに効率的なメディアです。

　最近、書店のコンピュータ書籍コーナーで見かけるのは、必要に迫られてやってくる人たちばかりです。破綻しかけたプロジェクトに何か妙案はないかと探すプロマネ風の40代。儲け話につながるイノベーションはないかと嗅ぎまわっている30代。就職が決まらず、コンピュータ入門書をこわごわ覗く20 代。

　むしろ活気があるのはWebデザインのコーナーですが、こちらに集まる若者たちはまったく違った人種です。ヒップホップかウラハラか、大人たちにはよくわからないけれどとにかくお金をかけずに自己主張したいというスタンスのおしゃれに身を包み、何を見ているのか視点が定まらない夢見る少年少女たちといった風情の若者たち。彼らは、自分が見た夢を他人に理解してもらいたいという欲求を抱えてそこに集まっていると見えます。

　要するに、この業界も広くなって、いろいろな人が参入しているということでしょうが、それにしてもハッカーたちはどこへ行ったのでしょうか。いろいろな人たちの間にまぎれて目立たなくなっているのでしょうか。

　ひとつ気がかりなことがあります。

　わたしには悪い癖があって、休日など暇なとき喫茶店に一人で入って、他人の話に耳を傾け、その人たちの生活や仕事について想像をめぐらしたりするのですが、最近スタバなどのコーヒーショップでは、年のころ20代後半、さりげなく高そうなカジュアルウェアを着て、自分たちの仕事について談論風発している若い人たちを見かけます。彼らの話から「納期」とか「プロジェクト」とかいう言葉が聞き取れますので、もしかしたら同業人かとあたりをつけるのですが、それにしてはコンピュータ用語が少しも出てこない。「OS」も「データベース」も「サーバ」も一切出てこないのです。

　彼らは仕事の愚痴を言い合うでもなく、むしろ今の仕事には十分満足しているらしい。それどころか自分の前に開けた出世の可能性にわくわくしているのが目の輝きから読み取れます。すぐそばでおじさんが立ち聞きしているのも気づかずに、彼らは仕事の薀蓄めいた話題をひとしきり得意げにしゃべった後、

　「技術には深入りしないほうがいいね」「うん」

と、なにやら後ろめたげにうなずき合った後、急に話題を失って黙り込んでしまう。こんなことが2度ほどありました。

　だいぶ前からIT業界は「3K」だとかいわれて、非人間的な使われ方をする産業だという評判が定着しています。そんなおそろしげな世界に果敢に乗り込んでくるのは、こんな野心たっぷりの、恐いもの知らずの若者たちなのでしょうか。それはいいのですが、そんな若者たちが一番恐れているのが、どうやら「技術に詳しい」という社内評価を立てられることのようなのです。彼らにしてみれば、生産部門に配属されるのは、自分のキャリアにとって損失であり、そんなことがないよう、上流をすいすい泳ぎ渡ってえらくなっていきたいというのが本音かもしれません。

　もちろんこれは、わたしが巷で立ち聞きした話の断片から組み合わせた推測に過ぎません。しかしもしこの推測が正しければ、それは日本のIT業界には技術に対する軽視、軽蔑、忌避の傾向が蔓延しているということではないでしょうか。

　1980～1990年代IT業界を闊歩していたハッカーたちは、この環境の変化が原因で激減しているのではないでしょうか。地球温暖化で絶滅の危機にあるホッキョクグマのように。もしそうだとしたら恐ろしいことです。

　銀行が営業できるのは一般預金者の貯金を背景にした信用があるからです。車が売れるのは高性能で安全な車を生産する力があるからです。どの企業も自分の利益の元は大切にし、常に気にかけています。IT業界が自分たちの利益の源をおろそかにしたらどういうことになるでしょう。これは日本のソフトウェア産業の危機ではないでしょうか。

　これからしばらくこのコラムを借りて、「下流」から見た、現在日本のIT業界が抱える構造的な問題について書いていきたいと思います。自分の経験にもとづいた、推測と独断と偏見の入り混じった話になると思います。反感を感じたり、憤慨したりする方がいらっしゃるかもしれません。反論は甘んじてお受けしますので、興味のある方はしばしお付き合いください。

　ところで、わたし自身はどんな「におい」をさせているかって？さあ、それはわたし自身、他人になってみないとわかりません。

【ＩＴ記事転載】下流から見たIT業界 - SEとPG、どっちが頭がいい？（2）

2009-09-24T17:16:00.001+09:00

転載http://el.jibun.atmarkit.co.jp/karyu/2008/10/sepg2-0e2d.html

　刺戟的な題名で続けます。

　前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、 PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。

●C言語＠UNIXでは

　COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。

　この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれなんとなくあいまいにSEを名乗ったりPGを名乗ったりしていましたが、SEは必ずプログラミングができましたし、PGは必ず仕様書が書けました。そもそもプログラミングを知らなければ設計ができませんでした。パソコンの開発環境は個人が独占して使えました。そもそもC言語はUNIX とともに作られた言語です。UNIXは大型機の硬直性を打開するためにミニコンで動かすことを前提とした開発されたOSですから、そもそもがPG主体の環境です。開発者なら誰もがプログラミングができて当然の世界です。

●VBでは、なぜ？

　ところがVisual Basicが登場してくると状況が変わってきました。再びSEとPGが分かれ始めたのです。

　VBは必ずしも前回説明したSE／PG分業アウトソーシング説のモデルに合いません。VBは極めて開発効率が高い言語です。同じ実装を Basic、あるいはC言語で行うとしたら、工数は数十倍に及ぶでしょう。こんな高能率な言語の実装を外注に任せてしまうのは、技術の蓄積という面で会社にとって損だと思うのですが。

●レベルが高いVBのプログラミング

　ご存知の通り、VBはフォームといわれるウィンドウの上にテキストボックスやボタンのような部品を置き、それぞれ「クリック」や「フォーカス」などのようなイベントごとにソースコードが書かれます。それまでBasicやC言語では、プログラム自体1つの構造を持ったまとまりだったのですが、VBの場合、プログラムは画面に見える各部品の中に断片的に散らばっているのです。

　このことはVBアプリの設計を難しいものにしました。分散しているソースコードを1つ1つ定義していたのでは、手間がかかってしかたがありませんし、仕様が断片的になり、かえって分かりにくくなります。そのため、設計書では画面全体の機能だけを記述し、PGが各機能の相互連携を考えることになりました。PGは仕様書を受け取ると、細部まで読み込み、それが全体ではどのような動きをするのか入念に頭の中で組み立ててから仕事にかかりました。最後には頭の中に機能の入念な地図が出来上がります。PGはそれを頼りに、どんなバグにも対応できるようになります。この地図をドキュメントにしてお見せできないのが残念です。

　また「コントロール」と呼ばれる画面上の各部品には、それぞれたくさんのプロパティがあり、それに設定されている値を操作することでさまざまな動きをさせることができましたが、おかげでリファレンスだけでかなり分厚いマニュアルになってしまいました。必要なプロパティやコマンドを覚えるだけでも一苦労です。さらにAccessやExcelのオブジェクトについても該博な知識が必要になります。PGが知らなければならない知識は、C言語と比較してもはるかに多いのです。

●SEは「御用聞き」？

　このようなPG作業に比べれば、VB開発のSE作業はお客さんの要望を文書にまとめるだけの地味で単純な作業に思えました。仕様書をまとめ終わったあとのSEは、プログラミングのお目付け役か、表現はよくないのですが、単なる「御用聞き」に思えたものです。もちろんユーザーの要件をまとめて形にするということは創造的で根気が要る仕事なのですが、マシンパワーを味方にして高生産性を挙げている側から見ると技術的に低レベルの仕事に見えてしまったのです。

　結局のところVBの開発では、SEとPGの技術的重要性は五分五分といったところで、どちらがより難しいとも、知性を要求される作業であるとも言えないでしょう。ですからSEさんたちは外注のPGに対して十分な敬意を払ってくれました。仕様の不明点は懇切丁寧に教えてくれましたし、設計のミスにも率直に対応してくれました。わたしたちがいつまでもバグ取りが終わらないときは、自分の責任でもないのに、深夜になるまでじっと作業に付き添ってくれたものです。

　VB開発においてSE／PG分業がかえって顕著になった理由は、前述したようなPG作業がアウトソーシングされるという傾向に加えて、 WindowsのUIオブジェクトが煩雑になったため、設計作業と一緒にプログラミング作業を負担できなくなったからということが主な原因だったと思います。すなわちVB開発の元請けは、VBのプログラミングが単純作業だから外注したのではなく、極めて専門性が高い技能だから、社外の専門家としてPGをプロジェクトに招待していたということなのです。

●もっとハイテク、Javaワールド

　Java開発では、実装作業はVBにも増して高い技術レベルが要求されるものになりました。Webアプリケーションに必要なのは単にJava言語に関する知識だけではありません。画面を構成するHTML、クライアント・サーバ間の情報をやり取りするHTTPプロトコル、Struts、Spring などのフレームワークの活用法、クライアント画面でのUIを補うためのJavaScript、果てはAjaxによるUIの質的向上まで、（Webアプリケーション開発はPGに）技術の最先端をこれでもかこれでもかというほど要求します。

　そしてなによりもオブジェクト指向設計の要であるクラス構成も、事実上PGが設計しなければならなくなりました。SEとPGの間のインターフェイスになるのは、SEが書く設計書――すなわち詳細仕様書ですが、これがVBと同じ画面を中心にした機能定義だけの記述です（注）。この方式では、サーバ側のクラス構成を一切規定できません。というか眼中にない。そもそもオブジェクト指向で設計するとどんなメリットがあるのか、きちんと理解していないSEもかなりいることでしょう。

　企業がそれまでメインフレームで行っていた基幹業務を次々にオープン系システムにダウンサイジングしていったわけは、ハードウェアの安さもさることながら、ソフトウェアをオブジェクトとして編成することで再利用性を高めることにありました。メインフレームではすでに大規模なビジネスロジックがソースコードとして実現されていましたが、COBOLの言語的性質から他システムに移植するには多大な困難が伴いました。このため、企業の組織変更や業務の合理化のたびに、大規模なシステム改修のコストが発生していたのです。オブジェクト指向プログラミングはソフトウェアの硬直性を解決するための鍵となる技術でした。すなわち、企業戦略上の重要な条件整備の役割をPGが担うようになったのです。

●こんな「タコ部屋」開発、勘弁して！

　にもかかわらず、多くのWebアプリケーション開発の現場では、PG作業の高度な専門性はまったく無視されました。

　2003年ごろ、ある大規模なWebアプリケーション開発に参加したときのことです。現場に呼ばれていくと、すでに開発はコーディングたけなわ。 PGが数十人大部屋に集められて作業していました。さっそく画面デザインと機能仕様書が渡されました。画面は数カ所のセクションに別れ、サブミットボタンも数個あります。たいへんなボリュームなのにそれを3日で作れという。

　その結果PGはどうしていたかというと、COBOLと同じように、すでに誰かが作ったクラスを流用して手直しして使っている。1リクエストに対して1クラス、それも1メソッドにすべての機能をコーディングしていました。当然メソッドのステップ数は数百に及びます。クラス構成もオブジェクト指向もありません。ただひたすらに急いで作って動けばいいという作り方です。こんな作り方ではかえって工数がかかってしまうのですが、そんなことおかまいなしです。

　そのうえ工程管理がすさまじいものでした。正副のプロジェクトマネージャがいて、2人で数十人のPGの進捗を管理していました。当然毎日これに忙殺されます。1日中かかってPGを1人ずつ別室に呼び出し、進捗状況を尋ねます。遅れているなら、なぜ遅れているのか厳しく問いただします。まだ環境に慣れてないなどといいわけしようものなら、「ほかの人はみなこの効率で仕事をしています」と圧力をかけてくる。まるで捕まって取調室に呼び出されたコソ泥のような気分でした。

　このような開発でできたソースコードは硬直的で、再利用性が悪く、どんなリファクタリングも受け付けないでしょう。この仕事を請け負ったSIer は、目先の開発効率に気をとられてかえって非効率な作りこみをしてしまったばかりでなく、アプリケーションの将来的なコストまでも大幅に引き上げてしまったのです。さすがにこのような開発を強いられたのはこのときだけで、これ以後こんなタコ部屋開発は経験したことがありませんが、もしかしたらまだどこかで、外国人PGを集めて同じ様な作り方をしているところがあるかもしれません。

●IT技術の空洞化

　JavaによるWebアプリ開発でPG作業が軽視されている傾向は現在でも一向に変わりません。かえって強くなっているくらいです。特に大規模なアプリケーション開発では、いっそうそれが激しい。ということは、社会的に重要なシステムほど粗悪なプログラミングがなされている可能性が強い。事実わたしがうわさに聞く話では、あの大企業のシステムがそんな状態なのかということが多いのです。これは日本のIT産業におけるソフトウェア設計技術が構造的な原因から空洞化していることを意味しています。いくら見かけのドキュメントを整備しても、それは顧客の要求だけが精緻に文書化されたというに過ぎず、それによってソフトウェアの品質をコントロールしているわけではありません。大事なことはソースコードの品質なのです。にもかかわらず今日のIT業界は、ソースコードの品質を向上させるどころか、かえって悪くする方向に向かいつつあります。いったいなぜでしょう。

　前回も触れましたように、「PGは労働集約型の単純作業で、SEこそが高度な技術を担う職分だ」という、1960年代の職制がアウトソーシングによる固定費節減戦略に誤って適用されている傾向が、その原因の1つです。何度もいいますが、本来ソフトウェアの作成という仕事は設計とコーディングという作業に明確に分けることができません。それを無理やりに分けようとするなら、ネット社会を形成してきた数々の技術革新の成果はすべてPGに残り、SEはそれらから完全に疎外されることになりかねません。

●SEの悲惨

　下請けSIerは、SEのほうがPGよりも作業単価が高いので、自社の社員をなるべくSEにしようとします。入社してまだ1、2年の若手をSEと称して元請けの現場に送り込む。そんな未熟な技術者に設計作業が務まるでしょうか。務まるのです。彼らに与えられる仕事は、顧客の要望を聞いて仕様書にまとめるだけ。プログラミングよりかえって簡単なくらいです。しかし、そのことで派遣されたSEのスキルに与える悪影響は計り知れません。彼が強いられるのは果てしないユーザーの要求変更をドキュメントに反映させる仕事。ドキュメント変更のたびに長い長いレビューが開かれて、それだけで精力を使い果たしてしまいます。設計に携わることで得られるはずの業務知識も、実際には切れ切れの断片に過ぎず、体系的な技術にはならない。知識として整理する余裕もない。

　例えば企業の会計システムを作るとします。その設計に携わって企業の会計を知ることができるようなSEがどれだけいるでしょう。会計の知識はそんな甘いものではありません。大抵はすでに会計の知識を持っているSEが全体を決めてしまって、業務請負で派遣させられたSEはその下働きをさせられるのです。SE作業があまりに非効率で膨大なため、本来の設計作業に参加するSEと、「仕様書書き」という単純事務作業に従事するSEが分離しているのです。長い忍耐の末、下働きSEが獲得できる業務知識とは何でしょう。知識の断片で仕様書を書いたというだけのことです。その結果ほとんどのSEは業務知識からは疎外され、実装技術の習得からも切り離されてしまう。現実的なスキルを何も持たないSEが大量に作られる。

●PGのスキルも劣化

　SEの技術がだめになると、PGの技術も同時にだめになります。社内で評価されない職種に誰が労働意欲を感じるでしょう。長時間労働に身をすり減らし、おのれの技量不足に打ちのめされ、少なからざる新人が脱落していきます。残った者は1日でも早いSEへの格上げを待ち望んでいるばかり。ごく少数の PGは実装技術の重要性に気がついて実装セクションに残ろうとしますが、そんな「変わり者」のキャリアパスを許容してくれるのは、人件費に余裕のある大企業だけです。大きな会社では（SIer以外でも）IT関連部署に、いかにも「ハッカー」のにおいをぷんぷんさせた猛者がいたりするものですが、開発技術者の供給源である中小SIerでは、人員に余裕がなく、いつまでもPGとしてモラトリアムさせてもらえないのです。それでも実装作業に残りたいという人間は、契約社員になるか、わたしのような個人事業主になるしかありません。わたしが知っている中で優秀なPGと思えた人は、みな大企業の片隅で仙人のようになっているか、会社を飛び出して一匹狼になっている人でした。高度な技能の持ち主も、正当に評価されなければこのような生き方を選ばざるを得ません。

　結果、SIerの社内にはPGがいなくなります。いったいSIerはこれでどうやって開発作業を行うつもりなのでしょうか。いざとなれば外注すればいいと思っているのでしょうけれど、ほかの会社でも同じ方針を採っているのですから、派遣されてくるPGのレベルなど推して知るべしです。低レベルの SEの設計で、未熟なPGが実装する。当然低品質の製品が作られる。ソフトウェアには形がないので、表面上機能すればユーザーからは苦情をいわれない。それを繰り返すうちに、業界全体が急速に必要なスキルを失っていく。度重なる銀行や交通機関のシステム障害の背景には、このような技術空洞化の構造があるのです。

●技術を甘く見るな！

　話が長くなりました。そろそろまとめに入りましょう。現在のIT業界で「SEとPGのどちらが頭がいいか」と問われたら、「どちらも頭は空っぽだ」と答えざるを得ません。これは技術者個人個人の責任ではありません。明らかに企業のアウトソーシング戦略の結果です。単に頭が空っぽなだけならまだしも、このような技術者が多数派になってしまったおかげで、技術に対する浅薄な侮りと無知が蔓延（まんえん）するようになってしまいました。

　こんなことをいっては「上流」にいる方々には失礼かもしれませんが、IT業界は上流にいるほど得になるような構造になっています。それぞれのプロジェクトについて自分のところで十分な経費を確保してから下流に流しますので、下流にいるほど仕事がきつくなります。それをうすうす感づいているから、若い人は少しでも上流に行きたがります。PGをしばらく勤めたらSEに、SEを少しやったらコンサルに。産卵まぢかの鮭でもあるまいに、自分の技術レベルも分からないまま、やみくもに次のステップを目指そうとする。会社も上流の方が単価が高いので、スキルも経験も関係なく自社社員を格上げする。その結果、技術力のない技術者が泡のように上へ上へと浮かび上がってくる。こんな技術者はそれぞれの工程できちんとした仕事をした経験がないので、自分のスキルさえ認識できない。ドキュメント作成が仕事だと思いこんでいるコンサルタントさえ出てくる。まさしく、同じエンジニアライフコラムニストの林さんがコラムで嘆いている通りです。

　この技術軽視の傾向がIT業界をどれほど蝕んでいることか。たんに若者のインセンティブをそぐばかりでなく、IT業界に対する一般社会の信頼を大きく損ねつつあります。世間は度重なる銀行や交通機関のシステムトラブルを大目に見てくれるわけではありません。このまま技術空洞化の傾向が続くなら、「ITは見かけ倒し」という評価が固まってしまいます。そうなれば企業はITへの設備投資自体を手控えるようになるでしょう。そうなってからでは遅いのです。

　SIer経営者の方に申し上げます。SEとPGの分業は実際の作業で不要な障害を作ってしまうばかりでなく、SEを技術のイノベーションから疎外し、スキルに悪影響を与えます。さらにSEには期待するほど業務知識は蓄積されません。もしSEに業務知識を持ってもらいたいなら、お金をかけて教育しなければならない。極端なことをいえば、MBAを取りにアメリカに留学させるくらいの覚悟がなければ、ろくな知識は得られないのです。

　また、PGの作業を低く評価し、外注で調達しようとすることは、社員に与えるべき貴重な開発経験を外注業者に流しているも同然です。コーディング作業のオフショア開発を増やしたりしたら、それこそ日本のIT産業の基礎をスポイルすることになりかねません。実装作業をアウトソーシングするという経営方針は決定的に誤っています。SEもPGもわけ隔てなく、固定費でもってじっくり育てていかなければならないのです。

　上流を目指す若手技術者の皆さん、自分の技術を過信してはいけません。あなたのいる業界は、PGを2年勤めたら自動的にSEに、SEを3年勤めたらコンサルになれるというような甘いところではありません。年功序列は通用しないのです。この＠ITなどを参照して、つねに自分のスキルを自分で測り、自己研鑽に勤めてください。会社の評価を真に受けてはなりません。悲しいことにいまのSIerは社員をじっくり育てていくという資金的余裕も能力もなくしているところが少なくないようです。あなたがSEとしてどこかに派遣されたとしても、それはあなたがSEとして十分な技量を持っているということにはならない。単に会社の都合で未熟なあなたをSEとして送り込んだのかもしれません。そして派遣先でさせられる作業は、あなたの技術力にほとんどプラスになりません。派遣先では、基本的にあなたに単純作業しか期待しない。あなたが自覚的に自分のスキル向上に努めているのでもない限り、あなたのスキルは空っぽです。そんなあなたがもし30歳ぐらいになって会社にいづらくなったとしても、すぐに辞めてはいけません。それは単にあなたの年齢とともに給料がかさんだので、じつは単純作業以外何もできないあなたを追い出したがっているだけかもしれないのです。

　こんなアドバイスをしなければならないこと自体、実に情けないことです。

（注）Javaの設計書がVBの開発と同じ形式になったのは、Java開発におけるドキュメンテーションの難しさが背景にあるのでしょう。Javaはご存知のようにオブジェクト指向言語で、ソフトウェアの機能は各クラスに分化し、実際のコードはさらにその中のメソッドに区分して書かれます。すなわちVB以上に断片的になっていますので、これをそのまま文書化しても一覧して分かるものではありません。それを分かりやすくする手法としてUMLなどの方法が開発されたわけですが、それを使っても一般のユーザーには何のことか分からないのはあまり変わりません。UMLはむしろ開発者間で仕様を確認するための方法なのです。一般ユーザーに分かるという点では、VBと同じ形で仕様書を書くしかなかったのです。

【IT記事転載】プログラマで、生きている - 上流でも下流でもない場所

2009-09-24T17:01:00.000+09:00

転載 http://el.jibun.atmarkit.co.jp/hidemi/2009/09/post-b9e2.html

当初のタイトルは『続・プログラマなんかで終わりたい』でした。

　あのコラムの中で「いろいろとありまして、派遣社員のままだとこれから先は厳しいと思った」と、おもいっきし圧縮してしまった部分について書いてみました。

　ネガティブな話はあんまり書きたくないなあ、という気持ちがあって、どうしたもんかと思っていたんですが、いくつになってもプログラマやってるとこんな事態も発生し得る、という脅し（？）をかけておくのもいいかもしれないと思いまして（苦笑）。

　以前の記事でも書いたんですが、わたしは派遣で12年ほど働いていました。その期間の大半を、わたしはわりと幸せに過ごしていました。

　はっきりいって、正社員だった頃よりも、ずっとのびのびと働けてたんですよ。

　何を話し合ってるんだかよくわからない社内会議に出なくていいし、電話をとらなくていいし、ずっとコードを書いてさえいればお金をもらえるし、とりたてて生活に困ることもなかったですしね（ゼイタクはできませんけど）。

　なにより、ダメSEにぶつかっても辞めればいい、というのが精神的にとても楽でした。

　派遣で働いていたころ、ほとんどのマネージャやリーダーは、わたしのことを大事に扱ってくれました。

　大事にしてくれたのは、わたしが使い勝手のいいプログラマだったからです。

　わたしはほとんど残業しなくても作業を常にオンスケジュールで動かしていましたから、残業してなんとか間に合わせている人たちに比べて、単価がだいぶ安いことになるんですよ。

　結果として自分は安く使われている、という自覚はありましたけど、それに不満はありませんでした。コストパフォーマンスがいい、というのはエンジニアとして誇るべきことだと思っていましたし、今でもそう思っています。

　そんな感じでけっこう、平穏な派遣生活を送っていたわけですが、それがいきなり破綻しました。きっかけはわたしがテストでミスをしたことでした。

　そしたら、その会社の3年目社員に、「あなたはなんでそんなに仕事ができないんだ！それでみんながどれだけ迷惑をこうむってるのかを自覚しろ！」と、みんながいるところで、大声で、延々と怒られたわけです。

　ちなみに当時38歳だったわたし。多分相手は25歳。

　あんまり年齢を気にしないたちだと思っていたんですが、それはさすがにショックでした。その件で、その3年目社員に迷惑をかけたのは確かなので、それは謝るしかありません。けれど、それがなんで「みんなに迷惑をかけている」ことになるのかがさっぱりわかりません。「わたしに迷惑かけてる」って言えばいいだけなのに……。

　そもそも、3年目にもなって1000ラインのコードを組むのに1カ月かけてるような人（しかもやたら残業して！）に、「仕事ができない」っていわれちゃってることが、どうしても納得いきません。

　あまりにも悔しくって、会社のトイレの便器をげしげし蹴ってしまいましたよ（←陶器はあんまり音が出ないから）。

　この件がきっかけで、わりと長いこと働いていたその会社を、契約が切れた時点で辞めてしまいました。

　相手先のマネージャさんがわたしを高く評価してくださっていて、戻ってきてくれないか、と派遣会社を通じて何度も打診があったんですけど、失職状態で困っていたにもかかわらず、きっぱり断りました。その3年目社員と顔をあわせるのがどうしてもイヤだったんです。

　昔、「意地はって餓死するタイプだよね」と言われたことがあるんですけど、本当にそうなるかも、と思いましたよ。

　たまには変な新人もいるさ、と気を取り直して次に働き始めた会社で、今度は2年目の社員に怒られました。わたしが作ったクラスを使ってる関数でエラーが出るのでどうにかしろ、と言うので、その人の席に出向いてコードを見たら、全然関係のないところでコンパイルエラーが発生していました。

　それをわたしが解決しなければならない理由がさっぱりわかりません。コンパイルが通らなくて困っているのなら「教えてくれ」と言えばいいだけのことです。

　内心、ものすごく腹を立ててたんですが、とりあえず「これはわたしの問題じゃありません」と言ったうえで直し方を教えたところ、独り言らしきものをぶつぶつ言うだけで、後ろに立ってるわたしを振り向かないという状態が10分も続いたので、なんだ待ってなくてもよかったのか、と思って自席に戻ったら「自分のミスを認めないうえに、話の途中で勝手に席に戻った。社会人としてなってない」といった内容のメールを部署内にばら撒かれました（わたしにもちゃんと届きました）。

　なんなの、その「先生に言いつけてやる～」的な行動は。席は1メートルと離れてないんだから声をかければすむだけのことなのに、直接は何も言ってこないで、いきなりメールばらまくという行動に出る、そのとっぴさがわけわかりません。

　その後も「あなたが作ったクラスを使ったら……」攻撃を受け、わたしはすっかり「仕事のできない人」ということになってしまいました。

　2件連続で若手社員に「仕事のできないプログラマ」として扱われたことにヘコんでいたわたしは、偶然とあるブログを読みました。

　「いい年をして、仕事にしがみついている女が職場にいて迷惑だ。正社員にもSEにもなれないでプログラマ続けてるってだけで、どれだけ仕事ができないかが分かる」といった内容でした。

　あの2人のどちらかが書いた、とまでは思いませんでしたが、そういう見方をされてた可能性があるのか、と思いました。

　「いい年してSEになれないなんてきっと仕事ができない人だ」（疑惑）
　　↓
　その思い込みを補強するようなイベントが発生する
　　↓
　「やっぱりそうだった！」（確定）
　　↓
　「なんでこんなダメな人に会社は時給を払ってるんだ」（怒り）
　　↓
　「会社の利益を損なうような人物を雇ってしまったと周囲に知らしめなければならない。本人にもそれを自覚させてあげなければならない」（行動）

　とかいう思考の流れがあったと仮定すると、あの人たちが妙に自信満々にわたしの無能ぶりを触れ回った理由が理解できます。

　まあ、これは単なる推測なのではずれてる可能性もありますが、わたしの中でそれが一番、腑に落ちた答えでした。

　あの人たちはあの人たちなりに正義を為してるつもりだったのか……って、納得してどうするよ、自分（苦笑）。

　40間近になってもプログラマやってる（今はすでに越えてますけど）だけで、「仕事ができない」という疑いをかけられることはわかっていました。それでも、自分の仕事ぶりを見てもらえれば必ず認めてもらえる、という思い込みがわたしにはありました。

　それまでさまざまなダメSEにつきあってきましたけど、面と向かって「仕事ができない」と言った人はいませんでしたし（知らないとこで言ってた可能性は考えないでおこう）。

　40間近になるまでそれを信じることができた、ということは、意外と恵まれたプログラマ人生を送っていた、ということなのかもしれません。

　わたしが積み上げてきたプログラミングのスキルは、コードもろくに読めない人にとってはまったく意味がない。意味がないから、プロフィールから推測される内容でしか、わたしは評価されない。プログラミング以外にわたしの武器はないのに、それを評価されないのなら、これからどうやってこの業界を生き抜いていけばいいんだ？

　その失望感は、わたしにとってはかなりなインパクトを持っていました。

　振り返ってみれば、わたしを評価してくれていた人たちは常にわたしより年上か同年代で、しっかりしたプログラミングスキルを持っていました。けれど、その年代の人たちは現場から遠ざかっていき、これからわたしが相手にしなければいけないのは、プログラミングスキルを評価する能力すら備えていない連中なのか？と思うと、暗澹たる気持ちになりました。

　ちなみに、わたしが新人とぶつかった2社ともIT業界における「上流」の会社でした。わたしを無能と判断した2人もいずれSEになって、「下流」の会社のエンジニアたちを仕切ることになるはずです（←もうなってるかもしれません）。

　コードもまともに読めなくて、プログラマの査定能力ゼロな人が、SEとして君臨することになるわけです。ホラーですね。

　一応、断っておきますが、新人がプログラマの力量を測れない、というのはたいした問題じゃありません。それはある程度、いろんなタイプのプログラマとつきあわないと身につかないスキルだと思うので。

　問題なのは、プログラマの力量を測れない人がプログラマを管理する職責を担うこと、もしくは、その職責を担っていると勘違いしていること、なんです。

　わたしは以前、「上流」の会社のSEの方々にとてもお世話になりました。正社員と派遣を同等に扱ってくれて、いろいろなことを教えてくれました。実質的にわたしをプログラマに育てあげてくれたのはその方々だったと、わたしはとても恩義を感じています。

　ですので、わたしはずっと「上流」の会社というものに対してネガティブな印象を持っていなかったんですが、その連敗はさすがに堪えました。

　就職氷河期の時期にあんな大企業に正社員雇用されたということは、そこそこ学業優秀だったんだろうと思いますが、そこで人生あがれたと考えるような人は、エンジニアとしては何の役にも立ちません。それなのに、「自分は人を使う側だ」という意識はしっかりあるので、タチが悪いです。

　はっきり言って、「上流」の会社の人たちが仕事ができないのは罪なことです。それは、その下で働かざるを得ないエンジニアたちのモチベーションを著しく下げるからです。

　「就職した段階ですべてが決まっていて、自分はどれだけ勉強しても報われない。大学を卒業した時からまったく成長していないような人にこき使われるだけの人生なんだ」と思ってしまったら、勉強するのがバカらしくなっても無理ありません。

　だからこそ、「上流」の会社に入ったからには、仕事のできる人になってもらわないと困るんです。

　きちんとしたコードさえ書いていれば認めてもらえる、という幻想は泡と消えたものの、プログラマを続けたい、という気持ちは折れていなかったわたしは悩みました。このまま年をとっていけば、状況はさらに悪化する可能性が高いですからね。ではどうすればいいのかと考え、正社員に戻ろうと決意しました。

　プログラマとしてのわたしを認めてくれる場所を探して、そこに落ち着こうと思ったんです。わたしは就職活動の際に「定年までプログラマ」を要求し続けましたが、そのまんまの意味は当然のこととして、プログラマとして定年まで使うという決断をしてくれる会社ならばプログラマの評価が低いなんてことはないだろう、と期待したからでもあります。

　「上流」だろうが「下流」だろうが、そんな相対的な位置はどうだっていい（←入れてくれる「上流」があるとは思ってませんでしたけど）。

　わたしをプログラマのままで働かせてくれる会社を探すんだ。

　そういう会社に入れたら、ばりばりばりばりコードを書いて会社に稼がせてやって、年齢なんか関係なくプログラマとして働き続けることができる、ってことを証明してみせるんだ。

　そんな決意を抱いて就職活動をした結果、わたしは無事に落ち着く場所をみつけることができました。世間的には「下流」かもしれませんが、プログラマとしてのわたしを大事にしてくれている、と絶対的に信じることができる場所です。それが、わたしの流れつきたかった場所でした。

　もちろん、この場所がわたしが定年になるまで今の状態を保ち続けてくれるとは信じていません。世の中、何が起こるかわかりませんからね。

　それこそ1年後には倒産してるかもしれませんし（不吉なこと書いてすみませんです、社長）、わたしの気持ちの方が変わる可能性もないわけじゃないですから。

　でもまあ、不安なんか言い出したらきりがありません。

　わたしはコードを書くだけです。

　そして、もっと正確で、もっと美しいコードを、もっと速く書けるようになるんです。

　そうやって、わたしがわたしの願望に従い続けることはきっと、わたしが居続けたい「場所」を守ることにもつながるはずです。

【ＩＴ記事転載】下流から見たIT業界 - SEとPG、どっちが頭がいい？（1）

2009-09-04T13:30:00.004+09:00

転載http://el.jibun.atmarkit.co.jp/karyu/2008/10/sepg1-acb2.html

　ちょっと刺戟的な題名をつけました。しかし決して挑戦的な意図があるわけではありません。SEとPGの分業がIT業界にもたらしている問題が今回のテーマです。

●SEとは何か、PGとは何か

　まずそれぞれの職分を正しく認識することからはじめましょう。プログラマ（PG）とはどういう仕事をする人たちでしょうか。

　いうまでもありません。プログラムを作る人たちのことです。大工さんは家を作る人、漁師さんは魚を取る人。こういった人々と同様にPGもその仕事の内容から自明です。

　一方SE――システムエンジニアの方は必ずしもそうではありません。システムのエンジニア？システムの技術者？ひどくあいまいな言葉です。この言葉はじつはもともと英語ではなく、「OL」などと同じ和製英語だといわれます。海外のコンピュータ技術書にもSEという言葉はほとんど見かけません。日本人が適当に言い始めた言葉だとしたら、あいまいなのも当然です。

　それではなぜ日本ではこんな言葉が使われ始めたのでしょう。これは思いっきり個人的意見なのですが、SEは日本にソフトウェア産業が勃興したとき、終身雇用と年功序列型のキャリアパスという企業風土の特色から生まれた日本独特の職種だったのだとわたしは考えています。

●わたしが受けた新人研修

　ちょっと昔のことをお話ししましょう。わたしのIT業界歴は1980年代後半、大学を卒業して、さる金融機関系のソフトウェアハウスに就職したことに始まります。銀行系の子会社のそのまた子会社でした。当時は銀行の第3次オンライン開発というのがあって、ソフトウェア業界は大量に人手を必要としていました。このことを世間では「ソフトウェア危機」と呼んでいました。わたしはそのとき大量に採用されたSE要員の1人です。

　同期の約6割は2カ月のCOBOL研修を受けて現場に配属されましたが、残りの4割はさらに2カ月間のSE講習を受けました。このSE講習、内容はどういうことかというと、一言でいうなら、主に各プログラムをどのように組み合わせて1つの流れにするかという技術です。すなわちこのとき教えられた SEの仕事とは、処理全体の機能を考えて、各ステップの機能を設計し、仕様書に書くことでした。PGはその仕様書をもとにプログラムを作るという分担です。簡潔で一見何の問題もないように見えました。

●いざ現場では

　しかし実際はこの分業は十分に機能していませんでした。SE講習が終わって現場に配属されると、現場のSEはPGをぜんぜん信用していませんでした。PGに仕事をまかせず、全部自分でコーディングしていました。そうした方が早いし確実だというのです。派遣されてきたSEほどその傾向が強かった。おそらく派遣SEさんたちはプロパー社員以上に作業効率を求められるので、プロパー社員の新米PGなど頼むに値しなかったのでしょう。

　当時わたしたちの会社ではプログラミング作業を集中管理して効率を上げようという目的から、「ソフトウェアセンター」という部署を設け、社内の PGを一カ所に集めて作業させる試みを始めていました。ところがSEさんたちはそこに仕事を注文しないで自分たちで作ってしまうのですから、部長は当然渋い顔です。しかし実際問題、そうやってソフトウェアセンターに集められたPGは、仕様書がよくわからないと文句は言うし、テストはいい加減だし、少しも効率は上がりません。よく考えてみれば、このソフトウェアセンターという組織は、企業の中でオフショア開発を始めてしまったようなもので、うまくいくわけがないのです。2年もたたないうちにこの組織は取りやめになりました。

●技術革新は職制を変える

　どうしてこのようなギャップが生まれたのでしょう。わたしが考えるところはこうです。

　わたしが最初に受けたCOBOL講習では、コーディング用紙を使って手書きでプログラムの作成を行っていました。まず原稿用紙のようなマス目の並んだコーディング用紙に鉛筆でソースコードを書き込むのです。それを外部の業者がパンチカードに打ち込み、上がってきたカードをPGが原稿と1行ずつ照合します。打ち間違いがないことを確認すると、データカードと合わせてカードリーダーにかけて機械に読ませ、テストを実行する。バグがあったらカードを抜き取り、自分で打ったカードと差し替える。このような作業環境では、プログラミングとはかなり手間のかかる根気の要る作業でした（このような環境でどうやってデバッグしていたのでしょう？）。

　このような作業をしなければならないのだとしたら、PGとはそれなりに意味のある職分だったでしょう。しかしわたしが実際に現場に配属されてみると、誰もこんな作業はしていませんでした。当時はすでにタイムシェアリング端末によって、SEもPGもエディタが自由に使えるようになっていました。みんなライブラリにアップロードしたソースを自分で手直ししています。そもそも誰も一からプログラムを書いたりしません。みなどこかから似たようなロジックのプログラムを探してきて、部分的に手直しして作ってしまいます。それが一番手早くてバグの起こらない方法だからです。

●形骸化したSE/PG分業

　タイムシェアリング端末という新しい道具がSE/PG分業を時代遅れなものにしてしまっていたのです。コーディングはSEが自分で行っても何の負担にもならないし、むしろPGに依頼すると、仕様を理解させる過程でコストとリスクが発生します。自分でしてしまった方がはるかに生産性が高く確実でした。設計と実装を区別することは現場では事実上、形だけのものになっていたのです。わたしの会社はソフトウェアセンターを廃止すると同時にSE/PG分業を廃止すべきでした。

　ところがそうはなりませんでした。SEという職種は頑強に残り続け、SEを技術的にPGの上位に置く考え方はなおも業界の常識として残っています。これには単にSEとPGの間の関係だけではない複雑な背景があると、わたしは考えています。

●アメリカではPGはえらい

　アメリカではプログラムを実装する人も設計する人もprogrammerと呼ばれます。そもそもPGの社会的地位が高い。プログラミングは大学ではアカデミックな研究の対象です。大学の先生が書いた優れた学術書が何冊もあります。

　COBOLの開発者グレース・マレー・ホッパーは、女性で、軍人で、最後には准将になって、彼女の名前がミサイル巡洋艦に付けられるまでになりました。PGの扱いは日本と外国とでは天と地ほども違うのです。これは、コンピュータ技術の発祥地アメリカではハードウェアとソフトウェアの重要性が同等に評価されて、コンピュータが総合技術として発展してきたことが背景になっているのでしょう。PGを単純労働だなどと誤解する余地などなかったのです。

●産業界とSE/PG

　日本でコンピュータが商業利用され始めたのはIBMの360が普及した1960年代だと思われます。当時日本ではソフトウェアに対する理解が薄く、 OSから言語処理系から基本ソフトウェアを全部アメリカに依存していました（これは今も同じですね）。ソフトウェア製造については学術的な蓄積はなく、ビジネスソフトウェアの作成は企業主導で行われました。そのとき企業の管理者には、コーディング用紙とにらめっこしながらパンチカードの束と格闘している PGが知的労働者には見えなかったことでしょう。COBOLのプログラムはいくつかのパターンが決まっていて、それを適用して量産することもできました。これゆえ日本の産業界ではPGは「単純労働者」と位置づけられてしまったのだと思います。

　日本の企業は最近まで終身雇用制だったといわれます。それが崩壊して今日さまざまな雇用問題を引き起こしているわけですが、しかし終身雇用制が健在だった時代も、すべての雇用者が定年まで働くことができたわけではありません。業務形態によりますが、単純作業労働を大量に必要とする産業では、比較的賃金の安い労働者を雇用して働かせる必要がありました。そのため企業は、若年者の賃金を低く抑え、一部の従業員には勤続年数が上がって給料が増える前に辞めてもらうようにしていました。

　この雇用形態にぴったりはまっていたのが女性労働者です。女性は雇用されても男性と同じキャリアコースに乗ることはなく、 30歳前には結婚して退職することが暗黙の了解となっていました（いまだにそのような風土を残す企業もあるかもしれません）。企業は「結婚＝女性の幸せ」という価値観を利用して一部の単純作業労働者を辞めさせることで、終身雇用という建前を守っていたのです。

　かつてはソフトウェア開発もこのような形態をとっていました。わたしが就職したときには、PGとして働いていた社員の半数以上は女性でした。今では考えられないことです。彼女たちは非能率なパンチカードによるコーディング作業を黙々とこなし、5年も勤めると誰かに見初められ、結婚し、仕事を辞めていったのです。今でも古くから使われているシステムには、彼女たちが作ったプログラムが現役で動いているかもしれません。時にそのソースコードはよくレイアウトされた印刷物のように美しく整えられていたりして、彼女たちの「意地」を感じさせられます。

●「スキル目標」としてのSE

　その一方で男子従業員は会社に残って技術の中核を担っていくことを求められました。彼らにがんばってもらうには、彼らを単純労働者としてのPGとは差別化する必要がありました。SE（システムエンジニア）というあいまいな言葉は、このようにして社員に技術の向上を促すキャリアステップという意味で使われ出したのではないかと思います。

　以上のことをまとめていうと次のようになります。本来ソフトウェア作成の高度な技術の担い手であったPGは、日本ではその現実的な作業形態から「単純労働者」と考えられてしまった、そのためソフト作成の知的性格を表現する言葉として「SE」という言葉が使われるようになったのです。

　これだけならば「システムエンジニア」という言葉は別に害になるものでもなく、たんに上級PGという意味を表す日本独特の業界用語ということに収まったでしょう。ところが実際にはこれによって生まれるSE/PGの区別が厄介な問題を引き起こすことになりました。

●1990年代に起こった変化

　1990年代になってCOBOL開発に呼ばれたことがあります。その頃にはもう開発現場に女性の姿はなく、男ばかりの世界になっていましたが、当時は気にもとめませんでした。ゆっくりした変化はなかなか気付きにくいものです。このときは気付かなかったもう1つの重要な変化がありました。それは設計作業をしているのは元請会社の社員で、実装作業をしているのはもっぱらよそから派遣されてきた外注PGだったことです。

　このときの開発のエンドユーザーは旅館業です。テレビCMでも聞いたことがある伊豆の有名旅館の客室管理システムをOAで作ろうとしていました。実装している外注PGには、十分にスキルのある中堅どころがそろっていました。それに対して設計しているのはプロパーの若手社員。設計力のレベルに不満があったのでしょう、元請の先輩社員がしきりに後輩を叱咤していたのが印象に残っています。

　ソフトウェア開発では早くから派遣労働が普及していました。これは作業の専門性からいって仕方のないことですし、少なくともこの頃のCOBOLの開発現場では、派遣労働を正当に評価してもらっていましたから不利になったという感じはありませんでした。むしろプロパー社員のがんばりに感心していたくらいです。しかし今から考えるとそんなことより、その元請がスキルに不安のある自社社員をあえて設計に起用していたことに疑問を持つべきでした。この会社では設計とプログラミングを分け、後者をアウトソーシングしていたのです。

●アウトソーシングとSE/PG

　ここでソフトウェア開発でなぜアウトソーシングが増えるのか考えてみましょう。製造作業の一部を外注することのメリットを理解するには、損益分岐点分析というちょっと面倒な原価計算の理屈が必要になるのですが、かいつまんで説明すると、固定費である労務費を変動費である外注費に切り替えたほうが、利益が出るようになる売上高、「損益分岐点」が低くなるのです（注）。

　売上高を急激に伸ばすことが期待できないソフトウェア開発では、固定費を少なくする方が有利です。日本のIT産業は、かつては女性の結婚退職を隠れ蓑に、ひそかに高齢になった労働者の一部を排除することで非効率な部門の固定費を削減していたわけですが、男女雇用機会均等法の制定などでそのようなことができなくなり、その代わりに固定費をアウトソーシングという形で変動費に変える道を選んだのです。

　まあ、以上のようなことは本当はきちんとしたデータをもとにして主張しなければならないことで、その意味ではこれはまったくのわたしの仮説にすぎません。しかし今日、日本のSIerの多くが企業利益のためにアウトソーシングを積極的に行い、その外部委託作業を切り分けるためにSE/PG分業を境目にしていることは、だれもが認めることでしょう。

　このアウトソーシングによる利益設計、すなわちビジネスモデルは、プログラミング作業に対するある先入見――プログラミングは単純作業であるという思い込みにもとづいています。PGは使い捨てにしても構わないが、SEは設計という「高度な」作業をして、顧客の業務知識を蓄積していってくれると。日本のIT企業のトップはどうしてこの誤った認識を改めることができないのでしょう。それが事実に見えた時代が一時はあったにせよ、少しでも現場に目を向けていればその誤りを容易に理解できることでしょうに。まるきり古い時代の、実質的に意味のなくなった分業区分をいつまでも有効であると信じている。間違った区分で外部委託の範囲を決めたことが、どれほどの問題を引き起こしていることか。

　その実態については、長くなりますので次回に述べたいと思います。

●PGは単純作業ではない

　これはわたしの持論ですが、プログラミングとは究極の「手仕事」です。どんなに技術が進んでもプログラミングという作業は残る。それは絶対にコンピュータにはできないことなのです。なぜならそれはコンピュータがすることを前もって考えることなのですから。この手仕事は職人仕事の性格を持っています。品質が製作者個人のスキルに大きく依存しています。しかもそのスキルはパターン化することができず、訓練では身につかない。PG個人の強い自発性がなければスキルアップしない。

　プログラムは、どんなものでも個人の技術の力量が問われる知的著作物です。上手な人が書いたプログラムは、まるで物理学の方程式のように美しい。そんなプログラムは当然バグも少ない。あっても見つけやすいのです。それがまるで大量生産品のように思われているのは、そういう作り方をすればできてしまうからです。困ったことにそれでもシステムは動いてしまうのです。

　経営者の方はこういうかもしれません。「なるほど、たしかにプログラミングは職人仕事かもしれない。優秀なPGを使えば品質の高いプログラムを作ることができるだろう。しかし優秀なPGを探すのは大変なことだ。安い労働力を使った大量生産方式でも、動くプログラムができるならそれでいいじゃないか」と。

　しかし考えてみてください。プログラムのほんの小さなバグがシステム全体に影響を与えるのです。1箱に不良品が3％以下なら許容できるというような話ではないのです。最近銀行のシステム統合で頻発した不具合のことを思い起こせば、その影響が理解できるでしょう。

　プログラマを粗末にしたらバチがあたりますよ。

（注）こちらのページにわかりやすく説明してあります。

プログラム楽しみ 编码的乐趣