アジャイル開発における設計の研究

はじめに
アジャイル開発の必要性
アジャイル開発における設計の手探り
おわりに
参考文献

こんにちは，Ridge-iの王です。

本記事では筆者の今までSEとして11年システムに関わる設計や開発の経験とRidge-iに入社半年の間、アジャイル開発の業務経験を通じて、アジャイル開発における設計の必要性、手法のノウハウ、設計の粒度や課題について、感じていたことを共有したいと思います。

はじめに

急ですが、みんなさん普段アジャイル開発を経験している内に、

下記のようなことを感じた事はありますでしょうか？

【否定】

・管理者や開発メンバーの考え方による、設計のプロセスを重視されず

・今までのやり方で特に大きな問題が起きてないからアジャイル開発で設計しなくてよい？

・設計資料を綺麗に整えなくとも、引継ぎに大きく影響を及ばさない

・設計のコスパが悪い、資料の整理とメンテナンス作業が面倒くさい

【肯定】

・プロジェクトごとに資料を標準化することの良さをメンバーと管理者に共有したい、

進捗管理や業務運用に役に立つはず

・設計自体はシステム開発の一部であり、時間を注ぐべきなのでは？

・設計の完成度がテストケースの充実さと繋がる

アジャイル開発の必要性

近年、一部大手企業にある多人数しか対応できない案件を除いて、

従来のウォーターフォールの開発手法より、アジャイル開発が段々主流になっている気がします。

特に中小企業で案件やクライアント予算の首を年々締めるような今の時代にとって、

DXやR&D事業の中、PoCが代表しリスクをコントロールしたい、ユーザビリティを最短にシステムの開発側にフィードバックする体制が必要とされています。

そのために、アプリやシステムを開発する手法の中、アジャイル開発が頻繫に用いられます。

一方、アジャイル開発に対する、

欧米と日本間のカルチャーギャップが存在することをここ最近実感しておりました。

(※欧米の国で直接仕事した経験がないですが、以前同じプロジェクトに属したヨーロッパの開発チームのメンバーと共同作業した経験と欧米出身の友人からの感想や英語の記事をベースに比較させて頂きます。)

アジャイル開発における12の原則

すべてのルールを一遍に討論しきれないため、今回は設計に関するルールを中心に、

欧米との認識齟齬とうか、ギャップを語りたいと思います。

欧米の観点👇

ドキュメントや仕様設計より、ソースコードが優先にきめられます。

日本👇

大企業にある一部技術研究の部署やベンチャーとをおいといて、クライアント側は属する従業員達は、基本的に管理マネジメント、営業向けや業界ごと実務の運用経験を重視する役割が多いのは一般的な認識です。

　　　では問おう：クライアント側の大半の従業員の方々はソースコードを読めますでしょうか？

　　　答えは否であります。となると、設計資料が自然に必要とされています。

納品の成果物

欧米の観点👇

動けるソースコードがあれば十分です。（+α：結果報告レポート.pptx 等）

日本👇（特に大企業）

Git HubのREADME.mdと結果報告書だけでは、資料として全然足りません。
ウォーターフォールほどとは言わない、少なくともアプリやシステムに関する機能説明、技術フレームワーク、モデル及びアルゴリズムの仕組み、DB並びに一連なデータのパイプラインを知りたいです。
エンドユーザに製品をプッシュするとき、ユーザマニュアルが必須、エンドユーザ側のチームで自ら保守できるようなドキュメント或いは知見が常に求められています。

設計の必要性をまとめ

上記の内容を踏まえ、日本のIT業界におけるアジャイル開発に設計がある程度必要とされることをご理解頂けるかと思います。観点を補完しまとめると下記となります。

小規模のプロジェクト（PoC等）がスタートのフェーズに対し、プロジェクト仕様或いはシステム業務を早くキャッチアップするため、ある程度まとまった資料があれば、新しく実装と検証したい機能を検討しやすい、且つお互いの認識齟齬を解消するには効率が良い。
ヒューマンスキルトランスファー、引継ぎ資料より、クオリティの良い設計資料が活用範囲が広く、汎用性も高い（他のプロジェクトの土台になる）。万一プロジェクトの要員が交替や休みとなったとき、プロジェクトの進行に妨げるリスクをある程度防ぐこともできる。
製品が納品された際に、或いは案件が長期のフェーズとなり、予算と契約を続けられた場合、自然に過去フェーズの仕様と設計資料がクライアント側に求められる可能性が高い。その場合、交替の要員が一から作った引継ぎ資料より、日頃まとまっていた内部設計資料をベースにブラッシュアップし、お客様の需要やフォーマットに合わせて資料を作成しやすい、技術や運用面ノウハウの漏れをカバーできる。

一方、アジャイル開発における設計のデメリットについて、本記事のスペースに限りがあるため、今回研究のテーマから割愛させて頂きます。

アジャイル開発における設計の手探り

アジャイル開発における設計のやり方

★FYI★

設計のやり方を述べる前に、アジャイル開発の主流手法から手法の選択によってプロジェクトの成功に関わることまで、ご興味が持っている方は下記の記事を目を通して頂ければと思います。

既に把握済みの方は下記セグメントの記述をスキップして頂いて構いません。

アジャイル型開発手法の適用領域とプロジェクトの成功．．．

オブジェクト指向開発と開発．．．

エンタープライズ領域のアジャイル開発の課題．．．

恐らくサーチエンジンで普通のクエリで検索してもアジャイル開発における汎用性高い設計方法は簡単に見つかりません。それも筆者が本記事をまとめる一つの理由であり、
もう一つは皆さんと議論してこの研究テーマを実運用に向け、方法論として固めて行きたい、
実際アジャイル開発に飛び込んだエンジニアに役に立てれば嬉しいです。

それでは、こちらで整理したノウハウを表します。

最低限設計すべき資料のカテゴリ👇

（※筆者の経験や考えていることに限りや過不足があり、ご指摘のほどを願います。）

スプリント（反復サイクル）開始の段階、最低限の設計資料を用意する
- 機能実装或いはテストがメインとなる場合、機能設計を用意すべき
- システム検証、DB構築やモデル訓練用のアノテーション処理等がメインとなる場合、
  DBの定義とデータを用意すべき
- アプリのGUI開発がメインとなる場合、画面レイアウト設計やモックアップ画面を用意すべき
スプリント中間の段階、内部の設計資料を用意する
- 結合検証がメインとなる場合、機能全体図、システムのIF定義やサーバ構成図を用意すべき
- お客様に向ける中間発表資料の準備として、開発フェーズに蓄積した資料をまとめ
スプリント後半の段階、外部の設計資料を用意する
- ファイナル報告となる場合、補足の資料も追加すべき
  （例：システムに使われる非機能要件、各試験の実施経緯並びに結果書）

設計のツール及び注意事項

【原則】

組織の成熟度(cmmi)に沿って、

プロジェクト人員の規模を顧慮し適切なツールを選択すればよいかと思います。

ITソリューション販売としてビジネス設計のツールやアジャイル開発を支える基盤のツール
（※ググるで検索すれば色んな種類がありますけど、
　一通り検証する時間がないためご紹介を割愛させて頂きます。）
筆者が体験したツールの中、フリーのオープンソースをベースに記述します。

Git Hub社のGitカンバンを用いてアジャイル開発の進捗状況を管理します。
GitHubに待望のカンバン機能．．．
Githubでカンバン機能を利用．．．
GitHubをフル活用してカンバン．．．
カンバンという管理サービスに関しては
monday、asana、miro社もに同類の機能を提供していますが、
お好きなツールやプラットホームを選んで頂ければかと思います。
ソースのバージョンやIssueの管理に関しては
bitbucket、Zenhub等のサービスもありますが、今Git Hubの一連のサービスがメジャーですので、興味がある方はご自身で試しておいてください。

Tipとして、GitのIssueを作成した際にlabelを自由に作成できる点を活用しましょう。
他にも、ドキュメントを設計する前準備として、Issueを立て、
設計の筋書き、打ち合わせのメモ書きをIssueのコンテンツに蓄積しずつ、
本格的に資料の設計を行う際に、Issueの内容が参照できるかと思われます。

仕様書を設計した際に（機能設計、詳細設計等）留意すべきのポイント👇
- 資料を作成するか否かの判断基準
  - 開発メンバーに伝えたいことが文字情報だけで理解してもらえそうかとのことです。
    チケットやIssueにメモしきれない複雑なロジックや画面イメージなどについて説明が必要な場合は、文章に落として仕様書を作成しましょう。
- 作成する書類カテゴリ及びおすすめのツール
  - 内部に向ける設計：Google - Document / Spreadsheet
  - 外部に向ける設計：MS365 - Excel / PowerPoint
- 理由
  - アジャイル開発の内部資料として、作成簡単、共有や編集しやすいのツールが求められます。
    そして、G-Driveのファイルサービスを使えば、
    基本的にフリー、メジャーに使われる、開発メンバーに共有しやすい、同時にオンライン編集可能等、幾つのメリットが考えられるので一応おすすめします。
    （勿論、Boxなどオンライン編集のソフトもありますけど、アジャイル開発の人員規模が大半限られるため、ここはメジャー以外のツールを割愛させて頂きます。）
  - 一方、お客様に提供する書類、いわゆる外部設計書を作成した際に、
    オンライン編集などの需要がなくなり、代わりに、しっかり仕様のフォーマットや図形のレイアウトを設計できるツールが求められます。性能の充実さだけではなく、
    クライアント側のネットワークに関するセキュリティポリシーの問題に関わった場合、有料のライセンスが必要ですけど、やはりMS365で作成したファイルが信憑性があり、現場によく使われることは筆者が長年体験していました。
- 補足
  - 上記に記載された内容はサンプルの説明であり、絶対ではありません。
    実際作成する資料の分類や機能による、使われるツールを自由に試してください。
    例えば、ER図を作成した際に、
    エクセルではなく、臨機応変に対応して頂ければと思います。
    - 内部資料：draw.io等
    - 外部資料：A5:SQL Mk-2等

ノウハウを共有した際に（Wiki）

Confluence
DevOps Wiki
その他OSSに提供されたWikの機能
開発ルールや何かのアクションを行う際の手順、作業を進めるうえでのTipsなどについては、Wikiに書き留めていくようにしています。管理者も開発メンバーも更新する場所が固定となり、情報を集約するうえではとても便利です。

おわりに

以上、筆者が考えている「アジャイル開発における設計の研究」について記載していました。
他の記事からも色々同様の観点を参考しましたが、重要なことは「アジャイル開発だから」という理由でドキュメントを書かないという思考停止に他ならない意識を喚起し、設計の重要さも伝えてアジャイル開発における設計のベストプラクティスを一緒に探りたいと思います。

ご清覧ありがとうございます。