ソフトウェアを開発することで対価を得るはずのソフトウェア受託開発業が、実態としてソフトウェア業ではなくなっているのではないか、というのが前号までの要旨。バブル崩壊によるボディーブローをきっかけに、システム構築の受託型から、より安易な要員派遣型に舵を切ったばかりか、プログラムを作らないプログラマが増えているという。システム工学やソフトウェア工学に関心を持つのは一握りの技術者に限られ、しかも組織として取り組む企業はほとんど皆無に近い。ソフト業が本来のソフト業に立ち戻る方策を探る。（佃均（ジャーナリスト）●取材／文）

ソフト工学の視点がない

 

足軽軍団か騎馬軍団か

 

　8月27日、東京・青海で行われた情報処理学会のソフトウェアエンジニアリングシンポジウムを終えた2人の足は、自然に盛り場へ向かった。居酒屋を目指す喧騒のなかで、自称「元プログラマ」のA氏が叫ぶように言う。

　「プログラマをダメにしたのは、オブジェクト指向の開発手法。プログラム・モジュールが整備されて、GUIがよくなったために、プログラマはプログラム・ジェネレータのオペレータになってしまった。プログラムを書けない、読めないのが、どうしてプログラマなんだ？」

　A氏は20年ほど前、世の中に出回り始めたばかりのJavaを駆使し、画像処理システムの開発に熱中していた。いまもバリバリの現役だが、「元」というのは、プロジェクト管理が仕事になっている目下の立場を卑下した表現にほかならない。

　目的の店に着いて、注文をしたあともA氏の言葉は途切れない。

　「例えば、織田信長が長篠で武田軍を破ったとき、信長は足軽に鉄砲を持たせて、1人が倒れても別の1人が入れ替わった。武田の騎馬武者は代わりがいなかった。だから武田は滅びた」

　ちょっと待て。

　信長が使った鉄砲を、システム開発におけるオブジェクト指向の手法に置き換えれば、足軽でもいいということになる。最新の武器を軽視したから、武田勝頼は滅びたのではないか。プログラムが読み書きでき、システムを作りこめる人たちの集まりでは、戦いに負けるということではないか。

　1985年に当時の通産省が推進した「ソフトウェア生産工業化システム（シグマシステム）」は、プログラミングの専門技術を十分に持たない半分素人でもプログラマとして使える環境をつくろうというものだった。プログラムを書けないプログラマが大量に生まれたのは、過去20年の成果であって、トータルな生産性が向上したということではないか。

　「そうじゃないんだ」

　A氏は反論する。

組織とシステムの関係

　ある地方の金融機関のシステム案件の受注を、東京の大手SIerと地元のソフト会社が争ったとき、発注者が選択したのは地元のソフト会社だった。現場で仕事をするプロジェクトチームの陣容がしっかりしている、というのが理由だった。だから、銀行に限らず、製造業、サービス業などシステムユーザー（発注者）の多くは足軽軍団型の組織、対してソフト会社は騎馬軍団型でなければならない、とA氏は主張する。

　「プログラマは剣術、弓術、馬術に秀でていて、さらに戦いの仕方、作戦の立て方も学ぶべきなんだ。なのにSI業界は、足軽を一生懸命集めて、とうとう足軽だけの集まりになってしまった。だから目の前にソースコードをポンと放り込まれても、それが何なのか分からないし、分かろうともしない」

　16世紀、甲州軍団は長篠で鉄砲という近代兵器の前に潰えたが、21世紀は騎馬武者の集団であってこそ戦いに勝てる。ソフトウェア工学、システム設計やプロジェクト管理の技術がなければ、ただの烏合の衆に過ぎない。1万人、2万人規模の足軽を組織できて軍団になる。だが、臨機応変の小回りはきかない。

　「それだけではダメだ。1万人の足軽を1000人ずつ10隊に分けて、自由自在に動かそうとしたら、最低でも500人のスタッフがいる。20人に小隊長が1人、10の小隊を束ねる中隊長、それを束ねる大隊長、さらに伝令や斥候、幕僚といった具合だ。少なくともそういうリーダーは、作戦や戦略の何たるかを知らなければならない」

　組織と一体化したシステムがソフト会社にも必要なのだ。言い換えれば、自社の標準的な開発手法や開発環境ということになるだろうか。そして最も重要なのは、発注者が何を望んでいるかを正しく理解し、そのためには何を準備し、どのような手段でシステムを実現していくかを考える頭脳だ。

3方向からのアプローチ

　「ベンチャーが強いのは、一騎当千の騎馬武者がそろっているからさ」

　A氏が言いたいのは、このことであるらしい。なるほど、一騎当千の騎馬武者は自分の経験と勘で機敏に動くことができる。ただし、少人数でできるのはゲリラ戦や局地戦だし、有利に展開できるのは土地勘があったり住民の支援が得られる場所（ソフト業でいえば得意分野）に限られる。

　大草原で敵の大軍を真正面に見据えて鶴翼の陣を張る（大規模システムに対応する）には、工学的なアプローチが欠かせない。それが欠け落ちれば、大阪夏の陣で豊臣方が展開した惨憺たる戦い──秀でた武者が連携なくそれぞれに突出して自滅する──になってしまう。つまり足軽軍団であっても、ソフトウェア工学は必須ということになる。

　そのとき、工学的アプローチには大きく3つの考え方がある。1万人の足軽で構成する軍陣をシステム開発体制だとすると、要員やツールなどリソースの配置をどう最適化するかがひとつの考え方だ。スケジュールだけでなく、リソースやリカバリーを包括的に管理する手法のことだ。PMO（プロジェクト・マネジメント・オフィス）は作戦司令部に相当する。

　2つめは経験則だ。ソフトウェア工学の表現を使うと、「エンピリカル・アプローチ」。過去の経験からいち早く危険を察知し、矛盾を見抜く現場力を技術者個人の経験値にとどめず、数値化したりルール化して、より多くの人が共有できるようにする。

　3つめはゴールシーク方式の考え方だ。5W1H（いつ・どこで・誰が・誰に・何を・どのように）を明確にし、最終的に提供する機能要件、非機能要件（レスポンスタイム、セキュリティ、ポータビリティ）をツリー状の多段構造で記述していく。そうすることで機能の重複や非機能要件との矛盾が発見できるのだ。

　そこでSLCP（ソフトウェア・ライフサイクル・プロセス）やソフトウェア作業標準、UML（Unified Modeling Language）の有用性が指摘されているわけだ。

　するとA氏は、フンと鼻を鳴らして言った。

　「所詮、そんなものは机上の空論さ。それでシステムができるなら、なぜ失敗プロジェクトが生まれる？」

　次回はA氏の言う「机上の空論」説を検証しよう。