NATO後援の国際会議において、ウォーターフォール・モデルの原型が生まれたのが1968年。それから約半世紀が過ぎた今、業務用システム開発における開発工程の再提唱である「エンタープライズ・アジャイル」が日本でも浸透し始めている。

調査会社ガートナー ジャパンがCIO（最高情報責任者）を対象とした昨年の調査では、アジャイルモデルおよび反復モデルを採用している企業は3割近くに及んでいるという（参照記事）。同社は今後この割合がさらに高まっていくとも予見しており、ユーザー企業をサポートする側のITベンダーやSIerも、「適応」が求められることになるだろう。

こうした状況を、チャンスととらえる企業がある。ウォーターフォール開発に慣れた業務系エンジニアの思考を変化させ、アジャイルに取り組める体制を整えている日進だ。

同社は昨年、NTTデータ イントラマートと業務改善プラットフォーム製品群『intra-mart』の開発パートナー契約を結び、それに合わせてアジャイル開発に対応できるエンジニアの育成を開始している。

特に導入コンサルティングに注力しているというビジネスプロセス可視化・統合ツール『IM-BIS』を活用した案件のプロジェクトマネジャーを務めている榎本周司氏に、同社のエンジニア教育の内情を聞いた。

ゼネコン体質のSI業界に一石を投じるべく、最新手法を先取りする

日進は以前から、日本のSI産業で問題視されてきたゼネラリスト重視のプロジェクト運営に一石を投じるべく、｢ハイブリット・オンショア｣という開発体制を採用してきた（詳細は下記）。

>> 日進が実現した“いいとこどり”の開発体制、「ハイブリッド・オンショア」が理に適っている

それが奏功して業績を伸ばしてきたが、別の課題が生まれていたと榎本氏は明かす。SES事業の枠内ではゼネコン的なピラミッド構造で動くSIプロジェクトの下流から抜け出せず、プロジェクト内容に応じてエンジニアのモチベーションも左右されやすくなるという問題だった。

この課題を解消するため、日進は『intra-mart』の開発パートナー提携によって請負ビジネス以外の事業の柱を作ろうとした。

「NTTデータイントラマートとの契約は、あえてIDP（intra-mart Development Partners)を選択しました。販売パートナーではなく開発パートナーを選択したのは、特定の製品提供に縛られず、良い意味での柔軟さを得るためです。初めての取り組みだけに、今はとにかくひたむきにやってみようというスタンスですね」

結果、これまでに付き合いのなかった顧客と直接取引を実現するなど、着々と成果を上げている。『intra-mart』の新バージョンに対応できるSIerがまだ少数である点も、日進の強みになっていると榎本氏は付け加える。

「私のチームが担当するBPMツールの『IM-BIS』は、ユーザー企業の担当者の目の前でデザインツール、ボタン、テキストボックスなどをクリックすれば、コードを書かずに画面をデザインすることができる製品です。また、画面処理だけでなく、サーバサイドの処理からデータベースのクエリなども全て自動生成するようになっています。それゆえ、常に変わり続けるユーザーニーズにも柔軟に応えることができるのです」

この利点を最大限に引き出すべく、榎本氏のチームはアジャイル開発の手法を学習し始めた形だ。

アジャイル未経験のチームと協働するには「クッション役」が大事

だが、先に紹介した「ハイブリッド・オンショア」しかり、国内外の人材で実装を行っている日進の開発スタイルに、アジャイルの手法を導入することは簡単なことではなかった。

そこで榎本氏は、まず実装チームの教育・育成に力を注いできた。

｢IM-BISを使いこなすための座学研修から始めていますが、それにプラスして、まずはアジャイル開発を実際に体験する場を作ることを重要視しています。ウォーターフォールとの一番の違いは、要件定義が整っていない状態で実装するのが求められること。最初は実装チームのメンバーから、『これで品質が担保できるのか？』、『プロジェクトが破綻しないのか？』などの声が上がりました｣

それでも、「変化し続ける顧客の要望に応えるためには、理屈を超えたことにもチャレンジしなければいけない」と伝えながら、チームを巻き込んでいったと話す。

とはいえ、精神論的に「やれ」と言い続けても、仕様書が固まっていない状態で実装したことがないチームを動かすのは無理がある。

先の見えない中で開発を進める上で最初のカギとなるのは、ユーザー企業と実装チームの間で「クッション役」となる人の動きだという。

日進ではその役割を榎本氏が務めながら、実装フェーズのエンジニアへの負荷を軽減している。

｢以前、当社のグループ会社で大連に籍を置くプログラマーが、IM-BISを使って行政法人さま向けのプロトタイピングを作成した時のことです。画面イメージと粗々の仕様から実装するという開発体制の変化に戸惑いを感じていました。エンドユーザーは日本でしたので、距離があり、直接話すというわけにもいきません。

そのため、私が仕様をヒアリングし、伝えるという調整を行いました。クッション役が間に入り、実現可能な範囲を折衝することで、アジャイルに取り組みやすい環境を作ることもできます。また、従来の仕様管理者・実装担当者という、単能工による分業スタイルではなく、仕様管理・実装を同じ人間が行う多能工スタイルというITトレンドへの転換も比較的容易に実現することが可能となります｣

スタート時点での稼働を減らす、引き算の重要性

仕様を詰めながら開発を進めるアジャイル開発では、顧客との間で要件定義～実装～確認・調整の「ループ」が必ず発生する。その点を見越してスパイラルな開発スタイルにシフトする意識付けも重要だと榎本氏は続ける。

｢従来型の開発に比べれば手戻りが格段に増えるので、実装の初期段階ではできるだけ工数を掛けずに開発するように伝えています。また、ループの回数が多くなり過ぎると予算超過や納期遅延などの問題が発生してしまうため、ここでもクッション役の判断力が重要になります｣

だからこそ、クッション役となる人間には、顧客企業の業務理解や要望把握だけでなく、実装の知識も必要となる。ここが、ウォーターフォール型のSIプロジェクトで要件定義～設計フェーズだけを担っていたエンジニアとは決定的に異なると榎本氏は言う。

良くも悪くも常習化していた「分業体制」からの脱却が求められるわけだ。

「実装のプロである必要はありませんが、あらかじめ何が可能で、どのくらいの工数で実装可能かくらいは理解していなければなりません。また、場合によってはお客さまの要望を100％聞くのではなく、『このフレームワークではできないので別のやり方を考えましょう』、『今回のご要望ではそこまでやる必要がないのでは』と逆提案して実装工数を減らす判断も必要です」

場合によっては、アジャイルにこだわらず、しっかり要件定義をしてから設計・実装に臨む方が早いという状況もあるため、この見極めを行うためになおさら「ツールの理解」と「実装への理解」が大切になるという。

「私の経験則だと、ドメイン数が少なく手早く開発するのが求められる業務システムにはアジャイル開発が向いており、逆にドメイン数が多いシステム構築には不向きです。こういった違いも見極めながらお客さまのご要望に応えていくには、アジャイル開発の教科書的な手法にこだわり過ぎず、“実戦”を重ねていくのが大事なのです」

アジャイル開発の歴史は、ウォーターフォール開発と比較しまだ半分にも満たない。分からないことを許容し、とにかくチャレンジすること。榎本氏の実体験による独自の教育論だ。

取材・文・撮影／川野優希（編集部）