ブライトコーブは継続的な改善を信条としています。それは、私たち自身やソフトウェアだけでなく、私たちのプロセスにも当てはまります。最近、私たちのグループが集まり、アーキテクチャ レビュー プロセスがどのように機能しているかについて話し合い、それを一新することに決めました。私たちは、次のようなアーキテクチャ レビュー プロセスを望んでいます：
- 反復的
- 快適
- さまざまなタイプのプロジェクトに適応可能
- 参加者の専門性を尊重する
その結果、私たちの最新のプロセスを記した以下の文書が完成した。
建築とは何か？
ソフトウェア・アーキテクチャとは、一度実装されると変更するのにコストのかかる基本的な構造的選択をすることである（出典）。
どのようなプロセスですか？
ソフトウェアの設計は継続的なプロセスである。完璧な意思決定をするために必要なことをすべて前もって知ることができるのであれば、アジャイルは必要ないだろう。これを反映するために、私たちのアーキテクチャ・レビュー・プロセスには、プロジェクトごとのニーズに適応できるいくつかのステップがある。
これらのステップをすべて実行する必要はないかもしれない。ステップを繰り返すことが有用な場合もある。一般的に、レビューと回顧は最低限と考えるべきである。以下の目標を達成するために、最も意味のあることは何でも行う：
- 可能な限り最善のソフトウェアアーキテクチャを決定する
- 有用なエンジニアリング・ドキュメントの作成
- 途中で学び、学んだことを計画に反映させる
- 決めたことや学んだことを仲間に知らせる
以下のセクションでは、そのプロセスの各ステップについて説明する。
建築ワークショップ
もしかしたら、新しいプロジェクトを計画しているかもしれない。まだ完全に定義されていない課題があるかもしれない。ある課題に対して3つの異なる視点があり、どれを選んだらいいかわからない。アーキテクチャー変更のアイデアがあり、それを問題提起につなげたいと考えているかもしれない。このような疑問に対して、サイロの中に閉じこもって答えを出そうとするのではなく、早い段階で他の専門家と話を始めるのが良い。そうすることで、計画が固まりすぎる前にフィードバックを取り入れたり、大きな変更を検討したりしやすくなる。また、アーキテクチャの準備がより整うため、アーキテクチャレビューをスムーズに進めることができる。
チェックリスト
- 対象分野の専門家（影響を受けるチームのリーダーなど）を招待する。
- 建築レビューのSlackチャンネルに招待する
- 3～8名の出席を推奨
提案
- まず、背景を十分に説明し、解決すべき問題を説明することから始める。既存の知識を持たない人を招くことで、問題提起に磨きをかけ、仮定に挑戦することができる。
- 建築ワークショップは推測の域を出ない。もしかしたら、そのアイデアが前に進まないかもしれないし、代わりにハックウィークのプロジェクトになるかもしれない。問題はない！私たちが直面している課題について、何人かの専門家が議論し、より深く学ぶことができたのであれば、それは勝利だ。
- 未知の部分が多すぎて前に進めない場合は、いくつかの研究活動を検討し、それから再挑戦する。プロトタイプ、リサーチスパイク、読書は、このフェーズで役立つツールである。
- 専門家以外も招待しましょう。建築設計の経験を積んでもらう良い機会です。良い建築をデザインする方法を学ぶには、自分でやってみて何度か失敗するか、他の人がやっているのを見るのが一番だ。
建築評
建築レビューとは、あなたの建築を多くの聴衆にプレゼンテーションすることです。ここでは、できるだけ多くの参加者を求めます。追加的なフィードバックを求めると同時に、聴衆にあなたのプロジェクトについて知ってもらうのです。これは、できれば開発が始まる前に行うべきです。
チェックリスト
- メインのエンジニアリングSlackチャンネルに招待する
- ミーティングが始まる直前に #エンジニアリング にリマインドする
- アーキテクチャレビューの前にエンジニアリングドキュメントを作成し、事前に参加者と共有する。
- ミーティングでは、文書を見ながら詳しく説明し、質問や意見を求める。
提案
- コンテキストを完全に提供し、解決すべき問題を説明することから始めます。聴衆には、おそらくブライトコーブを初めて利用する人や、あなたの技術領域に関するコンテキストを知らない人が含まれます。すでにご存じのように...」と言うのは、初対面の人を遠ざけ、参加を減らす可能性があるので避けてください。
- その場限りの文書ではなく、今後も更新されるエンジニアリング文書を作成する。プロジェクトの終わりには、実際に何が作られたかを示す最新のドキュメントがあることが理想的です。このドキュメントは、参照用、ステークホルダーとの共有用、新しいチームメンバーのレベルアップ用などに使うことができる。
- 文書には視覚的な要素を取り入れましょう。図表やホワイトボードの写真は、読者があなたのアイデアを効率的に理解するのに役立ちます。
- フィードバック・サイクルというよりも、防御であると感じる可能性がある。守勢に回っていると感じたら、今すぐすべての答えを持っている必要はないことを思い出してほしい。"その件に関してはありがとうございます。
- 誰かの言うことをすべて実行することは期待されていない。意見の相違は構わない。何かを見過ごすことは、それほど素晴らしいことではない。人々が互いに学び合うことで、最良のアイデアに引き寄せられる。
ドキュメント
ここでは、文書に含めるべき内容をいくつか提案します。これらすべてがすべてのプロジェクトに関連するわけではありません。
- システムの相互作用
- インターフェイス
- ドメイン・モデリング
- 配備計画
- 使用技術
- ホストはどこに住むのか
- モニタリング計画
- COG
- 請求
- ユーザー・エクスペリエンス
- メンテナンス性
- 妥協を受け入れる（技術的負債など）
- セキュリティ
- 虐待の可能性のあるパターン
- 安全なコーディングの実践
- 認証／認可
- 監査/ロギング
参加者ガイドライン
- 大人数で新しいアイデアをプレゼンするのは、かなりのストレスになります。どうか、彼らが良い経験をできるように助けてあげてください！
- こうしなければプロジェクトは失敗する」など、利害関係を高めて自分のアイデアを主張するのは避ける。見落とされていると思われる具体的な影響を説明することに集中する。
- "Why don't you just... "という言い方は避ける。これは、発表者が明らかな見落としを犯していることを示唆している。これは通常、考え方の問題なので、好奇心と探究心の観点からアプローチすることで、より建設的な会話につながる。
- もし、何かうまくいかないような気がするけれど、その理由がはっきりしないのであれば、それを持ち出す前にもう少し考えたほうがいいかもしれない。例えば、"私たちが考えていないこの道具を使うことに問題があると直感したので、後でもう一度検討したい"。
建築アップデート
長期にわたるプロジェクトでは、定期的に集まってプロジェクトの進捗状況について話し合うことが有効である。これは、これまでの経過を振り返り、更新されたアーキテクチャーを見直し、学んだことに応じて計画を変更する機会として機能する。
チェックリスト
- プロジェクト関係者全員を招待する
- 建築レビューのSlackチャンネルに招待する
- レビューで作成したエンジニアリング・ドキュメントを更新し、ソフトウェアの最新状態を反映させる。
- 会議の前に、振り返りのメモを募集する。何がうまくいっているのか、何がうまくいっていないのか、提案されたアクションを書き込む場所を提供する。
- ミーティングでは、更新されたエンジニアリング・ドキュメントを説明し、変更点に注意を促し、質問やフィードバックを求める。
- ミーティングでは、全員にレトロノートを読んでもらい、ディスカッションを促す。
提案
- 長期にわたるプロジェクトの場合、少なくとも四半期に一度はこの作業を行うのが賢明かもしれない。その結果、たとえプロジェクトが順調に進んでいたとしても、隠れた問題や斬新な新しいアイデアを発見することができる。
- そろそろこのミーティングをする時期だと感じているなら、おそらくその通りだろう。四半期の終わりやプロジェクトの終わりなどを待たずに。
建築 レトロ
このミーティングは、ソフトウェアが出荷された後に行う。基本的に、これはアーキテクチャーの更新と同じですが、最後のものであることと、より多くの聴衆を含める必要があることを除きます。
チェックリスト
- プロジェクト関係者全員を招待する
- メインのエンジニアリングSlackチャンネルに招待する
- レビューで作成したエンジニアリング・ドキュメントを更新し、ソフトウェアの最新状態を反映させる。
- 会議の前に、振り返りのメモを募集する。うまくいったこと、うまくいかなかったこと、変更案を書いてもらう場を設ける。
- ミーティングでは、更新されたエンジニアリング・ドキュメントを説明し、変更点に注意を促し、質問やフィードバックを求める。
- ミーティングでは、全員にレトロノートを読んでもらい、ディスカッションを促す。
提案
- レトロミーティングは、アジェンダに忠実であることが必ずしもベストではないミーティングのひとつである。もし人々が特定の課題について議論したいのであれば、そのための時間を作ればいい。必要であれば、いつでも時間を増やすことができる。
