【読書メモ】チーム・ジャーニー逆境を越える、変化に強いチームをつくりあげるまで

読書メモ

市谷聡啓さんの上記2冊に続いて、チーム・ジャーニーを読みました。
カイゼン・ジャーニーの続編ぽい感じだったので（実際には単体でも読める）2月の発売から楽しみにしており、3月に内容も多めだったのですが、ちょっとだらだらしながらになってしまいましたが読みました。

チーム・ジャーニー逆境を越える、変化に強いチームをつくりあげるまで

作者:市谷聡啓
発売日: 2020/02/17
メディア: 単行本（ソフトカバー）

カイゼン・ジャーニーは、1人から始められるカイゼンを繰り返しチームが遷移していく（だけど焦点は個人に合っている）物語でした。
対してチーム・ジャーニーは、チームマネジメントやチームづくりについて、よりチーム全体に焦点を当てた内容になっています。
物語方式にて、まず問題（ストーリー・問題編）、次に課題（ストーリー・解決編）、最後に解説が各章にておかれています。
基本編で4章、応用編で4章、それが1部+2部なので全16章というボリュームになっています。

概要・ポイント

大枠として、度々書かれていたこと

なめらかに進める
解像度を意識する
状況によってフォーメーションを組む

チームマネジメントにおいて、一気に状況を変えようと思っても無理は利かないので段階的に予定を立て進めていく。
人によってその情報や状況に対する捉え方（視座=高低/視野=広狭）が違うので念頭におく。
ひとつの固定の役割、既存の概念に囚われず状況に応じて柔軟に配置転換、役割の創出などを行なう。

その他、気になったこと、なるほどと思ったことなど。

コンウェイの法則

プロダクトやシステム設計が、組織構造（チーム分割等）を反映したものになることをいう。
逆にプロダクトの機能などから組織構造を作ることを逆コンウェイの法則という。

取引コスト

もとは経済学の言葉で、違う文脈を持っている相手に対してコミュニケーション取ることは取引コストが高い、などという。

「リード」という役割

「リーダー」とは別の「リード」という役割
・リーダー => 組織上の職位として定義
・リード => ある状況において前進を先導する「役割」。例）テクニカルリード、仮説検証リード、テストリード

情報の解像度

レイヤーによって粒度分けて展開するのが望ましい。
例えばPOなどのレイヤーで細かな機能についてまで話を展開してしまうと、開発者メンバー側では情報を受け取って「ただそれを実装する人」になってしまう。
ある程度は余白もたせて PO => リード => 開発者などに受け渡ししていき細部を詰める流れがよい。

番頭の輪番化

担当をローテーションすることで、トラックナンバー1問題（誰々しかこのコードを触れない問題）につながらないようにすること。

ただし、チームメンバーの専門性や関心などで、あるメンバーに依存する領域が生まれてしまうこと自体は悪いことではありません。むしろメンバーの多様性がいきている状態ともいえます。属人性を排除することを過度に目指すのではなく、何かが起きたときに他の人でプランB（本人ほど最適ではないが、他の人でもなんとか対応できる作戦）が立てられるかどうかを明らかにしましょう。

事前に許可を求めるより、後でゆるしを得たほうがたやすい

先に動いてしまって後でゆるしを得にいくということ
これ結構メンバー側目線で自分も意識していて、ケースバイケースではあるものの決裁権持っているひとにいちいち確認しても時間もったいない（=ボトルネックになる）と判断したら答え確定して出した方がいいなと

視座と視野で決まる視点

物事をどこからどこまでを見るようにするか、「どこから」というのは「視座」、「どこまで」とは「視野」にあたる。
その上で
・視座や視野への偏りをつくらないこと
・視座の高低と視野の広狭を自分たちの意思で行き来できること
が重要。

良かった点

少し登場人物の名前が分かりづらいが、相変わらずストーリーがおもしろい。
問題：課題：解説の割合、1:1:1 くらいですが、ある問題に対して内容割いている本も少ないように思うのでためになる。

惜しかった点

特になし

まとめ

本に解説してある内容でも実際の現場では状況も違うので、その都度ベストな選択や考えを結局自分自身がしたり持ったりしなくてはいけないのだけれど、その幅が広がったり選択がしやすくなるような内容の本だと思う。

いっぽうで結局正解はないので読者の主観に後は委ねられる部分も多くある、そういう不確定要素を好まないひとには向いていないかもしれないが、筆者の「正しいものを正しくつくる」でさんざん語られていたように今の時代そういう開発形態も考えも主流になっていくなかでうまく自分も適用できるようにならないとと感じた。

最近発売されたオライリーのみんなでアジャイル ―変化に対応できる顧客中心組織のつくりかたの説明にも

本書では、「顧客から始める」「早期から頻繁にコラボレーションする」「不確実性を計画する」をアジャイルの3つの原則とし、...

と書かれています。
自分も今の会社に入って分かったのですが、結構クライアント側の方が開発に入ってくることが多く、その良い面みたいなのはすごく感じています。それでいて知識も豊富だと後ででてくる要件も出づらいのでやりやすいなと。

今回の本はチームビルディング的な観点だったので、いちメンバーである自分には適用しづらい内容も多かったですが、そういう視点も持ちながら働く/働かないではわりと違うんでは、と思っているのでもちょっと視野広げてやっていきたいと感じられました。

2020-03-31

2020年3月振り返り

月次振り返り

結果

ブログ

目標：月 8 回（週2回）更新
結果：月 15 回更新

読書

目標：月 1 冊
結果：月 2 冊

反省点など

ブログ前半は調子良かったが後半失速気味になってしまった。
仕事の業務でフロントエンドできているのが収穫です。

来月に向けて

新たにコレを勉強する、っていうのが今のところない..
Vue or Nuxt もうちょっと勉強でもするか、この機会にAWSのSAP勉強するか悩み中です。

3月からフルでリモートでした。
当初の慣れのなさからは落ち着いてできるようになったので、もう一度もとに戻すところは戻してやっていきたい。

2020-03-18

Netlify で $ gulp build がビルドエラーになってしまう

Netlify Gulp

f:id:jotaki:20200318200015j:plain

いつもどおりNetlifyでGulp使ったプロジェクトをデプロイしようとしたらエラーが出てちょっと詰まったのでメモ。

管理画面側でDeploy Settingsからもビルドコマンドなど設定してましたがログに

Error running command: Build script returned non-zero exit code: 127

みたいに出て、ググってみるとビルドコマンドがないよ的な内容らしい。
ただローカルでは $ gulp build でうまくいってるのでイメージのバージョンとかかなと思いつつ公式見てみると、

Eleventy starter with serverless functions というのがあり、
https://templates.netlify.com/template/eleventy-starter-with-functions/

リポジトリ内に netlify.toml てのを見つけました。
https://github.com/philhawksworth/eleventyone

この netlify.toml は設定ファイルをコードベースで管理できるそうなので、

netlify.toml の中身

[build]
  command = "gulp build"
  publish = "dist"

とりあえずこれだけ書いてルート階層に置いてプッシュしてみました。
結果、うまくいった。

f:id:jotaki:20200318200027p:plain

厳密な原因分からずですが、とりあえずGulp使って自動デプロイまでの調査結果でした。

2020-03-17

【読書メモ】ユーザビリティエンジニアリング(第2版)

読書メモ

前回、前々回に続いてUXの知識をつけるべくユーザビリティエンジニアリング(第2版) ―ユーザエクスペリエンスのための調査、設計、評価手法― を読みました。

ユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―

作者:樽本徹也
発売日: 2014/02/26
メディア: 単行本（ソフトカバー）

Chapter1 ユーザ中心設計概論
Chapter2 インタビュー法
Chapter3 インタビューの実践
Chapter4 データ分析法
Chapter5 発想法
Chapter6 プロトタイプ
Chapter7 ユーザビリティ評価法
Chapter8 ユーザテスト
Chapter9 ユーザテストの準備
Chapter10 ユーザテストの実施
Chapter11 分析と再設計
Chapter12 ユーザ中心設計活動

概要・ポイント

イントロダクション（1章）
調査（2章〜4章）
設計（5章〜6章）
評価（7章〜11章）
エンディング（12章）

の大区分の中で、優れたUXを実現するためのユーザ中心設計（人間中心設計）プロセスや手法について解説されています。
Webやスマホアプリのような限られた端末に限らず、組込みシステム等でも活用できるような内容になっています。

ポイント

ユーザビリティとは

前提として、「ユーザビリティ = 使いやすさ」ではない。
「ユーザビリティに問題がある = 使えない」という意味でもある。

国際規格ISO9241では、ユーザビリティを「特定のコンテキストに置いて、特定のユーザによって、ある製品が、特定の目標を達成するために用いられる際の、効果、効率、ユーザの満足度合い」と定義しています。

効果は、ユーザが目標を達成できる
効率は、なるべき最短経路で目標を達成できる
満足度とは、ユーザに不愉快な思いをさせない

これら3つをあらゆるコンテキスト（前後関係や状況）において阻害しないことが重要。

ユーザーエクスペリエンス

仮にユーザビリティが満点であっても、その製品への評価は中程度にとどまる

ユーザの「非常に満足」という評価を得るためには、ユーザビリティを超えたレベルを目指さなければならない
代表例として「スターバックス」「東京ディズニーランド」「iPhone」
ユーザーエクスペリエンスの要素表層/骨格/構造/要件/戦略（ギャレットのユーザーエクスペリエンスの要素）
製品の開発が終わってから "上" にかぶせるものではない

ユーザ中心設計

優れたUXを実現するために、ユーザ中心設計（UCD: User Centered Design）、もしくは人間中心設計（HCD: Human Centered Design）を用いて、技術優先の考えや勝手な思い込みを排除して、常にユーザの視点に立った製品開発が行える。

骨格となるプロセスを反復することによってUXの完成度を上げていく。（評価と改善を繰り返すのが重要）

調査：ユーザの利用状況を把握する。

分析：利用状況からユーザニーズを把握する。

設計：ユーザニーズを満たすような解決案を作る。

評価：解決案を評価する。

改善：評価結果をフィードバックして、解決案を改善する。

反復：評価と改善を繰り返す。

ユーザの声

「ユーザの声に応えればユーザは満足する」という前提は間違いで、鵜呑みにせず暗黙的な要求まで満たす必要性がある。例：医者
アンケート、グループインタビュー（グルイン）のメリット、デメリット

コンテクスチュアル・インクワイアリー

インタビューアを弟子、ユーザを師匠と見立てて、師匠の体験を弟子に "継承" します。

コンテクスチュアル・インクワイアリーという手法。

心得教えを乞う → 根掘り葉掘り → 確認する → フォーカス移動の手順を繰り返す
師匠は気難しい / 話を要約する / 例外には触れない
良い弟子と悪い弟子 / 用意する質問は1つだけで、2つ目以降は質問を1つ目の会話から見つける
リクルートやインタビュー準備

質的データ分析

インタビューや観察で得られる情報は「質的データ」
加減乗除のような演算をしない、編集（切り貼り）できる、KJ法での分析が可能。

ペルソナ

決して "架空" のユーザではない

事実に基づいたフィクションを目指す
プライマリーペルソナ、セカンダリーペルソナを設けプライマリーペルソナの要求を完全に満たすことを目的にプロジェクトを進める。

ブレインストーミング

批判厳禁

自由奔放

量より質

便乗歓迎

視覚化

脱線禁止

1度に1人

・Yes And 話法

何を言われても、まず「イエス」と肯定した後に、そこに「それに加えて」「では次に」と自分の意見を追加しながら会話を進めます。

KJ法、ポジショニングマップ、ドット投票などで結論の収束を行なう。

キャンバス

ビジネスモデルキャンバス、それを元に新サービスなどゼロから発想するためのリーンキャンバスがある。
顧客・課題・ソリューションが解決しても、コスト・収益が成り立たないなどなりがち。説得力のある内容でキャンバスを埋めることが大事。

プロトタイプ

制作者が作るために作ったものではなく、ユーザに使ってもらうために作るため「試作品」というよりも「試用品」。
ローファイとハイファイ。Tプロトタイプ、オズの魔法使い。

プロトタイプとは、全体を大雑把に作ることではなく、必要最小限に絞って作ること。

ペーパープロトタイプ、パワポの使用も場面により有益。
階層構造の設計にはカードソートが有効で、クローズド（見出しあり）、オープン（見出しなし）がある。

評価

評価は目的に依って『統括的評価』と『形成的評価』に大別できます。

統括的評価とは、学習成果の総合的な度合いを "測定" することを目的とした評価です。
形成的評価とは、小さい学習ごとに、どれくらい理解できているか、理解するためには何をしなければならないかをフィードバックするための評価です。

具体例としてTOEICは典型的な統括的評価。英会話に通って発音矯正したり、文章添削するような継続性のあるものは形成的評価。

ユーザビリティ評価も2つに区分できる。
統括的評価の代表は「パフォーマンス測定」（タスク達成率、達成時間など）
形成的評価は『思考発話法』を使ったテスト。

原則として、統括的評価は設計プロセスの "前後" で用い、形成的評価は設計プロセスの "途中で繰り返し" 用います。
もう一つ、忘れてはいけない重大な原則があります。それは、「統括的評価しか行わないのならば、それは全く無駄な投資である」ということです。

ヒューリスティック評価

ユーザビリティ評価のための分析的手法の総称を『ユーザビリティ・インスペクション』といいます。

これは評価者自らの知識や経験に基づいて行なう評価だが、客観性を持たすたせるために様々なガイドラインが考案されてきた。

そのなかでヤコブ・ニールセンがユーザビリティ問題を分析して、原則を抽出したガイドラインを『10 ヒューリスティックス（10 heuristics）』という。ヒューリスティックスとは『経験則』という意味。

『ヒューリスティック評価』とは、この10ヒューリスティックスを根拠として、評価対象の製品が犯している "ルール違反" を探索するという手法です。

参考： Jacob Nielsen の「ユーザビリティに関する10のヒューリスティクス (問題解決に役立つ知見) / Ten Usability Heuristics」 — Website Usability Info

実施手順として、評価者は

複数の評価者で行なうこと（3人以上）
適任はユーザビリティエンジニアやユーザーインターフェースデザイナ
インターフェース設計者本人は除外

とし、合議制ではなく単独で評価、発見した問題点をどんどんリストアップしていく。その後評価者ミーティングでディスカッション、レポートに取りまとめる、という流れ。
ただ検出過多やコストの問題などがあり、ヒューリスティック評価は意外と贅沢な方法である。

認知的ウォークスルー

「人間の認知モデル」に基づいて評価を行う手法。
ユーザの技能や経験/タスク/操作手順/画面を定義し、そのなかで4つの質問（目標設定/探査/選択/評価）の探査学習ステップの内容を分析していく。

認知的ウォークスルーではユーザインタフェース上の問題点を詳細に検討するだけでなく、ユーザのとりうる行動を推測することで新たな要求開発にもつながります。

設計の初期段階で用いると有効な手法で、設計者自らがデザインを客観的に再検討するために用いることも可能。

ユーザテスト

ユーザが参加した評価手法の総称で、

ユーザにタスク（作業）を実行するように依頼する。

ユーザがタスクを実行する過程を観察、記録する。

がユーザテストの基本。そのなかで、

思考発話法と回顧法（形成的評価/質の評価）
パフォーマンス測定（総括的評価/量の評価）

など代表的なテスト手法がある。

・思考発話法
考えていることを話しながら操作してもらう。

・回顧法
操作が終わってから質問に答えてもらう。
ただ複雑な状況は回顧が難しいなどの短所もある。

・パフォーマンス測定
数値データ（タスク達成率や達成時間）が必要な場合、量的なデータ収集を目的とした代表的手法が「パフォーマンス測定」
ユーザビリティ3要素（効果・効率・満足度）に関係した量的データを計測する。
効果 → タスク達成率
効率 → タスク達成時間
満足度 → 主観的評価

主観的評価はフレームワーク（質問セット）を使うのが一般的。日本語版はWUSがメジャー
https://u-site.jp/usability/evaluation/web-usability-scale/

原則としてプロジェクトの前後で実施して、目標値を設定したり、目標の達成度や改善度合いを把握したりすることが目的です。
短期間にテストと改善を繰り返しながら、徐々に製品の完成度を上げていく反復デザインに適した手法ではありません。

ユーザテストは「反証」を目的としている。
そもそも問題点を見つけようとしているテストなので、予め問題が発生している製品などは対象にできない。（事前にヒューリスティック評価を行なうなどが必要）
被験者としては5名x3回のテストをするのが理想。（15人x1回よりも小規模なテストを繰り返し実施したほうが利用品質が向上する）

その他ユーザテストの準備としてスケジュールの勘所 / リクルートやリソースに関して / スクリーナ（該当者選別のための判定質問） / テスト設計についてなど。

ユーザ中心設計活動

・原始期
・黎明期
・揺籃期（前期/後期）
・躍動期
・拡充期
・完熟期

成熟度モデルとして6段階あり、例えば原始期は

ユーザエクスペリエンスは開発者やデザイナの個人的技量に委ねられている。標準的なUX/UIガイドラインなどは参照しているが、実際のユーザと対話する活動は行っていない。
UX/UCDの専門家はプロジェクトに参加していない。

という筆者が考えるモデルがある。
飛び級は無理なので、まずユーザテストからやってみるのが良い。ただ黎明期レベルでも成果は上がりづらい。

やりやすいのは、「既存製品の改善プロジェクト」。
リリース直前ではなく、改善プロジェクト開始前のテストからはじめる。プロトタイプを作って事前に有効性を検証できる。

調査と評価

ウェブサイトのユーザビリティ調査でも様々な手法を考える必要がある。

・既存のウェブサイトの問題点の把握とその改善策
→ ユーザテスト

・リニューアルに向けたユーザニーズの把握
→ インタビューなどの質的調査

・競合サイトの比較
→ パフォーマンス測定などの量的なアプローチ

またそれらは同時に行なうものではなく、設計プロセスのステップに応じて行なう必要がある。

①ユーザを "調査" して真のニーズを把握
②そのニーズを満たすような製品を設計
③その製品を "評価" して改善する

良かった点

前回読んだ虎の巻よりも各手順や手法が網羅されている感と内容が詳細なので、深い知識がつく（気がした）。
参考文献とかも王道（っぽい）ものを参照しているのでなんだか内容に信頼感があるように感じた。
UXの向上を目的とした色々な手法が解説されているが、単にビジネス上でも役立つようなコミュニケーション術、アイデア出し手法などを知ることができた。

惜しかった点

目次を見れば分かるには分かりますが、本の最初に調査〜設計〜評価のおおまかな流れと概要について触れたほうが頭に入っていきやすい気がします。

そこの知識ある前提で書かれている本ではあるかもしれないのですが。

まとめ

最後の「調査」と「評価」の使い分けにも書いてあったのですが、これまで読んだ本は触りの触りで、この本は深いところまで解説してあるなあという感想です。
1つ1つの手法についてもそうですが、組織の成熟度モデルについても実態に合っているような気がするので参考になりました。

2020-03-05

S3へのFTPクライアント接続にIP制限を掛ける

AWS S3 IAM

f:id:jotaki:20200305110857j:plain

htmlを静的ホスティングしているS3バケットへのブラウザアクセスはバケットポリシーでIP制限が可能。
だけど、FTPクライアントでのS3接続はIAMユーザーのアクセスキー&シークレットを使うので、そのユーザーの権限で設定してあげる必要があります。
ほぼ初めてちょっとテクいことをしてみたので（全然難しくないんだろうけど）メモしておきます。

IAMユーザーの作成

コンソールでIAMから S3_ftp-client-user というユーザー名でユーザー作成。
アクセスキー、シークレットを取得する必要があるので「プログラムによるアクセス」にチェックを付ける。

f:id:jotaki:20200305110321p:plain

とりあえずこの段階でポリシーはアタッチせず、タグは適当なものを付ける。
アクセスキーとシークレットはFTPクライアントでの接続で使うので控えておく。

f:id:jotaki:20200305110334p:plain

IAMポリシーの作成

アクセス権限として下記を与える。
"Action": "s3:*", は絞る必要があるときは絞って、 "aws:SourceIp": [] の中に許可するIPアドレスを追加していく。

f:id:jotaki:20200305110345p:plain

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        "ここにIPアドレス01",
                        "ここにIPアドレス02",
                        "ここにIPアドレス03"
                    ]
                }
            }
        }
    ]
}

S3FullAccessOnlyPrivateNetwork というポリシーを作成。（ Private ではなくネットワーク名がよい）

f:id:jotaki:20200305110358p:plain

IAMポリシーのアタッチ

最後に S3_ftp-client-user ユーザーに S3FullAccessOnlyPrivateNetwork のポリシーをアタッチしてあげる。
「アクセス権限の追加」を押して

f:id:jotaki:20200305110419p:plain

「既存ポリシーのアタッチ」から先ほど作ったポリシーをアタッチ

f:id:jotaki:20200305110436p:plain

動作確認

Transmit を使用して登録IPアドレスからの接続確認。

アクセスキー&シークレットを入力

f:id:jotaki:20200305110449p:plain

問題なくリストが表示される。

f:id:jotaki:20200305110501p:plain

登録していないIPからだと Access Denied となったのでOK

f:id:jotaki:20200305110513p:plain

まとめ

今回管理ポリシーを使ったのですが、あまり運用上推奨されるプラクティスではないと思うのでもう少しいいやり方がありそうです。
んまー管理ポリシー使うとしても、登録するIPアドレスはSystems Managerのパラメータストア使うとかがいいのかなと思ったり..実際にいじってみるといろいろ分かっていないなーという感じがしました。

2020-03-05

microCMS をさわってみるその9

microCMS Vue.js Netlify

日本製のHeadless CMS、microCMSをさわってみる。その9

f:id:jotaki:20200303155515j:plain

GitHub: https://github.com/yuheijotaki/micro-cms-ramen
Netlify: https://ramen.yuheijotaki.dev/

ラーメンコンテンツの描画

前回作ったコンテンツを描画していきます。
curlは python -mjson.tool をつけると見やすく出してくれます。

curl "https://jtk.microcms.io/api/v1/demo" -H "X-API-KEY: ここにAPIキー" | python -mjson.tool

JSONの中身は下記のような感じ

{
    "contents": [
        {
            "category": [
                {
                    "category": "\u307f\u305d",
                    "createdAt": "2020-03-05T07:07:17.724Z",
                    "id": "5__2y6A9e",
                    "updatedAt": "2020-03-05T07:07:17.724Z"
                },
                {
                    "category": "\u30e9\u30fc\u30e1\u30f3",
                    "createdAt": "2020-03-05T07:05:54.951Z",
                    "id": "pM7WYjpvf",
                    "updatedAt": "2020-03-05T07:07:24.608Z"
                }
            ],
            "content": "<h3 id=\"hjzz2WrKPk3\">\u3010\u6c60\u888b \u5473\u564c\u30e9\u30fc\u30e1\u30f3\u3011</h3><p>\u30b7\u30c3\u30ab\u30ea\u3068\u3057\u305f\u6b6f\u5fdc\u3048\u306e\u9eba\u306f\u6fc3\u539a\u5473\u564c\u30b9\u30fc\u30d7\u3068\u76f8\u6027\u629c\u7fa4\u3067\u3059\u3002</p>",
            "createdAt": "2020-03-03T06:37:47.405Z",
            "id": "hanada",
            "image": {
                "url": "https://images.microcms-assets.io/protected/ap-northeast-1:ab97ca46-b946-408b-917a-fae46b705181/service/jtk/media/FireShot%20Capture%20062%20-%20%E9%BA%BA%E5%87%A6%20%E8%8A%B1%E7%94%B0%20%E6%B1%A0%E8%A2%8B%E5%BA%97%20-%20%E6%B1%A0%E8%A2%8B_%E3%83%A9%E3%83%BC%E3%83%A1%E3%83%B3%20%5B%E9%A3%9F%E3%81%B8%E3%82%99%E3%83%AD%E3%82%AF%E3%82%99%5D%20-%20tabelog.com.png"
            },
            "name": "\u9eba\u51e6 \u82b1\u7530 \u6c60\u888b\u5e97",
            "updatedAt": "2020-03-05T07:12:51.182Z",
            "url": "https://tabelog.com/tokyo/A1305/A130501/13109890/"
        }
    ],
    "limit": 10,
    "offset": 0,
    "totalCount": 1
}

詳細ページのテンプレート、出力部分だけとこんな感じになります。
JSONの形通りにVueで出力すればOKですね。

<template lang="pug">
  div
    h1 {{ post.name }}
    div(
      v-html="post.content"
    )
    h2 カテゴリー
    ul
      li(v-for="item in post.category") {{item.category}}
    h2 食べログURL
    p
      a(:href="post.url" target="_blank") {{ post.url }}
    p
      img(:src="post.image.url")
</template>