仕事を楽しくなるようにしよう （2003/1/5 掲載)
△ デフレをチャンスにする
２００２年は、戦後の日本経済にとって試練がハッキリと見えた年でした。デフレの進行と不良債権の処理の加速によって多くの企業が倒産し、さらに経済のグローバル化が進んだことによって、戦後の日本を支えた「製造業」の足場が揺らぎ始めた年でした。そして２００３年は、この流れが加速すると思われますので、一層厳しい状況になることが予想されます。ただし、私はここで悲観論を展開するつもりはありません。むしろ、デフレの「北風」が吹く今こそ、時代が何を求めているのかを冷静に見極め、自分の能力を高めてアピールするチャンスとすべきなのです。市場（顧客）も「偽物」と「本物」を見分けようとするはずです。
この業界の根深い問題として、プログラムがちょっと書けるというだけの「ソフトウェア・エンジニア」が多過ぎることが挙げられます。KLOC当り３０件以上ものバグを出し、その結果としてプロジェクト期間中の月平均の生産行数が５００行にも満たないという状態にも関わらず、一向に改善しようとしないエンジニア、そして彼らに対して何ら有効な方策も講じることもなく、そのまま抱えているソフト会社が少なくありません。顧客の要求を満たせる見込みもないのに、いい加減な営業をしているソフト会社も目に付きますし、いつまで経っても、そのようなソフト会社を排除できない発注側企業の非力さも変わっていません。
デフレは、事業機会の減少に繋がるケースと、機会よりもコストの引き下げ圧力となって表面化するケースが考えられます。いずれの場合もデフレの「北風」は、ソフト会社やエンジニアに対しては「選択の風」となるでしょう。その意味では、きちんと腕を磨くエンジニアとそうでないエンジニアとが識別されるでしょうし、ソフト会社や企業の組織そのものも、いい加減な組織は淘汰されることになるでしょう。
こうしたデフレの状態がこの先も（少なくとも数年は）続くとすれば、頼りになるのは、自分の能力しかありません。市場が要求する「ＱＣＤ」を満たせるような知識と技術を着実に身に付けるしかありません。そのためには、とにかく仕事を楽しくなるようにやり方を変えることです。
△ 仕事を楽しんでいるか？
コンサルティングの仕事をするようになってつくづく感じるのは、ソフトウェアの開発という仕事を楽しんでいるエンジニアが少ないことです。多くの場合、「仕事だからやっている」という返事が返ってきます。その仕事を楽しんでいないということは、「苦痛だけど」あるいは「他に仕事がないから」続けているということにもなりかねません。
仕事というのは、最初から楽しい状態にあることは稀です。楽しくなるのは、その仕事を上手くこなせるだけの技術や知識が身についてからのことです。問題は、その知識や技術を、いつ身に付けるかということです。ただし、ソフトウェアの仕事の場合、技術がどんどん変化するので、知識や技術の種類によっては習得を日常の中で継続させなければなりません。そうして、仕事がうまくできるようになれば、仕事は楽しくなり、そのことがまた日常の学習行動の動機に繋がっていきます。結果によっては報酬も増えるでしょう。
でも、現実問題として、仕事を苦痛に感じている人は多いのではないでしょうか。顧客の要求を上手く把握できないために、途中で頻繁に発生する仕様変更に振り回されることになります。当然、そのままでは約束した納期には間に合わないので、自分の持ち時間を提供して夜遅くまで“頑張る”ことになります。でも、ソフトウェアの世界は、必ずしもそれでうまくいくわけではありません。今度は、必要なプロセスを省いたことによるバグに追い回されることになります。こうなると仕事は苦痛になってしまいます。楽しくなければ、そこから逃げようという心理が働きます。家に帰ってまで勉強しようという気にはなれないでしょう。私よりも早く寝ていても、「勉強する時間がない」ということになります。
自分のことをここで並べるのは少々気が引けますが、実は、私もこの世界に入って数年目の時に挫折して別の世界に“逃避”したことがあります。その時の“理由”は「技術的行き詰まり」です。でも半年たって、必要な勉強をしていなかった自分に気がつきました。上手くいかない原因を顧客のせいにしていたのです。そして別の世界を見たことで、ソフトウェアの世界がなんと創造的な世界であるか、ということに気がつき、そういう世界を捨てた自分自身を後悔しました。そこにはしっポを巻いて逃げた「負け犬」の自分がいたのです。
そうして何とかして１年後に元の世界に戻ったのですが、そこから２年余りは“がむしゃら”に勉強しました。「人生の負け犬」にはなりたくない、という思いがそうさせたのです。仕事が終わって家に帰ってから、ソフトウェアの基礎知識やいろいろなプログラミング方法や設計技術など、一から勉強し直しました。ＯＳの勉強はもちろん、当時はビジネス・アプリケーションを中心に仕事をしていましたので、実際に仕事で必要になると思われる業務知識も文献や雑誌などで手に入れました。オンラインの勉強もやりました。やり始めると、他に不足していることがどんどん見えてきます。やればやるほど、勉強するテーマが見えてくるのです。かつてこの世界から逃避したときには、此処まで見えていませんでした。いや、ただプログラムが書けるだけで何も見えていなかったのです。
要求を的確に掴むための表現の工夫や考え方も、概ねこの時代に手に入ったのです。そうして取り組んでいるうちに、仕事がスムースに行きだしたのです。その後は納期を遅らせることもなく、顧客からの仕様変更は適度にコントロールできるようになっていました。「仕様の変更は顧客から来るよりも、むしろ設計者が呼び込んでいることの方が多い」という考えも、この時の経験から手に入ったものです。組み込みの世界に転向した後も、この時に身に付けた習慣は、私を支えてくれました。
仕事の結果を顧客やベンダーから評価されるようになれば仕事は楽しくなります。今までできなかったことや、分からなかったことが、勉強することでできるようになり、それが仕事に使えて結果に繋がるのですから、どんどん楽しくなっていきます。楽しくなるからまた勉強します。逃避から復帰した後は、仕事を「苦痛」に感じたことは一度もありません。負担に感じることはあっても、それは全て解決する課題であり、勉強するテーマでした。また強くなれる機会を得たと思えば苦痛には感じなかったものです。
△ 必要な知識や技術の習得ができていない?
こうしてやって来た自分を振り返ってみると、今、ソフトウェアの仕事を楽しく感じていない人が多いというのは、やはり、仕事をうまくこなすために必要な知識や技術が不足しているのではないかと思われるのです。多くのソフトウェア・エンジニアたちは、実際に就職してから、ソフトウェアの設計に関する勉強を始めていると思われますが、現実には、「プログラミング」が中心になっているのではないでしょうか。
時代が変化し、事前に身に付けておくべき知識や技術が増えているにも関わらず、バブルがはじけてから、企業の方も初期教育に多くのコストをかけることができなくなっているため、ソフトウェアの「設計」に関する教育内容が不足しているものと思われます。初期教育の内容は、もしかすると２０年前と変わっていなかったりします。
実際に、現場でオブジェクト指向に基づいた言語を使っているとしても、実際に分析や設計作業において、オブジェクト指向の方法や手順をスムースに使えている人はどれほどいるでしょうか。いやその前に、モジュールの尺度という知識を持っていなければ、別の根本的な問題で足下をすくわれることになります。
何とか、「プログラム」は書いていても、それが思ったようには動いてくれなければ、手直しの繰返しになってしまい、顧客の要求に応えることはできません。設計の仕方によっては１０００行余りの定義行と５０行前後のステートメントで済むような状態遷移の処理が、５０００行もの実行ステートメントの塊として作られてしまいます。当然、テストも大変ですし、バグもたくさん入り込むでしょうから修正が繰り返されます。それよりもパフォーマンスが期待通りにはいかないかもしれません。そうなると（別の人が）作り直すことになって、生産性を著しく低下させます。
生産性が悪いということは、多くの場合、自分の持ち時間を投入することになり、その分、勉強に使う時間が減ってしまいます。これは、知識労働者であるべきソフトウェア・エンジニアにとっては致命傷となります。結局、これが「悪循環」の始まりとなって、「デスマーチ」へと突っ込んでいくことになります。この状態では、仕事を“楽しい”と感じることができるはずはありません。
うまく仕事をこなす方法を手に入れなければ、この「デスマーチ」サイクルに入ってしまい、ここから抜け出せなくなります。設計技法などは、確かに上手く仕事をするための方法ですが、「デスマーチ」に入ってからでは、なかなか習得する時間を確保できません。「デスマーチ」に入った状態でも手に入れることのできる「脱出するための方法」は、ごく僅かに限られたものしかありません。
△ 後退し始めたソフト開発組織
ソフトウェア・エンジニアの能力は、彼らを抱える組織の能力を表現することになります。最近のソフトウェアの組織を見ていると、９０年頃と比べて状況は悪くなっているのではないかと思われます。以前なら、このような問題は起きなかったのではないかと思うことがしばしばあります。バグの発生頻度も増えている組織もあるのではないかと思われます。
エンジニアへの教育能力も低下しているようです。初期教育については既に触れましたが、その後の継続的な教育も、ほとんど現場の「個人」に任されています。一つのプロジェクトを通じて、エンジニア各自に対して何を学習させるかという「計らい」が見えないのです。実際に、課題を与えられてプロジェクトに参加した経験を持っている人はほとんどいないのではないでしょうか。
プロジェクトが終わった後のデータも、ほとんど整理されることがないため、そこから改善のネタを手に入れることなく、次のプロジェクトに突入してしまいます。私に言わせればバグは「金鉱脈」であり、組織や個人の「レントゲン写真」です。これを掘って分析することで、自分（たちの組織）の問題点が見えてきます。ところが現実には、逆に土をかぶせて葬ってしまいます。これでは組織としての「意思」が、どこにあるのか見えてこないのも無理はありません。
これは組織の責任者が、自分が任されている組織をどう育てていくかという認識がないことが原因として考えられます。ただ、自分の組織に割り当てられたプロジェクトに取り組んで、それを仕上げることしか考えていないのではないでしょうか。いい加減な見積りや計画が行われていることも認識していない部門長もいます。ただ（良い）結果しか気にしていないのです。
このような部門長は、組織のメンバーの人生を預かっているという認識もないのでしょう。ただ、鶏のように卵を産んでくれればよいと思っているのではないかという気がします。数年後に人事異動でその職場を離れた後、元の職場のエンジニア達がうまくやっているだろうか、あの時身に付けさせたことが今でも役に立っているだろうか、と気になるそぶりも見せない人（部門長）が多くなっているように思えます。
組織の能力が後退した理由としては、不用意なリストラも上げられますが、“人の能力を活かさない”旧態依然とした人事の影響の方が大きいと考えています。その人事の改革に踏み込む組織と、依然として「立ち入り禁止」の札を立てた組織とでは、大きな差になってくるでしょう。実際に、そこに気がついて踏み込み始めている組織が出てきたようです。
△ 高給が取れる職業へ
一般には、ソフトウェア・エンジニアだからといって、他の職業と比べて格段に給料が高いわけでもありません。一部に高い報酬を取るソフトウェア・エンジニアもいますが、彼らは、今の日本ではおそらく特殊な存在だと思われます。多くのソフトウェア・エンジニアたちは、自分たちの給料を「世間並み」と見ているでしょう。むしろ、仕様の変更やバグの修正などで夜遅くまで仕事をしている分だけ、過酷な仕事（新３Ｋの仕事）と認識しているのではないでしょうか。
工場などの生産現場と違って、ソフトウェアの世界は時間の投入が必ずしも生産量の向上につながりません。時間を３０％増やしたからといって、ソフトの生産が３０％増えるわけではありません。比較的、時間が生産に結びついているのは、ソースをコード化するプロセス（いわゆる実装プロセス）ぐらいです。ただし、これも事前に適切に設計されいているときしか実現しません。
これ以外のプロセスでは、時間が生産性に比例する適切な範囲があって、それよりも少なすぎるようでは、あとで不足した作業を補うような作業がつぎつぎと発生し、終わってみると適切な範囲を越えていたということになってしまうでしょうし、必要以上に多過ぎるときも使途が曖昧な成果物を生み出すような無駄な作業を繰り返している可能性があります。ソフトウェアの開発作業には、要求に応じて、その範囲に収まるような適切なプロセスを設計することが求められるのです。その意味では、現状のソフトウェア開発の現場には、まだまだ生産性を改善できる余地が残されていると見ています。
デフレが一周したことで、昨年当りからソフトウェア・エンジニアの給料も引き下げられる方向に働いています。要求を満たすための上手いプロセスを設計できなければ、疲弊するだけで給料も下がってしまいます。この状態が「主流」になってしまうと、「ソフトウェア・エンジニア」という職種も色あせたものになってしまいます。
でも中国やアジアの国では、「ソフトウェア・エンジニア」は明らかに高給取りの職業であり、“選ばれた者”という認識があるため、その後の行動がまったく違ってきているようです。もちろん、期待されている働きができなければ、その仕事（職）を他の人に渡ることになります。折角、高給が取れるチャンスを手に入れたのに、簡単に手放すわけにはいきません。だから必死なのです。その結果、「ソフトウェア・エンジニア」という職業の地位が保たれることになります。
これに対して、日本では“選ばれた者”という認識でこの仕事をやっている人はどれくらいいるでしょうか。一部にいることは見えていますが、１割もいないでしょう。もともと給料に差がないことも影響していると思われますが、それは“期待されている働きができなければ、その仕事（職）を追われる”という事とセットでないと実現しません。これを受け入れなければ、「ソフトウェア・エンジニア」という職業も、他の職業と同じような扱いを受けることになるでしょう。そしてその先にあるのは、「ソフト産業の停滞」です。
２１世紀は、ソフトウェア無しに社会が成り立たない時代です。そこでは優れた「ソフトウェア・エンジニア」が必要なのです。優れた「ソフトウェア・エンジニア」には、それなりの報酬が得られるという社会の認識も必要ですが、同時に「自分たちは、２１世紀の産業の担い手である」という自覚の下に仕事をして欲しいのです。「プロ」というのは、そこから生まれるのであり、社会的な認知もそこから広がっていきます。
デフレが進行して、他の職業では所得が低下しても、ソフトウェアの開発の世界だけは、一人ひとりが生産性を上げることで“別世界”の状態にしなければならないのです。そうすることで、優れた人材を“此処”に呼び込まなければならないのです。それは、今、この仕事についている人の責任でもあるのです。
△ 危険な世代
そこで引っ掛かってくる問題があります。９０年前後のバブルの絶頂期に、日本の企業は新卒学生を大量に採用しました。大手の電機メーカーでは、３０００人と公表されていましたが、実態はそれを１０００人以上も上回っているという報道もあります。その結果、一つの企業で数年間で１万人という「新人」が増えたのです。彼らが全員ソフトウェアの仕事についているわけではありませんが、半分ぐらいは、ソフトウェアの開発に関係しているものと思われます。
当時、バブルの膨張によって、たしかにビジネスは拡大したかに見えました。でも、たとえば技術系に絞ってみると、それだけの新人が必要なほど事業が拡大していたとは思えません。数字が膨らんだだけです。他社が就職協定を破って“青田刈り”に走る中で、“人材獲得”に遅れを取ってはならずと、あらゆる「苗」に値段を付けてしまったのです。３社も５社も内定を手に入れた学生も少なくなかったのではないでしょうか。だから学生の方も、就職のことなど心配する必要は、ほとんどなかったと思われます。
その当時と比べると、今の学生の就職に対する意識の違いは非常に大きいと思われます。現実に学生が取り組んでいる行為が適切かどかは別としても、誰でも就職できる時代ではないことは、今の学生は認識しています。最近では５人に１人は無業者となっています。だから、真面目に就職に向き合っている学生が増えたのです。もちろん、それでも最初から諦めている学生もいます。
バブル期の絶頂期に採用された人たちは、現在３０代前半で、組織にとって重要な「世代」となっていますが、同時に、団塊の世代よりも大きな「こぶ」となって組織を膨張させているものと思われます。したがって、彼らの働きが組織の存亡を左右することになります。彼らが生産性を落とせば、その組織はたちまち行き詰まるでしょうし、彼らが新しいことに挑戦することを躊躇したら、後に続く世代の芽を摘み取ってしまうことになります。これは組織にとっては大問題です。だから、大手の電機メーカーでは、この世代に対して再配置と再教育に取り組んでいるのです。
バブル期の大量採用には間違いなく無理があったと思われます。必要以上の人数を採用した結果、初期教育だけでなく「ＯＪＴ」という現場での教育も行き届いていません。その後の「２０００年問題」に伴うソフト改造の“特需”も、その教育の不徹底に輪をかける形になりました。そして、個人の能力が十分に開発されない状態で現場に投入されているものと思われます。
そのことは、一般には生産性が一向に上がっていないという形になって見えるのですが、プロジェクト毎に生産量や生産性のデータをきちんと取っていない組織には何も見えません。結局、その不足を埋めるべく新たに要員が投入されます。これが「分担の分譲」です。この分譲は、あとで買い戻されることはなく、その時点の能力で納期に間に合う量が模索されます。それでも給料は減らないのですからこのままの状態で安定するのです。つまり、この状況においては、個人の能力が開発されずに、「現状」で（間にあう状態で）能力が停滞してしまう危険があります。最初から組織に余分な人がいなければ、この方法は取れなかったのですが、大量に採用された世代であっただけに、安直にその場しのぎの策がとられたものと思われます。
そして今、この世代が苦しんでいるのではないかと思われます。年代的にも組織の中で重要な位置にいるでしょうから大変です。彼らは見よう見まねでやってききたのです。ソフトウェアの設計技術などのソフトウェア・エンジニアリングに関する技術も、プロセスの設計技術も、チームのマネージメント技術も、みんな不十分な状態と思われます。中にはこのことに早く気がついて上手く状況を打開した人や、上司や先輩に恵まれてこれらの技術を習得した人もいると思いますが、多くはないでしょう。１０年かけて身体に染み込ませた「自分の持ち時間を投入するスタイル」は簡単には変わりません。
本人がこの状態を自覚しているのであれば、周りの人も手助けできるのですが、現状を「問題ない」と認識している限り、今の日本の組織ではどうにもできないかも知れません。生産性などのデータを見せて、「問題」に気付かせてあげるしか方法は無いかもしれません。何れにしても、このまま放置していては、彼ら自身の将来への道が途絶えてしまうし、組織も競争に勝てなくなります。
今からでも、不足する技術や知識を増やし、守備範囲を広げて生産性を高めて欲しいのです。組み込みの世界にいるのであれば、ソフトだハードだなんて“境界”の争いをやめて、生産性を上げるためにハードの世界にも少し足を踏み入れて欲しいのです。そうして、時代の求めるソフトウェア・エンジニアとして立ち上がってくれることを願っています。
この世代が、組織の中で人数的にも膨らんでいる「層」だということは、逆に、「管理者」への道とは別に、ソフトウェア・エンジニアとして極める道も出てきます。人数が多いという不利な状況は、違う場面では有利に働くものです。今からでも勇気をもって仕事が楽しくなるように挑戦して欲しいし、組織もこの世代を活かさなければデフレの時代に活路は見い出せないでしょう。
△ 上手く行く方法としてのプロセス改善
今年は多くの組織において「ＣＭＭ」に取り組まれるものと思われます。組織としては、生産性やコストを引き下げるために現状のプロセスの改善や品質の改善、さらにはそのような状態を維持できる組織とする方法として取り組むでしょうが、個人的には、これを「仕事が上手くできるための技術を手に入れる」機会と捉えることもできます。というより、そのように取り組んで欲しいのです。
「ＣＭＭ」をよく読んでみると、これを実現するには前提となる幾つかの技術が必要なことが見えてきます。例えば、「要件管理」に取り組むには、要件そのものがある程度うまく表現できて、仕様の変更が管理可能な範囲に収まるようでなければ要件管理は破綻します。逆に仕様の変更が管理可能な範囲に収まるようになっているということは、顧客との間で仕様について合意ができる状態になっているということでもあり、当然、仕様関係のバグも確実に減ってきます。さらには、仕様が見えたことに伴って見積りも容易になり、途中の仕様の変更が減ってくれれば、初期の見積りを大きく崩す要因も減ることになります。
このように「ＣＭＭ」でいうところの「要件管理」を実現しようとするだけでも、前提技術から取り組めば、こうした効果も得られるのです。これを、ただでさえ忙しいのに「要件管理」なんてやっておれない、という姿勢では、現状を打開するきっかけは何も手に入らないのです。
「要件管理」の副次効果としてはこの他に、顧客の求める内容が見えたことで、自分たちにとっての課題やリスクも見えてきますし、何よりも要求を実現するための「プロセス」を設計するのに必要な情報が手に入ります。この時、プロセスを表現する技術や大きさ（粒度）に関する知識が少し必要ですが、要求が仕様化されていることで、今回はどのような作業（プロセス）が必要か、どのような中間成果物を繋いでいけば最短のプロセスになるかを考えることができます。その結果として有効な開発スケジュールに繋ぐことができるのです。プロセスが設計された状態からスケジュールへは容易に変換できます。
これまで、ソフトウェアの開発作業を崩しているのは、ほとんどの場合、要求の仕様化プロセスに欠陥があったからで、「ＣＭＭ」の要件管理に取り組むには、先ずはここを改善しなければなりません。組織が「ＣＭＭ」に取り組むということは、「要件の仕様化プロセス」の問題に取り組むチャンスが手に入るということでもあり、その結果として、これまで繰返してきた要件の手直しによる混乱の状況を改善できる可能性が出てくるのです。「デスマーチ」から脱出するにも、多くの場合、ここから手をつけるしかありません。
プロセスの改善というのは、上手くいっていない現実のプロセスを修正して、使えるところは改善して使うし、使えないところは新らしい考えを取り入れて一連のプロセスに繋いでいきます。それを試行しながら上手くいくプロセスを作り上げていくのです。そしてその取り組みをしながら、要件管理やスケジュール管理、構成管理などに取り組むのです。現状の上手くいかないプロセスをそのままにして、その上に要件管理や進捗管理などを持ち込んでも上手くいかないことは誰の目にも見えています。だからこそ、多くの人は取り組めないと「反発」するのです。でも、要求の仕様化に取り組めば、このような「反発」は、意味のないことが理解できるようになります。
ただし、「ＣＭＭ」に取り組むといっても、「ＣＭＭ」には、その方法は書かれていませんので、必ずしも「要求の仕様化」技術が自動的に手に入るというわけではありません。残念ながら、適切な文献もないというのが現実です。そこで、私が持っている簡単な「仕様化」の方法について、今年は、このＨＰで幾つか紹介できると思いますので、参考にして下さい。
いずれにしろ、デフレの時代に打ち勝つには、早い段階でソフトウェアの開発作業が“上手く”できるようになって、自分の持ち時間を“次”のための勉強や研究に確実に投入できる体制を手に入れることです。それが、この世界で長く活躍する場を確保することにつながるし、何よりも、仕事が楽しくなるはずです。
２００３年１月
「硬派のホームページ」主催者より