2015.05.12

Agile Japan 2015講演 〜発注側から観るアジャイル開発〜

2

Agile Development/DevOpsの推進を担当している荒本です。今回は4月16日に開催されたAgile Japan 2015の事例セッションで講演した内容を紹介します。Agile Japanは日本のアジャイル開発を普及させるための活動として2009年から始まり今年で7回目となります。日本で開催されるアジャイル開発関連のイベントとしては最大規模のものです。今年のテーマは「失敗から学ぶアジャイル、成功につなげるアジャイル」です。アジャイル開発がエンタープライズのシステム開発へ広がりの兆しを見せる中、日本特有のソフトウェア開発プロセスの構造や、企業においてそれぞれ培われて来た慣習に対して、新しい開発方法を取り組むことは少なからずそれらの何かを変えていかなければなりません。今年のテーマから日本の企業がアジャイル開発を始めるにあたってどのような課題があり、どのように乗り越えてきたかの事例が多く発表されました。このようなテーマ設定からターゲットはウォーターフォール開発を主体としている企業のプロジェクトマネージャー層に設定し、セッションプログラムが構成されていました。

アジャイル開発チームと共に歩む ~発注側から観るアジャイル開発~

3
事例セッションを担当した(左から)KDDI株式会社 クラウドサービス開発部 川上 誠司/クラウドサービス開発部 荒本 実/クラウドサービス企画部 山田 高

KDDIでは約2年前にエンタープライズ向けクラウドサービスを利用するためのIDを管理するプラットフォーム(ID as a Service)を新規に開発するプロジェクトをアジャイル開発で取り組みました。昨年夏にサービス提供を開始し、以降継続的な価値向上のリリースを繰り返し、アジャイル開発のリズムを刻めるようになってきました。このような通信事業のサービスを支えるシステムにアジャイル開発を取り入れることは初めてでした。企画、営業、運用、コーポレート部門などの組織がそれぞれの役割に責任をもって一つの仕事を推進する当社のような企業においては、アジャイル開発の導入は単に開発部門だけが導入する一つの開発手法に留まらず、様々な役割の部門の理解と協力が必要となります。アジャイル開発導入を推進するユーザ企業の立場でどのような変化を起こしていったかについて、事例セッションで紹介しました。

開発チームのあり方を変える

4

まず、内製で開発する方針としました。これまでウォーターフォール型で開発するプロジェクトでは、開発部門は企画されたサービス要件に従い、システム化するための要求仕様書(RFP)を作成し、設計・実装はSI企業に発注し、成果物に対して受入試験を行い、サービスリリースをしてきました。アジャイル開発を取り入れるにあたって、この役割分担のままで発注先のSI企業に対してのみアジャイル開発を求めてもウォーターフォール型開発で抱えている課題は解決しないと考えました。なぜなら、様々な環境変化に対応し、軌道修正しながら必要とされる小さな価値を早くリリースさせる、ことを具現化させるには、開発部門も企画部門と同じ事業目線でバックログの優先順位を考え、そしてシステムのアーキテクチャーや実装を理解していないと正しくスプリント計画の判断ができないからです。しかし、これまで実装を外部に委託してきている開発部門が商用システムのプログラミングができるようになるまでは相当の時間を要することから、当社の開発方針に賛同し目指すゴールを共にできる外部パートナーのエンジニアと社内に共同開発チームを作り、開発体制を推進しました。結果、アーキテクチャー設計は自社の判断で最終決定し、パートナーエンジニアとのペアプログラミングによる実践でプログラミングのスキルを習得し、共同の内製開発チームが確立されています。

受発注の関係を変える

5

IPA(独立行政法人情報処理推進機構)のIT人材白書2014 によると日本のソフトウェア開発の約7割がユーザ企業(発注側)とSI企業(受注側)の契約関係による従来型の受託開発となっています。そこには契約上のSOW(statement of work)により、互いの明確な役割分担による牽制(互いの役割を補完し合う関係になり難い)や、失敗が許されないが故のリスクを取らないテクノロジー採用など、優れたサービスを一緒に開発しようとすることを阻害させるイノベーションが起こりにくい課題があると感じています。それはコミュニケーションと開発プロセスが企画チーム→開発チーム→SI企業→二次請けSI企業の縦方向の流れによることも起因しており、サービスを企画する人とテクノロジーに最も詳しいであろうコードを書くエンジニアが直接コミュニケーションすることは殆どのケースで無く、テクノロジーと企画がコラボレートする機会が失われてしまいます。

6

そこでアジャイル開発を取り組むにあたって最も注力したことは、チームビルディングです。Scrumをプロセスフレームワークとし、プロダクトオーナ、開発チーム、スクラムマスターを社内組織や契約の壁を取り払った一体のチームとし、チームのメンバーは全員それぞれの役割を担った横の関係であることを最も大切にしました。プロダクトオーナとなる企画担当と契約先の外部協力パートナーのエンジニアが直接顔を突き合わせ、コラボレートしながら設計・実装する、といったことが日常的に行われました。

7

契約を変える

一体のScrumチームとするために協力パートナーとの契約も変える必要がありました。従来型の受託開発では成果物を納品する請負契約ですが、成果物を予め定義しないアジャイル開発、かつ、共同内製開発チームを構成するには請負契約は不適切であり、準委任契約としています。準委任契約の場合には発注側が成果物責任を負う覚悟が必要となります。そのためにも自社で実装の中身まで理解しておく必要があり、これも内製開発が求められる理由の一つでした。また、受注側のパートナーにも受け身姿勢で設計・実装するのではなく、プロジェクトの成功のために自身の持っている技術スキルを最大に発揮する能動的な行動が求められます。前述しましたが、開発方針に賛同しゴールを共にした信頼関係を築けるパートナー作りも非常に重要な要素となります。

ユーザ企業でアジャイル開発を成功させるために欠かせないこと

先進的なWeb系企業でない限り、これまでウォーターフォール型で開発してきたユーザ企業では、社内の業務プロセスがウォーターフォール前提で回っており、アジャイル型を導入するには業務プロセスが適合しないなどの課題に直面することがあります。例えば、品質管理部門や運用部門と開発部門との業務プロセス、予算を獲得するための承認プロセス、SI企業と契約するための調達部門の業務プロセス、法務部門の見解など。最初からアジャイル型に拘り過ぎて業務プロセスに適合しないことで諦めてしまったり、部分導入に留めてしまうのではなく、業務プロセス自体のフローは大きく変えず、そこからブレークダウンされた個々の業務の中でアジャイル型を適用することを考えることで解決策は見出せるのではないかと思います。日本のユーザ企業におけるソフトウェア開発はSI企業に開発委託するケースが多いですが、アジャイル開発をウォーターフォール開発と対比させ、SI企業に対してのみ導入を求めてもミニ・ウォーターフォールになるだけで大きな効果は得られないのではないかと考えます。アジャイル開発は開発部門における開発手法の一つではなく、サービスを作り出すための手法であり、事業の企画部門と一体となったチームで進めることで本当の効果を得ることができるものだと思います。そのような意味では、最も大切なことは、SI企業に対して変化を求める前に、発注側のユーザ企業の方が先に変わらなければならないということです。

8

今後も適切なプロジェクトにアジャイル開発を適用していく計画であり、改善を繰り返さなければなりません。ユーザ企業の間でアジャイル開発を実践するための課題や解決方法、ノウハウをAgile Japanなどの場で共有し合い、日本でのアジャイル開発を広げて行きたいと思います。

Agile Japan2015講演資料:「アジャイル開発チームと共に歩む~発注側から見るアジャイル開発~

カテゴリ
タグ

KDDI株式会社 ソリューション事業企画本部
クラウドサービス企画部

荒本 実

新着記事
タグ
アーカイブ
カテゴリー
Contact
TOP