JaSST'24 Tokyoに参加してきました(1日目)

久しぶりにオフライン会場ありで行われたJaSST Tokyoに参加してきました! 久しぶりに会場での雰囲気を味わえたり知り合いに会えました。

チラシとかが入っていたバッグ。会場参加ノベルティ感がある。デザインかわいい

気になったセッションのメモと感想をまとめます。

オープニング

昨年亡くなられたにしさんについて言及がありました。「天国と地獄の境界分析」とか、「閻魔様にプロセス改善を提案」とかパワーワードが飛び出して笑っちゃいました。強い。

基調講演「Tangible software quality」 Gojko Adzic 氏

講演内容メモ

  • 会社が資金難になるようではいい品質のプロダクトとは言えない
  • ユーザーはプロダクトから価値を得られていてプロダクトは成功している、品質がいい
  • 測定、品質を測るとき重要なのは正しいものを測定出来ているから
    • 間違ったものを測定してはいけない
    • 価値のある重要なものより簡単に測定できるものを測定しがち
  • 診断的測定:何かが間違っていると示す
  • パフォーマンス測定:それを使って重要な意識決定ができるか、不確実性を減らせるか
  • 判断の価値と情報の有用性
    • 市場で成功できるかとか 不確実性が管理できればいい
    • だが一つの指標だけでは測りきれない
    • 様々な意思決定をしなければいけない それには複数の測定を組み合わせる必要がある
  • ユーザーが言っていることと開発が対応できることをトレードオフする
    • ユーザーの言っているリアルタイムレポートは1日1回でよかった
    • 開発は秒単位を想定していた
  • プロダクトの意思決定 どこに投資すべきかを決める
  • マズロー的な品質評価 それぞれにおいて十分というポイント
    • 成功しているのか アウトカム
    • 仕事ができているか 役に立つか
    • 使い勝手が良いか
    • 機能 アウトプット
    • デプロイ
いい感じの図がなかったので作った
  • 収益とかどのくらい使われているのか少なくともテスターは理解すべき
  • 重要なのはモデルを作ること
    • 10分テスト計画
    • リスク分析3つ
    • 変更頻度、ユーザー影響、
    • ACCマトリクス

感想

正直消化できてない部分も多いのですが、今回のJaSSTでよく出てきた「価値」の話の最初の一個です。価値に関する考え方を色々角度を変えながら話していただきました。具体例が多かったのが理解の助けになってよかったです。

QAエンジニアの〇〇UP!キャリア解剖で見える今どきの成長軸とは? SigQAの皆様

講演内容メモ

  • トークショーっぽいw一番ライブ感のあるセッション
  • 十人十色のSigQAのキャリアを紐解き、今どきのQAエンジニアの◯◯アップを7つ紹介
  • プレイヤー編
    • 個人のテスト力
      • テスト能力どう高めるのか
      • テスト技術も使うけど仕様やドメイン知識、テスト以外のIT知識
      • →身近なプロジェクトの中で何を学ぶか相談しよう
    • チームのテスト力
      • 適切な期間。タイミングで、ユーザーに品質価値を提供し、ユーザーの満足を確保する
      • テスト容易性の課題分析と対応
      • 文化と仕組みをちゃんと整備していればみんなが自走して改善していく
  • マネージャー編
    • なんとかする力
      • 世界は経営でできている

    • 前提 理解、分解、再構築する力
      • QCD 今何が起きているか理解して判断する
      • ファクトとしては一つだが、色々な見方をする
      • プロダクト、プロセス、道具
    • 考え続けて構想する力
      • ベースになるのは豊かな想像力
      • マネージャーは安定したら終わり。常に成長させていく
    • 構想力の磨き方
      • その立場その立場できちんとみにつけていればいずれ役に立つ
      • 伝わるゆさぶる文章を書く

    • ロール横断思考
      • どんな仕事をしていても必ずどこかで繋がる

井芹さん発表部分はアップされていたのでリンク貼っておきます

speakerdeck.com

感想

前説明通り、一番ライブ感あるセッションでした。「文化と仕組みをちゃんと整備していればみんなが自走して改善していく」は難しいところだけど、確かにそうだなと思っています。マネージャーはやったことないのですが、必要な心持ちが分解されて紹介されてて分かりやすかったです。

AI搭載プロダクトの品質保証の現在地点とこれから

講演内容メモ

  • AutifyがAIを使っている部分
    • 要素の特定をWebでもモバイルアプリでもAIを利用して行っている
  • ソフトウェア工学のためのAI
  • AIのためのソフトウェア工学
  • AIの制度を測っていく上でどういった考えで制度を測っているか
    • レーニングを使ったデータ
    • 自動生成データを使って制度を測っている
    • 実際のテスト実行でどのような結果が出たか
    • お客さんから問い合わせ
  • GUIの流行の変化でデータドリフトがおきて画面認識の精度が下がることはあるか?
  • 正解dataがないようなアウトプットをどう評価するか
    • 理想の答えはない
    • 5人の人が見て同じ評価をするとか、仮想的に評価を付ける
    • やりたいことを検証できているかは検討し続ける
    • 正解がないものはテストオラクルがないのか
    • ラクルがないわけではなく、人によって評価が割れたり評価にコストがかかったりする
    • 正解はないといいつつお客さんには正解がある。難しいポイント
  • 世の中に実際に出してユーザーに使って見てもらって初めて品質が図れるという側面がある中で、リリース前後で何を評価していくべきか
    • ビジネスKPIを見る
    • お客様からフィードバックをもらう手段をいかに丁寧に得られるかを準備する
    • リリースまでの品質は最低限を担保したい
  • 説明性がなく因果が捉えにくいというAIの側面をアカデミック領域企業間でどう腰を据えて検証を進めるのか
    • AIの結果はブラックボックス、それに対して説明を求められるか?
    • AIがどう判断したかの説明は求められないが、期待している結果が得られない説明は求められる感じ
    • 見せ方を工夫して期待値を下げる
    • ベータリリースしてフィードバックをもらってから100%展開する

感想

AIも何ができるかという期待値のコントロールは必要なんですね。確かにそうかも。AIは主に使わせてもらう側なので、AIを使った製品を開発する側の視点は面白かったです。

トークセッション「JaSSTのはじまりとテストのこれから ~にしさんへの感謝を込めて」

感想

メモがとっちらかってるので、ここは感想だけ。パネラーの皆さんのにしさんとの思い出やこれからの品質の話がされてました。
特に心に残ったのは「にしさんは心が中二」「必要だと思ったら周りを巻き込んで実現する」という話です。にしさんが作ってくれた場にはずいぶん助けられました。なので何かしらお返しができたらなと思っています。私が登壇とかブログやらするのはお返しも理由の一つです。

JaSST'23 Tohokuに参加してきた

5/26(金)に行われたJaSST'23 Tohokuにオンラインで参加してきました。
www.jasst.jp

今年のテーマは「アジャイルとテストと私たち ~明日「アジャイル」と言われたときに困らないためのヒント~」です。基調講演やtohokuお馴染みのワークまで、アジャイルについて色々な角度から話を聞けたり模擬体験ができました。

今年は現地には行かなかったので、東北の気分を出すために食べたファミレスの盛岡冷麺

アジャイルテスター視点で、ユーザーストーリーマッピングを活用した効果的なプロダクト開発」

川口 恭伸 氏(YesNoBut/アギレルゴコンサルティング

ユーザーストーリーマッピング

こちらの本の話です。
発表資料はこちら

  • アラン・クーパー
    • ペルソナの提唱者
    • ユーザーストーリーマッピングの序文を書いた

 「開発とデザインには共通の言葉が欠けている=Jeff Pattonは二つの立場をつなぐ」

  • Vacation Photo 共有知的なもの
    • 図とかをの共有知がある前提の上で共有知を思い出すためのトリガーとして付箋を書く
    • 付箋などを使いながら会話する。インタラクティブでエネルギーにあふれたもの
    • みんなで一緒に地図を描き、共通理解を作る
    • 地図は全体像をとらえられる、詳細も必ずリンクされている
  • やり方の種類
    • 計画実行型 科学的計画法
    • 自己責任 お金があると人は利己的になりやすい
    • 自己組織化 意欲に満ちた人々を集めて計画する
      • 全員がそれぞれに、この場所にいることを選択している

Q. 実際のプロジェクトでは人の入れ替わりが激しい場合があると思いますが、その場合のストーリーの共有はどのように行うのでしょうか
A. できるだけ変えないようにする。Long Stable Team. 変更したら計測できない
 定期的な配置転換してたらテスラには勝てないと思います

  • ストーリーのやり方
    • 時系列でチケットを並べる
    • 1stリリースでやることを絞る。削れば削るほどリリースできる可能性は上がる(期間内にやることを詰め込まない方がいい)
    • ウォークスルー:ユーザーの立場に立って使えるかどうか試してみる
    • 全体像と詳細を行ったり来たりする。たくさん話す、話し合うきっかけ
  • 0章(Jeff Pattonの言いたいこと)
    • ストーリーを使う目的はもっといいストーリーを書くことではない
    • 製品開発の目標は製品を作ることではない(作って終わりではなく、お客さんがよかったと思うこと
  • フォーマット(ユーザーストーリーのカード)
    • 誰がなぜ必要なのかを書く
  • プロダクトバックログ
    • 全体像は別に作っておく(全体像を見失いやすいので)
  • 機能について会話するとき
    • 誰のためのものか
    • 現状ではどうなっていて、リリースによってどう変わるか
  • アジャイル
    • 開発者がペースを決める
    • 優先順位付けされたバックログで任せていれば、かつ安定したチームなら、「これはいつできるか」の問いに答えられる
    • 価値があるか分かるタイミングが早くなっていく
    • ユーザーはどう使うかを観察する

感想

ユーザーストーリーマッピングがどういう理由で始まったか、どうして必要なのかを分かりやすく説明してもらえてよかったです。
「ワークやります」からの、計画実行型、自己責任、自己組織化の説明への繋ぎに引き込まれました。オンライン参加でしたが、会場参加だったらまんまと誘導に引っ掛かった自信があります。

「インスプリントにおけるQAの取り組みとハーモナイゼーション」

長田 亮介さん(freee)

アジャイルQA型

インスプリントでの取り組み

  • Ready条件
    • 開発チケットやQAチケットのDoneの定義(開発Doneが必ずしもQA開始可能と限らないので誰がどこまでやるか認識揃えておく)
  • MVP特定
    • 要件レベルで指摘していく
  • リスク洗い出し会
    • 関係者をできるかぎり巻き込んでリスク洗い出し
  • プロダクトバックログリファインメント
  • スプリントプランニング
    • QAのゴールの設定
  • インスプリント
    • デイリースクラム
    • 質問や重篤度の定義をする
    • 受け入れ基準の策定
    • 完全網羅は厳しい。テストパラメータと値を洗い出して、あとはテスト実行者に裁量を与える
    • API単位とか、APIとセットになる画面を開発するタスクを同じスプリントに積む
  • スプリントレビュー
  • スプリントレトロスペクティブ

ハーモナイゼイション

  • debug API
    • 問題点:利用申し込みから決済まで丸一日かかる
      • 本人確認データが返ってくるまで1時間はかかってしまう
    • QA用のすぐ結果が返ってくるAPIを作る(後続処理どうするかなども含めてデイリースクラムで頭出しの相談)
  • ここまで来るまでには、しっかりQAし続けたり、APIレベルでレビュー指摘をあげたりなどの地道な積み重ねがあった
    • それこそ最初の頃はあまりQAの話を聞いてもらえないという時期もあった

感想

開発にQAが入り込んでテスト活動してるのが素敵でした。QA用のAPIを開発してもらえる開発との関係性を作るまでの地道な努力もすごいなと思います。QAの疑問まとめシートは自分のところでも似たようなことはやっていますが、チームで話す時間はとってなかったので真似させてもらおうと思います。

スクラムチームにアウトスプリントで関わるテスターの取り組み事例」

大平 祐介さん(JaSST Tohoku 実行委員会)
※アウトスプリント この講演では別チームからスクラムチームに関わりスプリント外でテストしている

  • 担当しているシステム
    • ToB向けSaaS
    • テストコードは可読性を大事にしている
  • チームのリリース戦略
    • トランクベース開発
    • ショートトレイン:1スプリントで完結する機能改善
    • ロングトレイン:顧客影響の大きい、複数スプリントのにまたがる機能改善
  • 意識している2つのこと
    • プロダクト品質のシェルパ
    • いいチームでいたい。「いいプロダクトはいいチームから」
  • スプリントプランニング
    • スプリントレビューで何を見せたいかをメンバー全員で認識を合わせる
  • デイリー
    • エンジニアがテスト設計、実施するためのガイド、E2Eのレビューなどなど
  • スプリントレビューの準備
    • メンバー全員でプランニングで決めた欲しいフィードバックからアジェンダを作る
  • スプリントレビューのFB郷友会
    • レビューで感じた雰囲気の共有、フィードバックからの改善を考える
  • ふりかえり
    • 積極的にチームのいいところを話す、困ってること、気になっていること
  • コミュニケーション
    • メンバー全員と1on1、飲み会など
  • テスト設計&実施(メイン業務)
    • ユースケース、負荷テスト、SLO、マニュアルテスト、バグバッシュetc
  • メンバーと勉強会
  • チームビルディング
  • プロダクト品質はみんなで向き合うと楽しい
  • そのためにプロセス品質(チームの品質)をよくする
  • がっつりテスト以外にも、いろいろやれることはあるかも

感想

意識している2つのことで上げられていた「プロダクト品質のシェルパ」「いいプロダクトはいいチームから」がよくわかる講演でした。コミュニケーションが生まれるよう仕組みづくりを楽しくされてるのがすごいと思います

「Struggling with Agile Testing, in Rakuten」

半谷 充生さん、中村 祐輔さん(楽天グループ)

  • サービス:R Messe
  • 半年でリリースできた
  • とある日、メール誤送信のバグが発生
    • 開発案件を全部止め、UnitTestを書く
    • トラブル減、リードタイプ伸びる、リリース頻度減
    • DevOpsのテストのような活動をしたいとQAに相談
  • 課題
    • QAは独立した組織、各サービスからテストの依頼が来る
  • 提案
    • ドメインナレッジを融資、開発・PdMと一緒に品質を向上させることができる人を置く
  • 採用活動
    • テストを自分で設計・実行できる。コミュニケーションが取れる、エンジニア経験があるetc
    • 攻めたサポートができるQAエンジニア
  • ShiftLeft活動からスタート
    • 仕様の検討段階からQAメンバーが入る
      • 仕様の不明点を聞く、他サービスの情報のシェア
    • 開発側のMTGに混ぜてもらう
      • Daily Huddleへの参加、トラブルのふりかえり
  • 開発とより近い距離でありながら、従来のQAプロセスに乗せる
    • QAから仕様不明点を確認することで認識合わせの機会になる
  • テストエンジニアの強みを生かす
    • 営業日・時間に合わせて応答メッセージを変える→テストエンジニアの組み合わせのナレッジ
  • 3amigosの導入
    • 役割分担 PdM、QA、DEV
      • コミュニケーションをとる、フィードバック
    • 開発段階での仕様・スケジュールに対する認識間違いが少なくなった
    • 気軽に相談できる関係性の構築

感想

推しQA」という言葉を流行らせたいです。開発のバックグラウンドを持つQAを採用してShift-Left活動しているのがいいなと思いました。組合せなどテストに関する知識を提供しているなどいい関係性ができているのも素敵だと思います。

ワーク

今年のメインワークは、「経路検索アプリがない世界で経路検索アプリをリリースするとしたら」というお題でユーザーストーリーマッピングを行いました。
参加者は4人程度のチームに分かれて、お題を進めていく形です。
ユーザーストーリーに使うチケットは実行委員によって既に用意されていました。オンラインの参加者はMiro*1を使って同じ付箋を見ながら話していきます。各チームはチケットの中から、1stリリースのコンセプトを達成するのに必要なMVP(Minimum Viable Product)、2ndリリースのコンセプトを達成するのに必要なMVP、をそれぞれ選んでいく形式で進めていきました。

感想

当初私のところの音声がうまく入らずチームのみなさんにご迷惑をおかけしました…。チャットとかも併用しつつサポートしてもらえてすごく助かりました(ユーザーストーリーマッピングのワークは練習とメインで2回できるようになってるたですが、1回目は音声いじっててあまり参加できてない…)
ユーザーストーリーマッピングは初めてやったのですが、MVPに絞るとかなりの機能がそぎ落とされることに驚きました。機能を入れる、入れないは付箋を見つつ議論していたので、基調講演で触れられていた「みんなで一緒に地図を描き、共通理解を作る」とはこのような感じかなと模擬体験できました。
他のチームの成果物も見られたのですが、リリースに最小限な機能ということで大きなずれはなかったものの、各チームで選んでる機能に少しずつ違いがあって面白かったです。

全体的な感想

オンラインでもオンサイトでも楽しめるように設計されていてありがたかったです。質問やリアルタイムの感想とかはDiscordでまとめてられてて、オンラインの参加者もみんなでワイワイやる感じが味わえました。
テーマである「アジャイルとテストと私たち ~明日「アジャイル」と言われたときに困らないためのヒント~」に沿って各講演やワークが進められ、「基調講演で言ってたこと、今ワークでやってるこのことかな?」みたいな繋がる感じもあってすごく楽しめました。
登壇者、実行委員、参加者のみなさま、ありがとうございました!

*1:アジャイル開発ツール用のテンプレートもある:https://miro.com/ja/agile/

城めぐり 北条氏の築城術の集大成・山中城と三島市内の北条氏関連史跡

お城好きには畝堀(うねぼり)・障子堀(しょうじぼり)で有名な山中城に行ってきました! 山中城の麓の三島市内でも後北条氏ゆかりの地を巡ってきたので旅の記録をまとめます。

山中城

お城の概要

バスは30分~1時間に1本くらいの頻度であり、バスですぐ近くまで行ける公共交通機関ユーザーにもやさしいお城です。
三島駅から行く場合は、三島周辺の観光に使える一日バス乗車券「みしまる切符」がお得でした(2023年3月現在)

見どころ

まずはお城の全体像はこちら。

要所ごとに案内図や説明の看板があって見やすかったです
西ノ丸

全体的に西側の防御にすごく力を入れて構築されています。有名な障子堀があるのもこちら。お時間あまりない方は西ノ丸を重点的に見ていくのがお勧めです。

障子堀!

区切られた区画の中に落ちた敵を上の西ノ丸から狙い撃ちにでき、畝(うね)の上にいる敵も進行方向が限られるので西ノ丸から狙い撃ちにできるという、非常に堅固な構造です。えげつない防御構造してるし、この城を一日で落城させた豊臣方の物量はさらにえげつないですね。

障子堀の実物を見るとかなりの急傾斜なので、一度堀底に落ちると這い上がるのは無理だと思いました。今では保護のために芝が貼ってありますが、当時は滑りやすい関東ローム層の土がむき出しだったそうです。

大雨の被害で一部崩落している箇所ですが、関東ローム層の土がむき出しになっている部分で往時がうかがえます。土がむき出しの部分はとてもじゃないけど登れる気がしない

西ノ丸に接する西櫓は角馬出になっており、攻撃に出るときの備えもされています。

看板の図と解説が分かりやすい

山中城は西側が駿河方面、東側が北条の本拠である小田原になります。基本的に西からくる敵に備えた構造で、西の三島市街が良く見渡せました。晴れてれば富士山もよく見えるはずです。

写真だと雲に隠れてあまり分かりませんが、富士山の裾野部分が見えてます
北ノ丸

こちらの見どころは、城内と城外を隔てる北の丸堀。当時の堀底は今より2メートル以上深かったそうです。埋まってる状態でも深さ5~6メートルはあるように感じましたし、角度も急峻。60~70度はあるんじゃないかな。土だけでこの急な堀を構築するのは見事な技術だそうです。ここをよじ登って攻めるのはほぼ不可能だったんじゃないでしょうか。

写真だと伝わりにくいですが、傾斜角度と高さがやばい

本丸との間には木橋が復元されています。現地の看板によると考証の元で復元されたものだそうです。本丸への経路はいくつかありますが、いざというとき壊して時間を稼げるように木橋になってるところが多いようです。二ノ丸から本丸への経路も確か木橋+土橋だったはず(現地で二ノ丸に行きそびれるという痛恨のミスをしたため、確認できていません)

右側が北ノ丸、左側のちょっと高くなってる方が本丸
本丸

山中城の一番重要な施設で一番標高も高くなっている区画です。本丸内にはさらに一段高くなっている天守台があります。櫓があったと考えられているけど、後世の植樹の跡により発掘調査では確認できなかったそうです。

天守台から本丸を臨む。本丸は何段かに区切られたかなり広い平地が設けられています。

本丸は広い区画があり、かなりの兵力を備えられたと思われます。建物の跡なども見つかっているそうで、山の中でこれだけの平地をよく整地できたなと思いました。障子堀のところでも思いましたが、結構な山ですし土木工事大変だったでしょうね。ほぼ人力(+牛馬)でよくこれだけのものを築いたものだと思います。看板の説明に合った出土品を見ると硯とか坏といった生活用品も見られ、ここで北条方の人たちが駐屯して生活もしていたことが窺えます。

本丸には兵糧庫、弾薬庫があったと伝承されているそうです。看板の後ろに見える溝は排水溝と考えられているそう
三の丸

現在こちらの郭跡には宗閑寺というお寺があります。ここの境内に山中城城主松田康長以下北条方の兵や、豊臣の先鋒一柳直末のお墓が祀られています。

宗閑寺

お墓の写真は撮っていませんが、新しめのワンカップなどがお供えされており今でも大切にお参りされている様子がうかがえました。

岱崎出丸(たいざきでまる)

本丸のある区画から旧東海道を挟んで南の方に伸びている出丸です。西ノ丸同様、三島市街地方面が良く見えます。

手前は畝堀、遠くに見えるのは三島市街、右の方に見える建造物はドラゴンキャッスルという巨大アスレチックだそうです

ここは畝堀が見事でした。たまたま何かの作業中だったらしく写真に梯子が映ってますが、見えている部分で11段あることからかなり深さのある堀であることが分かります。

かなりの急傾斜。60~70度はありそう

ここには造成工事中のままと思われる郭の跡もあり、急ピッチで豊臣方の来襲に備えていたけど間に合わなかった様子などもうかがえました。

案内所・売店

山中城跡バス停のすぐそばに案内所・売店があり、百名城のスタンプや御城印はこちらでいただけます。うどんやそば等の軽食も売っていて、名物の寒ざらし団子を食べてきました。障子堀の見た目でワッフルを連想される方も多いと思いますが、障子堀ワッフルという商品も売ってますw(中身は普通の美味しいワッフル)

草団子は甘めの味噌だれ、白いお団子は抹茶塩でした。抹茶塩、意外と団子にあう!素朴で美味しかったです

三嶋大社

伊豆国一宮で北条氏も尊崇していた三嶋大社にお参りしてきました。

ちょうど桜が見ごろでした

建物等に後北条氏の時のものはあまり残ってないのですが、宝物館で後北条氏が発給した書状が見られます。私が行ったときは鎌倉殿の特別展示をやっていて、鎌倉時代の北条氏の書状や源頼家直筆書状等も見られました。特に源頼家の直筆書状は現存しているものがほとんどないそうで、見られてラッキー!

名物の福太郎餅もいただいてきましたよ。

境内の売店でお茶付きでいただけます。上品な甘さで美味しかった

祐泉寺

Google mapで「北条新三郎の墓」と表示されていたのが気になって行ってみました。北条新三郎は北条早雲の孫(幻庵の息子)で、武田信玄駿河に侵攻したときに北条方の前線の城・蒲原城を預かって戦死したそうです。

祐泉寺の門前

私が行った日はお彼岸だったので、地元の方がお墓参りに来られていました。自分のところのお墓のついでかなにかで、北条新三郎のお墓にもお線香をあげていていらっしゃったのが印象的でした。もしかしたらゆかりの方かもしれませんけど、お墓とかが地元の方に大事にされてるのっていいなと思います。

案内板もしっかりある!

千貫樋

北条氏康が娘の早川殿が今川氏康に嫁ぐ際に、婿引き出物として作った用水路が千貫樋です。伊豆と駿河の国境である境川をまたいで、駿河方面の130haを潤しているとのことです。このエピソードを聞いたときに、娘の結婚祝いに土木工事して用水路プレゼントって、氏康公は娘を溺愛しているなあと印象に残っていたので、一度実物を見てみたかったんですよね。

千貫樋の説明

国境の川とあったので境川は広いイメージだったのですが、現在は住宅と住宅の間をひっそり流れている感じでした。この川は現在も三島市と隣の駿東郡の境界みたいです。人のお宅の合間から千貫樋をのぞいてきました。

人のお宅の間からのぞける千貫樋

ちなみに千貫樋は静岡県の土地改良施設一覧に現役で載っております。
東部地域施設概要:千貫樋|静岡県公式ホームページ


山中城以外は徒歩で巡れる範囲内にあるので、三島市内の湧き水とかきれいな川を堪能しながら史跡めぐりができて楽しかったです。

源兵衛川の遊歩道

JaSST'23 Tokyoに参加してきました(2日目編)

3/9(木)、10(金)で行われたJaSSTソフトウェアテストシンポジウム-JaSST'23 Tokyoに参加してきました!
2日目に聴講したセッションと感想をざっくりまとめます。

JaSSTのお供のコーヒーとさくらまんじゅう

「AIテスト自動化ツールの向かう先」

伊藤 望さん(MagicPod)
小田 祥平さん(mabl Inc.)
近澤 良さん(オーティファイ)
松木 晋祐さん(JaSST東京実行委員会)

テスト自動化の三世代

1. キャプチャリプレイ、画像認識
コードの自動生成による保守の煩雑さ、実行時の不安定性
2. UIオブジェクト(locator)、データ・キーワード駆動
依然として保守コストかかる。自動化に開発技術が必要になって人材難
3. AdutoDetect(locatorの半自動取得)、Self-healing
2の課題を解決。多量のテストレポートの仕分け、テスト実行時間の長大化

明日はどっちだ?

  • 自動修復の深化(locatorだけでなくコマンドの提案)
  • 「ChatGPT-Powerd」をうたう自動テストツールが登場する
    • AIが作ったテストケースをどうレビューする?
    • レビューするAが別で出てくる?(画像生成のAIだと生成するAIと、AIによる生成か判定するAIがあるらしい)
  • 非機能系への進出
  • Visual Regression
  • サービスのドキュメントをAIに覚えさせてそこからテストシナリオ作ってもらう
    • Autfyのヘルプページを学習させてテストシナリオ作ってもらったところ結構いいものを作ってきたらしい
  • AIは細かく指示をするとそれに合わせて出力してくれる
  • 人間が試されているw
  • 翻訳みたいに、機械翻訳→おかしいところだけ人が直す、みたいな流れになるかも?
  • 自動テストケース生成がくるか!?
  • monitoringとtestingのオーバーラップ
    • 本番環境でテストツール動かすとか
    • datadogもE2Eテスト領域に参画している
  • テスト自動化領域はまだパイの奪い合いをする段階じゃない

感想

未来の話を聞けてよかった~! 人間はAIに分かりやすい指示を出して生成されたケースの選択とか修正だけするようになっていく未来になるのかなあとワクワクしながら聞いてました。discordでのありましたけど、これ毎年やってもらって定点観測したい!

「シフトレフトの失敗事例から学ぶ次のアプローチ」

高橋 信弘さん(AGEST)

シフトレフトできていますか?

シフトレフト:早いダニあkで欠陥を見つけるために静的テストと動的テストの両方を開発ライフサイクルのなるべく早い時期に開始すべき

シフトレフト導入施策

課題
大規模な現場
テスト観点が不明確
異なるテストを実施
テスト関連資料が多数

施策

  • テストフェーズごとの観点整理を実施(成功)
  • QAによる仕様レビュープロセスの導入(成功)
    • 参考にされた論文

https://www.juse.or.jp/sqip/workshop/report/attachs/2011/SQiP3-1.pdf

  • GQM法による品質特性ごとのメトリクス設定(失敗)
    • 参考にされた論文

鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア…

      • 導入後のイメージの共有不足
      • 対象範囲が広かった
      • マネージメント層とリーダ層の齟齬(マネジメント層の承認が通らなかったため導入失敗)

よりよいシフトレフトを求めて

にしさんの資料
What should you shift left

  • 従来も「目的」はたてて、「方法」も検討していたが、「共に考える」発想がなかった
  • 開発者とのコミュニケーション
    • 開発テストの最適化
  • モブテストの導入

全員参加で品質を向上していく!

感想

実際の例を紹介いただけて面白かったです。discordでもGQM法に皆さん興味はあるけど使いにくさを感じてるんだなというのが分かりました。個人的にもゴールと問いの設定が難しいと感じてます。質問でもGQM法大人気でしたw

「テストウェアのデータモデル」

朱峰 錦司さん、鈴木 一裕さん

お二人の資料

speakerdeck.com

speakerdeck.com

利用者側の目線

スプレッドシートテスト管理ツールの比較

資料が素敵すぎるのでそちらを見てくださいw

課題:解決策が見いだせない系
  • テストケースの単位とグルーピング
    • 一覧性の低下 → スプレッドシート側で解決できる?
    • 保守性の低下 → データ駆動の機能サポートで解決できる?
  • テストモデルとの相性
    • 記法が定義されたモデル 専用ツールで生成したテストケースを管理ツール側に移すとトレーサビリティがおちる
    • 記法が定義されてないモデル マトリクスで管理したいやつなど不便
課題:ベストプラクティス集めたい系
  • テストケースの管理構造
  • テスト実行のステータス
    • 成功を期待できないケースが増えてくると事態が複雑化する(今期では直さないバグなど)
  • 情報のトレーサビリティ
    • トレーサビリティ情報をどう役立てるかはあまり語られない
    • 自分たちにとって「どの情報に価値があるか」考えよう

提供者側の目線

テストケース管理の二大流派
  • チケット型(TestRailとか)
    • 基本的にツールの方で属性=フィールドを縛っている
  • スプレッドシート型(Quality Forwardとか)
    • 列の定義を自由にできる

※個人的には日本発のはスプレッドシート型が多いなーと思ってます

グルーピング
  • お好きに(入れ子あり)フォルダ構造で
  • 「テストスイート」という一段階の縛り
一覧性について

WebのUX/UIの世界
一覧の参照時に個々のケースまで見たいか?

テストモデルとのトレーサビリティ

前提:強いトレーサビリティは無理ゲー
弱いトレサビが無難と考えられる

管理構造の考察

観点とか目的でタグを絞り込む

実行

ケースと実行が1:1、1:Nなど

感想

実行委員から「骨太」なセッションをしてくれとの要望で企画されたセッションだそうですが、マジで骨太でした! テストケース管理ツールのタイプから課題、それに対するツール提供側がどう考えてるかを聞けてよかったです。

「特徴の異なる複数の自社プロダクトの品質への向き合い方を、ワイガヤします」

荒川 健太郎さん、伊藤 潤平さん、坂口 祐樹さん、山﨑 友藤さん、吉田 千鶴さん(ウイングアーク1st)

QAのコミュニケーションを活性化する話

課題

  • JIRAだけでチケットの管理を行おうとすると課題がある
    • 時間がたつとサブタスク側で情報が更新されず、正しい情報がフィルタで出てこない
    • チケット数が多くなるとJIRAフィルターだと一覧性が低くなってしまう

→MotionBoardに連携させて、親とサブチケット一覧で見られるようにしている
 dejiren(チャット型iPaaS)のバーチャルアシスタントを介してboardの情報を得られる
 チャットで情報が取れるのですぐコミュニケーションが取れる!
 

開発のプロセスで品質を作りこむ話

前提
開発が中でテストをして、QAが後からレビューする

課題
成果物に対するレビューを行うため、どうしても後からの指摘となってしまう

解決
テスト計画:全員に共有して常にだれもが見れる状態に
dejirenにアップしてinvoiceAgent(文書管理ツール)に接続

テストや業務の効率化の話

検証観点のテンプレート化
→新規で作成されるときにも半自動で反映できるように!

感想

自社プロダクト囲みながらわいわいやってるのが、チームの雰囲気がうかがえて良かったです。自社プロダクト使い込んでるのもいいなー。

「本の品質はどのように作られるのか ~プロマネとして書籍編集者がしていること」

傳 智之さん(技術評論社

品質の高い本≒いい本
「ためになる×お金ぬなる」の最大化を目指す

1. 価値の源泉を探す

  • 企画を決める
  • 「作るべき品質」を決めるのは難しい
  • ネタを探すな、人を探せ
  • 方向性を共有する、ただし共有できたと思っても後から食い違いが起こることも
  • 「はじめに」を最初にまとめて羅針盤/基点にする
  • 小さく試せる場を作る(Webで連載してみる)

2. 時間とコストと向き合う

  • 時間とともに品質は変わる 「一番乗り」は大事な品質になりうる
  • 「いつ出せるか?」が不確実な場合も 
  • オンリーワンに賭ける
  • 割り切ることで陳腐化を最小限に
  • タイミングが来るまで待つ
  • ゆとりを作るためにプロジェクト(企画)を増やす 利益の出る企画と利益的には微妙なチャレンジングな企画を組み合わせる

コンテンツを磨く

  • 「引き出す」の限界 ないものは引き出せない
  • 客観性wピ指揮したうえで主観を恐れず捉える
  • 特徴を浮き彫りにする10の質問
    • 理解のためにどこに注目すべきか
    • どこから始めればいいか
    • 最低限抑えるべきことは
    • 覚えやすくするには
    • やらないことは
    • 何が厄介なのか
    • それでどうよくなるのか
    • なぜそうなっているのか
    • ほかのやり方ではだめか
    • トレードオフをどうするか
  • 流れを意識して構成を考える
  • ドラえもんメソッド
  • 目次の演出を考える
  • 「わかりやすい文章」の品質基準(ルール)を守る
  • 欠陥をどこまで減らせるか
  • 校正あるある 何やっても見逃すときは見逃す…
  • 修正の落とし穴 修正すべきところの見逃しや修正自体の間違いを見逃す
  • バイアスを意識してゆとりをつくる
  • レビューをお願いするときの注意点 心理的安全性が保たれる方に依頼

魅力を伝える

  • 品質が意味を成すまでのプロセスにかかわる
  • タイトルの要件 読みたくなる、知ってもらいやすい
  • なんのためのデザイン?
  • 最適な版型を選ぶ (四六と呼ばれる版型は出版社によって大きさ違うらしい)
  • ページごとの見せ方・情報量を決める
  • 紙を選ぶ 本文用紙
  • 全体最適となる価格を考える
  • プロモーションを検討する
  • 営業を支援する

価値を育てる

  • アップデートで実績を延ばす
  • 改定+さらに変化を付けて売り伸ばしにつなげる
  • 点を面に展開する 本格入門シリーズ
  • 本ではないプロダクトへ
  • 「なんでPC書じゃない本を作ってるの?」 PC書の棚では届かない読者および著者にリーチする
  • 小さな挑戦、1つの出会いから「相互理解で広がる世界」へ

感想

本を作ることについて、ソフトウェアとの共通点や比較などを交えて話してくださってとても興味深かったです。本好きなのでこういうお話聞けるの楽しい!
JaSSTの翌日用事があって本屋に行ったのですが、タイトルのつけ方やレイアウト、カバーの紙などの観点が加わって、棚を見るのがいつもより楽しかったです。

全体的な感想

セッションはここに独立してますが、JaSST全体のテーマに沿って「あ、これ前聞いたセッションとつながるところあるな」という感覚がありました。discordでわいわいできる感じもあって一緒に見てる人とのライブ感も味わえてよかったです(来年はオフライン会場もあるとより嬉しい)
今年も楽しくてためになるJaSST Tokyoをありがとうございました!

JaSST’23 Tokyoに参加してきました(1日目編)

3/9(木)、10(金)で行われたJaSSTソフトウェアテストシンポジウム-JaSST'23 Tokyoに参加してきました!
今年のテーマは「相互理解で広がる世界」。カオスエンジニアリングの話から未来の話まで聞けて面白かったです。聴講したセッションと感想をざっくりまとめます。

「Chaos Engineering to Continuous Verification」

Casey Rosenthalさん(Verica)

初期のネットフリックスはサービス品質が悪かった
→当時のクラウドインスタンスは時々予告なく落ちていた
 意図的にインスタンスをシャットオフする。上手くいったので徐々に拡大 Chaos.com
 
エンジニアは自分のマイクロサービスとその両隣は分かっている。
チーフアーキテクトはいない
→CHAP(カオスエンジニアリングのチーム)を作って対処

What could go wrong in a complex system?


Game Day:システムに悪いことが起こったときにどうするか考える日

問題
とあるサービスでStagingのkafkaを止める
→Productionが止まった!

原因:staginの構成をコピーしてprodを作ったときに書き換え忘れてstagingのkafkaを見に行ってる部分があった

Game Dayでエンジニアが集まっていたのですぐに直せた(Game Dayでまだよかったとはいえ現場は阿鼻叫喚だったのでは…)

Verica社のopen incident database

https://www.thevoid.community/www.thevoid.community


間違った神話1「医療過誤を起こす人を首にすれば医療過誤は減るのでは?」
→No. スキルのある人たちがリスクの大きい可能性が高いものに対処した結果医療過誤が起きていた
 医療過誤を起こした人を首にした結果、より低スキルの人が対処することになり医療過誤が増えた
 
間違った神話2「ドキュメント通りにやれば問題はない」
→No. 致命的な問題はユニークなものが多い

間違った神話3「以前の根本原因から防御する」
→No. 気を付けていても人間はミスをすることがある。直接ミスを起こした人ではなく仕組みとかの問題(ここ理解合ってる?)
*1

間違った神話4「信頼性を定量的に測定する」
→No. 特定のインシデントがどのくらい悪いかなどは分からない

間違った神話5「リスクを避ける」
→No. 経験が蓄積されない

間違った神話6「シンプルにする」
→No. 機能を追加する=複雑になっていく

間違った神話7「冗長性を追加」
→No. 冗長性を加えたことでかえってダメになったことがある

エンジニアは経済性、安全性、負荷の3つの観点

カオスエンジニアリング

実験を促してシステムの弱みを認識する

複雑性に対する経済的な柱 1910年代のフォードの例
 関係の制約:ライン生産方式
 環境:鉄道より道路を整備して車が売れやすくした
 可逆性:フォードの例だとここはできていない。ハードが絡む部分は時間が必要なので難しい。
 

  • Software Engineering:the Reversibility Profession
  • CI/CD/CV
    • CV(Continuous Verification)システムが望んだ通りのふるまいをしているか確認する

感想

複雑なものをシンプルにできればいいのだけど、もうある程度複雑なまま扱わなきゃいけないからどうすればいいか、を考えるヒントが聞けて良かったです。間違った神話3で理解を間違えていたのだけど、他の参加者の方から補足いただけたり、質問も拾ってもらえて助かりました! 

MBTで目指すこれからのテストづくり」

須原 秀敏さん、蛭田 恭章さん(ベリサーブ)

MBT(モデルベースドテスト)とは

 テスト設計を自動化する技術。モデル(形式化された仕様)を入力して決められた変換ロジックを使ってテストケースを生成する

メリット
  • 説明性:どうやってそのテストケースが生まれたかを説明できる
    • トレーサビリティ:MBTモデル(or開発モデル)からテスト家素へのトレースが撮れる
  • テスト設計の品質向上
    • モデルを書ければ誰でも同じテスト設計が再現できる
    • 過去の欠陥を再発させないためのテスト設計の改善が実現できる
  • メンテナンスコスト
    • 単一のメンテナンスポイント
  • アジリティ
ベリサーブさんにとっての意義

MBTパターンを蓄積して再利用することで、テスト設計の知恵が「ちゃんと」たまる
MBTによりテストプロセスをデジタル化し、コアなデータを再利用可能にする
 特性が明らかになっている場合、MBTパターンを適用できるかできないかの選択と判断

GIHOZとの関係

 GIHOZは限定された(&非常によく使われる)MTBパターンを使いやすくするツール

TREES(テスト観点DB)

 テスト観点の進化系がMBTパターン
 (テスト観点はモデル化しきれてないMBTパターンの素みたいな感じ)

MBT実践事例

MBTをする上で大事なポイント

MBTモデル設計やテストケース生成に必要な知見を再利用可能な状態で形式知化することが大事

知見を形式知化するアプローチ

テスト設計者が持つ知見の取り込み
例:WebAPI仕様
 仕様はSwaggerにより形式化かされていた。以下の手順でパターン化
1. テストケースの収集
2. 仕様の確認
3. 暗黙的な仕様の確認 例:パラメータ間の大小関係
4. 暗黙的な仕様のパターン化

過去不具合から得た知見の取り込み
事象:不揮発性メモリの信頼性の問題でデータ欠損、データ読み込み処理に失敗し遷移不可になった
解決策:遷移の確率モデルを組み込む

質疑応答(メモできたところだけ)

Q. 「MBTパターン」以前に「MBTモデリング」が重要だと思うけど、なぜ「MBTパターン」なのかな? どういうモデルがあればよいのかを先ず追求すべきでは? もうすでにモデルは十分あるという認識?
A. どういうMBTパターンを適用すべきか(テスト戦略)
 →こういうモデルを書くべき(モデリングガイドライン
 
Q. パターン増えていきそうですが、ある程度増えると選ぶのも大変では? ドメインが異なると適用可能かの判断が難しくならないか?
A. 抽象化する。どういうモデルの特徴があって、どういうパターンにするかの順になるのでそれを選べる形にしたい。数は増えていくので解決を模索中

感想

これからのテスト設計のお話を聞けた気がして楽しかったです。こちらでも質問拾ってもらえて助かりました。

「カオスエンジニアリングの裏話」

堀 明子さん、松浦 隼人さん(オーティファイ)

基調講演のCaseyさんが書かれたこちらの書籍の翻訳の裏側のお話です。

注目したワード

  • テスト VS 実験
  • 妥当性確認 VS 検証
  • 定常状態
  • 影響範囲

Unknow unknownsに対処する

Known knownsはテストなどで対処、Unknown unknownsはカオスエンジニアリングで対処

  • 妥当性確認(validation)
    • 個々の要素が期待通りに実装されていることの検証に重きを置く
  • 検証(verification)
    • ビジネスケースと総合的な出力に重きを置く

Unknow unknownsに対処する

Known knownsはテストなどで対処、Unknown unknownsは実験、カオスエンジニアリングで対処

カオスエンジニアリングの発展原則

カオスエンジニアリングの原則 - Principles of chaos engineering


1. 定常状態(Steady State)に関する仮説を立てる
2. 実世界の事象を多様化させる(Vary:ハイレベルな変数を変化させる)
3. 本番環境で実験する
4. 継続的に実行できるよう実験を自動化する
5. 影響範囲(blast radius:爆発半径)を局所化する

感想

カオスエンジニアリングをがっつり解説してもらって、基調講演の内容の理解が深まりました。本買います!

「ローカル環境を用いたアジャイルテスティングの実践事例~より高速なフィードバックを目指し~」

村岡 里紗さん(freee)

問題:環境的なハードルがあり、QAエンジニアが気軽に変更を確認しに行くのが難しい

講演での「ローカル環境」の定義:画面や主要機能が動くかどうかを確認するのには足りる(パフォーマンスや構成は本番同等ではなくシンプル)
環境の制約なくできたところからテストしていける

実践事例

0. 可能な限りすべての情報をキャッチする(仕様決めのMTGにはすべて参加する)
1. テスト内容はチーム全体で合意をとる(リスク洗い出し会を行う)
2. 探索的にテストをしていく
3. 必要に応じて自動テストを追加し、今後のデグレに備える

効果

全体の約50%のバグが通しテストの前に発見される

課題

  • 実践できているのは一部にとどまる
  • 立ちはだかる「操作知識」という壁 立ち上げは容易だが、拡張するにはひと工夫必要
  • 適材適所の使い方をする必要がある ローカル環境でできないテストもある
  • 開発チームとの関係性が大切

感想

課題感持ってるところが非常にあるあるで共感しながら聞いてました。Discordも盛り上がっていて楽しかったです。ローカル環境でテストしてるうちに副次的にドメインの知識も深まってる点も良さそうと思いました。

「ロケーターを学んでテスト自動化上級者を目指そう」

伊藤 望さん(MagicPod)

ロケーター概要

WebページのUIの各要素は裏でエンジニアがシステムIDをつけている
が、システムIDがなかったりする場合もあるので、その場合は要素の順番とかで指定している

HTML概要

  • 「タグ名」で要素の種類が分かる(inputやbuttonなど)
  • 「属性」で要素の各種情報を指定(nameとかidとかplaceholderなど)

ロケーター文法解説

トラブルシューティング

初級編

問題:見た目上ボタンがあるのに、E2Eテストで「見つからない」エラーで落ちる
原因:見た目は変わってないけどidが変わっていた

上級編

問題:xpathで要素を指定しているテストが落ちた
原因:画面に文言が追加されたことにより、HTMLの構成がちょっと変わりxpathが変わっていた

ロケーターの使い分け基準

よいロケーター=メンテナンス性が高い=画面の変更が入っても影響がない
data-testidのようなテスト専用のものを振ってもらうのが推奨

感想

ローコードのE2E自動化ツールを触ってるけどHTMLの知識は少ない人にぜひ聞いてほしい内容でした。資料は後日公開いただけるとのことで楽しみにしています!

結合テストの自動化にQAはどうかかわっていったか」

永田 敦さん(サイボウズ
Before:手動テストがメイン
新規チーム:自動テストをメインにする

  • 方針 テスティングトロフィーにする(結合テストメイン)
  • 何が自動化できて、何が自動化できないのかのテスト設計の議論
  • より適切な場所、レベルで、テストを行う
  • 開発者、QAのテスト設計の議論により
  • 感謝の仕組みによってWhole Teamの実感が回っていく

感想

開発とQAの議論でよりよりテストができていくのが素敵でした。QAがテストコードも各チャレンジしているのがすごいですね。

「QAでE2Eテストを普及させるには?」

田中 龍一さん(freee)

E2Eテストの勉強会開催、成果

何をしたいツールなのかの説明からPullRequestのレビュー方法の説明まで行った
コーディングに興味を持ってくれる人が増えた

工夫

  • 参加メンバを第一陣、第二陣に分けた(前提知識があったりフィードバックよくくれる特性の人が第一陣)
  • 自動テスト何でも相談所を週一で開いた
  • 勉強会を行うメンバーが同じプロダクトのメンバーであること(具体的なアドバイスがしやすい)

感想

勉強会に色々工夫されてるのが素敵でした。特に参加メンバー第一陣にフィードバック積極的にくれる人としている点は、うちでも真似させてもらおうかなと思いました。

「開発とQAの垣根を越えるチームへ ~お互いを活かし合うWhole-teamアプローチ~」

SigSQAの皆様

ラーニングアウトカム

  • スキルや知識を【つくり方・進め方の知識・経験】と【バグ・トラブル・失敗】の2つの方向性で捉える"QMクリスタル"
  • どのようなスキルや知識、経験をシフトレフトすればよいのか
  • 本年度の課題感
    • 実際の現場においてより良い開発を行うためには、開発者、PO、PM等とどのように相互理解してチーム一丸となる進めるか

Whole-Team Approachとは何か

プロジェクトを成功させるために必要な知識とスキルを持つすべての人を巻き込むアプローチ

役割が異なる人たちの間にも、役割が重なる部分を意図的に設計。職種間で役割・責任を共有している

  • プロダクト開発へのチーム全体アプローチの紅葉
    • チーム内のコミュニケーションと協調が強化される
    • 品質を全員の責務にする
  • QAしてのWhole-Team Approach
    • チームで品質保証をするためにテストを見直す

QAクリスタルとは何か

  • QAチームの知識・経験、開発チームの知識・経験
  • 開発とQAが互いの得意分野を分かっていく感じ

パネルディスカッション

  • 仕様確定後の共有MTGにしか呼ばれなかったのを検討MTGから入っていくようにした
  • ハード3S(Strategy、Structure、System)はMECE向き、ソフト4S(Shared value、skill、staff、style)は被りが大事
  • お互いの視点を聞く
  • チームのバグ
  • 面倒くさいの言い訳にスキルがないを使う説
  • 青いクリスタルと赤いクリスタル(QAと開発のそれぞれの経験、知識)が自分の会社ではどんな感じになるんだろうを考えるのが一歩

感想

Discordの流速がものすごくて楽しかったです。「面倒くさいの言い訳にスキルがないを使う説」とかちょっと耳の痛いコメントもあり、面倒くさいをどんどん倒していかなきゃなーとなりました。

全体的な感想

「相互理解で広がる世界」のテーマの通り、QAが(少なくとも私は)あまり踏み込んでこなかったカオスエンジニアリングを詳しく紹介していただけて面白かったです。予測できないことを、コントロールできる範囲でどう試していくか、みたいなのが今から必要になってくるんだろうなあ。まだまだ知識が足りてないので勉強しなくては!
情報交換会で、基調講演のグラレコ見ながらわいわいできたのも面白かったです。グラレコ本当に素敵でしたので貼っておきます!

*1:※discordでKTさんから補足いただきました Verica - Inhumanity of Root Cause Analysis 「根本原因=ミスをした人を特定して気を付けてもらう」ということを指しているそうです。 日本的な感覚だとそれは根本原因としちゃいけない奴だろうと思っていたので混乱しました。

史跡めぐり 平泉~衣川、つわものどもが夢の跡(2)

JaSST Tohokuへ行ったついでに平泉、衣川へ行ってきました。ちょうど今年は大河ドラマでも平泉が出てきたこともあって一度訪れてみたかったのです。せっかくなので一日がっつり観光してきました。むしろ一日では足りなかったので再訪したい。

中尊寺

有名な金色堂のある中尊寺にも参拝してきました。参道沿いにあるお堂にお参りしながら月見坂を上っていきます。そこそこ長い坂なので、熱い時期はつらいかもしれません。タクシーだと坂の上にある金色堂のそばまで上がれるという話を聞いたので、体力に自信がなかったり気候がイマイチなときに行く方はタクシー利用が良さそうです。

月見坂。道沿いの木が立派

お堂色々

初めての中尊寺ということもあって、月見坂沿いに点在しているお堂やビューポイントを巡りながら登ることにしました。

月見坂沿いにある弁慶堂。他にもお堂がいくつもあります。
弁慶堂のあたりから見た風景。北上川とそれに注ぐ衣川が見えます。衣川は水面見えてませんが文字を付けたあたりから北上川方面に伸びてる緑のラインが川の土手です。
弁財天堂。黄色のあやめが咲いていて綺麗でした。もみじの時期も美しいと思う。

讃衡蔵

往時は大伽藍だったそうですが当時のものの多くは焼失しており、建立当時から現存する建物は金色堂と経蔵のみになります。ただ、寺宝のいくつかは今も伝えられており、一部は中尊寺の宝物館である讃衡蔵(さんこうぞう)で拝観できます。私が行ったときには、古くから伝わる仏像とか、中尊寺経という名前でも知られる紺紙金銀字交書一切経などが展示されていました。
当時から伝わる品々は本当に贅を尽くしたという感じでした。平泉のガイダンスセンターで藤原清衡の生涯と中尊寺建立の願文に触れていたので、月並みな感想ですが、彼が平和を祈って本当にできる限りのことを中尊寺に注いだのだろうなということが窺えました。

金色堂

藤原清衡が一番力を入れていたのではないかと思うのが、やはり金色堂です。

金色堂。内部は撮影禁止なのでここからのアングルのみ。

お堂の中に入ると、ガラスケースの向こう側に金色堂が見えます(仕方のないことなんですが、ガラスケースの向こうにあるとどうも「展示品」っぽく見えてしまう)とはいえ、建物全体が金箔に覆われ、内陣も金箔や蒔絵、螺鈿で飾られて贅を尽くしたものでした。讃衡蔵で読んだ解説によると、螺鈿に使われる夜行貝は沖縄あたりで採れるものだそうなので、奥州藤原氏が独自の交易ルートを持っていたことが分かるそうです。
奥州藤原氏三代の遺体と四代目泰衡の首級もこちらに安置されています。金色堂は一度訪れてみたかったところなので今回訪問できて本当に良かったです。

経蔵

金色堂と並んで建立当時から残っているのが経蔵です。往時はこちらに「中尊寺経」が収蔵されていたそうです。

経蔵。静かな佇まいがきれいでした。

覆堂

かつて金色堂を覆うために建てられたのが覆堂(おおいどう)です。(覆堂が建つまでは金色堂がそのまま風雪にさらされる形で立っていたのもすごい気がします。金閣寺のような感じだったのでしょうか)金色堂の保護という役割から内部に柱がない独特の構造となっているとのことでした。

覆堂は人が多くて正面の写真が撮れなかったので、松尾芭蕉銅像と覆堂側面の写真です。

平泉文化遺産センター

中尊寺から毛越寺への近道の途中にある文化施設で、敷地内には蔵王権現堂の跡と伝わる花立廃寺跡もあります。

この下に花立廃寺の遺構が埋まっています。

展示内容はガイダンスセンターと重複するところもありますが、こちらでは中尊寺ハスの剥製が見られます。

中尊寺ハスの花

中尊寺ハスは奥州藤原氏の四代目・泰衡の首桶の中に収められていたハスの種を、研究者の方が時を越えて発芽させたものです。800年前の種を発芽させられるのすごいですね。
泰衡の首に誰がどんな思いでハスの種を供えたのか想像すると色々なドラマがありそうです。結果的に泰衡の代で奥州藤原氏が滅亡してしまったので当主としてはあまりよい評価はされてないように思いますが、ハスの種を供えて先祖代々の傍に葬ってくれた人はいたということですよね。
中尊寺ハスは一度実物が咲いているのを見てみたいです(しかしハスの咲く時期は暑いのがネック)

無量光院跡

無量光院は奥州藤原氏三代目の藤原秀衡が建立した寺院です。往時は宇治の平等院鳳凰堂を模したお堂が建っていたとのことですが、現在は池のみが復元されています。平泉の信仰の山である金鶏山がちょうど西の背後になるよう建てられており、西方浄土を表したものだったそうです。
ここは午前中に立ち寄る予定だったのが、ルートを間違えて午後3時頃に訪れました。結果的にちょうど西に日が傾きだした時間帯になり、西の金鶏山から光が差してくる形になってよい雰囲気でした。たぶん夕方日の沈む時間帯に訪れると綺麗だと思います。

無量光院跡の復元された池。逆光気味ですが、金鶏山方向にかかる雲とその向こうの太陽で雰囲気のある写真になった気がします。

観自在王院

観自在王院跡は奥州藤原氏の2代目・藤原基衡正室が基衡の死後に建立したお寺です。現在は残っていませんが、舞鶴が池を中心にお庭が復元されています。平安時代の御庭造りの教科書『作庭記』によると「池は鶴か亀の形に掘るべし」を基にしたと考えられているそうです。

南門跡。写真で見えている範囲はほぼ観自在王院の境内にあたります。広大!
舞鶴が池。ちょうどお花が咲いていて優美な雰囲気でした。

毛越寺

毛越寺藤原基衡・秀衡が建立したお寺で、観自在王院の隣にあります。夫の基衡が建立した毛越寺の隣に、彼の死後正室観自在王院を建立したという時系列だそうです。建立当時から残る建物はありませんが、毛越寺庭園、特に大泉が池とそこに注ぐ鑓水は平安末期の浄土庭園の姿が良好に残っているのだとか。

毛越寺本堂
池。海岸線の荒々しいあたりを模したもの(だったと思います)
池に注ぐ鑓水。蛇行していたり急流と緩やかな流れがあったり、『作庭記』に記された技法が使われてる様子をそのまま見ることができる。曲水の宴も催される。
池に浮かぶ龍船。右のあたりは州浜といって海の波の緩やかなあたりを模したもの
常行堂。青モミジが綺麗でした。

義経公妻子の墓

ここは行こうかどうか迷ってたのですが、毛越寺を見学し終わった後まだ時間があったので「よし、行けるぞ!」ということで行ってきました。平泉の信仰の山である金鶏山の中腹にあります。けっこうな坂道を上るので電動アシスト付き自転車じゃなければ多分諦めてました。

金鶏山登山口

金鶏山への登山道入り口近くに小さなお墓が二基あります。そっと手を合わせて参りました。

ひっそりたたずむ義経公妻子のお墓

少しだけですが山の中に入るので、日の高いうちに行くのがお勧めです。

おまけ

ランチ@Cafe SEKIMIYA

お昼はネットで調べていたCafe SEKIMIYAさんへ。ちょっと路地を入ったところにある静かな雰囲気のカフェです。岩手のブランド豚である佐助豚を使ったメニューがあるとのことでこちらにしました。お肉は柔らかく、付け合わせの野菜も美味しかったです。

佐助豚のポワレがジューシーで美味しかったです。こちらのほかにスープ、デザート、ドリンクがついて1,300円でした。

こがね屋菓子店

駅からちょこっと歩いたところにあるお菓子屋さんです。入って正面のショーケースは洋生菓子が並んでますが、お土産にできそうな和菓子もあります。今回は一音(いっとん)という和菓子を購入しました。胡麻がたっぷり乗った焼餅に、平泉らしく金粉があしらわれています。上品な甘さで美味しかったです。

一音の外袋
焼餅の上に胡麻がたっぷり、写真ではちょっと分かりにくいけど金粉もあしらわれています。

史跡めぐり 平泉~衣川、つわものどもが夢の跡(1)

JaSST Tohokuへ行ったついでに平泉、衣川へ行ってきました。ちょうど今年は大河ドラマでも平泉が出てきたこともあって一度訪れてみたかったのです。せっかくなので一日がっつり観光してきました。むしろ一日では足りなかったので再訪したい。

平泉駅

駅前にレンタサイクル屋さんがあるので、一日予定でレンタルします。こちらでは自転車借りたら手荷物は無料で預かってくれます。これを知らずにコインロッカーに預けてしまった。。。
普通の自転車と電動アシスト付きのものが選べますが、体力に自信のない方は無理せず電動アシスト付き自転車を借りるのがお勧めです。平泉中心部以外にも足を延ばす予定があったり、中尊寺から毛越寺へ近道を通る場合には結構な坂道を通ります。

この日一日お世話になった電動アシスト付き自転車。とてもアシストしてもらった。

伽羅御所跡

まずは平泉駅にほど近い伽羅御所跡へ。こちらは現在住宅地になっていますので案内板くらいしかありません。

伽羅御所跡の案内板

柳御所跡、平泉ガイダンスセンター

案内板を通過して柳御所跡と平泉ガイダンスセンターへ。

ガイダンスセンターの裏側の外観(表の道路側からの外観は撮り忘れました)

こちらで平泉の歴史の概要が学べます。施設も新しくきれいで、入館料無量、なんと音声ガイドも無料で貸し出していただけました。出土品の展示や映像資料も充実してて一時間くらい見いってしまいました。
私は源義経から平泉に興味を持ち、それ以前の安部氏や藤原三代にはあまり詳しくなかったので、こちらで平泉の歴史を学べてよかったです。

特に奥州藤原氏の初代である藤原清衡については知っておくとよいと思います。

清衡が建立した中尊寺の願文の中に建立にかけた思いを想像させる一節があるので、長いですが引用します。

この鐘の一音が及ぶ所は、世界のあらゆる所に響き渡り、苦しみを抜き、楽を与え、生きるものすべてのものにあまねく平等に響くのです。(奥州の地で は)官軍の兵に限らず、エミシの兵によらず、古来より多くの者の命が失われました。それだけではありません。毛を持つ獣、羽ばたく鳥、鱗を持つ魚も数限り なく殺されて来ました。命あるものたちの御霊は、今あの世に消え去り、骨も朽ち、それでも奥州の土塊となっておりますが、この鐘を打ち鳴らす度に、罪もな く命を奪われしものたちの御霊を慰め、極楽浄土に導きたいと願うものであります。

中尊寺落慶願文 より現代語訳版をお借りしました)

藤原清衡は結果的に最後まで生き残ったことで、その過程で色々見たり、どうしようもなく飲み込んだことなどもあったのだろうなあと思われます。願文はもっと長いのですが、個人的にこの部分が一番言いたいことだったのではないかと思っています。ガイダンスセンターでは、この願文の解説のほかにも藤原三代をダイジェストで紹介する映像資料などもあり平泉を巡る予習にばっちりです。

また、ガイダンスセンターのすぐそばの柳の御所跡は柱の跡とかがほとんどなので、ここの解説で当時を想像するヒントになります。
さて、予習を終えてガイダンスセンターの裏手に出ると、そこから柳の御所跡が広がっています。堀や建物の柱跡が復元整備されており、大変広大で当時を偲ばせます。

復元された堀。水のない空堀だったそうです。
中心建物と考えられるあたりの柱跡


御所の池の跡も復元されていました。

池の跡。ガイダンスセンターで見た情報によると池は改修工事があったらしく、復元されているのは初期のバージョンの池だそうです。

ちゃんとごみ処理施設、穴掘って埋めただけのものだけど、もあって、ここで生活していたんだなーという妙な感慨がありました。

汚物廃棄穴群。分かりやすく復元されているのは4つですが、もっとあったらしいです。

高館義経

源義経最後の地・高館があったといわれるところです。北上川を見下ろせる高台の上にあり、小さな資料館と義経堂があります。松尾芭蕉の「夏草やつわものどもが夢の跡」という句でも有名な場所で、句碑もありました。

義経の木像が祀られてるお堂
高館から眺めた北上川。「夏草や つわものどもが 夢の跡」

義経最後の地がどこかは確定してないらしいのですが、ここの高台は館を建てるにはあまりスペースなさそうに見えました。(個人的には、この後にめぐった接待館の方が何となくそれらしい気がします)

衣川地区 接待館

平泉から衣川を越えて衣川地区に向かいます。衣川という地名について深く考えたことはなかったのですが、衣川という川があってその川が流れているあたりの地名も衣川というようです。衣川(川の名前)を挟んで南側が平泉、北川が衣川地区となっています。

衣川(川の名前)。奥の方に見える山には5月末でまだ雪が残っていました。

衣川を越えてから、しばらく衣川沿いに自転車を走らせると接待館跡に着きます。一見すると普通の野原のように見えるので、案内板がなければ見過ごしそうになります。

接待館跡の案内板。発掘で明らかになった内容が解説されてます。

案内板によると、発掘で土塁や宴会に使う「かわらけ」が大量に出土し重要な施設だったことが分かったとのこと。今は見学しやすく草は刈られていますが野原になっているので、ここでも兵どもが夢の跡感を味わえます。

案内板の背後に一段高くなってる部分がありました。発掘終わった後に保護のため埋めた?
この下に接待館の遺構が埋まっています

ちなみにこの接待館近辺は当時市が立って賑わっていたあたりだそうで、衣川七日市場という地名が残っています。

衣川地区 伝並木屋敷跡

接待館から少し自転車を走らせると、伝並木屋敷跡に到着します。こちらは奥州藤原氏の前に東北に勢力を持っていた安部氏の館跡と伝わっています。前九年の役で衣川の柵が落ちるときに源義家と安部貞任の「衣のたてはほころびにけり」「年を経し糸の乱れの苦しさに」のやりとりに詠まれた「衣川の館」ですね。
衣のたての話は、こちらの 『古今著聞集』 衣のたて | 二階の窓から に詳しく紹介されていますのでぜひ。

伝並木屋敷跡の案内板

案内板によると昔は桜並木に囲まれており、政治の中心だったそうです。今はほぼ田んぼと畑になっています。

接待館から並木屋敷までの道沿いにあった田んぼ。この時期の田んぼは空が映りこんで綺麗ですね。

※ちなみに平泉は観光地ですが、衣川に入るとほとんど田園と住宅になるので自販機とかお手洗いはなくなります。接待館と伝並木屋敷跡だけ程度であれば自転車なら一時間程度で回れますが、他の遺構も回りたい場合はご注意ください。駐車場もあまりないので自転車が一番便利だと思います。

中尊寺毛越寺にも行ったのですが、ちょっと長くなったのでに別記事に分けます。