ABOUT USフロイデールについて

アジャイルとラボ型開発

ウォーターフォールとアジャイル

ウォーターフォールとは

開発の早い段階で開発範囲(スコープ)を固定し、作業を「工程」という単位に分ける

システム開発の過程「要件定義・基本設計・詳細設計・実装/単体テスト・結合/総合テスト・本番」
という形で時間軸で「工程」という単位に分け、開発の早い段階で開発範囲(スコープ)を固定化、それぞれの工程で「仕様書」作成して開発側と発注側の認識をあわせながら、
滝の水が上から下へと流れ落ちるように、開発の各工程を進めていく開発手法を「ウォーターフォール型開発(以下ウォーターフォール)」と呼びます。

 ウォーターフォールは、各工程ですべきことがはっきりと分かれているため、
「要件定義を行う人」「実装/単体テストを行う人」と、役割をハッキリ決めることができます。
そのため「実装/単体テスト」の工程だけを他社に発注するような形をとることができ、
SIerは「実装/単体テスト」の工程を行うエンジニアを採用せず、その箇所を下請企業や客先常駐派遣で対応するスタイルが増えました。現在でもウォーターフォールはソフトウェア開発現場において主流を占めています。

ウォーターフォールの課題

01.後戻りする際、非常にコストがかかる

しかし、滝の水を下から上に逆流させるためには多大なエネルギーが必要なように、結合/総合テストで不具合が発見された場合、要件定義や基本設計の段階に戻ってやり直す必要があります。それはそのまま納期の遅延や開発コストの増加につながります。よくシステム開発の際に”炎上””デスマーチ”という言葉が使われることがありますが、これは本来要件定義や基本設計で決めるべきことがしっかり決めきれてなかったり、発注側も受注側も”何を決めないといけない”がよくわかっていなかった時に頻発します。

02.全て終わった後でないと、発注側はシステムを見ることができない

また発注側は、全ての工程が完了して納品した後でなければ実際に動くシステムを目にすることができません。いくら受注側から「仕様書にかかれていなかった」と言われても、納得のいくシステムが手に入らないと発注側の満足度は下がります。

ウォータフォールの課題がビジネスの致命傷になる可能性

これらの課題は、技術の進歩が加速度を増している現在、ビジネスにおいて大きな課題になる恐れがでてきました。ウォーターフォール型でシステムを開発する場合、1〜2年かかることが一般的です。その間、新しい技術やサービスがどんどんローンチされる現在、”後戻りできない”スタイルでは、できたとしても既に競合がリリースしていてシェアが取れないなど、ビジネスで勝ち抜けなくなる可能性が高くなります。

そもそも、人工知能やIoTなど、どんどんライブラリやフレームワークなどが出てきている現在、開発の早い段階で開発範囲(スコープ)を固定化するウォーターフォールでは、本当に発注側のビジネスに寄与する斬新なサービスを実装することは難しいでしょう。

アジャイルとは

最初に全てつくらず、ユーザーの反応を見ながら、開発とリリースを継続的に行う

アジャイルは、「イテレーション」 と呼ばれる一定の期間内で、ウォーターフォールと比べると少ない人数(5名程度が一般的)でチームをつくり、ユーザーの反応を見ながら開発とリリースを継続的に行っていく手法です。 イテレーションの期間はプロジェクトごとに異なりますが、1週間から4週間くらいであることが多く見られます。イテレーションの期間の中で、分析からリリースまで全て行い、発注に本当に必要な価値あるサービスを継続的にとどけます。

いわゆるプロトタイプ開発と異なり、アジャイルでリリースされるサービスは、顧客にとって「価値あるもの」である必要があります。
例えば「旅館のWebサイト」を構築する際、プロトタイプ開発ではWebサイトのモック(画面だけの”紙芝居”のようなもの)を作ります。モックがあると発注側はある程度イメージをつかむことができますが、それ自体は発注側にとって価値あるものではありません。
アジャイルの場合は、旅館のWebサイトの”一番重要な部分”、例えば”旅館の予約機能”をまず実装し、それを実際にリリースします。その後、発注側はユーザーの反応を見て、受注側と相談しながら”キャンペーン機能””SNS連携機能”などを適宜追加していく形をとります。

 

アジャイルのメリット

変化する状況に素早く対応できる

将来を正確に予測する事はできません。競合サービスのリリース、使用予定のライブラリのサービス停止、リードエンジニアの離脱etc...状況は時間とともに必ず変化し、発注側が受注側に要求を変更したいと考える場面が絶対にあります。そのような時、発注側と一緒に費用対効果を判断し、やるとなった時はリスクを抑え素早く対応することで、価値あるものを継続的に提供し続けることができるのがアジャイルです。

見積もりやドキュメントよりも実際に動くサービスにリソースをさくことができる

アジャイルは、ドキュメントや見積もりのような実際のエンジニアリングに関係のない部分の作業は必要最小限に抑えます。かわりに「受注側」と「クライアント」が役職や担当の壁を超え1つのチームとなり、両者で「何を終えたらうまくいっていると言えるのか」を、チーム間の積極的なコミュニケーションの中で定義・共有し、それを判断基準とします。結果、チームは「価値あるサービス」を継続的にリリースすることにリソースを割くことができます。

 

アジャイルとラボ型開発

アジャイルを行うために必要なものとあったほうが良いもの

変化がどんどん加速度を増していく現在、”アジャイル”への期待が、発注側も受注側も大きくなっています。しかし、ウォーターフォール型開発で”実装・テスト”の工程だけを対応していたエンジニアをいきなり集めても、それが即アジャイルができるチームになるかというと、なかなか難しいのが現実です。

なぜかというと、アジャイルの場合、チームメンバにはプログラマ・デザイナ・テスタ・マネージャなどとそれぞれ役割はありますが、ある程度その役割に”重なり”がないと、誰かが風邪や事故で行って期間離脱した時、チームの作業サイクルが止まり、”短い期間で開発とリリースを継続的に行う”ことができなくなるからです。

この「チーム」という考え方がヒエラルキーが浸透した日本の企業組織ではなかなか根付きづらく、まずここで何らかの支援が必要になることが多く見られます。

それだけではなく、アジャイルであるためにはスクラムやXP・Leanなど、様々なレイヤから見た開発手法やフレームワークが存在し、ある程度それらを理解・実践する必要があります。また、アジャイルになじみやすいアーキテクト(Ruby on Rails、その他)の知識もあったほうが良いでしょう。

フロイデのラボ型IT支援サービスと様々なラボ型開発

そのような段階を経てラボ型開発ができるようになったとしても、受注側と発注側の契約形態や認識のずれなどでなかなかうまくいかない場合も多々あります。フロイデールの関係会社であるフロイデ株式会社では、そのような課題を回避できるよう、技術者派遣事業をやってきた過程で取得したノウハウな一般派遣免許を生かし、派遣契約で一定期間(2週間から1ヶ月)、お客様先にエンジニアを常駐させて信頼関係を構築した後、エンジニアを自社に戻してラボ型開発(月額精算の準委任契約)への切り替えを行う「ラボ型IT支援サービス」を行っています。

このように、ラボ型開発を自社のサービスとする過程で、様々な新しい知識やノウハウの必要性を自覚して新しい手法を学び実践すると同時に、自社の過去の再評価を行って見出したプラクティスを競合会社との差別化の材料にすると、より効率的です。

フロイデールは、その時に培ったノウハウを、「採用」「技術者研修」「ラボ型コンサル」の3つの視点から、様々な形でご提供してまいります。