前回の続きです。今回は巨大システム会社は素人以下ばかりという話をします。
どれぐらい素人以下なのか、ということをプログラムに関係ない方にも分かるように小学校の算数レベルの事例で説明させて頂きます。「いくらなんでもそれはないだろう……」と思うかもしれませんが、実際、文系プログラマーに尋ねてもほとんど出来ないことを確認しています。
■等差数列の和を求める
例えば、全くプログラムの関係ない方にも分かるように、「4から12までの偶数の合計を計算する」という簡単なプログラムについて考えてみましょう。このような単純なものでも、残念なことにプロの技術者のほとんどの人が、以下のように答えます。
0 ＋ 4 = 4
4 ＋ 6 = 10
10 ＋ 8 = 18
18 ＋ 10 = 28
28 ＋ 12 = 40答え 40
これをプログラム風に書くと
確かに正しい答えは出ます。しかし、私は小学校で習う（ガウスが9歳で解いたという）、また、高校の「等差数列の和」の方法でプログラムすべきと考えます。計算式は下の図の通りで（ゆとり教育でなくなった？）台形の面積の求め方と同じになります。
「等差数列の和の公式」あるいは「台形の面積の公式と同じ」と判断が付けば一瞬で作ることができるプログラムですが、それらを忘れていて「足し算の繰り返しでない方法」という条件を付けられると、考えつくまでプログラムはできません。最悪の場合できないわけです。実際に文系のプログラマーに尋ねても、できないことが非常に多いです。
一方で単純な加算の繰り返しであれば、開発工数が掛かり、実行速度はかなり遅くなりますが、一般的なプログラマーなら誰でも確実に出来ます。単純作業のため見積も容易になります。
■仕様変更があったら
「誰でも確実にできる」上に「見積も容易」というのは良いことのように見えます。実際、それを理由として、あえて「単純な方法しか使わないほうがいい」と主張する者もいます。
例えば、「4から12までの偶数の合計を計算するプログラム」に「3で割り切れるときは除く（足さない）」という条件が追加されたときはどうなるでしょう。
公式からは直接できず、もう一度、考えなおさねばなりません。その際、プログラムの中で出てくる以下のような1行
result =（（start ＋ end）× counter）／ 2
が「等差数列の和の計算」を表す数式、あるいは、先ほどのイメージ図へ展開できなければお手上げです。担当者のスキルによって「最悪できない」という可能性が仕様変更があるたびに高まります。
ところが単純な加算の繰り返しであれば「3で割り切れれば足さない」という条件を追加するだけですみますので、一般的なプログラマーなら誰でも対応できるのです。ここだけを見ればいいことのようにも見えます。
■リスクを回避するため？
等差数列の和のような単純なプログラムは実際の現場ではありませんが、もし現場で作ることになっても5～8割ぐらいの確率で「単純な加算でやって欲しい」という依頼になるでしょう。もちろん、私はプロとして金を取るならもっと複雑なものでも「見たら分かるように訓練すべき」と考えているのですが、それは業界内では「暴言」と取られ炎上することになります（苦笑）。小学校の算数レベルでも避けるぐらいですから、もっと複雑な実際のプログラムでは、
・（プログラマーなら）誰でもできる。
・見積が容易。
・仕様変更があっても、誰でも対応ができる。
という理由で、会社・プロジェクトの方針として技術を避け、単純な処理の繰り返しで作ることになります。
結果、前の記事のような初級システムアドミニストレータレベルの技術までも避けてしまうことになります。できる方がプロジェクトにいたとしてもその技術は使えなくなるのです。そういうプロジェクトを繰り返すうちに、できないことが当たり前になり、結果的に「プロが素人以下の技術力」という業界になってしまいました。
システム会社の方針として技術を避け誰でもできるようにするということは、人海戦術を前提としているわけです。人海戦術を採るとすると、ヒエラルキーの上位に位置する人は「人を集め、手足として使う能力」ばかりが求められることになります（それも重要ですが）。技術を避ける方針ですから「（特に）上に立つ人に技術は不要」で「最悪でも人を大量投入すれば終わる」と考えているわけです。
例えば、特許システムのように（本当に終わると考えたかはともかく）千名を超える人を投入すればなんとかなると考えてしまうのは、会社（業界）の体質として、「単純化して人海戦術に落とし込もう」と考えていることの証左です。そして、規模によっては、単純な処理の繰り返しの人海戦術ではどうしても終わらないプロジェクトが発生することの証左でもあります。
プロジェクトが終わらないという事態までにならなくても、小さな所ではクリックして2時間掛かるというようなプログラムになってしまうこともあり得るのです。
リスクを避けたつもりが、更に大きなリスクを背負っていることになる。恐ろしいことに、それを進めている責任者に技術がないのため「単純な繰り返しで終わるかどうか」について根拠をもたずにプロジェクトを進めているのが現状で、例え成功裏に終わったとしても、それは偶然なのです。
その様な事態を防ぐには、是非、こんな問題でも、単純なものでは、1から10まで足すプログラムをホワイトボードに書いて貰っても良いです。依頼する前に、システム会社の考え方とスキルのチェックをして頂ければと思います。
※解答が欲しい方はメールで info@g1sys.co.jp 。
もう少し続きます。
生島 勘富（イクシマ サダヨシ）
株式会社ジーワンシステム
代表取締役