2人でやってみたアーキテクチャ・カタ

はじめに

みなさん、「アーキテクチャ・カタ」をご存知でしょうか？ アーキテクトとしての経験を積むためのアプローチです。 私はチームメンバーの方に教えていただき、この言葉を知りました。 本来「アーキテクチャ・カタ」は複数名で実施するものですが、どんなものか興味があったのでミニマムに2人で「アーキテクチャ・カタ」を実践してみることにしました。 この2人で実施する「アーキテクチャ・カタ」のことを「ミニ・アーキテクチャ・カタ」と命名してみます。 この記事ではその内容を振り返るとともにミニ・アーキテクチャ・カタを実施するならこんな感じにやってみては？というものをお伝えします。

また、アーキテクチャの非機能面のリスクを洗い出すための方法を整理するものとして「リスクストーミング」があります。 こちらも合わせて実施したのでご紹介します！

アーキテクチャ・カタとは

少人数(35人)グループを410チーム用意してそれぞれのグループでランダムに与えられた要件やコンテキスト（カタ）をもとにアーキテクチャを議論していくというものです。

本家様の記事はこちらになります。

http://fundamentalsofsoftwarearchitecture.com/katas/

また、日本語訳を記事にしてくださった方がいましたのでそちらも参照ください。

https://qiita.com/akihiro-iwata/items/67eb2dab528bd2b382f0

リスクストーミングとは

アーキテクチャ上のリスクを分析することであり、特定の側面におけるアーキテクチャのリスクを判断するための共同作業です。 一般的な側面（リスク領域）には、実証されていない技術、パフォーマンス、スケーラビリティ、可用性、データロス、単一障害点、セキュリティなどがあります。

さらに詳しい解説についてはソフトウェアアーキテクチャの基礎をご参照ください。

実際にやってみた

2人ということもあり、オリジナルが提唱しているものとは異なる方法で事前にルールなどは厳密に決めずとりあえず模索しながらやってみました。 1回30分合計4回実施しました。

Day1

Random Kataを利用してカタを選定します。 今回のカタはCheck Your Workが選ばれました。

カタ ある大学では、CSコースを大幅に拡張し、簡単なプログラミング課題の採点を自動化できるようにしたい。 ユーザーは 年間300人以上の学生、およびスタッフ、管理者。 要件 学生がソースコードをアップロードでき、それが実行されて採点されること。 評定と実行は、永続的で監査可能でなければならない。 他の提出物と比較したり、ウェブベースのサービス（TurnItIn）に提出することを含む、必要な剽窃検出システム。 大学の学習管理システム(LMS)との統合が必要。 教授が提出期限と時間を設定し、それを過ぎると提出が拒否される。 学生は、成績を上げるために何度でも提出することができる。 教授が評価基準を決定し、評価基準には指標やテストが含まれることがある。 その他の状況 大学のLMSはメインフレームベースであり、変更が非常に難しい。 成績は毎年、州の規制機関によって監査されている。 スポーツボールのために予備のスタジアムを建設しているため、大学にはITに関する予算がほとんどない。 同大学は、CS卒業生が全米で最も優秀な成績を収めたという記録を持っている。

こちらのカタからまずはアーキテクチャ特性と簡単な理由をブレスト的に出していきます。

  • 弾力性
    • 学生は締め切りのタイミングで一斉に提出してくると考えられるため。
    • 300人程度なのでそれほど問題にはならないかもしれない。
  • 低コスト
    • 予算がないため。
  • 長期保存性
    • 監査のために必要であるため。（永続的）
  • プライバシー
    • 学生の成績情報は秘匿にする必要があるため。
  • 可用性
    • 期限内は常に提出できるようにする必要があるため。

上記5つの特性候補として挙げました。 この中からアーキテクチャ特性として3つ以内に絞ります。 今回は以下の3つの特性を選定しました。

  • 低コスト
  • 長期保存性
  • 可用性

予算がない要件を最重要事項とし「低コスト」を選定しました。 次に監査システムの重要度が高いと考え「長期保存性」を選定しました。 最後にいつでも提出可能とし快適に課題に取り組んでもらうために「可用性」を選定しました。

Day2

アーキテクチャ特性が選定できたのでアーキテクチャを構築してみよう。。。と思いましたがあまりペンが進みませんでした。 なので、ユーザーとユースケースをブレスト形式で洗い出すことにしました。

ユーザー

  • 学生
  • 教授
  • スタッフ
  • 管理者

ユースケース(5W1Hで考える)

  • 教授がsemesterの最終月の上旬に講義の課題を出す
  • 教授が毎週小テストとして課題を出す
  • 教授が設定した課題を修正する
  • 学生が課題の回答を提出する
  • 学生が自分が提出した課題を確認できる
  • 学生が課題の回答を確認して、間違いに気づいて再提出する
  • 学生が課題の結果を確認する
  • 学生が課題の提出期限をカレンダーに登録する
  • 教授が学生の課題に剽窃があるかを確認し、あったものは不合格及びスタッフに報告する
  • 教授が学生の誰が誰の課題を剽窃したか確認できる
  • 教授が課題の締切を変更する
  • 教授が課題の結果を提出期限開始提出期限内提出締め切り後に確認する
  • 教授が課題の誤りに気づき、課題の内容を変更する
  • 教授が優れた回答を講義で紹介する
  • 監査人がいつでも監査ログを確認できる
  • 管理者が監査のためのデータを監査人に提出する
  • スタッフが教授に依頼されて、課題を設定する
  • スタッフが教授に依頼されて、課題を期限を変更する
  • スタッフが教授に依頼されて、課題の内容を修正する
  • 教授が特定のスタッフに課題の変更権限を付与する
  • 管理者が特定のスタッフに課題の変更権限を付与する
  • 教授が課題のテンプレートを作成する
  • 教授が課題をコピーして、内容を少し変更して作成する
  • 教授が課題を事前に作成しておき、期限になったら公開できるように設定する
  • スタッフが学生の入学時に利用できるように設定する
  • スタッフが学生の卒業・退学時に利用できるように設定する

Day3

アーキテクチャを構築するために、ユースケース・ドメインを広げすぎないように要件を踏まえてスコープを絞ります。

対象とするユーザー

  • 学生
  • 教授
  • 管理者

対象とするユースケース

  • 課題
    • 設定
      • 作成
      • 更新
      • 締め切り
    • 提出
    • 再提出
    • 採点
    • 剽窃
    • 参照
  • 監査
    • テストの実行
    • 評点
  • その他の前提
    • 成績はテストの点数で決まるものとする。
    • 剽窃の判定は過去の提出物と、同じ課題の生徒間の提出物から判断するものとする。

ランダムに選定されたカタから汲み取ることができなくて疑問に思ったことはこちらで条件を勝手に設定しました。

以上のユースケース・ドメインに絞りいよいよアーキテクチャの概要を描いていきます。 今回、アーキテクチャを構築する上ではGCPを使うこと前提で考えてみました。

ラフスケッチで今回は以下のようなアーキテクチャ構成としました。

低コストと可用性を鑑みてCloudFunctionを中心とした構成となっています。

picture1.jpg

Day4

前回作成したアーキテクチャラフスケッチをもとにアーキテクチャ図を清書します。

アーキテクチャ図はこちらになります。

picture2.png

そしてこれをもとにリスクストーミングを実施します。

リスクストーミングを実施する観点としては

  • 絞った3つのアーキテクチャ特性へのリスク
  • それ以外の重要だと思うアーキテクチャ特性へのリスク を考えました。

実施した結果はこちらになります。

picture3.png

それぞれ以下のようなリスク評価が洗い出せました。（リスク評価が大きい順）

  • Firebase：リスク6
    • 認証の元データがADとかだとIdentityPlatformの利用になりコストがかかるかも。
    • ユーザーのデータベース管理をどうするか次第。
  • CloudFunctions(テスト自動実行)：リスク4
    • テストなので無限ループやタイムアウトする可能性がありコストや可用性への影響がある。
    • 任意のコードが実行できるのでセキュリティの問題がありアプリケーションレイヤーで担保する必要がある。
  • CloudStorage：リスク4
    • 大きなオブジェクトが積み重なりコストが嵩む可能性がある。
    • 設計で適切にライフサイクルやクラスの設定をしないとコストが嵩む。
  • CloudSQL：リスク4
    • コネクションがたくさん貼られてしまい可用性を悪化させるリスクがある。コネクションがあると安全そう。
  • LMS：リスク3
    • LMS通信でのタイムアウトのリスクがあり完全性への影響がある。
  • CloudSQL：リスク2
    • 不要データを削除しないとコストがかかる。

リスクストーミングを実施し上記に挙げたリスクが洗い出せました。 今回はここで終了となりましたが、ネクストアクションとしてこの結果を元に軽減案について議論したり実装時のレビュー観点などに活用することができます。

次やるなら…

今回の実施を踏まえて次は以下の様なタイムボックスでミニ・アーキテクチャ・カタを実施をするのがよいと思っています。

  1. 要件を確認 (15 min)
  2. ユースケースを整理し、スコープを絞る (20 min)
  3. 必要なアーキテクチャ特性を列挙 (10 min)
  4. 必要なアーキテクチャ特性を3つに絞る (10 min)
  5. アーキテクチャをホワイトボードで整理 (25 min)
  6. アーキテクチャを見やすく整理 (事前準備)
  7. リスクストーミング (20 min)
  8. 完成！

おわりに

本来複数人でやる「アーキテクチャ・カタ」を2人で実施してみましたが、自分が持っている知見をもとに議論する経験ができて貴重な時間になりました。

私のような経験が浅いエンジニアにとってアーキテクチャ・カタはアーキテクトとなる上で必要なトレーニングであることは間違いないです。 ただ、私はまだまだ知見が浅くドライバーとして引っ張っていただける方が必要だと認識しました。 これまで業務で新規開発の中でアーキテクチャ選定に関わったことはありましたが、アーキテクチャ特性をしっかりと明記してそれを根拠・起点にアーキテクチャは組めていなかったように感じました。 誰かが良いと言っていたから、今まで使い慣れた技術だから、使ってみたい技術があるから etc…といった理由でアーキテクチャを選定するのではなく、しっかりとアーキテクチャ特性を考えて設計できるアーキテクトになりたいと意識できました。 適切なアーキテクチャを設計してユーザーにとって価値のあるものを提供したいです。

また、コミュニケーションのきっかけとしても他チームのエンジニアの方とやってみるのも面白そうです。

他にも、今回はGCPで考えてみましたがAWSやMicrosoftAzure、はたまたプラットフォームに依存しないような管理などほかの条件で考えてみるのも良さそうです。

使用したツール

  • Architeectural Katas
  • Notion
    • 議事録
    • メモが共有できればなんでも大丈夫です。
  • ホワイトボード
    • 雑多に構成図を書き出すには物理が便利です。
  • diagrams.net
    • （draw.io）
    • アーキテクチャ図清書用に利用します。
  • Jamboard
    • リスクストーミングの際にアーキテクチャ図に付箋をペタペタ貼るのに利用します。