torutkのブログ

ソフトウェア・エンジニアのブログ

ソフトウェア開発技術の現在と今後

ソフトウェア技術者(Software Enginner)、プログラマ(Programmer)を名乗るのであれば、日本のソフトウェア開発産業の今後は気になるところです。

多段階下請け構造という悪癖は、発注側の予算の使途を正確に把握することで改善されるのではないか?
支出の大半が、下請けへの再発注に起因する管理費(ピンはね)に消えるとしたら、それを喜ぶことがあるだろうか。個人情報管理や発注側の秘密情報漏洩などの問題も多段階下請け構造によってしばしば発生している。

短期間で低コストで曖昧な要求に対応するには?
アジャイルな開発をするしかないだろう。但し、技術の蓄積、品質保証の仕組みはアジャイルには含まれていない。アジャイルに力を発揮するチーム作りも組織の責任だ。組織的にアジャイルを活用するには、アジャイルプロセスを責任を持って回すことが必要。

参考文献

二つの合理性と日本のソフトウェア工学

http://www.nistep.go.jp/achiev/ftx/jpn/stfc/stt042j/0409_03_feature_articles/200409_fa01/200409_fa01.html
文部科学省附属の研究機関である科学技術政策研究所が発行する「科学技術動向」の2004年9月号に掲載された記事。

  • 世界の最先端を行くアメリカのソフトウェア・コンサルタントたちが、トヨタ生産法のような「日本式」を、ソフトウェア工学の手法に取り入れ始めた
  • 急速に変化していくビジネスに対応するために、ソフトウェア工学の技術として不可欠なものになりつつある
  • ソフトウェア企業のモデルは2つ。
    • 「ソフトウェア製品企業」不特定多数の顧客が買うソフトウェアを作り、コピーを大量に販売する
    • 「ソフトウェアサービス企業」少数の顧客に対して要望に応じてソフトウェアやシステムを構築する
  • ソフトウェア開発の3つの技術力
    • 基本ソフト、ビジネスアプリ、ゲームなどの個別の製品としてのソフトウェアを開発する能力
    • ソフトウェア開発方法論を元に、発注元の要望を要求として健在化させ、低コストで短期間に高品質なカスタム・ソフトウェアを各発注元のためにカスタム・メードし、それを管理・運営する能力
    • 独自のソフトウェア開発方法論(生産技術)を開発し、それが各企業の競争力の源泉となる
  • ソフトウェア産業最大・最重要の生産装置は「人」
  • ソフトウェアサービス企業の技術分野では日本は見るべきものはゼロ
  • 「知」を記述し記録し加工し伝達するための最良のメディアは、言語である。(UMLも含む)
  • ソフトウェアの本性が合理性・論理性そのもの。本性が合理性・論理性であるものを、非合理的・非論理的に作成しようとすることが困難なのは当たり前
  • ソフトウェアの本性は次の2つ
    • ソフトウェアはサイバー空間を支配する人工的ルール
    • ソフトウェアは目的をもって構築される
  • 仕様とは目的の定式化であり、その定式化された目的とそれを解決するための「解」としてのプログラムを本来の目的に照らし合わせて、同時に検討すること、それがvalidation
  • 藤本(隆宏)の説は設計・製造という行為を「情報の転写」としてとらえる「設計情報転写説」という理論に基づいており・・・
    • 要求工学は、暗黙知という情報を形式知という情報に転写すること
    • 仕様に基づくプログラムの開発とは「形式化された目的」である要求を実行可能なプログラムの形式に転写すること
  • アジャイル法は、カスタム・ソフトウェアの開発現場における現実に対処するために生まれてきた
  • 要求仕様の獲得としてののモデリングにおいて、最も効率的に要求を集める手法の1つはアジャイル法を使うこと
日本のソフト開発力を取り戻せ

日経コンピュータ2004年12月13日号の特集記事。
IPA参加にSEC(ソフトウェア・エンジニアリング・センター)を作成した。ソフトウェア開発の現場にはまだ工学的手法が根付いておらず、勘と経験の属人的な状態としている。30年以上続いた多段階の下請け構造の結果、日本のソフトウェア開発会社の75%は100人以下でコーディングだけを生業とする人出し(人材派遣)形態。

注目する3つの動き

  1. エンピリカル:現場のデータを測定し、それを分析して評価し、現場にフィードバックする
  2. アジャイル:チームによる改善
  3. 要求工学

ソフトウェア・ファクトリ
コラムで書かれていたが、この時代のソフト開発を知らないのでメモ。
1970年代〜80年代にかけて、製造業の大量生産方式や品質管理方式をソフト開発に導入。背景には、

  1. 自社製メインフレームによるプラットフォーム(ハード、OS、ミドルウェア、言語)が均一
  2. アプリケーションが実行する処理はそれほど複雑ではない
  3. システム構築の期間が長く、費用や人をつぎ込むことができた

90年代に入るとオープン化とバブル崩壊により、常にOSとミドルウェア検証に追われ、プロジェクト規模が小型化し、標準プロセスにのっとる方が無駄が多い状況となった。ソフトウェアファクトリで蓄積した開発方式は時代に合わなくなり、冬の時代に入った。

セル生産方式
少数の多能工が部品の取り付けから加工、組み立て、検査までの全工程を担当する仕組み。ウォーターフォール型開発は、コンベヤ式生産でかつコンベヤをいくつかに分断し、一部を外注するビジネスモデル。ソフト仕様変更に機微に対応するのは難しい。