SE心得 

 SE業務に関する随筆です。読者として一般の方を想定しています。一般の人に、「SEってどんなことをやって、コンピュータシステムを作っているの?」という雰囲気がつかんでもらいため書きました。SEのだんな、奥さんをもっている方(しかも自分はSEではない)で、何でうちの亭主(女房)はこんなに帰りが遅いんだ?と頭にきている方にぜひ読んで欲しいと思います。そして、相方の大変さを知ってください。

1.ゼネコン

 あなたの会社がコンピュータシステムを入れたくなり、コンピュータの専門企業に依頼したとしましょう。やがて、社員が数名やってきて、打ち合わせをすることになるでしょう。でも、そのうちのわずかが、依頼した会社の社員で、あとのメンバは、おそらく外注企業の人間です。名刺は依頼した会社のものを使うかも知れませんが。

 そして、打ち合わせ後、費用の見積もりをもってくるでしょう。構築費用3000万円とか、いってきます。うち、人件費が2000万円とします。依頼した企業をA社とし、外注企業をB社とC社とします。(外注とは仕事を受けた企業が、別の企業に仕事の一部を依頼しなおす場合です)すると、1000万円がA社、1000万円がB社とC社になります。B、C社が実際の開発作業のほとんどを受け持つことになるでしょう。それぞれ500万円を受け取ります。丸投げに近い場合もあります。B、C社は開発しますが、1社では開発しきれません。ですから、彼らも外注を使います。依頼先の外注企業をD、E.F、G社とします。すると、250万円をB社、C社、125万円をD,E,F,G社となります。

 ここでは、依頼先企業、一次外注企業、二次外注企業の3層になりますが、大規模なシステムですと、これが五次くらいまでいきます。一番したの企業では、ヘタすると、1人、2人の社員数だったりします。もらえるお金も相当にやすいです。

 ですから、ゼネコンに仕事を依頼したかのように外注、外注,...という構造になります。1社に開発を依頼したつもりでも、実は数社、数10社が働いています。ソフトウェア開発などが実はほとんどこのパターンです。巨大なピラミッドが動いていると思っていいでしょう。

 あなたが、出来上がったシステムに欠陥を見つけて、怒ったとしましょう。「こまりますね」A社がやってきて、平謝りします。A社の社員は、B社の社員を呼びつけます。そして怒鳴りつけます。「どうしてくれるんだ!」B社の社員は、机に頭をこすりつけてあやまります。そしてD社の社員を呼びつけます。「おい、どうすんだ、このやろー」....(以下、一番下にいくまで繰り返す)

 また見積もり時点で、あなたがA社に対して、厳しく値切ったりします。困った顔でA社社員はうなづきます。A社はB社を呼んで、同額の値切りをします。B社は泣きべそをかいて、C社を呼びます。そして同額を値切ります。C社は本当に泣いてしまいます。下にいくほど、値切り額はきびしいものになっていきます。

 逆にD社の社員が自らミスを見つけます。C社に人間に謝ります。「ばかものー」と怒鳴って「君もついてきなさい!」といってB社にいきます。C社はB社にあやまります。D社もついていきます。B社は「こまったなあ」といいながら、A社にいきます。A社は「まったく」と怒ってあなたのものとにやってきます。こうして、上にあがっていくわけです。

 あなたとA社が、見積もりで、1人月(1人が一月働く量をいいます)200万円と決めます。A社はB社に頼むときには、120万円くらいで頼みます。B社がD社に頼むときには、1人月70万円とかになります。社員は、30万円くらいで働きます。あなたの会社に実際に導入する際に、やってきた技術者は給料は非常にやすいです。200万円なんてまったくもらっていません。

 システムに致命的なミスがあって、稼動が遅れたりします。あなたは、半額しかはらえないよ!といいます。A社は、B社に決められた額の1/4しか払いません。B社はD,E社にまったく払いません。「君達のおかげで、我々も1円ももらえなかったんだよ!」うそをいいます。かくして、ピラミッドの一番したの会社が失敗の重みを背負います。倒産することもしばしばです。

 あなたは、おそらくA社の人間を見て、彼らが作ってくれるのか、と思って安心したかも知れません。でも開発の実体はかくのごとしです。ずーーーと下までいったら、なんとコーディングしてたのは、新人教育も満足にうけていない1年目の新人。もっとひどいと、バイトの学生だったなんてこともあるのです。

 ここまでピラミッド構造が大きいと、A社も、一番したでは、どういう会社が作っているのかは、わからなくなってきます。何層にも依頼関係があるので、把握するのは困難です。オウムが開発にかかわっていた!と大騒ぎになったことがありましたが、巨大システムでは、開発しているスタッフ全体をおさえるのは、困難、というよりほとんど不可能です。だって、一番したでは、人件費を押さえるために安いところに依頼するしかなく、秘密でいろんな人に依頼していることもあるからです。

2.仕様書

 コンピュータシステムの設計をする際に、あのような難しい、大きいシステムをどうやって考えて作っていくのでしょうか?

 実はビル建設と同じことをしています。まず、ビルを建てる場合ですが、ビルを建てる所有者に、どんなビルにしたいのかを聞き取ります。そうして、所有者の希望をかんがみて、建築士が設計書を作成します。設計書を所有者にみせて、このビルでいいかを最終確認。OKなら、いよいよ工事開始。土台をしっかり構築し、骨格を作り、壁、床と作って、内装を行ないます。チェックを十分したのち、完成というわけです。

 コンピュータシステムも全く同じです。以下のような作業になります。

1.客の希望(こういうことをしたいんだ)というのをヒアリングする。必要なら資料をもらう。
2.それを元にして、仕様書と呼ばれる設計書を作成する。
3.設計書を客に見せて、説明してこれでいいかを確認する。
4.OKを貰った仕様書(基本、または機能仕様書)をもとに、いよいよ開発にはいる。まず、システム全体を大きなブロックに分割して、それぞれのブロック単位で開発します。そのために役割を決める。これも仕様書にします(構成仕様書)。
5.次にそのブロックごとの中身を設計します。(詳細仕様書)
6.最後にコーディング(つまり、作成)する。(プログラム)
7.できたら、テストをしていく。一度に組み立てて、テストするのでなく、少しづつ大きなブロックをつくってみて、テストをしていく。最後に、全部を組み立ててテストする。完成!

 問題は、2で完成する設計書なのです。これが、SEの仕事をつらいものにする元凶なわけです。ほんとです。

 なぜでしょうか?設計書(仕様書)が、客がほしがっているシステムと合っていないからなのです。プログラムを作り始めてからは、あまりミスはおきません。だいたいうまくいってしまいます。なぜなら、作るほうはプロだからです。しかし、完成してみると、客が驚くことを叫びだします。「なにこれー?こんなのがほしかったんじゃないよー。だって、XXXXもできないし、YYYYだって、こんなのではダメ。仕事にならないよー。」ということです。

 ビルにたとえてみましょう。ビルがいよいよ姿をあらわして、完成まぎわに、所有者が「ええー?なにこのビル!こんなんじゃだめだよ!」なんて言い出したらどうなりますか?もう一度、ぶっこわして、設計しなおして、一から作り直すことになります。そんなことになったら大変です。あまり聞いたことがないです。(荒井注さんのカラオケ店のように、出入口が小さくてカラオケ設備がはいらなかった、なんてことはあるようですが)

 でも、システム開発では、ザラにあることなのです。いや、むしろ、客の希望していた通りだった、うん、これでいいんだよ、なんてことは、ほとんどないのです。信じられないと思いますけど。これじゃあだめ、と宣言され、結局、大幅な作り直しが頻繁に入るのです。作り直しなのに、締め切りは変わりませんから、SEは突如、悲惨なモードに突入します。徹夜の連続、しばらく家には帰れなくなります。土日などありません。残業数100時間モードに突入します。結構、体を壊す人が続出します。

 なんでこうなるの?最初にいったとおりに、仕様書が客の希望するものとかけ離れているからなのです。なんで、かけ離れるのでしょうか?それは、次回に分かりやすく、説明してみたいと思います。(続く)

3.仕様書 − その2

 さて、今回は前回の「仕様書が客の希望と違ってしまう」理由をかいてみます。いくつかの理由があるのです。

1.客が読んでくれない(読むきがしない)

 システムの動きや、機能を仕様書としてかいてあるわけです、ですから、その仕様書の枚数は大変なものになります。簡単にかいたつもりでも、電話帳みたいな仕様書になったり、それが何冊にもなったりします。そんな紙の洪水を渡されて、さあ、読んでチェックしてください、といっても無理なのです。見た瞬間、唖然としてしまうでしょう。ため息をつくでしょう。

 また、内容も技術者が書いたものですから、専門用語を平気でつかってたり、わかりづらかったり、説明が下手だったり、難解だったりします。ますます読むきがしなくなります。

 客の担当になんとか読んでもらおうと説明会を開いたりしますが、客はグロッギーです。頭に入れて、考えてチェックするなんて状態になりません。技術者も平気で分厚い仕様書を1ページ目から、根気よく説明していきます。客は失神寸前になります。

2.承認したくない

 客がきちんと仕様書を読んだとしましょう。そして、「この仕様書でいいですよ」といったとしましょう。はんこを押すこともあるでしょう。すると、仕様書とおりに完成してから、「あ、これではだめだったんだ」と解ったときに問題がおきます。仕様書を読んだときには、これでよかったと思ったけど、実際に使ってみたら、現場の作業と合わないことがわかってしまったとします。このとき、「この仕様書でいいです」といってしまったのですから、SE,コンピュータ企業に直してと依頼しても、言われたとおりにつくりましたのでダメです、というでしょう。どうしても直してと頼めば、じゃ、追加の料金をいただきますということになります。

 これは困るのであります。客側の承認してしまった人間の責任になってしまうではありませんか。だから、客の人間は、「承認しません」。システム開発経験の長い老獪な人ほど、承認どころか、読んでもくれないのです。よく読んでしまったら、「あなたも読んでくれたじゃありませんか」と責任を追及されます。だから、読みません。そうすれば、問題がおきたときに、全部、SEのせいにできるのです。「ええーそういう風に作っちゃたんだ。知らなかったなあ。その仕様ではダメですよ。直してください」といえるのです。

3.読んでもだめ

 できあがったシステムは眼にみえるもので、かつ操作できます。動くものなのです。でも、仕様書は紙です。動くものをかくわけにはいきません。書いたものは図にしろ、説明にしろ、とまっているものと言えるでしょう。

 操作するときの画面の動き、業務とどう連携するかの時系列チャートなどは、どううまく説明して仕様書に記述しても、実感としてピンとこないのです。

 いくら客が気合をいれて、紙の仕様書から、実際の動き、操作のイメージを考えても、人間の空想力には限りがあります。紙ではいいと思っても、実際に動かすと問題点はやまほど出ます。

4.客だって会社を全部知っていない

 仕様書を、客がわの担当者に渡します。で、業務との関連はこれでいいですよね、ときいてもダメなのです。だって、その担当だって、会社の全てを知っているわけではありません。しったかぶりをしていることもあるのです。

 また、自分の課のことでも同様です。管理職が担当すると思いますが、管理職は一般の直接担当の仕事内容を全部知っているわけではありません。課長がこれでいいですと、いったのに、課員は「こんなんじゃ、使えないよ」ということはザラです。

 上記の4つの理由により、大幅に、仕様書と希望が一致しないのです。そうして、かけはなれたシステムが現れます。そこで、気が付いて、修正になってしまいます。ここまでくると、大変です。もとから直すのです。壁紙をはりかえろといってるのではないので、死にます。

 古来からこの段階(テスト段階といいます)で、大問題が発覚し、大戦争がはじまるのです。そうして、あなたの大切な人は会社から全然かえってこなくなるのです。「今テストはじまったところだ」などと亭主がいいましたら、「ああ、当分かえってこないのだなあ。」と思いましょう。そして、スタミナのつく食べ物を出してあげましょう。

 現在、仕様書と希望の食い違いをすくなくする手法が沢山開発されています。でも、上記のようなことがなくなるまでにはいたっていないようです。

4.バグ

 システムにはどうしてもバグが入ってしまいます。一応できてから、テストをしてバグを取り去っていきます。ゲームなどで多少のバグは、裏わざ?になったりしますが、業務用アプリではとんでもありません。バグとの戦いは、エンジニアの宿命です。

 コーディングといって、プログラムを書いたり、仕様書を書いたあとでも、それをみんなで見直して、間違いを取り除きます。レビューといいます。結構、多くの間違いが見つかり、取り除くことができます。レビューはバグを減らすための特効薬であります。それでも、システムをくみ上げて動かしてみると、間違えがガンガンでてきます。それをみんなで、見つけ次第、報告して、原因究明して直して取り去っていきます。

 多少はどんなに注意してもバグはでますが、多すぎたり、いつまでたっても減らない(いくらでも見つかる)ようだと、大変です。本稼動が遅れて、大問題に発展し、賠償問題になったり、上司が頭をさげまくるようになります。バグの多さは、システム開発者のスキルの評価につながります。バグが多いと、直すために、SEも残業時間が激増します。お金も客からはもらいずらくなります。でも、バグは実はどんな開発でも多いのです。開発者の永遠の悩みなのです。

 どうすればバグを減らせるか。それは多くの開発者の課題でした。バグの研究は、1つの研究テーマとなり、人間はなぜ誤りを犯すのか、という原点に戻って探求されるようになってきました。でもそんなものではない気がします。

 人がプログラムを組みますと、人によって、発生するバグが数が全く違うのです。Aさんが組むと、10個。でも、同じものを組んでも、Bさんは、300個バグを生んでしまったりします。また、ほんの一部の人ですが、バグ0個などという人もいます。私の最初の上司は、バグを作らない人で有名で、私も5年くらい師事しましたが、バグをみたことがありません。対して、担当する分野で、1回の開発で何百ものバグをうむひともいました。間違いなくいえることは、個人によって、平均バグ発生件数に大きな違いがあるということであります。個人の属性なのです。

 システムは多くの人間で協力して作っていきます。みんなで作ったブロックを最後にあわせて組み合わせます。すると、いろんなバグがでます。いろんな現象として現れます。システム全体に、波及します。

 でも原因を追求していくと、何人かの限られた人のプログラムに根本原因のバグが集中しているのです。1人、バグが異常に多いひとがいると、その異常は、システム全体に波及するのです。大きなシステムだと、原因究明作業は非常に時間がかかり、難しいものになるのです。

 イメージでいうと、1KGの白い絵の具に、1滴のインクを垂らせば、もう白い絵の具として使えなくなるようなものです。

 私は法則を発見しました。「伊藤の品質最小率の法則」これは、100人で開発すると、その中で、もっとも、品質の悪い、バグの多い人間の作るプログラムの品質に、システム全体の品質がなってしまう」というものです。

 だから、バグのないシステムを作ろうとすれば、理屈では簡単です。平均バグの少ない人間を選抜して、彼らだけでシステムを作らせるのです。バグの少ないシステムは聞いてみると、だいたい、少人数で作ったものが多いです。多人数で人海戦術に近い状態で短期につくったシステムでは、バグは莫大な数になったものです。

 伝説の芸術的プログラムは、だいたい少人数、または1人でつくったものです。パソコン黎明期のころに、ビルゲイツじきじきの設計のソフトウェアを沢山つかいました。MS−BASICなどをつかいましたが、本当に、品質がよく、安定していて、速度もはやく、高性能でした。MSも会社が大きくなり、ソフトの規模も大きくなって、多人数開発になってきてから、バグが多くなってきたようですね。

 でも、現場では、バグの少ない技術者だけで作る、なんてことはいってられません。夢物語です。短期で数10人体勢でやらなければなりません。ですから、新人とか、バグの名人とかも含めて、開発せざるをえないのです。

5.残業

 SEは残業が多いです。どんな職種でも今の時代、残業はありますし、増えているようですが、SEはそれにしても多いです。多すぎます。SE経験のない、SEのワイフのためになんで残業がこんなに多いのかを書きます。お願いですから、だんなさんを「あんたが要領が悪いから仕事を押し付けられてんでしょ!」「なんでこんなに残業おおいのよ。私のことを大事におもってないんでしょ」なんて、責めないでください。だんなさんは、死にそうな大変さで仕事をしています。お願いです。

 理由は以下のものが考えられます。

1.みつもった仕事量をいつも少なく見積もる。

 このシステムを作るのにいくらかかるのか、これは何人月(人×月)かかるのか、から算出します。しかし、算出した結果を元に費用を出して、顧客に出すと必ず値切られます。これはどの商売でもそうなので、仕方ないことなのかも知れません。でも、通常はいろんな材料費も含めての費用なので、その材料の工面で費用削減を検討できます。

 でも、SEはそんなものないです。全部人件費です。値切られれば、人月を減らすしか方法がありません。かくして、100人月かかる作業が80人月で請け負ってしまいます。20人月分、効率あげてがんばれ、と上司から激が飛びます。でも、そんな神風特攻隊的なことをやれば自動的に、最後は悲惨な現状になります。結局、プロジェクトが進むと、間に合わなくなり、残業・休日出勤でまかなうことになります。

 でも、残業費がでればいいほうです。ひどい会社だと、タイムレコーダを打刻してから、残業しろなどという酷い会社もあるので、悲惨です。つまり、値引きを社員の悲惨さに押し付けていることになるのです。

2.バグが多い

 これは前の項をお読みください。工数見積もりの際に、どうしても、バグ検出と修正の工数を少なめにみてしまうのです。経験から、算出しても、「はじめから、『誤り、ミス』を見込んで仕事をするな!」などといわれます。危機管理0でいきますので、バグがでればそれは自動的に残業で処理する以外にはないのです。

3.みんな忙しい

 通常、あるプロジェクトが忙しくなれば、他の部隊を応援にまわすでしょう。でも、これがSEの場合、うまくいかないのです。なぜなら、応援をだそうにも、みんな忙しい、ぎりぎりの工数で仕事をしています。「手伝っている余裕などない」というのが本音なのです。結局、自分たちでやり遂げる以外にありません。残業で。

4.残業をするのが「当然」になっている

 企業文化、職場文化として、できるSEは残業をするのが、あたりまえ、一生懸命仕事をする人間はみんな残業になっているという風土があります。家にもう何日もかえってないなどというのがあたりまえになってしまい、帰らないとまずいよ、などと忠告するような人間はSEには少ないです。逆にいうと、早く帰宅する人間は、反逆児ということになってしまうのです。残業をプラスとかんがえる発想なのです。最近は外資系の登場で、だいぶ変わってきたようですが。

5.遅れのいいわけ

 プロジェクトが遅れますと、大問題になります。もちろん、大変なことになりますが、最後の弁解が「残業してがんばっているので許してください」なのです。「遅れているが、今日は帰ります」というのは責任放棄に思われてしまうのです。

6.テストは休みと夜にやる

 最後のテストで、実機環境でテストする場合には、仕事につかわれている平日、昼間にはできません。みんなが帰った、深夜、休日にやらざるを得ないのです。

 といったような理由でSEには恒常的に残業が多くなるのです。ですから奥様にはぜひ理解をしてあげてほしいのです。疲れているのに、プロジェクトの遅れで深夜まで残業し、明日の休日にも出勤しなければならない。進捗会議では、遅れを責められる。くたくたなのです。そうして、かえってくると、奥様から罵られては立つ瀬がないではないですか。ぜひ、暖かく迎えてあげてほしいのです。

6.オーバラップ

 ゲーム業界では、1つのゲームを作るのに、何ヶ月、何年もかけて、熱中して開発を行います。そのチームのメンバは、自分の持てる才能、情熱、努力をすべて、作っているゲームに叩き込みます。超人的激務をしたのち、発売。苦労したかいがあって、おお売れとなる、(または売れずにやばくなる)わけです。

 開発が終われば、放心状態に近いものになるようです。ここで、しばらくは休み(といっても数日、数週間ですが)をとるそうです、充電期間といいますか、まあ、骨休めであり、激務続きのアクセントであり、家族サービスの期間でもあります。こうして、また心機一転、新作の開発にむかうわけです。ゲームはできてなんぼ、売れて何ぼの世界ですので、才能のない人間は生き残れません、そのかわり、このような生活のアクセントがつくわけです。会社も、まあ、発売もしたし、しばらくやすめや、となるわけです。

 SEではどうでしょう。システムを作り上げるわけですし、ゲームと同じプログラムをつくるのですから、なんとなく似たような仕事内容のはずです。はじめちょろちょろ、なかぱっぱで、作り出し、大忙しの時代がやってきます。そして、その作業もシステムの安定稼動で収束してきます。

 SEがゲーム関係者と大きくことなるのは、作業のオーバラップがきわめて激しいということでしょうか。上記のような仕事が、すこし時期をずらしながら、複数はしっているのです。もちろん、ゲーム開発者も、複数の仕事を並行してやっています。でもSEはそういうレベルのことではないのです。

 SEのシステムは、実は、「売れてなんぼ」ではありません。完成しても、当初の見積もりのお金以外は客からはもらえないのです、ですから、「ああ、終わった、ちょっとゆっくりしよう」などは許されません。通常はどうなるのかというと、「ひとつの仕事が楽になってくる前に、つぎのプロジェクトをだちあげ、合計作業量が常に一定になるようにする」ということです。つまり、間断なく忙しいのです。「どんな仕事だってそうだぞ!」といわれるのですか?でも、それは違っています。なぜなら、常に作業ピークがくるようなレベルで仕事を与えるわけです。完全に一直線になるように複数のプロジェクトを並行して担当させ、常にどれかのプロジェクトが作業ピークになるようにしています。

 いってみれば「SEは生かさず、殺さず」であります。でも別に会社が残酷というのではないのです。会社も収益構造が人間の労働時間で算出するものであるため、常にそのような状態に社員を持っていく以外に、生き残る道はないのです。

 ものを生み出す仕事というものは、どうしても人間、生活にアクセントが必要だと思います。ぶっつづけで生み出しつづける、というのは実にしんどいことです。小説家や漫画家もそうなのですが、彼らは好んで業界にはいってきていますし、収入はハンパじゃありません。SEは、結構、やむをえず、よくわからずこの業界にはいってきた人間が沢山おります。、最近はかなり改善されましたが、まだまだ実際の開発をしている人間の収入はそんなではありません。よっぽど、システム開発が大好き、というのでなければ、実にしんどいと思います。ですから、気分転換がいつまでもできないので(休日、深夜残業も続く)、精神的にまいります。目標感、達成感はよわくなっていくます。

 端的に現れるのが、プロジェクトの打ち上げパーティです。通常、うちあげは、「おわったあー」という達成感、安堵感で盛り上がり、陽気にさわぐことができます。でも、複数のプロジェクトが常にかぶさっていると、打ち上げいって、飲んでいても、どうしても、リラックスできません、すぐにやってくる次のプロジェクトのピークが心配で心配でしょうがないのです。ですから、開放感がありません。よく宴会はあれます。