UD Day 2 成果物の定義

1.概要
成果物の作成を重視しないアプローチがとりわけスタートアップのリソースが少ないプロジェクトにおいては一般的ですが、これに近い形として、我々は最小限の成果物を定義するというアプローチを採用しました。
尚、プロジェクトにおいて何を文書化し、何を文書化しないかはby Projectで異なるもので一律な定めはありません。PMPなどでもツールとして紹介されるものがありますが、どれを採用するかはあくまでもプロジェクトを推進する人の手に委ねられます。

2.要件定義フェーズの成果物

  • コンテキストダイアグラム:DFDのレベル0で、システムとシステム外部のデータのやり取りを表す。システム初見のメンバーに概要をシェアするのにも用いる事ができる
コンテキストダイアグラム
  • ユースケースモデル:アクター(ユーザー)が行うアクション(ユースケース)を定義する。ハイレベル・ユースケース図は、ユースケースのトップレベル。
ユースケースモデル
  • マネージメント計画書:プロジェクトを管理する際の方針や方法について記載する。
    1. プロジェクトチームの体制
    2. 変更管理をどのように行うか
    3. どういうコミュニケーションの種類(頻度等)があるか
    4. リスク管理、タスク管理はどのように行うか
    5. スケジュール管理をどのように行うか、どういったツールを利用するか
    6. ファイナンス管理の方法(何が管理されるべきでどのくらいの頻度で集計・確認を行うか)
    7. リリース管理及び方法
    8. 成果物管理(バージョン管理ツール等を含む)
    9. プロジェクト参画メンバーが共通して持つべき価値観や採用基準
  • アーキテクチャー選定結果:採用する言語、フレームワーク、HW及びSW、設計・開発において使用するツール群とそれらを採用する理由と採用した場合のコストについて記載する。独立させずに、オペレーショナルモデル内で分かるように記載すればそれで良いかもしれない。
  • ロバストネスモデル:バウンダリ(画面)、コントロール(アクション)、エンティティ(モデル)からなる設計。MVCモデルで作成する場合に必要となるもの、それらの相互作用を定義する。
ロバストネスモデル
  • UIプロトタイプ:画面の構成および遷移について記載する。
UIプロトタイプ
  • UIの設計標準:画面の種類と各レイアウト、フォント・色彩、アイコン、ボタン・ラジオボタン・リンク等のコントロール部品、メッセージ等について本サービスにおいて採用する仕様をまとめる。UIプロトタイプと一緒の成果物としてまとめる事を検討しても良い。
  • 機能外要件:運用要件、キャパシティ要件、性能要件、障害対策要件、セキュリティ要件について記載する。
    1. バックアップの対象・方法・頻度
    2. 3〜5年程度でどの程度のキャパシティまでを保存し得るか
    3. ノード当たり同時何ユーザーの接続を想定するか
    4. 拡張方針(どうなったらノード追加するか、どう追加するか)
    5. リリースの方法、それに利用するツール(デプロイツール), Continuous Integration系のツール等
    6. サービスレベル、計画停止時間帯の設定
    7. 障害の検知、通知方法・ネットワークセキュリティ(AWSのNWセキュリティやAMI(ユーザー権限))、暗号化、データの暗号保存(特にカードデータ等)の検討
  • オペレーショナルモデル:必要となるノードと各ノードにおける要件を論理(概念上必要となる単位でのまとめ)と物理(実際の配置のされ方)の2つの観点でまとめる。利用するSWの一覧などはここに含めても良いであろうから、アーキテクチャー選定結果との統合を考えても良い。論理的なサービスグループとそれぞれの中に含むサービス、その要件(セキュリティや信頼性、パキ要件)を記載している例もある。想定するイメージは、必要となるCloudのノードの定義、各ノードで動かすサービス(Dockerのコンテナやその中のプロセス)。単純なウェブサービスであれば、簡単なもので良さそうではないか。
オペレーショナルモデルの例(実際に採用した構成案ではありません)
  • テクニカルプロトタイピング実施結果:プロジェクト全体の成否に関わるような技術的な懸念事項がある場合に、先行して、このタスクを実施し、実現可能(もしくは代替案がある)ことを示す。
  • ドメインモデル:自然言語レベルにおけるクラス図。システムに関わる実体とそれらの関係性を示す概念図。テーブル定義のインプットになりえるもの。プロジェクト初期について、システム化対象に必要となりそうなモノについて共通理解を得るのに使える。テーブル定義において、問題となりえそうな箇所があれば、振り返って作成する形でも良いと考え、作成しないと判断。
ドメインモデルの例
  • 外部インターフェイス:外部連携がある場合のインターフェースの概要。
  • データディクショナリー:データ項目の名称とその内容を定義した設計書。定義が曖昧となり得るところが発生すれば、その時点で作成することとした。

2.設計

  • データベース仕様:テーブル定義、インデックス一覧、ER図を作成する。テーブル定義は、テーブル名と各テーブルにおける定義(カラム名、カラムサイズ、データの種類、その他)を記載する。各テーブルにおけるインデックスについては、別途インデックス一覧としてまとめるか、もしくは、各テーブル内で一律のルールにより合わせて記述できればそれでも良い。ER図は、特段の要件が無い限り作成しない。
  • ユーザー・インターフェイス仕様書:実際のGUIのデザインを作成する。Fireworks, Photoshop, GIMP等のツールによるレイアウト作成を想定する。外部のデザイナーへのデザイン依頼をしても良いが、その際には、選定方法を十分に検討する。その他の仕様部分については、UI設計標準の詳細化を必要に応じて行う(同じ成果物にて管理を想定する)。(画面タイプ以上に細かい単位での画面の詳細設計はメンテナンス性を考慮して行わない)。最近の例としては、SketchなどのUIのプロトタイプツールを使う考えもある。
  • コンポーネント・モデル:ソフトウェア、ソースコード、ライブラリーモジュール等をコンポーネントとして捉えて、それぞれの関係性(どのファイルでは何を使用するか)を明示する。初期のスナップショットとして作成し、メンテナンスはせず、以降はファイルの一覧にて確認する。
  • クラス図:クラス間の関係性を示す設計図
クラス図の例
  • 運用障害対策仕様:要件定義フェーズの機能外要件の内容についての詳細を設計する。・必要な運用と方法・考えうる障害の種類と対応方針(想定)
  • オペレーショナルモデル:要件定義フェーズのオペレーショナルモデルの内容についての詳細を設計する。配置モデルはここに含めるものとする。
  • CTP(Comprehensive Test Plan):テスト方針書(全体テスト計画)。主として、以下の項目について記載する。記載に際しては、各局面で作成した成果物の内容が必要十分に盛り込まれていることを確認する必要がある(網羅性)。(ST:要件定義、IT:外部設計、UT:コーディング)
    1. テストの種類と実施方法
    2. テストの目的と範囲
    3. テスト対象環境
    4. テスト判定項目
  • 業務運用設計書:必要となる業務の種類とその業務を運用する方法を記載する。ユーザーサポート、クレーム・問合せ対応…etc等を想定する。
  • ファイル設計:クライアントサイドで利用するファイルが有る場合、そのフォーマットを記載する
  • 帳票設計:帳票類があれば、そのフォーマットを記載する
  • シーケンス図:あるアクションについて、各オブジェクト(及びその関数)がどのような順で呼ばれて、実行されてるかを示した図。実行順の制御が必要であれば、作成する。
シーケンス図の例
  • パッケージ図:パッケージ間の依存関係を示したもの
  • 配置モデル:システムの実際の配置(ノード、ノード内のソフトウェア等)を記載するが、オペレーショナル・モデルと重複するので、オペレーショナル・モデルにて含めても良いか。意味することが同じなので、オペレーショナルモデルで考えることとする。
  • リリース計画:段階的なリリースとなる場合には、それを記載する。リリース方法やツールについての詳細な設計が要件定義フェーズの記載以上に必要であれば、行う。

以降、実装フェーズでは、主に実際のコードや構成ファイルを作成し、また、テスト(UT/ITa, ITb, インフラテスト)については、各テストにおけるテストケースを作成しています(ここでは割愛します)。

このようにして、最初に作るべき成果物を絞ってから、進めました。
結果的に作りすぎた感がこれでもあるので、振り返りとしてドキュメントは最小限にすべきだろうと考えています(元々そのつもりだったのですが)。もっとミニマムが理想かもしれません。保守的な考えになるほど、後々のことを考えて、文書化してしまいますが、文書化すること自体が目的ではないので、やはり、成果を出すためにやるべき内容に絞って進めるべきだろうと考えるようになりました。

UD Day 1 問題と解決策(仮説)

0.はじめに
2019年の3月頃にコメントできるブラウザUDをリリースしました。ダウンロード数が芳しくないのが残念ですが、このシステムの設計や用いた技術・アルゴリズム等の詳細について、どなたかの参考になればと思い、書き起こすことにいたしました。
Dayいくつまで行くか分かりませんが、全体のシステムを網羅しようと思うとなかなかの量になると思います。

Apple Storeのリンク)
https://apps.apple.com/us/app/ud/id1454147581

尚、箸にも棒にもかからなかった場合、コードについてもすべてオープンにしようと思います。

1.概観
UDは、モバイルのブラウザとAPIシステムから構成されています。ブラウジング(ウェブサイトの閲覧)の度にAPIシステムに対するトランザクションがバックエンドで発生するため、多数のユーザーによる利用を考えた場合、超スケーラブルである必要があり、それ故にハイパフォーマンスである必要があります。
超スケーラブルであるためには、いくつか検討すべき項目があります。例えば、DBサーバーです。旧来のRDBはRead-Onlyのレプリケーションされたノードを持つことにより分散性を高めていますが、Writeするノードのパフォーマンス・キャパシティ上の限界値がWriteの制限になります。つまり、WriteもReadも分散するには、これでは満たしません(ただし、最新の情報としては、RDBでも上記要件をみたすものはありそうです。ですが、これにはコストの壁があります。全てはコストとのバランスに尽きます)。
このようにウェブシステムに一般的に見られる典型的な構成では難しく、今回超スケーラブルなシステムを作りました。と言っても世の中にあるプロダクト群を使ったものです。
この一連の連載により、以下の分野について、参考になると思います(順不同、参照する内容の一部)。ご意見もあれば、忌憚なくいただければと存じます。

・スケーラブルなシステムのアーキテクチャー
・複数リージョン(GCP)において分散するシステム
・Cassandara/ScyllaDB
・Ansibleによる自動構築
・gin-gonicによるウェブシステム
・iOS〜APIサーバー間のHandshake

2.問題と解決策

冒頭が長くなりましたが、Day 1の本旨は、なぜこれを作ったか、です。我々は、以下の問題と解決策を仮定しました。解決策を実装したものがUDです。

  • 問題:ブログやSNSの登場とともに情報発信が簡単になった一方で、ウェブの世界には、断片的だったり、偏りのある、使えない情報が多い(通常一つのページは、とある人や組織の視点で、一つの方向性(主観)に沿って書かれることが多いため)
  • 解決策:ページが一側面を照らしているものと仮定して、別の側面が何かを併せて知ることで、はじめて、知りたいことの全体像を知ることができる(別の側面とは、例えば、異なる意見、補足的な情報、もしくは指摘などのフィードバック。)
  • 解決策の詳細:これらの情報をコンテンツに紐づく形で提供する、つまり、閲覧中のページに対して、別側面の情報(ページ作成者以外のユーザーのコメント)をする仕組みがあれば良い。

もう少し詳細に書くと、ページのURLに対して、ユーザーのコメントを紐付かせて保存し、それをウェブページの一つ上のレイヤーで位置に応じて表現する方法が良いと考えました。
それを試しに実装してみたのがモバイルブラウザのUDです。

次回以降で、このシステムをリリースするまでに行った要件定義、設計、実装の主要なトピックについて順次公開していく予定です。(続く)