【第35回】How to SE

最近いろいろなシステム開発の現場で目が点になるような大事故が多発しているようである。その原因の多くがオープンの時代に入社して、ソフトウェア工学を全く学ばないでドキュメントも無用スパイラルでいこうと育った人々が、30代~40代の中堅になってきて、基礎的な設計力もないままに大規模なシステムを開発するために起きる事故である。これは悲劇である。
SEの仕事は傍から見ると、PGが多少組めればその延長上で誰でもできるような仕事に見えるが、プログラミングとシステムの設計は全く違う仕事なのである。その違いがわからず素人を平気で大仕事にアサインしたりして起きる事故である。これは100%人災と言うしかない。
SEの仕事をバカにして素人を投入するというのは、この職業をナメきっているとしか思えない暴挙である。
SE稼業がどういう訓練の上に成り立つのかをここで解説してみたい(これを読んで理解できない人は素人か、根っからのPGなので、あまり上流工程にかかわらない方が身のため(命のため?)だと思います)。

まず、入社数年でその人がSEになれるかどうかが決まる。40才から一念発起しても不可能である(少なくとも筆者の経験でそうなった人を見たことがありません)。
まず一流のPGになることが第一歩、そこから大きなブレークスルーが必要である。それは「量から質」への転換である。別の言い方をすれば、「仕事を科学する心」が芽生えないと設計の重要さは理解できない。そのためにPGから設計に至る量から質への転換は以下のようなプロセスを経て実践される。


スタート

仕事が面白い(面白さをいかに発見するかがポイント)

たくさんプログラムを組む
↑     ↓
時々褒められる

量産(生産的)に限界が見える

残業しても徹夜しても限界がのびない

何故こなせないか悩む

仕事のやり方を変える
    ↓   ↑NO
手数を減らして質を作り込めるか

|YES

GOAL


筆者はかつて新人の頃、どうやったら完璧なプログラムが書けるかチャレンジしたことがある。その頃はアセンブラを組んでいた。

まず、文法、命令を完璧に頭に叩き込んだ。次に、それを極めて正確に記述して、最初から机上デバックをやった。その次にマシンのように正確に打ってタイプミスをなくした。
この段階まで行くとコンパイルは一発で通る(昔は今のようにPGを怠け者に変えるデバッカーというツールのはありませんでした。従ってモンキーデバックというバカな仕事のやりかたもありませんでした)。
これでプログラムは極めて早く出来たが、仕様どおりでないとSEから叱られて手戻りが発生した。そこでSPEC(プログラム仕様書)を呑み込むまでじっくり読み込んで、SEの記述の癖、阿吽(あうん)の欠落を理解するようにした。

その次にデバックの方法にメスを入れた。最初にコンパイルしてテストすると(単体テスト)、バグが山のように出る。そのバグに最初は100ヶ所、次にコンパイルすると50ヶ所、次にコンパイルすると30ヶ所という具合に、最初の段階では等比級数的に減少する。バグが1桁になった時がまずポイントである。デバックのスピードを落とすのである。具体的には1回の修正で1ヶ所しか直さない。それで再度コンパイル、テストして、1つずつじっくり直していくのであ る。1桁台まで生き残ったバグは非常に複雑な要因を持っているのでしぶといのである。そこで心を鎮めて勇気を出してデバックのスピードを落として1回に何ヶ所も修正せずに1つ1つのバグを仮説と検証を繰り返しながら科学的に潰してゆくのである。
これで完璧にSPEC通りのプログラムが出来たと思ったら、設計変更がまだ発生するのである。それはその前後のプログラムが生成するデータに不整合や不備があって結合テストをやると動かなくなるからである。そこで自分のプログラムのスペックだけでなく、前後のプログラムのSPECにも目を通して不整合を最初から折り込んでデバックした。

そのうちに筆者は1本のプログラムを請け負うのにサブシステム全体を理解して取り組むようになった。その頃までいくとSEのバカさ加減が見えてくるので、これなら俺が設計した方が早いと思って設計の道に進むわけである。
ここまでがPGからSEへの入り口の1プロセスである。

だが、設計の道はそんなに甘くはない。

筆者はかつて25歳くらいのときに初めてHIPOで詳細設計を任されて失敗したことがある。
その頃の先輩も全くソフトウェア工学を学んだことのない人だったので、最初は1本のプログラムの詳細設計をやってくれと任された。
見様見真似で喜び勇んでアルゴリズムを書いていたら、その頃のHIPO規約はダイクストラのGO TO文不要論が幅を利かせていた時代だったので、正直に書いていったらA3で180枚の大プログラムになってしまった。今から考えると先輩の見積りミスである。ステップ数で1万行余り、2週間の納期ではバグが潰しきれず筆者は退場させられた苦い思い出である(これがソフト屋人生の唯一の失敗であります)。
この時にソフトウェア工学を真剣に学ばなければならないと決心した。
「アルゴリズムの王」になろうと決心したのである(本メルマガ第5回目参照)。
マイコン制御の自由な世界から大型汎用機の世界にいったのはそういう背景からである。設計を1から学びたいと志したからであった(これを自分の中で「急がば廻れ戦略」と呼んでいます)。

話が長くなるのでそれからの過程は割愛するが、その後以下のように進んでいくことになる。


上級プログラマ(上級プログラミング)

サブシステム担当SE(詳細設計)

複数サブシステム担当SE(基本設計)

プロジェクトリーダー(概要設計、基本設計)

複数プロジェクトマネジメント(開発計画書、要求定義)


実は上級プログラマまでが自分1人でできる世界である。
サブシステム担当になると、人に組んでもらわないと出来ない世界になる。
複数サブシステム担当SEとなると、人に働いてもらわないと出来ない世界になる。
プロジェクトリーダーになると、人に任せないと出来ない世界となる。
プロジェクトマネジメントSEになると(旧ユニバックでは(ユニシスではありません)このレベルが課長でした)。任せる人を育てないと出来ない世界となる。

その過程でSEの3スキルを身に付けなければならない。
即ち、1つがテクニカルスキル、自分自身の技術力2つめがマネジメントスキルで、自分が命令を出す人(部下、協力会社)への交渉力である。
3つめがポリティカルスキルで、自分に対して命令を出す人(上司やお客様)への交渉力である。この3つのスキルを磨かなければならない。その上でアプリケーションやITインフラの深い理解力が必要になる。それゆえ、SEは2年や3年では養成することが出来ないし、当人になりたいという固い意思がないと導くことの難しい世界なのである。こうした地道な訓練を10年くらい続けてやっと1人前なのである。
大プロジェクトに素人さんがチャレンジして失敗するのは必定であるし、マニュアルを読んで明日からやれる商売でもないのである。

じつは素人さんには素人さんが理解できない。

だいたい「経験がないからできません」というSE?(もどき?)は「自分の能力ではこの仕事は無理です」と主張していると読み替えないといけないのである。
経験なんか関係ないし、経験で進むのはある特殊な業務知識だけであって、それにしても経験によすがを求めるような人に新分野は不可能である。
人間は最初からできないと思ったことはいつまでたってもできないのである(経験を人質にしているので、できるようになるための工夫もしません)。
会社に10年いようが20年いようが訓練していない人は素人であります。

皆さんくれぐれもご用心を。