第4回で共通のCase／Stepモデルを作ったとき、頭にあった問いがありました。性質の違う課題を、本当に同じ器で扱えるのか。今回は、その答え合わせです。
性質の違う3課題を選んだ
検証のために選んだのが、これまで紹介してきた3課題です。あえて性質をずらして選びました。似た課題ばかりでそろえても、共通化の検証にはならないからです。
- Webサイト接続障害: 障害の切り分け。標準化したいのは、確認の順序と原因の判断。
- IAM権限追加: 変更と権限の設計。標準化したいのは、最小権限の判断観点。
- 環境調査・引き継ぎ: 環境の棚卸し。標準化したいのは、環境全体の確認観点。
もし3つとも似た課題なら、同じUIに載って当たり前です。切り分け、設計、棚卸しという毛色の違う3つが同じモデルに載るなら、共通化はある程度うまくいっている、と言えるはずでした。障害対応は上流から下流への一本道、権限設計は判断の積み重ね、環境調査は広く浅く網羅と、進み方の質もかなり違います。ここまで違うものを一つの器に入れられるかが、設計の本当の試験だと考えました。
最初のWeb課題を基準実装にした
進め方としては、まずWebサイト接続障害を基準実装として作り込みました。ここで共通のCase／Stepモデル、3カラム画面、進捗保存、完了制約、ローカル補助を一通り固めます。いわば、後続の課題を載せるためのレールです。最初の一つは、共通部品を育てながら作るので、どうしても時間がかかります。
そのうえで、IAM権限追加を追加し、次に環境調査・引き継ぎを追加しました。追加のたびに確認したのは、「共通の部分に手を入れずに載るか」でした。ここで共通側をいじらないと進まないなら、それは共通化ができていない、というサインになります。
データ追加と登録だけで載った
結果から言うと、2つ目と3つ目の課題は、基本的に課題データのファイルを一つ書いて、一覧の配列に登録するだけで載りました。共通の型、スキーマ、進捗ロジック、進捗保存、3カラム画面は、作り直していません。
これは、第4回で狙った「課題を足すのはデータを一つ加えるだけ」が、実際に成り立ったということです。10ステップ、12ステップ、15ステップと長さも違い、扱う観点も障害・権限・環境とばらばらなのに、同じUIと同じ完了制約で最後まで完走できました。IAM課題を足したときにも、環境調査課題を足したときにも、画面やロジックの作り直しは要りませんでした。
正直、ここは作っていて一番うれしかったところです。設計の再現性という抽象的な狙いが、3つ目まで載って初めて、手応えとして返ってきました。2つ目までは「たまたまかもしれない」と思っていましたが、3つ目が同じように載ったことで、少し自信を持てました。
共通化しきれなかったところ
とはいえ、まったく無改修だったわけではありません。唯一の共通UIの変更は、課題ごとの安全上の注意（「この課題ではAWS環境を変更しません」など）を画面上部に常時表示するようにした点です。
これは3つ目の環境調査を作るときに入れた変更ですが、特定の課題だけのためではなく、3課題すべてに等しく効く汎用的な改善だったので、共通側に入れました。逆に言えば、こうした「全課題に共通で効く改善」だけを共通UIに寄せ、個別の文言や観点は課題データ側に置く、という線引きを守れたということでもあります。ここが崩れて、特定の課題のための分岐を共通側に書き始めると、器はすぐに汚れていきます。そうならないよう気をつけました。
一方で、課題ごとの細かな性質の違い――たとえば環境調査の「対象外／未確認」の扱いのような観点――は、完全には共通化できず、データの書き方でカバーしている部分が残ります。器はそろえられても、中身の書き分けは課題ごとに手をかけるしかない、というのは前回までと同じ結論でした。共通化には、ちょうどいい深さがあって、それより深く共通化しようとすると、かえって窮屈になります。
テストで、崩れていないことを確かめる
課題を足すたびに怖いのは、前の課題や共通部分を壊すことです。追加が別の場所を壊していないか、目視だけでは自信が持てません。そこで、課題を追加するごとにテストも足していきました。スキーマの検証、ステップの順序、完了制約、最後までの完走、進捗の保存と再読み込みでの復元、そして画面の描画中にエラーが出ないこと。
実装レポートの時点で、アプリ側のテストは173件（18ファイル）が通っています。あわせて、別に用意している読み取り専用のレポート生成ツール（Reporter）のテストも67件が通っています。3課題を載せても既存のテストが崩れていないことを、数字で確認できる状態にしました。テストがあると、「たぶん大丈夫」ではなく「壊れていない」と言えるので、追加のたびの不安がずいぶん減ります。
フレークの原因を調べて、タイマーを調整した
一つ手こずったのが、テストがときどき失敗する（フレークする）ことでした。毎回ではなく、たまにこける。この「たまに」が一番やっかいです。原因が分からないまま再実行で通ってしまうと、つい放置したくなります。
追ってみると、原因は二つありました。一つは単純にテストの実行時間で、ステップ数の多い画面結合テストが、並列で負荷がかかったときに既定のタイムアウトを超えていました。ここはタイムアウトの上限を引き上げて対応しました。もう一つは、一定時間後に自動で消えるトースト表示が、テストの外側で状態を更新し、警告をエラーとして出してしまう可能性でした。こちらは、結合テストで時間を擬似的に制御する仕組み（フェイクタイマー）を入れて安定させました。
結果として、テストを繰り返し実行しても173件がそろって通るようになりました。フレークは「たまたま」で片付けず、原因まで下りて直したほうが、後々の自分が楽になると改めて感じた作業でした。
作ってみて感じたこと
3課題を同じ器に載せられたことで、第4回で立てた設計の仮説には、ひとまず自信が持てました。新しい課題は、原則としてデータを足すだけで載る。この見通しが立ったのは、大きな収穫です。
ただ、これはあくまで3課題での話です。もっと毛色の違う課題――たとえば承認のやり取りが何度も往復するような課題――を持ち込んだときに、共通モデルがどこまで耐えるかは、まだ分かりません。再現性を確かめられたのは3つまで、というのが正直な現在地です。
次回は本編の最終回です。第1回で感じた問題意識に立ち返り、OpsMate Proで目指す「本当の標準化」とは何だったのかを、現在地と将来像とあわせてまとめます。