上流工程・下流工程などという区分でソフトウェア開発をして成功するとはとても思えない

今回は完全にIT雑談である。

私は大手での開発経験というものは持っていない。しかも現時点での経験年数からいうと、プログラム開発をするよりもネットワークやサーバの設計・構築・運用管理をやってきた年数のほうが長い。その過程で様々な管理ツールなり社内システム的なものを作ってきたが、基本それらは自分で設計図を引き自分でコードを書きテストしデバッグしリリースしアップデートしていた。すべて一人だ。

世の中、特に日本のシステム開発では「上流工程」「下流工程」なるものが存在し、私の友人の何名かも「上流工程」なる部分を業務で受け持っている人もいるようだ。最初、私は上流だの下流だのの示す意味そのものが全く理解できなかったのだが、ざっくばらんに言えば上流とは建築でいえば建築士が図面を引くことに似ていて、下流とはその図面をもとに建物を建てる建築業ということになるだろう。

私のこれまでの開発に関する経歴をざっとお話ししてみたい。

専門学校を卒業してから20歳でこの業界に飛び込んだ。最初は派遣業だった。しかもプログラマとして働き始めたのは入社して1.5年ぐらいしてからだ。それまでは普通にLotus1・2・3(知ってる?Excelがメジャーになる以前にトップセールスだった表計算ソフト)を使ったデータ整理だったり資料作成だったりと、開発現場にはいたものの普通の事務業務全般をさせられていた。あるいは単なるテスターをさせられたこともあった。
その後、ある派遣先で同様に事務業務をしていた中で「おまえプログラムかけるの!?」と派遣先の先輩から言われてプログラムの仕事を任されることとなる。派遣契約的にその仕事をしてよかったかどうかは分からないが、おそらくそのあたりは担当営業がクリアしていただろう。たぶん単価を少し上げているはずだ。
それはともかく、そこからは様々な言語を使って開発をさせてもらった。C言語がメインだったが、アセンブラを使ったこともあった。産業組み込み関係だったので、MC68000や6903といったMPUのアセンブラも書いたことがある。Quick BASICとGP-IBを使った計測系ソフトウェアやRS-232CとC言語を使ったデバイス出力データの可視化ソフトウェアも書いた。一種の内製品ではあるが、顧客にもその様子を見せたりすることも多かったので(納品物として添付されたものもある)、仕様書を書いたものもあった。その仕様書を書いたのは当然私だ。マニュアルも書かされたけど(笑)。

その後は某所システム課に転職しFreeBSDを中心としたサーバ構築とCiscoやFreeBSDをベースとした基幹・末端ネットワークの設計・構築・運用管理などをやってきた。大規模なPC端末を含めたリース品のリプレイスプロジェクトも何度か経験してきた。これはもう開発ではなくてシステム運用に含まれるであろう。こんな仕事をおよそ15年程度してきた。もちろんその過程でプログラムを書いたこともあったが、ほとんどはPHPやPerlを使ったウェブアプリであった。これらもDBを使うこともあったのでDB設計から仕様は自分で引いた。ほとんどの場合仕様書は書かなかったが、コメントで残したりするなどの対応をしたものも多い。

さて、最初の話に戻ろう。
上流・下流の区分まではよしとして、では上流と呼ばれる「設計図」を書く仕事については比較的よく耳にすることがある。
その中でも耳を疑ったのは、プログラミングや開発経験をしたことのない人が設計をするという事実である。
もちろんこの形式で開発をしている企業は多数あり、実際にうまくいっている(ように見える)ので、間違った開発手法ではないと言えないこともないだろう。しかし、私は極めて不自然だし怖い話だと思っている。

というのも、プログラムを書いたりシステム開発をしたことのある人であれば、設計図通りに物が簡単に作れることはないし、仮に設計図に誤りがないとしても言語やアルゴリズムの選択によっては開発に難を要するものも出てくる。たとえば連想配列のある言語とない言語では開発速度が異なる可能性があるかもしれない。たとえばオブジェクト指向言語でれば何てことのない実装のはずが構造化プログラミング言語の場合は専用のモジュールまで自作しなければなずバグの温床までも多く点在させる結果となるなど、予期せぬこともありうるわけである。そして世の中、そうそう天才肌のプログラマで埋め尽くされているわけではないから、そういう壁を越えて決められた期間内に開発を完了させることができるなどという妄想は極めて危険なのである。

大きなシステムは一人ではすべてを面倒見切れない。だから設計者と実装者で区分すればいいという考え方があるのかもしれない。しかし私から見るとこの区分は極めて問題を誘発しやすい構造だとしか思えないのだ。設計者は設計者の立場都合で設計したものなのであり、おそらくは顧客の満足度を最大限にするために設計した仕様で満たされているのである。しかし実装者からみると本来実装すべきではないものや、根本的に実装することがおかしい部分もあるだろう。このケース、おそらくデータ構造の設計が顕著にみられるような気がするのだがどうだろうか。顧客の希望に合わせたデータ構造を実装経験のない人間が設計した末路というのは実は私も何度か見ているが、それはもうおぞましいの一言に尽きる。データ構造は実装だけではどうにもならない場合が多い。いや実装で対応することは可能だとしても、現実的な時間内に処理が完了しないなどのいわゆる計算量問題という壁にぶち当たる場合がある。そのため上流工程なる担当者が数学的に問題ないことを視野に入れたデータ設計をしない限り、実装者は苦行を強いられるような場合もたびたび起こりうるということだ。そしてしばしば、上流と下流のコミュニケーションは破たんしているか互いに疎通できない状況にある場合が多いと思われる。

そういう状況があるからこその近年のアジャイル開発やXPプログラミングなどといったスタイルの発展や広まりがあるのだろう。アジャイル開発経験も私はゼロであるが、小さなグループによってイテレーションしながらシステムを雪だるまを作るように徐々に徐々に組み上げていく方法論は、ソフトウェア開発に実にマッチしているのではないだろうか。理由としては、実装者が設計に携われることや、検証的な実装も含めながら着実に目標に向かっていくスタイルなので問題があっても修正がしやすいこと、通常グループは少数のため、実装者の意見や経験を反映しやすく、かつ活かしながら実装化できることがあげられるのではないだろうか。

いろいろとつれづれ書いてみたものの、私が言いたいのはどういう設計方法であれ、実装経験のない人が設計を行うということは危険極まりない手法であるということ、それだけなのだ。
比喩ですまないが、建築士だって自分で建築の経験をある程度は持っている場合もあるし、仮に設計だけだとしてもあの業界がそれで成立するのは、確実に数学と物理法則で縛られているからである。したがって図面に従って作れば、強度計算なども含めたすべての結果を反映した実装が確実に行えるのである。
しかしプログラミングは数学知識がある程度必要だとしても、数学や物理を用いた設計が行われるわけではない。その点が極めて大きな問題であり、建築と比較できない最大の点であろう。

とにかく、上流・下流なる意味のない区分とそれらに従ったシステム開発手法は、そろそろ終焉を迎えてもいい頃合いなんじゃないだろうかと私は思うのである。

ITプロジェクトの「見える化」 上流工程編 (SEC BOOKS)図解入門 よくわかる最新システム開発者のための要求定義の基本と仕組み (How‐nual Visual Guide Book)やさしくわかるBABOKマンガでわかるプロジェクトマネジメントアジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

コメントを残す

メールアドレスが公開されることはありません。