アジャイル開発の
スタートアップ時に
直面する課題を
包括的に解消します

BlueMemeは、OutSystemsをはじめとしたプロダクトと、
コンサルティング、トレーニング、受託開発などのサービスを体系化し、
「AgileSDK」(アジャイル・エスディーケー)として提供をいたします。

アジャイル開発手法が
注目されている理由

ビジネス環境が加速度的かつ予測不能で不確実さを増している昨今、
様々な変化に柔軟に対応することが可能なアジャイル開発手法への期待がますます高まっています。
その背景には、具体的に以下のような社会的必然性があると考えられます。

 

社会的な大きな変化

20年前には想像もできなかったコンピュータの小型化やインターネット環境の普及、スマートデバイスの登場、そして人間と会話が可能なAI等、テクノロジーは破壊的なスピードで進化し続けています。中でもスマートフォンの世界的な普及は、情報のデジタル化および、誰もが情報を手軽に入手できる情報技術の民主化を加速させました。このテクノロジーの進化によって、現在、人間によって行われている知的労働でさえも、コンピュータによって自動化されると考えられています。近い将来必ず訪れる、想像することすらできない新しい社会への対応力が求められています。

 

業務アプリケーションの小規模化・多機能化・短期化

世界的なスマートデバイスの普及と様々なインターネット上のプラットフォームの登場により、アプリケーションのモジュール化と短命化が進み、同時に開発期間と予算も縮小化の傾向にあります。そのため、今後はアジャイル開発と自動プログラミング技術、AI技術を中心としたアプリケーション開発が加速的に発展すると考えられます。この事から、少人数かつ短期間でアプリケーションの開発が可能なアジャイル開発手法が、世界中の多くの企業で採用され始めています。

 
 

サイロ型の機械的組織からボーダレスな有機的組織へ

従来的には、それぞれの役割をそれぞれの部署で集中して実施する「機械的組織」と呼ばれる縦割りの構造こそ、効率の良い組織形態だと考えられていました。しかし、安定した環境下でのマネジメントに向いているとされる機械的組織は、社会もIT市場においても変化の激しい現代には不向きと言えます。
「有機的組織」は、職務権限が柔軟でボーダレスな組織を指します。情報があらゆる場所に分散しており、水平的なネットワーク型の伝達構造を持つことが特徴です。 権限が分散化されている為、ひとりひとりに裁量権と同じだけの責任が生じ、現場での「迅速な意思決定」が求められます。
ソフトウェアプロジェクトのパフォーマンスに重点を置いた調査諮問機関「The Standish Group」による調査では、システム開発において成功率を上げる最もな要因は迅速な意思決定という調査結果が明らかになっています。 不確実性が顕著な今日、個人個人が様々な変化に柔軟に対応することで現場での迅速な意思決定を可能にする有機的組織が、社会全体で求められています。

しかし、
アジャイル開発手法を
導入する際、必ず3つの問題に
直面します

どのようなチームを
構築すればいいのか?

これまでは経験豊富なプロジェクトマネージャーや優秀な技術者をリーダーにすればプロジェクトを回すことができた。しかし、アジャイル開発手法ではそれがうまくいかない。

どのようなアーキテクチャを
用いるべきなのか?

これまでのシステム開発では、膨大な費用をかけてデータベース設計やデータ移行を行っていた。アジャイル開発手法では、そのやり方がうまくいかない場合が多い。

どのように開発プロセスを
変えればいいのか?

様々なノウハウを詰め込み標準化された開発プロセスや方法論が社内に存在するが、これをアジャイル開発手法の流れに合うように変えればうまくいくかどうか確信が持てない。

「AgileSDK」は、
アジャイル開発手法導入時に
発生する
3つの問題を解消する
標準キットです

当社が提唱する方法論「AgileSDK」は、OutSystemsでアジャイル開発を始めるときの標準キットです。
「チームパフォーマンスモデル」「アーキテクチャモデル」「アジャイルV字モデル」の3つで構成されております。

チームパフォーマンスモデル

高生産性を実現するために、新しいテクノロジーやアジャイル開発手法の適切な活用法や、「男女比」「チームサイズ」などを定義したチームモデル。

アーキテクチャモデル

リレーショナルデータベースでは
設計が難しいデータモデルと、
AI/IoTを活用するための
柔軟で多様なデータモデルを実現する
アーキテクチャモデル

アジャイルV字モデル

アジャイル開発手法を用いた大規模なシステム開発を実現するための、素早く意思決定を行うことを最も重要視した、V字型の開発プロセスモデル。

Team Performance Model


チームパフォーマンスモデル

「これまでは経験豊富なプロジェクトマネージャーや優秀な技術者をリーダーにすればプロジェクトを回すことができた。しかし、アジャイル開発手法ではそれがうまくいかない」。チームパフォーマンスモデルは、チームの意味、期待値、コミットメントを明確にし、プロジェクト開始時に自律的なチームを形成するためのプロセスモデルです。


従来のチーム構成方法での
アジャイル開発は難しい

チームの標準化は結果を保証するものではないため、だれがどのプロジェクトでやってもうまくいくような標準化は非常に困難です。また従来のトップダウン型の組織論には副作用があり、アジャイル開発手法に求められる「様々な変化に対応していく組織」を作り上げることは容易ではありません。組織における問題の多くが、「これはやってくれるだろう」というお互いの期待値のズレによるものと、現場を理解しようとしないトップダウンの遅い意思決定プロセスが原因であるためです。

アジャイル開発手法を
採用するだけでは
プロジェクトの大幅な成功率の
向上には繋がらない

2013年から2017年までの約12万件のプロジェクト評価によると、アジャイル開発手法を採用したプロジェクトの成功確率は、アジャイル開発以外のプロジェクトの約1.6倍となっており、大幅に上昇しているとは言い難い結果が出ています。

従来の開発手法での
プロジェクト成功率

アジャイル開発手法での
プロジェクト成功率

From: Decision Theory from Standish Group

迅速な意思決定を行うことが
プロジェクトの成功率を
最も向上させる

成功の要因はアジャイル開発をただ導入することのみではなく、加えて、「迅速な意思決定を行うためのプロセスやスキルを持つチーム形成」が必要です。1件当たり約1人時を基準とした迅速な意思決定を行っている場合のプロジェクトの成功率は、3倍以上に上昇することが分かっています。なお、10億円規模のプロジェクトにおいては約10,000件の意思決定が必要と言われています。集まっただけではチームにはなれません。必要なのは迅速な意思決定を可能にする自律型チームを実現するための形成プロセスの明確化です。

遅い意思決定での
プロジェクト成功率

迅速な意思決定での
プロジェクト成功率

From: Decision Theory from Standish Group


迅速な意思決定を可能にする
自律型チームを実現するための
形成プロセス、
チームパフォーマンスモデル

Drexler & Sibbetが提唱した、ハイパフォーマンスなチームを作り上げるための方法論「チームパフォーマンスモデル」に沿って、当社が独自のコンテンツとして開発したチームのトレーニングサービスや、定量評価ツールを提供し、自主性と意思決定能力を備えた自律型チームの育成をご支援します。

最適なチーム作りを体系化

チーム作りに欠かせないステップを、チームの「参集」に始まり、「信頼構築」から「成熟」、「チーム再編」に至るまでの合計7ステップに体系化し、可視化しております。

トレーニングの提供

「意思決定のスピード」「チームの成熟度」などチーム稼働で重要な9つの要素を定義し、それらに基き「アジャイル開発に適した自律型チーム」に成長するためのトレーニングをご提供します。

アジャイルアセスメントサービス

チームを四半期ごとに定量評価して、レーダーチャートに課題を可視化し、現状と改善点を把握するツールなどをまとめた「アジャイルアセスメントサービス」をご提供いたします。

Architecture Model


アーキテクチャモデル

これまでのシステム開発では、膨大な費用をかけてデータベース設計やデータ移行を行っていました。アジャイル開発手法では、そのやり方がうまくいかない場合が多くあります。アーキテクチャモデルは、最適なアーキテクチャを選択することでシステムの開発・運用の工数を削減することと、技術者の多能工化を実現し、システムの構築・保守のために必要な人材を最小限に抑えることができるプロセスモデルです。
アジャイル開発に適したアーキテクチャモデルを構築するためには、「テクノロジーの選択」と「必要な人材の数」の2つが重要なポイントになります。


テクノロジーの選択

アジャイル開発に最適な
テクノロジーの選択

紙で運用されている業務をExcelでデジタル化することは、データ構造の変更が無く、アーキテクチャがシンプルなため、比較的容易に実現可能です。しかし、リレーショナルデータベースとJavaとWebでデジタル化する場合には、データ構造のミスマッチが多くなることでアーキテクチャが飛躍的に複雑化し、想像以上に困難です。業務要件をすべてサポートする、最も開発効率の良い選択をすることが求められます。

階層型データに対応した超高速開発基盤を活用

オブジェクト指向言語をアーキテクチャとして選択すると、開発工数が飛躍的に増加してしまいます。階層型データに対応した超高速開発基盤を活用することで、オブジェクト指向への変換を避けることができます。

さらに、階層型のデータ構造に対応した
データベースを活用

リレーショナルデータベースとJavaとWebの場合、データ構造のミスマッチが多く、アーキテクチャが飛躍的に複雑化します。階層型のデータ構造に対応したデータベースを選択することで、階層型のデータをそのままデータベースにに保持・活用することができ、変換のプロセスが減少します。

階層型データに対応したアーキテクチャを
併用することが工数削減の鍵

階層型データに対応したアーキテクチャを併用することで、データ構造の変換により発生する膨大な開発工数の増加を防止することができます。


必要な人材の数

必要な人材を最小限に抑える

アーキテクチャの選択によって必要な人材が大きく変わります。最新技術を用いて技術者の多能工化を実現し、システムを構築及び保守するために必要な人材を最小限に抑えることが求められます。

これまでは別々のスキルを持つ
別々のスペシャリストが必要だった

マルチデバイス対応のアプリケーション開発には、Web技術者、Android技術者、iOS技術者、サーバサイド技術者、データベース技術者と、別々の技術を持つ人材がそれぞれ必要でした。人数増加におけるリスクはもちろん、Web系の技術者はそもそも集めることが難しいことも問題です。

最新技術を活用し、1人の技術者の多能工化を実現

最新の技術と最適なアーキテクチャを選択することで、それぞれのスペシャリストが有さない他の領域に関する部分を補足します。それによりスペシャリストの能力をツールが補うことによる多能工化を実現できます。

リレーショナルデータベースでは設計が難しいデータモデルと
AI/IoT活用のための柔軟で多様なデータモデルを実現するアーキテクチャモデル

レガシーシステムからのマイグレーションを容易かつ迅速に実現するとともに、多様なデータの柔軟な活用を可能にする様々なアーキテクチャモデルを提案いたします。当社によるアーキテクチャモデルの提供事例では、データ統合基盤に採用したエンタープライズNoSQLデータベース「MarkLogic」と超高速開発基盤に採用した「OutSystems」を連携させて、社内に蓄積された多様なデータを活用できる業務システムを構築するサービスをお客様に提供しております。
>>プレスリリースはこちら

最適なアーキテクチャの
選択基準を定義

「業務要件と設計情報を慎重に切り離す」「インピーダンスミスマッチ等の問題を抑えたアーキテクチャを選択する」など、アーキテクチャの選択基準を定義付けております。

階層型データに対応した
アーキテクチャの活用

事前のテーブル設計が不要なNoSQLデータベース「MarkLogic」を用いることで、データ構造の変換により発生する膨大な開発工数を大幅に削減することができます。

多能工化を可能にする
アーキテクチャの選択

マルチデバイス対応のアプリケーション開発には「Web技術者」「iOS技術者」をはじめ、5種類の技術を持つ人材が必要ですが、OutSystemsを用いれば、1人の技術者で対応可能です。

Agile V-Model


アジャイルV字モデル

開発方法論に関係なく、1件当たり約1人時を基準とした迅速な意思決定を行っている場合は、プロジェクトの成功率が3倍以上に上昇します。10億円規模のプロジェクトにおいては約10,000件の意思決定が必要と言われており、迅速な意思決定を行うためのプロセスやスキルがプロジェクトの成功率を最も向上させると分かっています。「アジャイルV字モデル」は、意思決定を明確するための超高速開発基盤向けのプロセスモデルです。
アジャイル開発に適した開発プロセスには、「方法論の選択」「工数計算」「意思決定モデル」の3つの重要なポイントがあります。


方法論の選択

「アジャイル」とは、
最高のチームを作るための
方法論

アジャイルとは、ソフトウェアの開発チームが、いままでより効果的な考え方をしたり、効率的な作業方法を実践したり、よりよい決定をするための手順や方法をまとめたものであり、最高のチームを作るための方法論でもあります。1986年に発表された竹内弘高と野中郁次郎の論文である『The new new product development game』において、製品開発という速さと柔軟さが求められる場面では、様々な専門性を持った人がチームを組み、人とチームを重視し、彼らの自律的に動ける環境を与えることで、ブレークスルーが起こりやすくなり、製品化までの時間が短くなると主張しました。野中郁次郎らが指摘した先進的な企業の製品開発の6つの特徴は以下です。

Built-in instability
不安定性の組み込み
Self-organizing project team
自律型のプロジェクトチーム
Overlapping development phases
重複した開発フェーズ
Multi-learning
多層学習
Subtle control
柔らかな管理
Organizational transfer of learning
組織内による学習の移転

工数計算

生産性の変動率を考慮した
工数計算が、
適切なリカバリーを可能にする

開発の生産性は、開発規模、チームサイズ、プロジェクト期間で変動するため、プロジェクトデータベース等を活用して工数を算出することが必要です。生産性の変動率を考慮した工数計算により、適切なリカバリーが可能になります。

リカバリー案の効果を計る

開発が遅延しており、何か手を打たなければリリースに間に合わない状況にある場合、リカバリー案としては、主に「機能削減」「人員追加」「納期延長」の3つの手段がありますが、それらがもたらす効果の単純計算は可能なのでしょうか。

開発規模と生産性の関係性を考慮した工数計算

グラフは最低生産率、平均生産率、最高生産率を示しています。現状のチームの生産性が10時間/FP、進捗率25%、1人当たりの時間単価7,500円の状態で、200FPを削減し、残りの機能を次のリリースに延期した場合の工数計算の例です。生産性が11%上昇していることが分かります。

チームサイズと生産性の関係性を考慮した工数計算

グラフは最低生産率、平均生産率、最高生産率を示しています。現状のチームの生産性が10時間/FP、進捗率25%、1人当たりの時間単価7,500円の状態で、3名追加した場合の工数計算の例です。6人を9人にしただけで、生産性が51%下がっていることが分かります。

プロジェクト期間と生産性の関係性を考慮した工数計算

グラフは最低生産率、平均生産率、最高生産率を示しています。現状のチームの生産性が10時間/FP、進捗率25%、1人当たりの時間単価7,500円の状態で、プロジェクト期間を2ヵ月追加した場合の工数計算の例です。生産性は17%下がりました。

生産性の変動率を考慮した適切なリカバリーを算出する

開発の生産性は、開発規模、チームサイズ、プロジェクト期間で変動します。このケースの場合は、機能(スコープ)削減がベストという結果を出すことができました。


意思決定モデル

迅速な意思決定を行うための
プロセスモデル

アジャイル開発において、素早い意思決定を行うことは最も重要であるため、少人数の自律型のチームで意思決定が行える仕組みを構築する必要があります。また、受入基準を明確に定義することで、業務要件と詳細設計の意思決定を明確に分離し、技術者への負荷を軽減すること、がプロジェクトの成功に繋がります。

業務機能の定義から受入テストまでの基本的な流れ

プロジェクトの意思決定の階層および基本的な進め方は、「①業務機能要件分析」からはじまり、「②ソフトウェア機能要件分析」「③計画、実装及びテスト、ソフトウェアの開発」「④テスト」「⑤受入テスト」の流れとなっています。

意思決定が不明確なプロジェクトでは
技術者に大きな負荷がかかる

本来は設計と実装に注力すべきシステム担当者に、業務サイドの意思決定もなく、直接業務機能の見直しを迫るケースが多くあります。このような、階層化を無視した流れは、技術者に大きな負荷がかかります。

終わらないアジャイル開発の原因は受入基準の不備

実装するソフトウェアが要件を満たしているかどうかを評価するための受入基準を作成することにより、ソフトウェアはテストケースに合格するように設計及び実装が行われるため、実装完了後、短期間でテストに合格させることが可能 です。しかし受入基準を作成しなければ、要件の不具合を明確にすることは不可能です。また、テスト結果を評価するための明確な受入基準がなければ、テストの度に異なる視点で場当たり的なテストが行われてしまい、要件が増加し続け、開発の負のスパイラルが発生します。


大規模なシステム開発を
アジャイルで実現するための
V字型の開発プロセスモデル、
アジャイルV字モデル

当社が提 唱してきたアジャイル開発の方法論とプロセスを体系化した「アジャイルV字モデル」を提案いたします。大規模プロジェクトへのアジャイル開発手法の適用を可能にするとともに、開発プロジェクトのプロセスのモデル化及び明確化を支援してまいります。

アジャイルV字モデル

ソフトウェア開発の上流工程であるビジネス機能要件定義に始まり、ソフトウェア機能定義、設計、実装と配備、テストとそれぞれの評価までの計8つのステップをV字モデルで表現および可視化いたしました。

3つのフィードバックループ

アジャイル開発の核心である「作って、見せて、修正する」のサイクルを、7ステップを結ぶ3つのフィードバックループを用いて可視化しました。ソフトウェアの不具合などを予防し、検出をサポートいたします。

プロダクトのご提案

アジャイルV字モデルの7ステップに対応する、OutSystemsの実装テンプレート・共通部品などを始めとしたプロダクト群から、お客様企業のお悩み・ニーズに合わせてプロダクトをご提案いたします。


大規模アジャイルの基本構造

大規模アジャイルの手法の多くは、システム開発における意思決定を3~4の階層に分けて行い、複数のスクラム開発チームを運営するという構造が基本です。しかし、いきなり大量のスクラムチームを作ると破綻してしまいます。まずは1つのスペシャルスクラムチームを作り、そのチームに一番難しい一機能を切り出します。スペシャルスクラムチームができたら、それを見習う次のスクラムチームを作り、数値化できるまで実施します。

アジャイルV字モデルとの関係

アジャイルV字モデルの3つのフィードバックループは、大規模アジャイルの基本構造である「ポートフォリオマネジメントチーム」「プロダクトチーム」「スクラム開発チーム」に、それぞれ割り当てられます。

資料請求および
デモンストレーションのご希望は
info@bluememe.jp または
0570-080-016 まで
お問い合わせください。