[木内里美の是正勧告]

2018年1月22日(月)木内 里美（オラン 代表取締役社長）

リスト

　ある業界団体からの誘いを受けて、政府のシステム関係者向けに“ライブ開発”をするイベントに立ち会わせてもらった。ライブ開発とはその場でテーマを出し、それを実現するシステムを開発するもの。言わばアジャイル開発の一種である。政府の関係者に多様な開発手法があることを体感してもらい、情報システム開発の選択肢を増やすことがイベントの趣旨だった。

　このイベントが企画された背景には驚くものがあった。数々の失敗プロジェクトの反省もあって、政府におけるシステム開発の時間が長期化しているのだ。何しろ要件定義書の作成に1年、発注手続きに半年以上、開発に複数年かけているのが一般的だという。当たり前だが、そうして稼働させたシステムは陳腐化も早く、業務の刷新もできないまま次期システムの計画に入ることが多いとも聞いた。つまり従来のウォーターフォール型開発では開発期間が長すぎるので、アジャイル開発なら期間を縮められるのではないかという思惑があるようだった。

　しかし、そもそも政府における情報システム開発の失敗は、多くが発注側の主体性の無さが原因ではなかったか？ 加えて個別入札に拘る調達の仕組みやベンダーマネジメントにも問題があり、技術の理解も十分ではない。そうした中で、外部委託と言えば聞こえはいいが、いわゆる丸投げに近い開発が行われてきたせいではなかっただろうか？

　そんな根源の課題を見直さないままにアジャイル開発に期待を寄せている──。そう感じたのは筆者だけではなかったはずだし、大いなる誤解と言わざるを得ない。アジャイル開発に安易に期待しても主体性がなければ成功するわけがない。なぜならウォーターフォール型開発よりも主体性や協働が強く求められるからだ。

定義が明確でないものには危うさが伴う

　アジャイル開発は日本の生産現場の強みを研究した米国で1990年代後半に広まった開発手法だ。明確な定義があるわけではない。アジャイルという言葉から「俊敏」「素早い」というイメージが強く、ウォーターフォール型開発手法の対義語のように扱われることも多いが、正確な理解ではない。中間的な開発手法にはプロトタイプ開発や反復開発や古くからあるRAD（Rapid Application Development）やRUP（Rational Unified Process）などもある。

　最近では超高速開発と呼ばれるRAD系の開発ツールがたくさん出てきて、これらを使った開発がアジャイル開発だと考えている人たちもいる。アジャイル開発の本流のようなスクラムやエクストリーム・プログラミングこそがアジャイル開発と理解する人たちもいる。このように定義が明確でないために「アジャイル開発」の議論は解釈が様々で、一部の特徴だけを捉えて議論していたりして曖昧であり危うい。

　しかしアジャイル開発の一つのエポックは2001年にアジャイル開発関係者が集まって「アジャイルソフトウェア開発宣言」というマニフェストを示したことであろう。そこには「個人と対話」「動くソフトウェア」「顧客との協調」「変化への対応」というアジャイル開発手法の価値が示され、アジャイルソフトウェアの12の原則（http://agilemanifesto.org/iso/ja/principles.html）が示されている。

本質を外さないアジャイル開発の勧め

　12の原則の一部を抜粋してみよう。