MENU

03-6222-9506

受付時間 平日 : 9:00〜18:00(日本語対応)

Contactお問い合わせ
   

ホーム

     

ブログ

アジャイル開発に設計書は必要?バックログとの役割の違いも解説

   

アジャイル開発に設計書は必要?バックログとの役割の違いも解説

サムネイル画像

アジャイル開発とは

アジャイル開発とは、システムやソフトウェア開発における手法のひとつです。従来のウォーターフォール開発はあらかじめ全工程にわたる計画を立ててからそれを実行する、というプロセスでした。それに対しアジャイル開発は、途中で生じる状況の変化へ適宜対応しながら開発を進めていくという手法です。

”素早い”、”機敏な” という意味がある 「アジャイル(agile)」は、頭の回転が速いというニュアンスも含まれています。「計画・設計・実装・テスト」といった工程を機能単位の小さなサイクルで繰り返すことができるアジャイル開発は、まさに開発〜サービスインまでを素早く実行できる手法です。

アジャイル開発については、こちらの記事でより詳細にご紹介していますのであわせてご覧ください。

「アジャイル開発とは?」

 

アジャイル開発に設計書は必要?

アジャイル開発において、設計書などのドキュメントは不要と考えられる傾向にあります。効率とスピード感を重視し、個人間で対話をしながら開発を進めていく場合が多いからです。

また、アジャイル開発という概念が生まれるきっかけとなった「アジャイルソフトウェア開発宣言」では、「包括的なドキュメントよりも動くソフトウェアを価値とする」という一文があります。この内容も相まって、「アジャイル開発=設計書(ドキュメント)は不要」という認識が強くなっています。

ただし設計書をまったく用意せず、口頭でのやりとりだけで開発を進めていけばチーム内で要件に関する認識の齟齬が生じる恐れがあります。言った・言わないによる混乱で開発が滞れば、アジャイル開発の大きなメリットである「スピード感」や「効率性」を損ないかねません。

アジャイル開発における設計書作成には、メリットとデメリットのどちらも存在します。それらを理解したうえで、チームにとって適した対策を取ることが大切です。

設計書を作成するメリット

アジャイル開発で設計書を作成することのメリットとしては、以下の3つを挙げることができます。

・要件に関する認識齟齬の防止
・開発遅延の防止
・運用の負担を軽減

先述の通り、設計書がまったく用意されていない中で開発を進めていくと要件に関する認識の齟齬が生じるリスクは高まります。そうなると、実装までのスピード感が失われ、アジャイル開発を採用する意味もなくなってしまいます。

また、何らかの事情があり別チームや新たなメンバーへの引継ぎが必要となった際、資料がなければ十分な引継ぎを行うことは困難です。開発者が運用をしない場合、または将来的に引継ぎの可能性が考えられる場合も設計書は作成するべきと言えます。

設計書を作成するデメリット

アジャイル開発においても設計書が役立つとはいえ、以下のようなデメリットも潜んでいるため注意しましょう。

・設計書の作成に時間がかかる
・柔軟に内容を変更することが難しい

設計書を作成するにあたり、多少なりとも時間を割く必要があるため実装までのスピード感が失われることになります。

また、短いスパンで改変を繰り返す前提にあるシステムは、設計書を作成してもリリースの度に内容が古くなってしまいます。

上記のデメリット、そして先ほど挙げたメリットを踏まえて考えると、設計書を作成してもしなくてもスピード感が失われる懸念は拭いきれません。では、どのように対応すればチーム内におけるコミュニケーションの円滑性と開発のスピード感を両立できるのでしょうか。

 

設計書とスピード感を両立させるポイント

アジャイル開発のスピード感、そして設計書のような「認識齟齬対策」を両立するには、以下のポイントを押さえることが大切です。

テキストファイルにラフな設計書を記す

APIのIF仕様書やDBテーブル設計書のように、しっかりとしたフォーマットをもとに設計書の内容を詰めても良いでしょう。しかしこれでは時間がかかるうえにハードルも高く感じやすいため、テキストファイルにラフな設計書を書き記す程度から始めてみることをおすすめします。

「設計書は詳細な内容を整えながら作るもの…」という意識は一度手放し、開発者間で作業内容をすり合わせる際のたたき台として使うメモといった感覚で作ってみましょう。それだけでも、開発のイメージを具体的にするための手助けになります。

チケット管理ツールを使う

「Redmine」や「Backlog」などのチケット管理ツールは、アジャイル開発におけるプロダクトバックログの管理に役立ちます。チケット管理ツールにてタスク単位で完了条件を記載しておけば、認識の齟齬を防ぐ対策として効果を発揮します。

しっかりと内容を詰めた設計書を作成するとなると、相応に時間がかかるものです。しかしチケット管理ツールで「メモ程度」にタスクを設定する形であれば、開発者の間で会話しながら記載できるため少ない時間でまとまります。

なお、ツールは好きなものを選んでも問題ありません。ただし「Google スプレッドシート」は導入しやすいものの、短いスパンで内容を更新する必要がある場合にはおすすめできません。更新の際に通知する機能がないため、誰かが行った追加・変更・削除などの編集を見落とす可能性があるからです。

タスクを細分化して設定する

ラフな設計書作成やチケット管理ツールの利用を試しても効果が望めなかったり、継続が難しい場合は必要な作業を細かく区切ってリストにしてみても良いでしょう。

設計書ほど内容の詰まったドキュメントは残りませんが、作業の工程をタスク名として一言でまとめておくだけでも何をすれば良いのかすぐに把握できます。ただしタスクをまとめる際、ひとつのタスク名に対して複数の作業工程を詰め込むと混乱しやすくなるため注意しましょう。

「設計書」と「プロダクトバックログ」を使い分ける

チケット管理ツールなどを用いたタスク管理は、どちらかというと「プロダクトバックログ」に分類される手段です。これだけでも開発をスムーズに進めるための効果はある程度期待できますが、設計書とはまた違う役割があり、プロダクトバックログだけではカバーしきれないケースも存在します。そのため、両者の役割を理解したうえで使い分けることが作業の効率性を上げるポイントです。

設計書とプロダクトバックログのどちらも作成すると、更新時に伴うスピード感の低下が危惧されるものです。しかし内容を変更する際、リアルタイムに更新をするのはプロダクトバックログだけで問題ありません。設計書は「長期的な保守をしやすくする」というのが主な役割なので、ある程度の仕様が固まってから反映するなど更新のタイミングを工夫するとスピード感も損なわれません。

デザインツールを使う

ブラウザ上で簡単にデザインできる「Figma」や、Webサイトやモバイルアプリ等のデザインに使用できる「Adobe XD」を利用することもおすすめです。ツールを使いワークフローを作成したり、プロトタイプを作成しながら進める方法も効果的です。

 

プロダクトバックログの限界とは

プロダクトバックログは設計書よりも作成に時間がかからず、チケット管理ツールなどを上手に利用すれば更新状況もリアルタイムで把握できるという点がメリットです。しかしプロダクトバックログを用意するだけでは、将来的な運用をスムーズにするための準備が万全であるとは言えません。

プロダクトバックログでは1つのプロダクトをチケットに起票し、必要に応じてチーム内でQ&Aやディスカッションを行うことで決定した事項を概要欄に反映します。アジャイル開発は開始時点で詳細な仕様が固まっていないことが多いため、様々な関係者がプロダクト使用の設定に携わることができます。また、開発が完了したプロダクトバックログはクローズとなり内容に変更がない限りオープンされないため、開発者が現在集中するべきプロダクトも分かりやすくなるというメリットがあります。

このことから、プロダクトバックログとは開発者が作業スケジュールを立てやすくなるタスク管理法としての効果を発揮するものと言えます。

一方で、プロダクトバックログでは正しい仕様を確認したくても分かりにくいという点がデメリットです。例えば、プロダクトバックログ上で以下のような記録が残っているとします。

①a1・a2・a3という機能を含む画面Aを開発する
②「チケット1」で画面Aについての要件を起票
③開発が完了したので「チケット1」をクローズに
④画面Aの機能a1とa2を仕様変更をする
⑤「チケット2」で④の要件を起票
⑥仕様変更が完了したので「チケット2」をクローズに
⑦画面Aの機能a2を仕様変更する
⑧「チケット3」で⑦の要件を起票
⑨仕様変更が完了したので「チケット3」をクローズに

このような変更を経てから改めて画面Aの正しい仕様について確認をする場合、クローズ済みのチケット3つをシステム上から見つけ出すだけでなく、時系列に合わせて組み立てる必要があります。

その際チケット管理ツールから検索すれば該当のチケットを探し当てることができますが、検索が漏れていたり組み合わせ方を間違えると、誤った仕様を正しいものとして認識してしまいます。誤った認識を前提に新しい仕様変更を検討することになれば、より深刻な被害が及ぶリスクが高まることでしょう。

プロダクトを長期的に運用するのであれば、開発の当事者ではないメンバーが参入する可能性も十分にあります。新しいメンバーへの引継ぎをスムーズに行うためにも、正しい仕様が分かりやすく記されてある設計書は必要です。

プロダクトバックログと設計書の役割の違い

プロダクトバックログは、開発に関する作業のタスク管理をしやすくするという役割があります。すでに完了したタスクはクローズされるため、このプロダクトに関して今やるべきことはあるのか?何をやるべきなのか?が分かりやすく効率的な作業を実現できる点がメリットです。

プロダクトの開始当時から開発・運用に関わり、プロダクトの動きや正しい仕様について理解しているメンバーであればプロダクトバックログだけでも支障なく保守を続けることができるでしょう。しかし先述の通り、プロダクトが現在の形に至るまでの経緯や正しい仕様を知らないメンバーが参入する場合もあります。その際にスムーズな引継ぎを助けてくれる存在が、正しい仕様を具体的に書き記した設計書です。

プロダクトバックログと設計書の役割をまとめると、以下のような違いが見えてきます。

プロダクトバックログ 設計書
・特定のプロダクトにおける要件をスピーディーに伝えられる(タスク管理がしやすい)
・コメント機能で様々な関係者と一緒に仕様を策定できる
・正しい仕様の確認が必要な場面は不向き
・正しい仕様を理解するための資料に役立つ
・作成に時間がかかるためアジャイル開発においてはスピード感を損なう恐れがある

 

両者には向き・不向きがあることが上記にてお分かりいただけたでしょうか。どちらも作成するとなれば相応の時間やモチベーションが必要ですが、設計書に関しては一度作成すればプロダクトの長期的な保守が楽になります。

アジャイル開発は最小限の体制からスタートし、リリース後の機能に対する市場からのフィードバックをもとに長期的な改善を重ねるというやり方が一般的です。だからこそプロダクトバックログで上手に計画・タスク管理を行いながら、設計書の正しい仕様に基づいた長期的な保守が重要になります。

 

ハイブリッドテクノロジーズの提供サービス

ハイブリッドテクノロジーズは、高い品質管理のもと、アプリケーション開発、システム開発の設計、デザインなどの上流工程から開発、運用、保守に至る全ての工程をトータルでご提供することで、クライアント企業のデジタルトランスフォーメーション(DX)推進をサポートいたします。

お客様の要望に合わせて、アジャイル開発やウォーターフォール開発等の開発手法やラボ(ストック)型サービスや受託(フロー)型サービスを柔軟に組み合わせて対応させていただきます。

【アジャイル開発ご希望のお客様】
・アジャイル開発についてはこちら

【ウォーターフォール開発ご希望のお客様】
・ウォーターフォール開発についてはこちら

【ラボ(ストック)型開発サービスご希望のお客様】
・ラボ(ストック)型開発サービスについてはこちら

【受託(フロー)型開発サービスご希望のお客様】
・受託(フロー)型開発サービスについてはこちら

ハイブリッドテクノロジーズが選ばれる理由

01 ビジネス設計〜実装・保守までワンストップで提供できるサービス体制
既存サービスの変革や新規サービスを成功を導くための顧客体験発想による設計からプロジェクトをスタートし、MVP開発を通して顧客のビジネスグロースを一緒に共創していくサービスを提供します。

02 UCS(ユーザー中心設計)によるUI/UXデザイン
実際にそのサービスを使うユーザーを調査、分析しながら、人間中心設計を元にデザインを行なっていきます。

03 スピード感をもった開発体制の構築
要件定義で定めた機能の中から優先度の高い重要なものから、アジャイル・スクラム開発を用いて開発することでサービスインまでの期間を短縮。素早いリリースを実現し、機能の追加などのブラッシュアップを行います。
ベトナムにおける日系No1*1という知名度の高さと20,000人以上*2の候補者リスト*2を元に必要な人員リソースの確保が可能なため、スピード感をもった開発の実行が可能です。

04 累計290社の顧客のプロダクト開発実績
当社が創業以来、豊富なシステム開発・アプリ制作の実績があり、それらを通じて蓄積した知見やノウハウを持ち合わせています。企画段階から要件定義・デザイン・開発まで担当し、プロジェクトを成功に導きます。

05 低コストかつ自由度の高い開発
フルスクラッチ開発とパッケージ開発のいいところどりを実現。 フルスクラッチ開発だとコストが上がる傾向にありますが、当社はベトナムのリソースを活用することでコストを抑えられます。
また、パッケージ開発だと自由度が失われる傾向がありますが、当社はスクラッチ開発で顧客予算に合わせて、スコープを見定めながら、進めることができるので、低コストで自由度の高い開発が実現できます。

06 国際標準規格に則った品質管理体制
情報セキュリティマネジメントシステムの国際規格「ISO9001」、「ISMS(ISO/IEC270001)」、ソフトウェア・テストの国際規「ISTQB Platinum Partner」の認証を取得しており、国際標準規格に則った品質管理体制を提供しています。

  1. 株式会社マイナビが運営するベトナムITエンジニア専門の求人サイトITviecは、給与・教育・マネージメント・企業文化・オフィス環境の観点から、Best Companyを選定。Hbrid technologies Vietnam Co., Ltdは、2019年と2020年に、日系企業で最高位に選出されました。
  2. 過去の当社へ応募頂いた開発候補者のリストです。応募のタイミングでリクルートシステムに登録し、常にそのリストから候補者へのリサーチできる体制を持っています。

 

まとめ

アジャイル開発とは、あらかじめ具体的な計画を立ててから開発を行う従来の手法とは異なり、途中で生じる様々な変化へ臨機応変に対応していくという手法です。だからといって手ぶらの状態でスタートしても良いという訳ではなく、長期的な保守を見据えて設計書を作成し、正しい仕様について記しておく必要があります。また、チケット管理ツールを利用すれば関係者を交えた仕様の策定やタスク管理もスムーズに行えることでしょう。

  • この記事を書いた人
  • この記事の監修者
執筆者画像

窪田 陽介

はじめまして!ハイブリッドテクノロジーズの窪田です。 当社は、次世代テクノロジー開発で世界をリードするベトナム人エンジニア700名(日系企業最大規模)を有し、ビジネスデザインを日本国内で、開発をベトナムで行う「ハイブリッド型開発」により、EC、モバイルアプリケーション、HRシステム、ポータルサイトなど長期運用が必要とされるサービス提供を行う企業のシステム設計、開発、運用業務に加え、デジタルトランスフォーメーション(DX)推進によるお客様の事業成功をコミットしています。

監修者画像

窪田 陽介

はじめまして!ハイブリッドテクノロジーズの窪田です。 当社は、次世代テクノロジー開発で世界をリードするベトナム人エンジニア700名(日系企業最大規模)を有し、ビジネスデザインを日本国内で、開発をベトナムで行う「ハイブリッド型開発」により、EC、モバイルアプリケーション、HRシステム、ポータルサイトなど長期運用が必要とされるサービス提供を行う企業のシステム設計、開発、運用業務に加え、デジタルトランスフォーメーション(DX)推進によるお客様の事業成功をコミットしています。

Download

ダウンロード

ダウンロードバナー画像

この資料をダウンロード

ご相談、資料請求はお気軽にお問合せください。

   Contactお問い合わせ