こんにちは、エンジニアの中島です。
この記事は2024年7月のLIFULL社でのアクセシビリティ改善およびやっていき活動の報告です。
この活動報告は月次で出すかもしれないし出さないかもしれないくらいの温度感で運用されています。
続きを読むLIFULL AI Hub 100ミニッツ #2 開催報告とお知らせ
グループデータ本部データサイエンスグループの嶋村です。
データサイエンスグループが主催でデータサイエンス系の自社イベント『LIFULL AI Hub 100 ミニッツ ＃2 「ファクトブック」』を開催しました。第1回目の『LIFULL AI Hub 100ミニッツ #1 「LLM（大規模言語モデル）の研究開発」』に引き続き、オフライン・オンラインともに盛況となり、今回も講演を聴講していて学びがありました。当日は、X（旧Twitter）でも実況しておりましたので、当日の様子が少しでも伝わればと思います。
主催のデータサイエンスグループはグループデータ本部配下の研究開発組織になります。グループデータ本部は、LIFULLグループで生まれる新たなデータを安全かつ効果的に活用できるようにし、事業の変化と持続的な成長を促進することを目指している組織です。その中で、データサイエンスグループは「活用価値のあるデータを創出」し、「データを活用した新たな機能やサービス」の研究開発に取り組んでいます。
今回のテーマである「ファクトブック」は、以前本ブログでも記載した「LIFULLファクトブックで目指す真のドメイン知識獲得」に関する発表となります。弊社LIFULLの事例だけではなく、先行してファクトブック活動を続けられている東北一円にドラッグストアを展開する薬王堂さまの事例に関する発表もありました。
続きを読む2024年4〜6月 LIFULLのアクセシビリティへの取り組み
こんにちは、エンジニアの中島です。
この記事は2024年4月〜6月のLIFULL社でのアクセシビリティ改善およびやっていき活動の報告です。
この活動報告は月次で出すかもしれないし出さないかもしれないくらいの温度感で運用されています。
続きを読むE2Eテストをシフトレフトしてdevelopブランチでの自動テスト実行時間を80％短縮した話
QAの山下です。
QAグループという名前で横断組織として手動&自動テストやツール開発、プロセス改善など仕組みづくりに取り組んでいます。
今回は LIFULL HOME'S の開発で実行されているE2Eテスト（リグレッションテスト）をシフトレフトし、実行時間を80％短縮した話を紹介します。
ざっくり何をやったのか
- 大規模なリポジトリでのdevelopマージ後のE2Eテストの9割をPR上で実行可能にした
- コードのpushからE2Eテスト完了まで5～8分で完了できる
- 運用上の課題も頑張って解消した
目次
- ざっくり何をやったのか
- 目次
- 結論
- 前提情報
- テストの削除とリファクタを行い、テストケースを3割削減した
- デプロイ後のアプリケーションに対してe2eテストを実行できるようにした
- 開発チームとのコミュニケーションを積極的に行い、運用課題の発見と改善を実施した
- これからやりたいこと
結論
以下の図の通りです。
Git-Flowをベースとしたフローに則り開発されていたリポジトリで、developマージ後に実施されていたE2Eテストの9割をPR上で実⾏できるようにシフトレフトしました。
コードのpushからE2Eテスト完了まで5～8分で完了します。
前提情報
今回のPJの紹介にあたって前提となる情報を記載します。
E2Eテストとは
本番相当の環境で、ビジネスプロセスを最初から最後まで実⾏するテストの⼀種です。（ISTQBより）
LIFULL HOME'Sでは内製の⾃動テストフレームワーク「Bucky」を使ってE2Eテストを実施しています。
リグレッションテストとは
ソフトウェアの変更されていない領域の欠陥を検出するためテストの⼀種。（ISTQBより）
Aの機能に手を加えたのにBの機能でバグが出た！のような現象を検知するテストです。
LIFULL HOMESでのE2Eテストの位置付け
- 重大な問題点がないことを(回帰テスト観点で主要機能の動作)を保証する。
- テストした結果、不具合が発見された場合は修正を行う。修正が完了しない限り、本番へリリースすることはできない。
テストスコープは以下です
- 動かなくなると重大な被害を被る機能群
- 物件の検索や資料請求等
- 過去に障害が起こった機能群
- 確認が漏れそうな機能群
シフトレフトとは
テストおよび品質保証の活動の実施を、ソフトウェア開発ライフサイクル内で可能な限り早く⾏うためのアプローチ。（ISTQBより）
今回はdevelopブランチで実施されていたテストをPR上で実行するようにしたことでシフトレフトを実現しています。
シフトレフトするメリットは以下が挙げられます
- 早期にフィードバックできることで大きな手戻りやバグを未然に防ぎ、全体のテスト時間を短縮しソフトウェアの品質向上が期待できます。
EEとは
- 瞬時に検証環境が手に入るEphemeral Environmentの略称。
- Pull Requestの内容をもとに一定期間アクセス可能な環境の複製をデプロイする機能。
- Vercelのpreview環境のようなもの
- 弊社の全社アプリケーション実行基盤であるKEELの1つの機能です。
対象のプロダクトの規模
今回実施した対象のリポジトリの規模を記載します。
- LIFULLの看板サービスであるLIFULL HOME'Sの主要機能が実装されているリポジトリ
- 1ヶ月間のauthor数: 約100人、Merged PR数: 約200
起こっていた課題
- developブランチマージから本番環境反映まで8.5時間かかっていた
- QAGの工数が1~4時間/日かかっていた
- 基本的に朝9時からdevelopブランチに対して自動テストを実行
- 実行後の結果を確認、バグが検知されれば開発チームに仕様確認
- 14時くらいに本番環境反映
- E2Eテストでバグを検知した時の手戻りの多さ
- Revert対応率は3年連続で50%を超えていた
- QAGと開発チームのコミュニケーションに時間がかかる
- 弊社QAGは横断組織で、機能開発チームに常駐しているわけではありません。そのためE2Eテストが失敗した際に、E2Eテストのメンテナンスが必要なのか、バグなのかがすぐに判断できませんでした。
- 都度開発チームに調査依頼を投げていたので、両チームの負担となっていました。
ここまではこのPJに関する前提状況を書きました。ここからはPJの中で実施したことを時系列順で書いていきます。
テストの削除とリファクタを行い、テストケースを3割削減した
前述したdevelopブランチマージ後に実施していたテストは、合計400ケースほどありました。これらをそのまますべてシフトレフトすると以下の懸念がありました。
※後述のリファクタは保証したい内容は変えずにシナリオを変えることを指してます。例えば元々1ケース1アサート*2 だったシナリオを1ケースで2アサーションするように変更する等です。
- 実行時間が長いことで開発者体験が悪くなる
- 最悪の場合、QAと開発者の対立の原因になる
- 再実行数が増えコストが上がる
これらの問題を解決するため、テストの再設計を実施しました。結果としてテストケース数を3割削減、またテストの実行時間も削減できました。
この項目で実施したことは以下です。
- テストを実行時間順にソートする
- 実行時間が長いものから削除、リファクタ、再設計箇所の洗い出し
- テスト技法を用いて検討
- 該当のテストケースが追加された時の意図(バグチケット等)を基に、現在でも同じテストケースが必要か検討
- レビュー実施
- 開発者との合意形成
- テストの削除、リファクタ、再設計を実施したことによりステークホルダーに影響があるため合意を形成する必要がありました。
- ステークホルダーは機能開発のエンジニア、企画職
- 合意は以下の内容で形成しました
- 対象テストケース
- 削除対象とした理由
- 実装
デプロイ後のアプリケーションに対してe2eテストを実行できるようにした
本題とは離れるので詳しくは割愛しますが、HelmにおけるChart Hooksを編集し、前述のEEデプロイ後にEEに対して E2Eテストを実行するようにデプロイパイプラインを修正しました。
開発チームとのコミュニケーションを積極的に行い、運用課題の発見と改善を実施した
ここまでで「リモートブランチにPushされる度にPR上でE2Eテストが実行される」状態にはできました。しかし作ったら終わりではありません。ここから運用課題とどう向き合ったのかを書いていきます。
挙がっていた運用課題は以下です。
それぞれについて問題の概要、検討事項、解決法を書いていきます。
テスト結果通知のコメントが量産されPRが見づらくなる
問題の概要
現状E2Eテストが完了した際に以下のようなコメントがされます。
画像
開発している時には気づけなかったのですが、コミット数が多くなってくるとコメントがその分量産されPRの見渡しが悪くなるとのフィードバックをもらいました。
検討事項
「PR内に存在する過去のE2E結果コメントを削除→新規のテスト結果コメントを投稿」の処理に変えれば良いのでは？と考えました。
懸念としては、PR内で過去のテスト結果を見ることができなくなることでした。
しかし
- 過去のテスト結果を見ることはユースケースとして多くない
- 別のマネジメントツールがあり、過去の結果を見たくなった時はそこからPRの番号で閲覧できる
ので問題無しと判断しました。
解決法
以下の処理に変更しました。
- PR内に存在する過去のE2E結果コメントを削除
- 新規のテスト結果コメントを投稿
マージ要件を満たせない
問題の概要
このE2EテストはCIとしてPushの度に実行されます。またリグレッションテストとしての役割も持っているので、当然全てのテストが成功してからdevelopブランチに反映されるべきです。
そのため導入時はテストが100%成功していないとマージができないようにしていました。
しかし、このルールでは開発者体験が悪化してしまいました。原因は以下です。
- E2Eテストは他のテストレベルと比較して不安定さが高い
- ネットワークの問題等で1個でも失敗してしまうとマージができない
- 後述の「テストの再実行がやりづらい」問題のため、テストの再実行に10分かかってしまう。
- ABテストが多い
- LIFULL HOME'Sでは多くのプロジェクトが並行して進んでおり、それに比例してABテストも数多く存在します。
- 基本的にはE2Eテストシナリオではメインに採用されている方を期待していますが、自動テスト時に期待していない方を引いてしまった場合、UIやロケーターが変わるので失敗してしまいます。
- 開発者も他チームのABテスト事情を全て把握しているわけではない
解決法
マージ要件に閾値を設ける手段を取りました。
具体的には自動テストのpass率が90%を超えている場合にはマージ可能としました。
検討事項
チーム内で話し合った結果、避けたかったこととしては以下が列挙されました。
- バグの流出
- 自動テストで検知されているバグを無視してマージした結果本番で障害が出る
- E2Eテストの形骸化
- テストが失敗してもマージ可能なため自動テストのメンテナンスをせずに放置される可能性がある。
- 自動テストのメンテナンス不足で失敗が増え、テスト結果が信頼できなくなる等が起こる傾向にある
- 開発者体験が悪くなること
- プロダクトコードに問題が無く、flakyテストによってマージが阻まれる事
- 他チームで実施されているABテストによってテストが失敗し、マージが阻まれる事
- テスト成功率100%を求め続けることで開発者のストレスになる
- 最悪の場合QAと開発者で対立が生まれる
上記の「バグの流出」と「E2Eテストの形骸化」は自動テスト成功率を100%を強いることで解決できますが、3つ目に関しては自動テスト成功率を100%を強いると起こり得てしまう問題です。
過去の自動テストの結果を見て、flakyテストとABテストで期待していないパターンを引いた場合でも90%は下回らないということが分かりました。
そのためマージ要件をE2Eテストのpass率100%→90%に変更しました。
テストの再実行がやりづらい
問題の概要
テストの再実行を行いたい場合、以下の手順を踏む必要がありました。
- EEの再起動
- E2Eテストの実行
- E2Eテストの結果
特にコードの修正をしていない場合の再実行では、E2Eを再実行したいだけのためにEEの再構築も行わなければなりません。
EE再構築からテスト完了まで10分を超えることもあり、これはユーザーにとってストレスでした。
解決法
GitHub Actionsのworkflow_dispatchを使い、E2Eテストの再実行を楽にしました。
以下の流れでテストの再実行が実施されます。
- workflow_dispatchでPR番号を入力する
- 入力されたPR番号から再実行すべきテストケースを取得
- 入力されたPR番号から再実行対象のFQDNを取得
- WorkflowでE2Eテストの再実行用スクリプトを実行
これによってコードの変更をしていない場合でのE2Eテスト再実行の手間が軽減され、時間としては10分→5分ほどにまで削減できました。
これからやりたいこと
シフトレフトすることでE2Eテストの実行時間を80%短縮することができ、早期にフィードバックができるようになりましたが、まだまだ改善できる部分があります。
e2eテストの安定化
現在はUIの変更や改修に対して脆いテストが存在しています。これを解消するためにdata-testidのような自動テスト用の属性をプロダクトコードに導入し、テストの安定化を図りたいです。アラートの仕組み化
前述の通り閾値を設けてマージの可否を決めています。そのため本来メンテが必要なテストケースが放置されてしまう可能性があります。
現在はQAGが定期的にテスト結果をモニタリングし、担当部署にアナウンスしていますが今後はアラートの仕組みを導入して一定の条件で担当部署に通知するようにしたいです。ABテストに対応するためのcookie固定化
前述の通りLIFULL HOME'Sでは多くのプロジェクトが並行して進んでおり、ABテストも数多く存在し、この数に比例して「自動テストで期待していないパターンを引いてしまう」という問題が発生しやすくなります。
これを解消するために「e2eテストからのリクエストだった場合はABテストのcookieを固定化する」ような仕組みを開発者と協力し導入したいです。
これからもQAとして品質改善、開発スピード、開発者体験向上に貢献していきたいと考えています。
不動産広告画像を定量的に評価する取り組み
グループデータ本部データサイエンスグループの嶋村です。
グループデータ本部は、LIFULLグループで生まれる新たなデータを安全かつ効果的に活用できるようにし、事業の変化と持続的な成長を促進することを目指している組織です。その中で、データサイエンスグループは研究開発組織として、「活用価値のあるデータを創出」し、「データを活用した新たな機能やサービス」の研究開発に取り組んでいます。
事業を革進し続けて様々な社会課題を解決していくために、データを最大限に活用できる状態にしていきたいと考えています。その一環として、不動産情報・住宅サイトであるLIFULL HOME'Sに掲載される不動産広告画像を定量的に評価（数値化）し、その評価結果をプロダクトの改善に活用できる状態にするための取り組みを続けています。
2024年4月27日に弊社が協賛している「第88回 Machine Learning 15minutes! Hybrid」が開催され、今回の取り組みについて登壇をしました。
続きを読むLLM開拓者が集う会！ 「第89回 Machine Learning 15minutes! Hybrid」開催報告
データサイエンスグループの島です。 普段は機械学習システムバックエンドの開発や運用を行っております。
2024年5月25日に半蔵門の本社2Fにて機械学習(AI・人工知能)に関するライトニングトーク(LT)会が開かれました。 素晴らしいLT会でしたので、内容をいくつかシェアさせてください。
第89回 Machine Learning 15minutes! Hybrid - connpass
「Machine Learning 15minutes!」というコミュニティを運営している門前さんが主催するLT会です。 以前の開催に引き続き、LIFULL AI Hubが協賛という形での開催となりました。
現地参加とオンラインのハイブリッド開催で、会場20名、オンライン100名ほどがいらっしゃいました。
様々な方が発表してくださり非常に盛り上がりました。豪華な内容でとても示唆に富んでいました。関係者の皆様、参加いただいた皆様ありがとうございました。
LIFULLからは分析に関わる社員向けのデータ活用施策であるファクトブックに関する発表を行っております。
とても盛りだくさんなLT会ですべてをご紹介できないのですが、LIFULLのような事業会社でのAI活用という視点で心に残ったものを共有させてください。
- 元木 大介さん【２週間で世界１万ダウンロード 自然言語プログラミングの衝撃】
- 吉崎亮介さん【仕事の対話をAIでハックする考え方とプロセス】
- 森 正弥さん 【AIは人の仕事を奪うのか？ AI時代の新たな哲学】
- 懇親会
テスト仕様書の共通テンプレートをつくった話を膨らませてみた
こんにちは。クオリティアーキテクトグループでQAエンジニアをしている星野です。
元々はQAグループという名前で横断組織として社内のテストプロジェクト支援などを嗜んでいましたが、
組織が統合・再編成され、より自動テストやツール開発、プロセス改善などエンジニアリングに寄った仕組みづくりに取り組んでいます。
３行まとめ
共通のフォーマットを開発したよ
抵抗感なく浸透させるように工夫したよ
こっそり横断的なメトリクスも取ったら便利っぽかったよ
背景
課題
LIFULLではチームごとにやりやすい開発体制を選択しています。
奇抜な開発スタイルをとっているわけではありませんが、それぞれに特色があり独自に改善活動を行って進化しています。
改善の進めやすさなど柔軟性のメリットもありますが、一方で次のような課題が出てきます。
- ナレッジの横展開がむずかしい
- フォーマットが異なるためツールやノウハウをそのまま再利用できないことがある
- 部署異動や新人の学習コストが高い
- 学び直しが必要になる
- 他部署の成果物を読み解く際にフォーマットの理解から必要になる
我々のような横断的なQA組織の立場としては次のような課題があります。
- 測定・調査が難しい
- チームごとにテスト成果物のフォーマット（ここではテスト仕様書・項目書）が異なるためメトリクスを活用しにくい, 状況を把握しにくい
- 非同期で変化するためそれぞれの形に合わせて自動化しても追跡が難しい
- 改善施策を広めにくい
- 上記の「ナレッジの横展開」と同様
- １チームの閉じた単位で改善を行うためスピードが出ず再開発する必要もある
加えて最近では特に海外の開発拠点とこれまで以上に密な連携を行って開発するようになりました。
覚えることが多い状況の中、テスト部分で海外拠点メンバーが困らないように「とりあえずこれまで通り自分たちのフォーマットを使って進めましょう。どんな形がいいかはみんなで検討しよう。」の方針となるチームも多く、フォーマット迷子になっている状況でした。
対策
ここまでの流れでおわかりの通り、標準となるテスト仕様書のテンプレートを開発しました。
シンプルに言うとそれだけなのですが、会社のテックブログなのでそれらしいことを書きます。
やったこと
もちろんですが、チームの外にいる人から「急だけど今日からこのテンプレートでテスト書いてね！じゃ！」と言われても圧倒的なパワー差による主従関係でもない限り通りません。
ではどんなテンプレートを用意すれば既存のやりかたと勝負できるか。
品質分野の人間なのでみんな大好きな狩野モデルを出して説明します。
（引用 : ナレッジ - 品質管理なら日本科学技術連盟 ）
狩野モデルについての詳細な説明は割愛します。
要は利用者の目線で見たときに、当たり前に揃っていて欲しいものがないと不満を感じるし、魅力に感じるような要素がないと満足度は上がらない、というざっくり説明で進行します。
このモデルをもとにどんなテンプレートが必要かを考えると、以下を満たす必要がありました。
- 当たり前品質（満たさないと論外）
- 現在使っているテンプレートでできることはできる
- テストケースの書き方を極力変える必要がない
- 一元的品質（あればあるほどいい）
- サポートの手厚さ
- 魅力品質（これだけでも使う理由あるやん）
- 開発チームの未解決課題にアプローチした機能
当たり前品質編 : 満たさないと論外
まずはじめに行ったのは既存フォーマットの調査です。
基本的にはチーム単位で独自にツールベンダーと契約することは予算的にも現実的ではないため、スプレッドシートを用いることが主です。
スプレッドシートは自由度が高いため独自進化しやすく、GASや式を用いた機能拡張が進んだチームも見られました。
機能の不足で乗り換えを躊躇するチームは限られているので充足は徐々に行っていくとして、まずは元となるテストケースの書き方（カラムなど）に焦点を当てます。
よく使われるカラムや書き方を調べ、代替や統合ができそうかを考え、プロトタイプを作ってはヒアリングを行い（海外拠点メンバーを含む）利用者の声を聞きにいってました。
特に奇抜なフォーマットが出来上がるわけもなく、よくある一般的な内容に落ち着いたため詳細は省略しますが、
PMなど進捗が気になる人に一目で状況がわかるようにテスト進捗メトリクスのグラフをつけたり、
複数端末で同時にテストする需要があるのでテスト結果を入力するカラムを複数個並べるといった小さな気配りを機能ごとに想定ユーザーとシチュエーションを設定していっぱいちりばめた記憶があります。
もちろんですが、想定は想定でしかないため、実際に見てもらってユースケースと食い違ったり噛み合わせが悪い部分はアップデートを重ねています。
その後は不足している機能の拡充で、既に進化しているチームのシートを参考にしながら機能を汎化させ取り込んでいきます。
具体的には、スマートフォンの実機でテストする際の効率をよくするためにQRコードを自動で生成したり、テスト環境を切り替える際にテストケース内のドメインを一括で切り替えたりといったあるある機能群なのでこちらも割愛します。
つまるところは「この機能がないと不便なんだよなぁ〜」をなくす運動です。「その機能、別になくていいのに必須入力なんだよなぁ〜」も生み出さないよう、利用者以外には影響を及ぼさないような設計を意識しました。
魅力品質編: 乗り換える理由をつくる
いま現在利用されているテンプレートでは叶っていない機能、抱えている・またはこれから抱える問題の解決につながるような機能を考えます。
背景でも述べていますが、ここは明らかでした。海外開発拠点との連携が密になり、言語の壁が課題となっています。
DeepLのような翻訳サービスが進歩していても、都度都度テストケースの中身を翻訳にかけるのはとても手間です（ましてやスプレッドシートなのでセル単位）。
メンバーも元々英語が必要な環境だと言われて入社しているわけではないですし、自分もそうですが全員が全員、語学が堪能ではありませんし全員が急に上達するのも現実的ではありません。
そこで、指定したシートのテストケースをボタンひとつで翻訳してくれる機能を用意しました。ありがとうGoogleTranslate関数くん。
他にも共通テンプレートとなると複製の手間が発生することが目に見えているため、GASでAPIを用意し常に最新版のテンプレートを生成してくれる仕組みを用意したり、それをgithub actionsに組み込んでPR作成時にトレースも取れた状態でつくれるようにしたりと開発者体験の向上を進めました。
これで「今まで使ってたGoogleDriveから複製して使ってたこれまでのテンプレートより全然楽じゃん...」な状況が手に入ったわけです。
横断部署が常にぶちあたる浸透の課題
ヒアリングを重ねて使いやすい形を手に入れ、既存機能にも追いつき、他にない機能も搭載されました。
プロダクトを作った後に課題となるのは「浸透」です。使ってもらえなければこの新テンプレートは存在しているだけで何の価値も出せていません。
ロガー
そこで、まずは利用状況を追跡し可視化する機能を実装しました。
利用時に必ず操作するボタンをトリガーに、利用しているチーム、github actionsから生成されていればPR番号などをログとして蓄積し、見える化を行いました。
これにより、一度使っていてもその後に利用が見られなければ、なにか問題・課題を見つけてくれていると考えられるのでヒアリングをする、といった動き方ができます。
また、よく使ってくれているチームや一度も使っていない（知らない or 乗り換えるメリットを得られない）チームなどが明らかになります。ターゲットが明確になることで次の打ち手の確度が上がります。
実際はクチコミで「なんかQAがつくったテンプレがいい感じらしい」と自然に広がってくれたようで、じわじわ増えていく様子が見られました。
リリースした新機能が活用されているのかどうかだったり、サポートの問い合わせがあったときにログの利用者情報からシートをすぐ特定できるため重宝しています。
広報
次に、定期的に丁寧なアナウンスです。
読み手にとって価値の薄い「つかってくださ〜い」の広報を何度行っても響きません。むしろノイズとなり煙たがられます。
そこで、魅力となる便利機能が搭載されたタイミングで、その機能の概要と使い方を1~2分の動画説明を添えて広報しました。
使い方もほぼ誤解なく伝わっているようで、利用数に対して機能の使い方に関する質問はほとんどありません（バグの報告や新機能の提案、感謝の声などがフォームやDMに届いてます）。
使われていなくて質問がないのか、使われている上で質問がないのか、これには大きな違いがありますが、前述の利用状況を見える化したことでその判別ができます（ちなみに独自の名前をつけたことでslackにてエゴサがとてもしやすい）。
効果と現状とこれから
定量的なアウトカムについては恐縮ながらまだ計測できていません。
取り組み自体、半期で計画・調査・実装・展開・浸透を行なっているためデータを蓄積している最中になります。
また、このテンプレートは裏でこれまたこっそりとメトリクスを収集できるようにしており、利用されたすべてのシートでテストケース総数や実施した環境数、テストタイプの数や実施期間などが取得できています。
これらのデータを既存テンプレート利用時の実態と比較できればよかったのですが、背景で述べたようにチームごとに実態が異なっており、また詳細なデータも取れるかわからないのが現状です。
整理しやすくなった、見やすくなった、翻訳機能が助かっている、などの定性的なフィードバックはもらえるようになったものの、定量的なアウトカムはやはり難しいため、
新たに取得しているメトリクスから、新機能リリース後の変化や改善施策実施後の効果計測、チームごとの健康状態可視化、ベストプラクティスの発見と横展開などの取り組みに繋げていく基盤として機能させていこうと構想しています。
終わりに
ただただ共通テンプレートをつくった話を長々と述べました。
たかが共通テンプレートですが、利用するだけで恩恵を得られるような仕組みを用意したり、改善を誘導するような仕込み（本記事では割愛しました）ができたりと、工夫の余地は結構ありました。
たかが共通テンプレートですが、浸透させるのも頭を悩まされ、たくさんの方に協力していただきました。
たかが共通テンプレート。されど共通テンプレート。
以上です。
お読み頂きありがとうございました。
