続・100万行のソフトの作り方

縦割りのソフトウェア開発に関しては、
ウォーターフォールがその顕著な例でしょう。元々、ウォーターフォールは数十年規模のソフトウェア開発で実証されたもので、当然の事ながらチェックポイントでイテレーティブに作業が行われています。ですが、日本も含めて短期間のプロジェクトに適用する段階でイテレーティブな要素が割愛されました。これは、生産ラインにおけるオートメーションに似ています。本来的に工業化されていないソフトウェアにオートメーションの分業化を持ち込んだことが、問題の本質と思います。そして、一番問題なのは人が変わるときのコミュニケーションが十分でないことです。良く言われることですが、UMLはコミュニケーションのための表現方法であって、それ以上でもそれ以下でもありません。EAでも、コミュニケーションが成り立たなければ絵に描いた餅でしかありません。UML2やMDAでも、要求モデルから実装モデルまでの連携が自動化できるとは思えません。そこを繋ぐのは人であり、その人のセンスなのかも知れません。だからこそ、動くソフトウェアを早く出すというのが重要だと思う。唯、それがどの部分なのかを見極めるのが難しい所だと思う。

｢続・100万行のソフトの作り方｣を拝見して、
活発な議論されているのは大変興味深く実感した。
小生は、これまで所謂、約15年前になるが｢SE｣であり、
また、｢プログラマー｣であった。
当時は、アプリケーション・パッケージ利用が少なく、
大抵の場合、業種毎に、ベース・プログラムソースが決まっていた、と記憶している。このソースコードを見ると、整然とコーディングされているものもあれば、
最近、2007年問題で話題にのぼる｢スパゲッティーコード｣と呼ばれるものもあった。当時はCobolが主流、そして、PCソフトウェアはベーシックであった。
今回、注目されるのは2点だ。一つ目は、シリコンバレーのソフトウェア開発(｢SE｣と｢プログラマ｣の違い含む)と日本国内の違い。2点目は、膨大なステップ数を持ったソフトウェア開発のメソドロジーに関するものだと認識している。
前者は、かつて議論されてきたキャリア・パスの共通認識が、IT業界の中においてコンセンサスを得られなかったままで時間が経過した結果に引き起こされてしまったのではないだろうか。当時は、入社して｢プログラマー｣を経験、その後、｢上級プログラマー｣になった後に、
顧客業務の分析などの基本設計ができるソフトウェア開発者に至る(これを｢SE｣と呼んでいた)といった具合にだ。ただし、当時でさえ、単なるプログラム開発だけでは十分といえなかった。現在、インターネットが主流になっているが、その頃はパケット通信が主流であり、
業界によっては、全銀協手順やリテールに特化したプロトコルもあって、ネットワーク知識を持った技術者は希少価値が高かったといえる。特に、いまのように、オープンや標準化された技術が少なかったことに加え、電子化されたマニュアルなどが少なかったこともあって、主従関係が成立していたといえる。
この頃の成果評価は、仕様書の書き方から、単体テスト、複合テスト、テスト・データの作成方法、ソースコードの記述方法などが対象となり、いかにして、｢できる先輩｣の下で仕事をするかといったことが、その後のスキルを左右したと思われる。
小生は、幸運なことに、アンダーセン・コンサルティングのシステム構築方法や他社ソフトウェア開発方法などを社会人になった当初に学ぶことができたことは、現在も大きな財産となっている実感している。
説明が長くなってしまったが、｢SE｣とは｢プログラム作成｣は当然であり、｢ネットワーク｣｢検証｣｢効率化施策｣｢マニュアル作成｣｢顧客への技術教育｣まで含めた、広い範囲の知識が必要ではないだろうか。
ところが、企業組織が大きくなると、このタスク毎に縦割り組織になる傾向がなかったとはいえないだろう。
後者に関しては、モジュール開発手法を利用すれば、当時でさえ、センスの良いエンジニアであれば、高い生産性が図られていた。この点では、ステップ数の議論以上に、業務に即した、もっと言えば、仕様書に忠実なソフトウェア開発が求められていると思われる。今後、EAやUMLに期待したい。だが、オブジェクト指向に走りすぎると、その弊害としてソースコードが理解できなくなる事態をも引き起こす可能性があり、このトレードオフを最適にすることが、マネージャーに要求されているのはないだろうか。ご参考まで。

　そう言えば先日、納期の短縮を求められた時にマネージャ（と思われる人）が「プログラマーとSEを増やせばなんとか」と無責任に発言していたので、「SE増やしたところでどーにもならんじゃろ」と思ったのを思い出しました。
　そもそもここでは設計もプログラマーと呼ばれる人がやっているので（つまり他の人が書かれている「SE」なので）、「そもそも増やしたSEってなにするねん？」と突っ込みたくてしょうがありませんでした。
（突っ込むとただでさえ無駄に長いミーティングがさらに延びそうだったのでやめましたけれど）

プログラムが書けない SE がいることにも驚きですが、もっとひどいのは、プログラムにコードというものが存在することすら知らない「コンサルタント」という職種の人たちだと思います。
今の IT 業界が、そうしたコンサルタントたちによって半ば牛耳られていることも事実です。で、技術者は軽んじられる一方です。
技術者に対するしかるべきリスペクトを行っておかないと、日本のソフトウェア産業は遠からず危機的状況に陥ると思います。

日本市場におけるSEという職種の特殊性だと思われます。日本における給与格差でも、SE>プログラマになっていますよね。でも、プログラムが書けないというより理解できないSEは、個人的に嫌いです。何故なら、実装する技術は未だ成長過程で、構想が何でもできるわけではないですから。だからこそ、アーキテクチャが重要だと叫ばれていると思います。
テストエンジニアに関してはとても重要な仕事だと思います。そして、テスト ファーストで利用されるunitテスト等はホワイトテストですよね。これだけでは、プログラムの品質は向上してもシステムとしての品質は向上しないですよね。だから、XPではシナリオがあると思うのですが。このことも含めて、日本においてはソフトウェアに関わるエンジニアは何を目的にしているかを自覚する必要があるし、その作業を行うという意義を社会や会社も認める必要があると思います。そうしないと、職種による差別が無くならないと考えます。