業務システム開発へのスクラム開発適用事例システム開発において、激変するビジネススピードへの追従と、新たな技術を適用する上で抱えなくてはならないリスクに柔軟に対応するために、アジャイル型のスクラム開発という手法は一つの答えです。不確実性に対して顧客とベンダーが一丸となって立ち向かうチームを作り、成功させたプロジェクト事例をご紹介いたします。スクラム開発のノウハウをお役立てください01開発プロジェクトが抱えていたリスクシステム開発における不確実性と未知へのチャレンジ大規模な社会インフラを運用する情報システム企業を親会社に持つA社は、業務アプリケーション開発に強みを持っている。社会的に大きな責任を伴うシステムを開発するA社にとって、システムの品質は最重要項目である。システムの品質とは、ユーザーが要求する機能を提供できることは当然として、本番運用におけるサービスレベルの保証からなるもので、アプリケーションを動かすシステム基盤、インフラにも、一定レベルの品質が要求される。そんな中、同社は大きな技術的チャレンジを迎える。ATOMプロセッサを搭載した低消費電力・低コストのサーバーを集積したサーバーシステムの採用が決定したのだ。通常サーバー用途で使用されるハードウェアと比較すると1台当たりの性能も信頼性も劣るが、数十台を組み合わせた拡張可能な構成をとることで、システム全体として冗長性を確保しつつ、スケーラビリティを備えたインフラ基盤とするのが狙いだ。一般的に、多数のリクエストを同時に処理するWebサーバー、Webアプリケーションサーバーは、スケールアウト構成となる場合も多く、1台当たりの信頼性はそこまで求められることはない。データベースサーバーにはアプリケーションからのデータアクセスが集中してもその処理速度の低下や応答停止を引き起こさないよう、高い性能と信頼性が求められる。ハードウェアの制約に従いつつ、求められる品質を担保するために同社が選択したのは、分散型データベースの採用であった。この選択により、システムの実現性は見えてきた一方で、同社にとって未経験のシステム基盤の上で、未経験の分散データベースを稼働させる、という大きな技術的不確実性を伴うプロジェクトとなった。不確実性はプロジェクト推進にとってリスクであるが、リスク発現時の対処コストをそのまま計画に織り込むとコスト高の要因ともなってしまう、非常に頭の痛い問題でもある。不確実性を受け入れ、プロジェクトを前進させるためのスクラム開発とは前記のような技術的不確実性を抱え、新システムの開発とハードウェア・ソフトウェアスタックの検証を並行してプロジェクト推進する同社。検証の過程で設計に影響を与えるような変更が発生することが十分に見込まれる中では、プロジェクトの工程をフェーズごとに分割し、段階的に成果物を確定させていく、従来のウォーターフォール型開発では対処が難しいことが予想された。このような状況下で、アークシステムが提案したのは、アジャイル型のスクラム開発によるプロジェクト推進である。スクラム開発とは、プロジェクトを1~4週間程度の「スプリント」と呼ばれる短い期間で区切り、各スプリントの中で優先度の高いシステム要件から開発していく手法だ。システム要件は全て「プロダクトバックログ」と呼ばれるユーザーにとって価値のある単位に細分化され、規模の見積、優先度付けがなされる。スプリントを繰り返すごとに、ユーザーにとって価値があり、優先度の高い機能が出来上がることになる。この繰り返しの中で、システム開始時には気づかなかった要件やビジネス要求の変化に合わせてプロダクトバックログリストを絶えず洗練させ続けることで、ユーザーにとって真に価値あるものの開発に集中できる。アークシステムの提案のポイントは、技術的不確実性への対処とシステム要件を等しくプロダクトバックログとして扱うというところにある。技術的不確実性への対処が当初想定規模を超え、システム開発の進捗を圧迫しそうになった場合でも、顧客価値という一貫した基準で優先度を付け、対応可否を判断する。することで、システム要件の開発を先送りしてでもリスクに対処するのか、それともある程度リスク対処したところでシステム要件の開発を優先するのか、プロジェクトが進行する中でも柔軟に対応することを可能にしたのである。仮に技術的不確実性への対処が想定より膨らんでしまった場合に備え、金額・スケジュールのバッファを積んでおくのではなく、優先度の低いシステム要件を開発することを止めることで対応する。これまで、前工程の要件定義でユーザーと合意したシステム要件は全て提供することが当たり前であったA社にとって、システム要件に優先度を付けること、ましてやスコープアウトはなじみの薄い概念であったが、納期とコストを一定に抑えたまま、プロジェクトを推進できることが評価され、両社で協力してシステム開発にあたることとなった。立場を超えてチームを形成し、ともに問題に立ち向かうシステム開発において、発注者と受注者の信頼関係は常に重要である。スクラム開発においては、プロダクトバックログごとの規模見積、1スプリントで対応可能な規模など、信頼関係がなければ成り立たない。受注者側でごまかしがあってはならないのはもちろん、発注者側でもしっかりした根拠に基づいて検証できることが求められる。本プロジェクトの推進に当たっては、日々の開発状況、ソースコード、テスト課題発生状況など、すべてがA社からも見える状態で行った。スプリント終了時には、それまで完成しているシステムを実際に動かしながら進捗を確認した。時に、デモ中に仕様に対する両社の認識の齟齬が浮き彫りとなり、熱を帯びたディスカッションが繰り広げられることもあった。並行して進めていた分散型データベースの検証では、特有の意図しない挙動が発見され、システム設計の変更を迫られることもあった。した課題が発見されるたびに、両社で解決策を話し合ったことで共通の認識が生まれ、課題に対して協力して取り組む土壌ができていく。スプリントを繰り返すごとに、1つのチームとして信頼関係が深まっていった結果、ともに問題に立ち向かう関係が出来上がっていったのである。04柔軟な変更と的確な判断を可能に変化を受け入れ、ユーザー価値に焦点を当てたシステム開発をプロジェクト開始当初、アジャイル型の開発に不安を抱えていたA社であったが、プロジェクトの進捗とともに徐々に不安は解消されていき、安心感を得られたとの声をいただけた。それは、下記のような導入効果が実現したためであろう。プロジェクト進捗の見える化システム開発における進捗報告は、当初計画に対し今現在どの程度進んでいるのか進捗率で報告したり、課題一覧を共有したりする場となる。1~2週間隔で行われるのが多いのではないか。前記の通り、本プロジェクトにおいてはすべてが見える状態で進めたため、課題の発生や解決の状況は、定例の場を待たずに共有される。進捗状況もただの数字としてではなく、実際に動作するアプリケーションとして表現されるため、一目瞭然である。要件に対する認識の齟齬や、そもそものビジネス環境の変化による変更要望などは、ともすれば受発注両社の対立を引き起こす要因となり得る。本プロジェクトのように、大きな技術的不確実性がある場合、それをどちらがリスクとして背負うかで対立を引き起こすこともある。スクラム開発を選択し、協力し合うチームとして信頼関係を深めつつプロジェクトを進めたことで、プロジェクト開始時には分からなかったユーザー要件が明らかになったり、技術的課題が持ち上がったりしても、対立するのではなく、協力して解決に当たることができるようになった。結果として、大きな技術的不確実性があったにもかかわらず、本プロジェクトは当初想定したスケジュールとコストの範囲内で無事にカットオーバーを迎えた。本プロジェクトのように、事前に影響範囲を評価することが難しい不確実性を抱えたプロジェクトにとって、スクラム開発に代表されるアジャイル型のプロジェクト推進手法は特に有効ではないだろうか。05スクラム開発のノウハウをお役立てくださいシステム開発のその先についてこれまでシステムは利用するだけであった企業においても、開発を外部に委託していては、ビジネス環境の変化の速度についていけない状況が生まれている。アークシステムでは、受託開発におけるスクラム開発はもちろん、ユーザー企業の内製化支援にも積極的に取り組んでいる。豊富な開発経験を持ったスクラムマスターと開発メンバーが、ユーザー企業のメンバーと一緒のチームとなり、プロダクト開発をすることで、システムを構築して終わり、ではない、新たな価値を提供していく。お問い合わせサービスの導入をご検討されているまたはサービスについてのご質問などがございましたらお気軽にお問合せください。