IPAが書いたアジャイル開発の研究会報告書

IPAが200頁にものぼるアジャイル開発の研究報告を公開していた。
IPAが公開している研究報告は、RubyやRailsやアジャイル開発などの昨今の話題を日本のIT業界のエスタブリッシュメントがどんな観点で見ているのか、を知る上で非常に参考になる。
運営委員に平鍋さんや羽生田さんがいて議論に加わっているのが興味深い。
気になる文言をメモ。

【元ネタ】
情報処理推進機構：ソフトウェアエンジニアリング

調査報告書[1.68MB]

研究会報告書[924KB]

成果概要資料[702KB]

・共通フレームについても、改めて見直してみたが、ウォーターフォールを標榜していると誤解されても仕方が無いなと感じた。ウォーターフォールを定義できる辞書を整備して、最後に、段階的や進化的プロセスも説明できるよという書き方になっている。要求定義が不十分であることが、リスクとして扱われている。アジャイルプロセスでは、このことはチャンスである。
↓
共通フレームは、経産省がまとめた日本版のIT標準プロセス。(←さかばさんの指摘を受けて修正)
共通フレームを作った人はアジャイル開発をどのように見ているのか参考になる。

・IBMやMicrosoft がALM (agile application life cycle management)の分野に出てきたのは、Rally やVersionOne がこのツール市場のリーダーになってきていて、世界的にも市場が広まってきたことが動機である
↓
IBMやMSが何故アジャイル開発ツールを積極的に販売しているのか？
時代の流れ。
マーケットの推移。

・当社ではWIP (works in progress) limit（仕掛り制限） の様なものを、Redmine で実装しようと試みている。また、この機能に内部統制要件も加えて、JSOX 監査にも対応出来るタスク・承認・証跡管理の統合ツールにしようとしている。

・どこまでやるかはあるが、SVN (Apache Subversion), Hudson, Maven (いわゆるCI環境)で出来るだろう。Redmine まで組み合わせれば、開発者のタスク数までトラッキング出来る。
↓
IPAの研究報告書からRedmineが出てくるとは意外だった。
アジャイル開発は、ホワイトボードやPostItなどのアナログでしかプロジェクト管理できない、と思われがちだが、チケット駆動開発を使えば、ソフトウェア開発プロセスそのものをIT化できて、開発そのものをより自動化出来るはず。

・現在、私は、添付の論文にある「形式手法のアジャイルへの適用」に、以前から興味をもち、勉強しているところである。
・FormalMethod のアジャイルの適用についてだが、有望な観点だと思う。
↓
一部の人達は形式手法の可能性を色々試している。
形式手法とアジャイル開発の関係は僕はよく知らないので、調査してみたい。

・韓国のサムスンSDS とLG CNS（韓国の２大SIer）にヒアリングに行ったととき、彼らは通常、システムを３回作ると言っていた。設計－開発－テストのプロセスを大きく３回繰り返している。
・(日本の)ソフトウェアの国際競争力に関して、関連業界団体が共同で試算した輸出入額（2000年まで）で計算すると、限りなくマイナス１に近い。つまりまったく競争力がない。
↓
ソフトウェア開発とハードウェアの開発の違いは、バージョンアップにあると考えている。
ソフトウェア開発は、1回のプロセスでドカーンと一発リリースすると必ず失敗する。
3回リリースして初めて品質も使い勝手も良くなる。

韓国が最近目立ってきているのは、ソフトウェア開発の特徴を熟知していて、ソフトウェアプロダクトラインのような開発スタイルの研究が進んでいるからではないかと思ったりする。
それに比べて、日本のSIは未だにWF型開発のまま、20年以上何も変わっていないのではないだろうか。

・IT 産業(特にSIer)は、知識集約型のはずなのに、あいかわらず労働集約型である。某米国IT ベンダの方にアーキテクトは育成するのか？」と質問したことがあるが、「育成なんてしない。だって、アーキテクチャ設計ができる人を採用するから。」という単純明快なご回答であった。
・私が気になっているのは１点のみ。日本式多重下請け構造のままで、世界と戦えますか？ということである。
↓
昔から言われている問題。
業界や会社が状況を変えるのは無理だと思う。
オープンソースやコミュニティがその状況を変える可能性を秘めていると思う。

僕はアジャイル開発こそ、ソフトウェア開発の特徴を最も表していると考えている。
つまり、システムを頻繁にリリースしてバージョンアップしながら、システムの品質も使い勝手も改善していくスタイルがソフトウェア開発なのだ、と。
そして、頻繁なリリースに耐えうる技術、プロセスを支える基盤の一つにチケット駆動開発があると確信している。