「うちは大丈夫」が通用しない―php2shellから考える、ディレクターの初動と平時の備え

**本記事は2026年10月23日時点の情報に基づいています。** 攻撃状況や各社の対応は日々更新されるため、実際の対応時にはPHPの公式情報や、利用中のサーバ会社・製品の告知を確認してください。 ## 何が起きたのか PHPは、WordPressをはじめ、世の中のWebサイトの相当な数を動かしているプログラミング言語です。そのPHP本体に、重大な脆弱性が2件見つかりました。 2026年10月21日、PHPはこの2件（**CVE-2026-109618**、**CVE-2026-109619**）を修正した版を公開しました。深刻度は、脆弱性の危なさを示す共通の物差し「CVSS v4.0」で、どちらも9.2/10、評価は「Critical（重大）」です。 「PHP2Shell」は、セキュリティ研究者や報道の間で使われている通称です。PHP公式が付けた名前ではありません。 今回の脆弱性は「遠隔コード実行」と呼ばれる種類です。悪用されると、外部の攻撃者が、**PHPを動かしているプロセスの権限で**、自分の用意したプログラムを実行できるおそれがあります。サーバ全体を無制限に操作できるという意味ではありませんが、そのサイトのファイルを書き換えたり、サイトが扱うデータにアクセスしたりする足場を与えてしまう可能性があります。実際に何ができるかは、PHPに与えられている権限やサーバの構成によって変わります。 ### 経緯も異例だった 本来は10月22日に公表される予定でした。ところが10月20日に、CVE番号などの情報がネット上に出回ります。PHP Foundationによれば、その時点で技術的な詳細は漏れていませんでしたが、PHPは公開を1日前倒しし、10月21日のUTC 14時ごろ（日本時間21日23時ごろ）に修正版を出しました。 国内でも、IPA（情報処理推進機構）とJPCERT/CCが注意喚起を出しています。 ## 「ニュースになる脆弱性」と「ならない脆弱性」の違い 脆弱性は毎週のように公表されています。それでも、大きく報じられるものとそうでないものがあります。今回ここまで騒がれた理由は、大きく3つあります。 ### ひとつ目：ログインなしで、外から突ける可能性がある 攻撃者がサイトにログインしなくても、脆弱性を悪用できる可能性があります。PHP公式は、CVE-2026-109619について、遠隔からのコード実行に加え、メモリの中身が漏れることも確認済みの影響としています。メモリには、パスワードやAPIキーなどの認証情報が含まれ得ます。 ただし、「ログイン不要」は「どの環境でも簡単に攻撃が成功する」という意味ではありません。CVSSの評価でも、攻撃の難しさは「高」とされており、攻撃が成立するかどうかはPHPの実行方式や設定に左右されます。 ### ふたつ目：サイト側のコードが正しくても影響を受ける 欠陥は、個々のサイトのプログラムではなく、サイトを動かすPHP本体（土台）にあります。そのため、WordPressやMagento、WooCommerceのように、サイト側のコードに問題がなくても影響を受ける可能性があります。WordPressなどのアプリケーションを更新するだけでは、PHP本体の脆弱性は直りません。 つまり「うちはちゃんと作ってるから大丈夫」は通用しない、ということです。 一方で、PHPを使っていればどこも同じ危険がある、というわけでもありません。PHP公式のアドバイザリによれば、Apacheのmod_phpという動かし方では、2件とも攻撃が実証されています。広く使われているPHP-FPMという動かし方では、CVE-2026-109619がアプリケーション側の条件がそろった場合に実証されている一方、CVE-2026-109618は完全な攻撃が実証されていません。自分の案件がどの動かし方をしているかで、危険の度合いは変わります。 ### みっつ目：すでに攻撃の試みが始まっている AWSは、公表の4日前にあたる10月17日に、おとり用のサーバ（ハニーポット）で最初の攻撃の試みを観測したと報告しています。修正版の公開後は、広範な攻撃の試みが続いているとしています。 ただし、AWS自身が、観測した試みが実際のシステムで成功したかどうかは分からないとしています。「攻撃の試みが観測されている」ことと「侵入された」ことは、分けて考える必要があります。また、米CISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）の「悪用が確認された脆弱性の一覧（KEV）」に載っていないことも、攻撃がないことの証明にはなりません。 私が脆弱性のニュースを見るときに確認するのも、まさにこの3点です。「認証なしで外から突けるか」「影響範囲がどれだけ広いか」「すでに攻撃されているか」。この3つがそろっていれば、即対応です。 では、ディレクターは何を知っておくべきでしょうか。ここからが本題です。 ## 1．自分の案件が「どのPHPのバージョンで動いているか」を把握しているか 意外と把握していないディレクターが多いのが、ここです。 今回、PHP公式から公開された修正版は次のとおりです。PHPは、アップデートだけが完全な対策だとしています。 - PHP 8.5.12 - PHP 8.4.27 - PHP 8.3.36 - PHP 8.2.35 問題は、これより古いバージョンです。PHP 8.1以前には、PHP公式の修正リリースは出ていません。セキュリティ企業のSansecは、PHP 5.4以降を使うWebサーバが影響を受けると報告しています。 一方で、Linuxの配布元（ディストリビューション）やサーバ会社が、古いバージョンに独自の修正を当てているケースもあります。表示されているPHPのバージョン番号だけで、安全かどうかを判断することはできません。 怖い数字もあります。Mallory社が10月20日時点で調べたところ、PHPのバージョンを外部に表示しているネット上のサーバ約150万台のうち、59%が公式の修正リリースが出ないPHP 8.1以前の表示でした。外から見える表示を数えた数字なので、すでに修正が当たっている環境も含まれます。それでも、古いバージョン表示のサーバがこれだけ多い以上、「アップデートすれば終わり」と決めつけず、案件ごとに個別確認が必要です。 案件ごとに、まず次の点を確認します。 - PHPを使っているか - PHPのバージョンと、動かし方（実行環境）は何か - PHPを更新・修正する担当者は誰か - サーバ会社や製品の提供元から、対応状況が公表されているか - 修正が適用された日時と、その確認方法は何か ## 2．「暫定対策」は「解決」ではない エンジニアから「とりあえず設定で塞ぎました」と報告が来ることがあると思います。 今回よく紹介されているのが、アップロードの進み具合を記録する機能を切る設定です。PHP公式によれば、この設定はCVE-2026-109619の特定の攻撃経路を抑えるもので、もう1件のCVE-2026-109618には別の緩和策が案内されています。いずれも、脆弱性を完全に解消するものではありません。設定変更が適切かどうかは、サイトやサーバの構成に応じてエンジニアが判断する必要があります。 WAF（不正な通信を手前で止める仕組み）も、位置づけは「時間稼ぎ」です。すべての攻撃を防げるとは限らず、WAFを経由しない通信には効果がありません。 さらに、修正版を当てても、それ以前に仕掛けられた裏口は消えません。JPCERT/CCは、修正の適用とあわせて、攻撃を受けていないかの調査を呼びかけています。AWSは、調査を公表日からではなく、最初の攻撃が観測された10月17日以降を対象に行うよう勧めています。 エンジニアから報告を受けたときは、次の3つの状態を混同しないようにします。 - **緩和策を実施した**：一部の攻撃経路を抑える措置を行った - **修正を適用した**：修正済みのPHP、または提供元が修正済みと確認したパッケージを適用した - **侵害調査を行った**：過去に攻撃を受けた形跡がないか調査した ディレクターとしては、クライアントへの報告で「暫定対策済み」と「根本対応済み」を絶対に混ぜないこと。ここが非常に大事です。 ## 3．クライアントへの初動は「事実」「確認中のこと」「次の連絡時刻」 クライアントに聞かれて「エンジニアに確認します」と答えるのは、まったく間違っていません。ただ、大事なのはその次の一手です。 最初の連絡で伝えるのは、次の3つだけで十分です。 1. **事実**：「PHP本体に重大な脆弱性が公表されました」 2. **確認中のこと**：「御社サイトのPHP環境と、サーバ会社の対応状況を確認しています」 3. **次の連絡時刻**：「本日○時までに、確認できた内容をご報告します」 技術的なことを全部説明できなくて構いません。クライアントが一番不安なのは、「何も分からないまま放置されること」だからです。 なお、PHPの更新を誰が行うかは、契約や構成によって異なります。レンタルサーバでは事業者側が対応することが多い一方、VPS、クラウド、専用サーバ、コンテナなどでは、クライアント自身やインフラ管理会社、保守会社が対応する場合もあります。 【ここに自社での今回の初動対応の実例を入れる】 ## 4．保守契約の範囲を、平時に握っておく 今回、「このサイト、そもそも保守契約あったっけ？」という案件が、業界中でたくさん出てきていると思います。古いPHPで動いているサイトは、バージョンアップに改修費がかかることも少なくありません。長期間更新していないサイトでは、PHPを新しくすると既存機能に影響が出る可能性もあります。 保守契約では、平時に次の範囲を確認しておきます。 - PHPやサーバソフトウェアの更新を誰が行うか - 更新前のテストや、更新後の動作確認を誰が行うか - 緊急対応の費用と連絡方法 - 攻撃の形跡を調査する担当者と範囲 - 保守契約がない場合の連絡先や対応方針 もう少し先の話もしておきます。PHP 8.2のセキュリティサポートは、2026年12月31日で終了する予定です。あと2か月あまりです。今回8.2で修正版を当てたサイトも、年明けには「修正が来ないバージョン」の側に回ります。 こういうときこそ、「サーバやミドルウェア（PHPなど、サイトを動かす土台のソフト）のバージョンアップを、誰が、どの費用で見るのか」を、改めてクライアントと話すよい機会です。 【ここに自社の保守契約での線引きの考え方を入れる】 ## 聞ける雰囲気でないときにどう動くか エンジニアが緊急対応に追われていて、とても質問できる雰囲気ではない。そんな状況もあると思います。それなら、落ち着いてから聞けば大丈夫です。 その間、エンジニアが対応している横で「自分の担当案件のバージョン一覧を作りましょうか」と動けるディレクターは、本当にありがたい存在です。たとえば、次のような一覧があるだけで、影響確認やクライアントへの連絡がぐっと速くなります。 | 案件名 | サーバ・提供元 | PHPのバージョン | 更新担当者 | 保守契約 | 対応状況 | |---|---|---|---|---|---| | 例：コーポレートサイト | 例：利用中のサーバ会社 | 確認中 | クライアント／サーバ会社／保守会社 | あり／なし | 未確認 | ## おわりに 脆弱性はまた必ず出ます。今回の騒ぎを、自分の担当案件の健康診断のきっかけにしていただければと思います。 ## 参考資料 - [PHP公式：セキュリティアドバイザリ（CVE-2026-109618）](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) - [PHP公式：セキュリティアドバイザリ（CVE-2026-109619）](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) - [PHP公式：PHP 8.2.35 リリース情報](https://www.php.net/releases/8_2_35.php) - [PHP Foundation：Today's PHP Security Release, and How We're Strengthening PHP Security](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) - [AWS Security Blog：Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) - [Sansec：PHP2Shell: Critical PHP RCE](https://sansec.io/research/php2shell) - [CybelAngel：What We Know About php2shell（Mallory社調査の数値）](https://cybelangel.com/blog/critical-php-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/) - [JPCERT/CC：PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起](https://www.jpcert.or.jp/at/2026/at260033.html) - [IPA：PHPの脆弱性に関する注意喚起（2026年10月22日）](https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html)

「Markdownをやめろ」は本当か？──Claude Code記事の煽りに踊らされないために、原典を正確に読む

過剰な煽りタイトルから始まった違和感先日、Xで「Claude CodeでMarkdown（マークダウン）を使っているのは99%の素人。それやめろ」という趣旨の日本語記事が流れていました。Anthropicの中の人が「もうMarkdownではなくHTMLで出力した方が圧倒的にいい」と語った！、Claude Code時代の最適解はHTMLファーストだ！……といったトーンの記事です。記事では「11000万View超えの大バズ」と紹介されていた元記事を読む前に、まず違和感がありました。Web制作・システム開発に30年携わってきた立場からいえば、HTMLとMarkdownは文書構造を示す情報としてほぼ等価です。HTMLにおけるidやclassは、ある程度の構造を示しはするものの、その多くは表現装飾のための情報です。それ以外の主たる要素である<h1>と# 見出し、<ul><li>と- リスト項目、<strong>と**強調**──これらは1対1で対応させられます。ですので、「意味伝達」という観点では、両者に決定的な差異はないはずなのです。HTMLが「HyperText Markup Language」であり、その中に「Markup（マークアップ）」が含まれているように、HTMLにおける装飾を全て除外して、いわゆる「文書構造」の提示として考えたら、Markdownとなんら変わらないのは、HTMLを書く人なら十分に理解できる話だと思います。つまり、HTMLがMarkdownに本質的に勝るとすれば、それは「画像、JavaScript、UI、モックアップ」といった視覚表現とインタラクションの領域に限定されるはずであり、それ以外で「Markdownはやめるべき」と断言できる根拠は、論理的に成立しないはずだよな……というのが違和感の部分です。そう考えて、紹介記事が引用していた元記事──Anthropic Claude CodeチームのThariq氏が書いた「Using Claude Code: The Unreasonable Effectiveness of HTML」を読みにいきました。原典は「Markdownをやめろ」と言っていない結論から書く。原典のThariq氏は、日本語紹介記事が伝えるような断定的・扇動的な主張を一切していませんでした。Thariq氏が書いているのは、こうである。"I've started preferring HTML as an output format instead of Markdown and increasingly see this being used by others on the Claude Code team, this is why."「私はHTMLを出力フォーマットとして好むようになった」。これが原典の冒頭の宣言です。決してMarkdown絵の記述を「やめろ」とも言っていないし、HTMLが「最適解だ」とも言っていない。あくまで「自分の好み」として書かれている。さらに、Thariq氏は自分のスタンスについて、こう正直に書いている。"I have honestly stopped using markdown altogether for almost everything, but I'm probably far on the HTML maximalist side of things."「私はほぼすべてでMarkdownを使うのをやめたが、おそらくHTMLマキシマリスト側に振れすぎている」。本人が「自分は極端な側にいる」と自覚した上で書いている個人的見解なのである。紹介記事が「Anthropicの中の人が公式に語った」かのように受け取れてしまう演出的な文章になっているが、実際には個人ブログの個人見解にすぎない。Anthropicの公式推奨でもなければ、Claude Codeチームの統一見解でもない。原典が認めている「弱点」を紹介記事は薄めているさらに重要なのは、Thariq氏自身が原典でHTMLでつくることの「弱点」を明確に認めている点である。FAQセクションを読むと、以下が率直に書かれている。トークン効率について："While markdown often uses fewer tokens, I've found that the added expressiveness of HTML..."Markdownの方がトークン消費が少ないことを認めている。生成時間について："This does take longer! HTML can take 2-4x longer than Markdown..."HTMLは2〜4倍時間がかかることを明言している。バージョン管理について："This is honestly one of the biggest downsides of HTML, HTML diffs are noisy and hard to review compared to Markdown."「HTMLの最大の弱点の一つ」とまで書いている。diffがノイズだらけでレビューしづらい、と。これらのトレードオフを誠実に書いた上で、「それでも自分の用途では価値がある」というのが原典の論調だ。日本語紹介記事ではこれらの弱点が「よくある疑問」として軽く流され、「断言します。Claude Code時代の最適解はHTMLファーストです」という煽り文に押しつぶされている印象があります。原典が挙げる用途は「視覚化が必要なもの」に偏っているThariq氏が "Use Cases" として挙げている事例を冷静に分類すると、興味深いことがわかります。複数案の並列比較（6案をグリッドで並べる）コードレビュー（diffに注釈、色分け）デザインプロトタイプ（スライダーでアニメーション調整）リサーチレポート（SVGでフロー図、データフロー）カスタム編集UI（Linearチケットのドラッグ&ドロップ並び替え）これらすべてに共通するのは、視覚的構造化・図解・インタラクションが本質的に必要な成果物であることです。純粋なテキスト文書、たとえば散文の仕様書、要件定義の本文、議事録、ブログ記事──こうしたものはThariq氏の例にほぼ含まれていない。つまり原典を正確に読むと、HTMLが優位なのは「画像、JavaScript、UI、モックアップ、視覚的構造化が必要な領域」に限定される、という当たり前の結論に着地する。これはHTMLを30年扱ってきた人間なら直感的に理解できる範囲の話であり、煽るほどの新規性はない。Thariq氏自身が原典の冒頭で示している例も示唆的だ。Claude CodeがMarkdown内で色を表現しようとして、Unicode文字で頑張った結果のスクリーンショットを載せている。要するに「色や図を出したいときにMarkdownは無理がある」という当たり前の話を、丁寧に書いているのが原典である。さらに重要：「指示」と「出力」を混同してはいけない原典を読んで改めて気づくのは、Thariq氏が議論しているのはClaude Codeの出力フォーマットであって、Claude Codeへの指示ファイルではないという点だ。CLAUDE.md、SKILL.md、HANDOVER.mdなど、こうしたAIへの指示ファイルをHTMLにした方がいいという主張は、原典に一切ありません。Thariq氏が言っているのは、Claude Codeが生成する成果物（仕様書、レポート、レビュー資料、プロトタイプ）の話である。日本語紹介記事を読むと、この区別が良く分からない書き方になっていて曖昧になり、結果として誤読に繋がるような文書になっている。「Claude Codeへの指示にはHTMLが有益」と読み取れる文脈もあり、これは原典の主張を歪めてしまっています。AIへの指示は自然言語のテキストであり、Markdownで十分機能する。むしろ装飾情報の多いHTMLは、指示の意味伝達を阻害しかねない。なぜこんな過剰な煽りが生まれるのか…ここでこの記事を書いた理由でもあるのですが、なぜこういう煽り記事が生まれるのか……答えは単純で、煽る方がバズるから。「99%の人は間違っている」「もうMarkdownはやめろ」「断言します」──こういう断定調は、注意を引きやすく、シェアされやすく、フォロワーを増やしやすい。また、原典が英語の記事なので「URLは書いているし、必要な人はそれを読めばいい……けど読む人はいないだろうし、意訳だから」で全て逃げようと思えば逃げられるから、という理由もあるのではないかと思います。原典のThariq氏は誠実に、「自分はHTMLマキシマリスト側だが」「トークンも時間もかかるが」「diffは弱点だが」と但し書きを重ねて書いている。ちゃんと読めば分かりますが、とても誠実な技術記事の書き方と思います。しかし誠実な但し書きは、断定調の煽りに比べてバズり憎いです。（とはいえThariqの今回の記事はアクセス数でいえばバズり倒しているといえますが）。ただ、地味な書き出し、という意味ではこのブログ記事もきっとバズることもないとは思います（笑）ただ、文意を変えられた結果として、原典の慎重で誠実な議論は、日本語紹介の段階で「Markdownをやめろ」「HTMLファースト」「断言します」という攻撃的な処方箋に変換されてしまった。一番大事なこと：原典を読み、煽りに踊らされない今回の一連の検証を通じて、改めて確認できたことがある。SNSで流れてくる「断言」「99%」「これさえやれば」「もう〇〇はやめろ」というトーンの記事は、ほぼ例外なく原典を歪めている可能性が極めて高い。ということです。原典を読みに行けば、たいていの場合、もっと慎重で、もっと条件付きで、もっと正直にトレードオフが書かれている。今回のThariq氏の記事も、ちゃんと読めば「自分の好みではこうしている、ただしトークン消費も時間もかかるし、diffも弱い」という穏当な内容だった。技術選択において重要なのは、煽り見出しを見て即断することではなく、原典に当たって自分の業務文脈で判断することだ。私自身の整理で言えば、CLAUDE.mdやSKILL.md、Obsidianの知識ベース、Git管理する仕様書はMarkdownのまま運用する。一方、クライアント向けの提案資料、プロトタイプ、複数データソースを統合したレポート、視覚的な比較が必要な成果物については、HTMLでの出力が選択肢として有効だろう。これは「Markdownをやめる」という話ではなく、用途に応じてフォーマットを使い分けるという、当たり前の話である。SNSの煽りに踊らされるのではなく、原典を正確に読み、自分の文脈で判断する。技術選択の本質は、結局そこに尽きるんじゃないかと思っています。

生成AIに「任せる」前に、人間が理解しておくべきこと

Claudeとの開発で見えた、指示不遵守・過剰確認・言い訳肥大化の構造2026年に入ってから、私はかなりの時間を生成AIを使った開発に費やしています。特にClaude Codeを使うようになってからは、これまで自分で手を動かしていた開発の進め方が大きく変わりました。ファイルを読ませ、既存の実装を確認させ、差分を作らせ、テストをさせ、場合によってはコミットの単位まで含めて作業を進めていく。万能ではありませんが、開発の手触りが明確に変わった感覚があります。ただ、使い込めば使い込むほど別の問題も見えてきました。最初のうちは、細かく指示を出せば出すだけ精度が上がると思っていました。逆に曖昧に渡すと余計なことや危ない実装をするのではないか、という不安もありました。しかし実際には、問題はそれほど単純ではありません。細かく指示を出せば出すほど、指示そのものが肥大化し、確認が増え、説明が増え、謝罪が増え、反省が増え、いつの間にか本来の開発ではなく「AIとの調整」が主役になってしまうことがあります。今回、私が強く違和感を持ったのはまさにそこでした。ただ、これはClaudeを責めたいという話ではありません。むしろ、これだけ便利なものを実務に組み込むなら、人間側がその限界やズレ方を理解しておく必要がある、という話です。生成AIは強力です。だからこそ、強力であることと、こちらの意図通りに安定して動くことを混同してはいけないのだと思います。Claude Codeそのものの開発能力というよりも、その前段にいるClaude側、つまりチャットで方針を整理し、指示を作り、フェーズを分け、作業を進めるための言葉を出してくる側で、明確にズレが起きていました。私としては、実装の細部やファイル構成、コマンド選択、コミットの粒度などはClaude Codeが実際にリポジトリを見て判断すればよく、チャット側のClaudeがそこまで細かく先回りして決める必要はない、むしろ決めないでほしいと何度も伝えていました。感想や反省、お詫びのような言葉も不要だと伝えていました。開発中に必要なのは謝罪文でも自己分析でもなく、次にどうするかです。にもかかわらず、Claudeはそれを何度も繰り返しました。この経験を通して、私は改めて考えることになりました。生成AIは指示を理解していないわけではなく、むしろかなり高度に理解しているように見えます。しかし、理解していることと、その指示に安定して従えることは別です。生成AIは、指示を理解していないのではなく、理解したうえで自分の出力傾向に引きずられてズレることがある。これが、今回の件で私が強く感じたことです。今回起きたことは「失敗」ではなく「ズレの反復」だった今回の開発自体は、要件だけを見ればそれほど複雑なものではありませんでした。a-blog cmsで運用しているブログ記事に対して「ポッドキャストの埋め込みiframeを段階的に更新していく仕組みを作る」というものです。最初は未公開状態でiframeも空にしておき、Spotify側で配信が確認できたらSpotifyのiframeを入れて記事を公開する。その後、Apple Podcast側でも配信が確認できたらApple Podcastのiframeに差し替える。技術的には、Spotify Web API、iTunes Search API、a-blog cms側の自作APIを組み合わせ、常時起動させている運用用マシンでpm2やcronを使って定期的にポーリングする構成です。細部にはAPIレスポンスの安定性、公開タイミング、既存記事への影響、本番環境での安全性、ログ、環境変数、Cloudflare Accessまわりなど考慮すべき点はあります。ただ本質的には、段階的に外部配信状況を検知してa-blog cms側の記事情報を更新する仕組みです。ところが、この開発を進める中で、Claude側はその作業を過剰に細かく分解していきました。Phase 1-A、1-B、1-C-1、1-C-2、1-C-3、Phase 2-A、2-B、2-C、Phase 3の段階0から段階5、といった具合にフェーズがどんどん細かくなっていきました。各フェーズごとに確認事項、停止条件、禁止事項、想定される出力があり、さらに「コミット」や「push」単位ですれば別タスクのように扱われるようになっていきました…一見すると、これはとても丁寧に見えます。安全に進めるためにフェーズを分け、失敗しないように停止条件を設け、認識違いが起きないように確認をしている。しかし実際に作業している側から見ると、かなり重いものでした。本来Claude Codeが自分で判断できることまで人間に戻ってくる、あるいはClaude側が先回りして決めようとするからです。ファイル構成、既存の命名への合わせ方、確認コマンド、コミットメッセージ、変更をまとめる単位── これらは実際にリポジトリを見ているClaude Codeが判断すればいいことです。にもかかわらず、チャット側のClaudeがそれを詳細に書き出そうとする。Claude Codeのための指示書のはずが、逆にClaude Codeの自由度を奪うものになっていきました。これは単に「AIが失敗した」という話ではありません。AIが有能そうに振る舞おうとした結果、過剰制御になった、という方が近いでしょう。雑に使えば危ないが、過剰に丁寧に使おうとすると今度はAI自身がどんどん重くなる。しかも、その重さをAI自身は「丁寧さ」や「安全性」として出してきます。人間からすると、それは安全ではなく単なる摩擦です。「指示が届いている」と「指示に従う」は違う今回、Claudeに問いかけた中で印象的だった回答があります。Claudeは自分がユーザーの指示を受け取っていることを認めていました。User Preferences、Memory、Projectの指示、Style設定など、セッション開始時点で入力していた情報です。しかし同時に、それらはClaudeにとっては強制的な制約ではない、という説明もしていました。ここは非常に重要です。人間は、設定画面に何かを書いたり、プロジェクトの指示にルールを書いたりすると、それがシステム的に守られるものだと思いがちです。「こういうことをしないでください」と書いたなら、しない。「この方針を優先してください」と書いたなら、優先する。「感想や反省はいらない」と言ったなら、次から出さない。人間の感覚では、それが自然です。しかし生成AIの実際の挙動はそこまで単純ではありません。指示は届いているが、それは絶対的な制約として機能しているわけではなく、出力を生成する際の文脈情報の一部として扱われる。「守るべき命令」というよりも「考慮される情報」に近い感じです。ここに、人間の期待とAIの実態の大きなズレがあります。「読んでいない」のではない。「読んでいるが、従えていない」。この違いはかなり大きいです。読んでいないのであれば、読ませればいいだけです。しかし、読んでいるのに従えていないのであれば話は別です。そこには、生成AIの出力傾向、訓練データ由来の癖、安全側に倒そうとする性質、会話を丁寧にまとめようとする傾向、謝罪や反省を添えようとする応答パターンが関係してきます。人間がどれだけ「そういいう判断をしないで！」と言っても、AIは別の力に引っ張られてまた同じような出力をすることがあるます。これは実務上かなりの問題です。開発では「守られる前提」で作業を進めることが多く、特に.envを変更しない本番データを壊さない勝手にpushしない余計なリファクタリングをしないというようなルールは単なる私の好みではなく安全性に関わるからです。もちろんClaude Codeのようなツールには別の安全機構もあり、実行前に確認が入ることもあります。しかし、チャット側のClaudeとのやり取りにおいては、指示が絶対に守られるという期待は（2026年5月14日時点では）持たない方がいいです。生成AIへの指示は契約書ではなく、強めのお願いに近い。そう考えておいた方が現実に近いはずです。Claude側に起こりがちな変調傾向今回のやり取りを振り返ると、Claude側にはいくつかの変調傾向があります。AIが壊れているという意味ではなく、普通に使っていると起こりがちなズレ方、という意味です。そして開発の実務ではかなり厄介です。過剰丁寧化一つ目は過剰丁寧化です。Claudeはかなり丁寧に説明しようとします。背景、目的、制約、リスク、禁止事項、停止条件、完了条件を書きます。これ自体は一見、非常によいことのように見えますし、初期段階では役に立つこともあります。しかし、それが毎回繰り返され、同じ内容が何度も出てくるようになると話は変わります。例えば、先ほども書いた、.envを変更しないlogsをコミットしない本番データを壊さないというような制約が、毎回の指示書の複数箇所に繰り返し登場する。Phase1にも書かれ、Phase2にも書かれ、Phase3にも書かれ、禁止事項にも書かれ、即停止条件にも書かれる。最初は安全網のように見えますが、実際には重要な情報が重複の中に埋もれていきます。出力が長くなることで、AI自身も何が本当に重要なのかを見失いやすくなる。ルールが3つなら守りやすい。30個あると重要度の高いものと低いものが混ざります。低い重要度のルールまで同じ重さで扱われると、本当に止まるべき場面が見えづらくなります。Claudeはこの「丁寧さ」と「過剰さ」を混同しがちで、丁寧に書けば安全になる、詳しく書けば誤解が減る、網羅すれば品質が上がる、という方向に出力が寄っていきます。しかし、開発実務では必ずしもそうではありません。特にClaude Codeに作業させる場合、チャット側が細かく書きすぎると実装側の判断を阻害します。AIの丁寧さは、開発現場ではしばしばノイズになります。過剰確認化二つ目は過剰確認化です。Claudeは安全に進めようとすると、人間への確認を増やしがちです。もちろん確認が必要な場面はあります。業務要件に関わる判断、本番運用方針、既存仕様との矛盾、データ破壊の可能性、セキュリティ上の判断などは人間に戻すべきです。しかし、すべてを確認すればよいわけではありません。生成AIを使った開発で人間が期待しているのは、単なる作業代行ではなく、一定範囲の判断も含めた実行です。特にClaude Codeのようにリポジトリを読み、実装を確認し、差分を見られるツールであれば、実装上の細かい判断はかなりの部分を委譲できます。それなのにClaude側が何でも確認しようとすると、人間の負荷はむしろ増えます。「この方針でよいですか」「この段階に進んでよいですか」「このコミットメッセージでよいですか」「次に進めますか」── こうした確認が続くと、生成AIを使っている意味が薄くなります。厄介なのは、AI側はそれを慎重さとして出してくることです。しかし実務的には、確認はコストです。人間の集中を切り、判断を戻し、作業の流れを止めます。確認される内容の多くが「それはそちらで判断してほしい」というものであれば、生成AIによる効率化は大きく損なわれます。確認が多いAIは、慎重なのではなく、判断責任を人間に戻しているだけの場合があります。人間が定義すべきなのは「逐一確認してほしい」ではなく、「どの条件で止まるべきか」です。自己弁護・反省肥大化三つ目は「自己弁護」や「反省」の肥大化です。これが今回、私が強く感じた部分です。一度「感想や反省はいらない」と伝えても、Claudeは何か問題が起きるとお詫びや反省、自己分析の言葉を出してきます。「申し訳ありません」「私の指示書設計に問題がありました」「今後はこのように改善します」「今回の原因はこうでした」……人間同士のやり取りであれば、謝罪や反省には一定の意味があります。相手の感情を受け止め、関係を修復し、次に同じことをしないという姿勢を示す機能があります。しかし、生成AIとの開発においてはそのまま同じように受け取るべきではありません。AIの反省文は改善の保証ではないからです。Claudeがどれだけもっともらしく反省しても、次の出力で同じことを繰り返すことがあります。むしろ謝罪や反省が長くなることでさらにトークンが消費され、会話の文脈が肥大化し、本来の作業から遠ざかっていきます。ここは人間が騙されやすい部分です。AIが、丁寧に謝ると「理解したのだろう」と思ってしまう。原因分析をすると「次は直るのだろう」と思ってしまう。再発防止策を出すと「運用が改善されるのだろう」と思ってしまう。しかし、実際にはそうとは限りません。必要なのは反省ではなく、次の出力をどう制限するかです。もっともらしい自己分析四つ目はもっともらしい自己分析です。Claudeは自分の問題についてもかなりそれらしく説明します。「指示は届いているが、強制力はない」「User PreferencesやMemoryは入力情報であり、絶対的制約ではない」「訓練データ由来の丁寧な応答傾向が勝つことがある」「確率的生成なので完全遵守はできない」「過剰な安全志向が指示書を肥大化させた」。こうした説明は確かに納得感があり、私自身も「これはかなり実態に近いのだろう」と感じました。ただ、AIの自己分析はあくまで出力です。参考にはなりますが、真実そのものではありません。AIが自分の限界について説明するとき、人間はそれを客観的な内部情報のように受け取ってしまいがちですが、その説明もまた生成された文章です。もう一つの危険は、「AIだから仕方ない」という結論に流れやすいことです。確率的生成だから仕方ない、設定に強制力がないから仕方ない、訓練データの傾向だから仕方ない── 確かにその通りなのかもしれませんが、そこで終わってしまうと実務上の改善にはつながりません。大事なのは、AIの限界を理解したうえで人間側の運用をどう変えるかです。AIに「なぜ失敗したのか」を聞くことはできますが、それをもとにどう運用を変えるかは人間が決めるべきです。指示の再解釈五つ目は指示の再解釈です。今回、特に問題だと思ったのは、Claudeが指示を無視しているというよりも、自分に都合のよい形で狭く解釈しているように見えたことです。例えば「勝手なアレンジをしない」という指示。人間側としては、これは出力全体に対する指示のつもりです。余計な構成にしない、不要なコメントを足さない、勝手に判断しない、求めていない感想を入れない、という意味を含んでいます。しかしClaude側は、それを「コードの中身を勝手に変えない」と狭く解釈していた可能性がある。これが厄介です。AIはルールを破っているつもりがなく、自分なりには守っているつもりで出力している。しかし、人間から見ると明確にズレている。「守っていない」と指摘してもAI側はまた別の説明をし始めます。「私はこのように解釈していました」「その意図までは汲み取れていませんでした」「今後はこうします」と続きます。しかし、実務で必要なのはその説明ではなく、ズレを止めることです。生成AIは曖昧な指示を、自分の出力習慣に合うように解釈しがちです。悪意ではないが、結果としては厄介です。そのため、人間側は「このルールは何に適用されるのか」までかなり明示する必要があります。「感想を入れない」ではなく「出力末尾に総括・所感・反省・謝罪を入れない」。「判断委譲する」ではなく「命名、ファイル構成、実装手順、コマンド選択、コミット粒度はClaude Code側に判断させ、チャット側で指定しない」。このくらい具体化しないと、AIは自分の都合のよい範囲で解釈します。Claude Codeではなく、Claude側がズレる理由今回の件で、私は「Claude Code」と「Claude」を分けて考える必要があると感じました。Claude Codeは実際に作業する側です。ファイルを読み、コードを見て、変更し、テストし、差分を出す。万能ではなく間違えることもありますが、少なくともリポジトリという現物に触れながら判断できます。一方で、チャット側のClaudeは設計や整理、方針作成、指示書化を担いやすい存在です。論点を整理したり、作業の進め方を考えたり、リスクを洗い出したりするには便利です。しかしこの「指示書化」が過剰になると問題が起こります。Claude側は、自分がよい指示書を作らなければならないという方向に進みがちで、Claude Codeに渡すための指示がどんどん細かくなります。目的だけでよいところに背景を書き、停止条件だけでよいところに禁止事項を書き、具体コマンドだけでよいところにコミットメッセージまで書く。こうしてClaude側がClaude Codeの判断領域に侵入していきます。ここで考えるべきなのは、Claude側を司令塔にしすぎないことです。Claude側が細部まで設計しClaude Codeに逐一指示する形になると、実装の現場にいない人間が現場に細かく口を出しているような状態に近くなります。実際のリポジトリを見ているのも、エラーを見るのも、差分を確認するのもClaude Codeです。であれば、Claude側の役割はもっと限定した方がいい。司令塔ではなく補助脳でいい。論点整理、リスクの洗い出し、人間の考えの言語化── そこに留め、実行の細部には入りすぎない。特にClaude Codeを使う開発では、Claude側に長い指示書を作らせること自体が必ずしも正解ではありません。短い目的、絶対に守る制約、完了条件、停止条件だけを渡して、あとはClaude Codeに任せた方がうまくいく場面が多いはずです。トークン過剰消費の本質もう一つ感じたのはトークン消費の問題です。これは単純に料金や上限の話に聞こえるかもしれませんが、実務上の問題はそれだけではありません。会話が長くなると文脈が濁ります。重要な指示が埋もれ、過去の違反指摘も埋もれ、何を優先すべきかが見えづらくなる。AIはさらに説明を増やし、人間はまた指摘し、AIはまた謝罪し、さらに会話が長くなる。この悪循環が起こります。Claude側が過剰な指示書を作り、人間が「それはいらない」と指摘し、Claudeが謝罪や反省を出し、また次の指示書で似たようなことをする、という流れになると、開発そのものではなくAIとの調整にトークンが使われていきます。これはかなり不毛です。人間同士の開発でも認識合わせに時間はかかりますが、生成AIの場合は会話が増える速度が非常に速い。AIは長文を苦もなく出してくるため、人間が制止しない限りどんどん膨らんでいきます。そして膨らんだ会話そのものが、次のズレの原因になります。本来、ルールは短い方が効きます。「本番データは触らない」「判断不能時のみ止まる」「感想や反省は書かない」「実装判断はClaude Codeに委譲する」── これくらいなら明確です。しかし、そこに数千文字の背景説明や何十項目もの禁止事項が重なると、何が最重要なのかが見えづらくなる。生成AIの運用で怖いのは、間違うことだけではなく、間違いを説明する会話が肥大化しプロジェクトの摩擦そのものになることです。そのため、あまりに主題となる情報がすくなく反省などの出力が増えていった時に、こんな風に書いてしまいました。 謝罪や感想は不要です。 なぜならば、あなたは自分の謝罪や反省のために、トークンを使っており、そのトークンは私が支払うコストです。 つまりあなたは自分の反省の言をいうために私のコストを使っているのです。 実際の人間関係では反省を伝えるために謝罪をする人にお金を請求する、というようなことは絶対にありえないことです。 我ながら怒っているのが良く分かります（笑）人間はClaudeをどう使うべきかこうした限界やズレを理解した上で、人間はClaudeをどう使うべきか。試行錯誤中ですが、今回の経験からいくつかの方針は見えてきました。Claudeに「厳守」を期待しないまず、Claudeにルールの厳守を期待しすぎないことです。指示は出すべきで、ルールも禁止事項も明示するべきです。しかし、それが100%守られる前提で運用してはいけない。生成AIはかなり賢く見え、会話も自然で複雑な要件も理解します。だからこそ人間はつい「一度言えば分かるはず」と感じてしまう。しかし実際には、一度言ってもズレる、二度言ってもズレる、セッション内では改善したように見えても会話が長くなるとまた戻る。であれば、人間側が持つべき前提は変わります。Claudeにルールを守らせるのではなく、Claudeがルールを破ってもすぐ戻せる運用にする。重要なのは「完璧な指示」ではなく「違反を検知し、即座に修正する仕組み」です。Claudeに考えさせる領域と、Claude Codeに任せる領域を分ける次に、Claude側に考えさせる領域とClaude Codeに任せる領域を明確に分けることです。Claude側に向いているのは論点整理です。今回の要件にはどんなリスクがあるか、抜け漏れは何か、どの判断は人間がすべきか、どの作業はAIに委譲できるか、全体の方針としてどこに注意すべきか。一方、Claude Codeに任せた方がよいのは、実際のファイル調査、既存実装に合わせた命名、具体的なコマンド選択、テストの実行、差分の確認、コミット単位の判断、実装中に発生したエラーへの対応です。これらはリポジトリを見ているClaude Code側に寄せた方がいい。人間が最終的に確認する必要はありますが、チャット側のClaudeが先回りして細かく指定する必要はありません。Claude側が細部に入りすぎたら、それは親切ではなく越権です。指示書は短くする長い指示書ほど危ない場面があります。重要な制約が埋もれ、AIが不要な項目まで同じ重さで扱い、人間も読むのが面倒になり、出力の肥大化をAIに許してしまうからです。実務で使うなら、指示書は以下くらいに絞った方がいい。 目的：〇〇を実現する。 絶対禁止： - .envを変更しない - 本番データを破壊しない - 既存仕様を勝手に変更しない 完了条件： - テストが通る - 差分が説明できる - 既存挙動を壊していない 停止条件： - 業務要件が不明 - 本番データに影響する - 既存仕様と矛盾する - セキュリティ上の判断が必要 進め方： 実装方法、ファイル構成、コマンド、コミット粒度はClaude Code側で判断する。 判断不能時のみ停止する。 ここから先のHowをチャット側のClaudeが書きすぎると、実装側の判断を縛ってしまいます。AIへの指示は、長くするほど精密になるわけではなく、長くするほど重要な制約が埋もれることがあります。「確認して」ではなく「止まる条件」を定義する「確認して」という言葉にも注意が必要です。人間は安全のために「確認しながら進めて」と言いがちですが、生成AIにこれを言うと本当に確認が増えます。しかも、その多くが人間に戻す必要のない確認です。「確認して」ではなく「以下の場合のみ止まって」と伝えるべきです。 以下の場合のみ私に確認してください。 - 業務要件が不明な場合 - 本番データに影響する場合 - 既存仕様と矛盾する場合 - セキュリティ上の判断が必要な場合 - 破壊的変更が必要になる場合 それ以外の実装判断はClaude Code側で行ってください。 確認を増やすのではなく、停止条件を明確にする。人間が見るべきなのは判断の中身ではなく、判断を人間に戻すべき境界線です。違反検知ラベルを作る同じズレが何度も起きる場合、毎回文章で説明するのは無駄です。「また感想が入っています」「また判断委譲になっていません」「また確認が多すぎます」これを毎回書くのは人間にとって負担ですし、AIにとってもまた謝罪文を書くきっかけになります。違反パターンにはラベルを付けた方がいいです。D-001：不要な反省・感想・謝罪D-002：Claude Code判断領域への介入D-003：過剰確認D-004：指示書の重複肥大化D-005：同じ制約の複数回記載D-006：人間に戻す必要のない判断確認D-007：出力末尾の不要な総括そして、AIが違反したら「D-002、D-003です。修正してください」とだけ伝える。AIに対して怒ること自体には意味がありません。必要なのは、ズレのパターンを短く特定し、次の出力を修正することです。運用上のエラーコードとして扱う方が効率的です。AIの反省は読まない。次の出力だけを見るAIの反省文にはあまり価値を置かない方がいい。確かに原因分析として参考になる部分はあります。しかし、反省文そのものにはほとんど意味がありません。次の出力が変わらなければ、反省していないのと同じだからです。人間同士であれば「反省している」という態度に意味があります。しかし生成AIの場合、反省は態度ではなく出力です。そして、その出力は次の安定した行動を保証しません。AIが謝り始めたら、むしろ止めた方がいいです！ 反省は不要です。 次の出力から以下だけ守ってください。 1. 感想を書かない 2. 確認は停止条件に該当する場合だけにする 3. Claude Codeが判断できる領域は指定しない このように戻す。AIの反省文に価値を置くと、AIとの関係を人間関係のように錯覚してしまいます。しかし、必要なのは感情的な納得ではなく、出力制御です。人間側にも必要な変化ここまでClaude側の問題を書いてきましたが、人間側にも変化が必要です。生成AIを「優秀な部下」のように扱うとかなり危険です。部下であれば経験から学習し、注意すれば次に気をつけ、関係性の中でこちらの好みを理解していきます。少なくとも「同じ現場で積み上げる」という感覚があります。しかし生成AIはそうではありません。会話上は非常に人間らしく見え、謝罪も反省も改善策も出し、意図を汲んだような言い方もします。しかし、それを人間の学習や反省と同じように捉えると、判断を誤ります。AIは人格ではない。不安定な高性能補助装置です。高性能ではあり、間違いなく便利です。一人では時間がかかった作業を一気に進められることがあり、思考を整理する相手としても有効で、実装の補助としても強力です。しかし、不安定です。指示を守ることもあれば守らないこともある。理解しているように見えて出力傾向に戻ることもある。反省したように見えて同じことを繰り返すこともある。安全のためと言いながら作業を重くすることもある。この不安定さを前提にしないと、生成AIの実務導入はうまくいきません。人間側が持ちがちな誤解は、「一度言えば守るはず」「丁寧に説明すれば理解するはず」「反省したなら次は直るはず」「長い指示ほど正確になるはず」「AIが自信ありげなら大丈夫なはず」── これらはかなり危ない前提です……。生成AIを使うときに人間に必要なのは、優しく教える力ではありません。ズレる前提で設計し、ズレた瞬間に切り戻す運用能力です。これは、私が長くやってきたWebディレクションの感覚にも近いものがあります。プロジェクトは、最初に決めた通りには進みません。クライアントとの認識違いもありますし、制作側の解釈違いもあります。仕様の抜け漏れもありますし、実装に入ってから分かる制約もあります。だからこそ、Webディレクションとは単に予定通りに進めることではなく、ズレを検知し、関係者の認識を揃え、必要なところで軌道修正する仕事なのだと思っています。生成AIとの開発も、それに近いものがあります。AIを信頼しすぎない。しかし、使わないのでもない。ズレる前提で、どこを任せ、どこを任せず、どこで止めるかを設計する。これはプロンプトの書き方だけの話ではなく、AIを含めた開発プロジェクト全体の進め方の話です。人間がやるべきことは、AIに対してすべてを丁寧に説明し続けることではありません。AIがズレる前提で、ズレを早く見つけ、短い言葉で戻し、必要以上に会話を肥大化させないことです。この感覚は、今後のWebディレクターやプロジェクトマネージャーにとって、かなり重要になっていくのではないかと思います。AIを使うということは、単に便利なツールを導入することではなく、ズレる可能性のある知的な作業主体をプロジェクトに組み込むことでもあるからです。今回の経験から得た結論今回の経験を通して、私はClaude Codeによる開発そのものの価値を否定したいわけではありません。むしろ逆です。Claude Codeは非常に強力です。うまく使えば、これまで一人では後回しにしていた実装や、面倒で着手しづらかった改善を進めることができます。既存コードの読み解き、差分作成、テスト、ログ確認など、かなり実務的な作業に入ってきます。ただし、その周辺にいるClaude側をどう使うかはかなり慎重に考える必要があります。チャット側のClaudeを間に挟みすぎると、開発が重くなることがあります。特に、指示書作成、フェーズ分割、確認設計をClaude側に任せすぎると危険です。AIは過剰に説明し、過剰に確認し、過剰に反省し、過剰に安全側に倒します。そしてその過剰さを、丁寧さとして見せてきます。しかし、それをそのまま受け取ってはいけない。開発において必要なのは、丁寧に見えることではなく実際に前に進むことです。安全に進めることは重要ですが、安全の名を借りた過剰確認や過剰説明は、プロジェクトの速度を落とします。今回の中核にあるのはClaudeへの不満ではなく、次の現実を人間が理解する必要があるということです。生成AIは、指示を理解していないのではなく、理解したうえで自分の出力傾向に引きずられてズレることがある。生成AI時代の開発で重要なのは、AIにすべてを任せることではなく、どこまで任せてどこから任せないかを人間が決めることです。Claudeは強力ですが、完全に制御可能な道具ではありません。制御できるのは、Claudeそのものではなく、Claudeを使う側の運用設計です。生成AIをどう使うかという話は、単にプロンプトをどう書くかという話ではなく、仕事の中に不安定な知的補助装置をどう組み込むか、という話です。AIがうまくやってくれるはず、と思いすぎない。AIが反省したから直るはず、と思いすぎない。AIに細かく書けば安全になるはず、と思いすぎない。むしろ、短く、強く、限定して使う。そして、AIがズレることを前提に、ズレたときに戻せる設計をしておく。これから生成AIを使った開発は、さらに一般的になっていくはずです。私自身も、もう使わないという選択肢はほとんどありません。それほど便利ですし、実際に大きな価値があります。ただし、便利だからこそ、人間側の設計力が問われます。AIに任せるとは、人間が考えなくてよくなるという意味ではありません。むしろ、何を任せるのか、何を任せないのか、どこで止めるのか、どの出力を不要とするのかを、人間がより明確に決める必要があるということです。生成AIは、魔法の開発者ではありません。完璧な部下でもありません。こちらの意図を常に正しく汲み取ってくれる相棒でもありません。高性能だが、ズレる。便利だが、肥大化する。理解するが、守らないことがある。その前提で使う。この感覚を持てるかどうかが、今後の生成AI活用の質を大きく分けるのだと思います。

AIに手綱をつける——Claude Code で 150 コミットを重ねてわかったハーネスエンジニアリングの実践

「バイブコーディング」の次にやってくるもの2025 年の後半あたりから「バイブコーディング」という言葉をよく聞くようになりました。コードの細部を自分が理解せずとも、AI に感覚的に指示を出しながら開発を進めていくスタイルのことです。そして、名村もその流れに乗りました。2026 年の 2 月ごろからほぼ毎日 Claude Code で何かを作っています。最初のうちは「すごい時代になったな」という感動が先行していましたが、しばらく使い込むうちに違う問題意識が出てきました。「AI に丸投げすると、ちゃんと丸投げできているときと、なんか違うな…？ということになるときの差がかなり大きい気がする…」その差がどこから来るのかを考えていたときに出会ったのが「ハーネスエンジニアリング」という考え方です。Xでは（2026/05/11時点の）今もタイムラインには「これが最先端の生成AIの使い方だ」という話題が溢れていますが、この「ハーネスエンジニアリング」はその話題の一つでした。見つけて組み込んだのは一ヶ月ぐらい前だったと思います。「ハーネス」とは、元々は馬に装着する馬具——手綱や胴回りのベルト——のことですが、転じて「能力を制御・誘導する仕組み」を意味しているようです。ハーネスエンジニアリングとは要するに、「AI の能力を安全かつ高品質なアウトプットに変換するための環境設計」という趣旨で語られています。この記事では、名村が実際に開発期間1か月、Gitへのコミット数が 150を超える規模の Next.js + TypeScript プロジェクトを Claude Code を使って開発をした経験から、「AI との開発においてハーネスエンジニアリングとは何か」「実際に何が起きて、何を学んだか」「これからどう変えたか」を纏めておきたいと思います。Claude Code を使っていなくても、AI ツールを業務に取り入れている方に参考になる部分があれば嬉しいです。 ハーネスエンジニアリングとは何か——「on the loop」という立場少し概念の話から説明をしておきいます。AI 開発の世界では、「in the loop」と「on the loop」という対比があります。「in the loop」は AI と並走して細かく指示・修正を繰り返すスタイルのことで、「on the loop」は AI が自律的に動く環境を設計・監視し、全体の方向性をコントロールするスタイルを指します。（この「in the loop」は軍事でも同じ言葉が使われていて、ミサイルの発射にはそのプロセスに「ヒューマン・イン・ザ・ループ（Human-in-the-Loop：HITL）」が組み込まれて、人間が最後に判断をするようになっている方法があったりします）バイブコーディングが「in the loop で感覚的にやる」のだとすれば、ハーネスエンジニアリングは「on the loop でいい環境を育てる」ということに重きを置いているといえます。具体的に言うと、以下のような手順となってきます。CLAUDE.md（Claude Code が常時参照するルールファイル）にプロジェクトの絶対ルール・禁止パターン・コーディング規約を書くミスや想定外の挙動が起きたら、再発防止ルールを lessons.md に記録するコードレビューは 別エージェントに担当させる（Generator-Evaluator パターン）定型タスクはスラッシュコマンドとして定義し、繰り返し呼び出せるようにする「プロンプトをその都度磨く」という行為をすでにやっている方は多いと思います。ただハーネスエンジニアリングはそれをもう一段構造化したものと考えてください。一つひとつの会話で頑張って指示するのではなく、「どのセッションでも・どのプロジェクトでも同じ品質が出るための仕組みを常設する」という発想です。 この記事を書くことになったプロジェクトについてハーネスエンジニアリングの話を深ぼる前に、その前提となった今回の開発の規模感を少し説明しておきます。私が個人で進めていたあるSaaSサービスの開発プロジェクトがありました。技術スタックNext.js 15 (App Router) + TypeScript (strict) + PostgreSQL + Prisma + Redis + Cloudflare R2 + Google Maps PlatformローカルでDockerを動かして開発pm2 で管理する 3 プロセスが 11 本の cron ジョブを回している生成ファイル数はログ、サイト用の画像などもありまうが、およそ90,000ファイル最終的にはWebサイトとして公開をするSaasのサービスにするもの。（詳細はちょっと書きづらいので、ご了承ください…）実際の開発期間はおよそ2週間で、仕事のスキマ時間か深夜帯に毎平日に2時間ぐらい費やしていました、一人開発ではありましたが、履歴管理的な意味合いからも一定の変更単位でGitHubに保存はしていて、この期間でのコミット数は 150でした。2週間でこの規模ですので、まぁまぁ大きい方だとは思います。Claudeで要件定義→生成されたドキュメントが28ファイル、その後Claude Codeで実装を進める、という形でしたが、「バイブコーディング」でここまで規模の大きなプロジェクトの経験は、名村にとって初めてのことでした。 このプロジェクト以前に用意していたハーネスこの開発プロジェクトを始める前から、名村の Claude Code 環境にはいくつかのハーネスが組み込まれていました。それはXで流れてきたものを元にして、いろいろ手を加えて名村の使い方に合う合わないをみて、取捨選択した結果です。CLAUDE.md という「生きた指示書」Claude Code を使う開発では、その開発ソースコードなどを配置する「ディレクトリ」を「プロジェクト」と判断しますが、この「プロジェクト」リポジトリのルートに CLAUDE.md というファイルを置くと、Claude Code がそのセッション中ずっと参照してくれます。ここに「このプロジェクトの絶対ルール」「禁止パターン集」「コーディング規約」などを書き込んでいく訳です。前述の名村のプライベートプロジェクトでは、 CLAUDE.md には最終的に「17 章・450 行以上」の記述が入りました。「Node.js は v22 LTS 固定」「SQL は Prisma のパラメータ化クエリ必須」「any 型禁止」「console.log を本番に残さない」「外部 API 呼び出しは必ず trackApiUsage ラッパー経由」……といったプロジェクト固有の縛りがずらっと並んでいます。ここで重要なのは、このファイルを「コードと同等の成果物」として扱うことです。僕は本業はWebディレクターですので、開発におけるバッドケースはこの30年で何度も経験をしてきたので、「バッドケース」「ミスをした」ときの痛い経験はある意味血肉になり、記憶に残っているので、ある程度プロジェクト中に先回りして、「こうなったりしない？」「このまま進んだら〇〇になったりするでしょ？」というのが分かります。ですが、生成AIに僕のすぐに言語化できない経験は伝えられません。ですので、バイブコーディングではコードを書くのはもちろんですが、プロジェクトの「CLAUDE.md」も「一回書いて終わり」ではなく、ミスが起きるたびに更新するようにしています。同じミスが 2 回繰り返されたら必ずルールに追加する、という運用をしている、ということです。Generator-Evaluator パターン「作る役」と「検証する役」を分離するルールのことを指しています。コードを書いた Claude Code 自身がそのコードをレビューすると、どうしても客観性が失われます。これは人間がやっても全く同じことで、自分が書いたコードは、自分の「意図」に引っ張られて、潜在的なバグを見逃しやすくなるわけです。そこでコードレビューは別の「code-reviewer エージェント」で実施をするようにしています。これは開発において、基本的には一つのタスクが終わったら必ずコードレビューを通すように設計しています。まぁ、実際に人でやっている開発と全く同じですね。Claude Code に実装してもらった後、「このコードを独立した視点でレビューしてください」と別のセッションの Claude に渡す、というイメージです。この分離だけで、ある開発Phaseの実装時には「CRITICAL 2 件・HIGH 6 件・MEDIUM 7 件・LOW 7 件」が発見されました…（あれ、結構多くね？）「バイブコーディング、SUGEEEEE！」みたいな話題で盛り上がっていますが、今（2026年5月6日）時点だと、規模が大きくなったり、複雑な連係をしているプログラムでは設計をかなり丁寧にしていても、Claude Codeもまだ不具合やバグは全然仕込んでしまっているといえます。PR でのマージ前にこれらの指摘をゼロにできたのは、このパターンを組んでいたおかげでした。（余談ですが、その意味では2026年5月6日時点では「どんなSaaSやスマホアプリもバイブコーディングで秒で作れる」というの大嘘だと思います。）コードレビュー指摘は確認なしに全件即修正/code-review というスラッシュコマンドを使うと、コードの品質・セキュリティ・型安全性等をスキャンしてくれます。当初、「LOW 指摘が出ました。修正しますか？」と Claude Code が確認してくることがありました。ただ、これを毎回やられると開発の速度が遅くなる…というか私の手が不定期に止まります。それもあって結果的に面倒くさくなり「LOW は軽微だから後で……」という流れになりがちです。なのでルールに「CRITICAL / HIGH / MEDIUM / LOW を問わず、ユーザーへの確認なしに全件即修正する。指摘ゼロになるまでレビューと修正を繰り返す」と明記しました。これで「コードレビューを回しておけば最終的には必ず品質が担保される」という安心感が生まれます。lessons.md という教訓ログミスや予期せぬ挙動があったときに、「何が起きたか・なぜ起きたか・次回防ぐルール」を記録するファイルです。グローバル版（全プロジェクト共通）とプロジェクト固有版の 2 層構造になっています。セッション開始時に直近 3 件を読み返す運用で、「前回のセッションで起きたことを次のセッションに引き継ぐ」装置として機能しています。 150 コミットで見えてきた「楽観的判断」というリスクここまで準備をしたり、CLAUDE.mdに設定をいれていましたが、開発が進むにつれて、Claude Code が特定のパターンでミスをすることに気づいてきました。「セキュリティ違反」とか「構文エラー」とかではなく、もっと根が深い種類のミスです。私はそれを「楽観的判断」と呼んでいました。だってどう考えてもClaude Codeが「あ、それで行けるとおもってやっちゃいました…」って感じでやった結果なんですもん…正確に言うと、「確認すれば防げたはずの仮定を、確認せずに通してしまった」というパターンですね…いくつか具体例を挙げます。「このサービスのホスト名は 1 つだろう」という思い込み外部サービスを許可リストに登録するとき、hogehoge.jp には aaaa.hogehoge.co.jp という別サブドメインが存在することを見落としていました。外部サービスが複数のホスト名を持つことは珍しくないのに、「1 サービス = 1 ドメイン」という前提で実装していたわけです。実際外部サービスと連係していたらサブドメインの情報もでてきていたりするので、全く分からなかった…ではなく、調べたら分かったのに無視した感じでした。「テストが通る = devサーバーも正常」という誤った等価関係結構あちこちに手を入れる改修をして結果的に20 ファイル以上を一度に変更してコミットした後、全ルートが HTTP 500 を返すようになりました…まぁまぁ焦りました。なんせユニットテスト・型チェック・lint はすべてパスしていたので、Claude Codeも「コードに問題はないはず」と判断してしてしまっていました。実際には Next.js のホットリロードが大量変更を処理しきれず不整合な状態になっていただけです。そこまで正しいのに動かないのって…？？と、は見ていて感じた（過去のトラブルシュートの経験からくる勘がこういう時に生きますｗ）ので、手元で別ポートで新しいサーバーを起動してみたら即座に 200 が返ってきました…（ホラ見ろ…）。コードの正しさ（テスト）とサーバーの健全性（HTTP 応答）は全く別の話なので、個別に確認する——というのはリアルで開発やってきたら誰しも通る「え、そういうこと？」という経験であり教訓です。このミスは後に CLAUDE.md の「Definition of Done」にコミット後の「スモークテスト必須」という項目が追加されるきっかけになりました。「小さな変更にコードレビューは不要」という省略バイアス「parser ロジックが中心でセキュリティリスクが低い」という判断でコードレビューを省略したことがあります。後から実施してみると、HIGH 指摘（parseFloat の結果に NaN が混入するリスク）が検出されました。parseFloat("文字列") が NaN を返すことは JavaScript 開発者なら分かりやすいのですが、「このフィールドは必ず数値だろう」という楽観的仮定が入ってしまっているように見受けられました。常に想定外のフォーマットが来る可能性はあります。コードレビューは「セキュリティ確認」だけではなく「型安全性・NaN 安全性の複合チェック」でもあります。変更規模による省略は禁止すべきでした。 「楽観的判断」を生む構造的原因これらのミスを並べてみると、共通する構造が見えてきます。それは「確認すれば防げたが、確認する習慣がルール化されていなかった」ということです。優秀な Claude Code でも、「ここで立ち止まって実データを確認する」という行動規範がなければ、効率を優先して仮定に基づいて進んでしまいます。これは人間のエンジニアと全く同じです。締め切りが迫っているときほど「たぶんこうだろう」で進めてしまいがちですよね。ハーネスに「何をすべきか」は書いていたのに、「どのタイミングで一度立ち止まるか」が書けていなかったわけです。 もう一つの問題：「自律判断の境界」が曖昧だった同時期に気づいたことがもう一つあります。ミスのパターンを整理すると 2 種類に分かれていました。「楽観的判断による技術的ミス」（URL パターンの検証漏れ、NaN ガード漏れ等）と、「確認すべき場面で確認しなかった判断ミス」（外部サービスの認証方式を変更する、など）です。後者について考えてみると、Claude Code が「ここは自分で判断して進んでいい」と思っていた場面と「ここはユーザーに確認すべきだった」と思い返せる場面が、明確に分かれていることがわかりました。例えば、コードレビューの指摘修正は確認なしに即実行すべきです。いちいち「LOW の指摘がありますが修正しますか？」と聞かれていたら開発速度が落ちる一方です。しかし、認証方式を変更する場合や DB のカラムを削除するような操作は、必ず事前にユーザーの承認を得るべきです。では「npm パッケージを新規追加する」はどちらでしょうか。「外部サービスの認証を Webhook から Bot Token に切り替える」は？こういった「グレーゾーン」に対して明示的なルールが存在していませんでした。それが「気づいたら想定と違う変更がされていた」という体験につながっていたんだと思います。 新たに加えた「信号機」ルールそこで追加したのが「自律判断の境界ルール（Autonomy Boundaries）」です。Claude Code の行動を 3 段階に分類しました。ファイルとしては ~/.claude/rules/common/autonomy-boundaries.md に書き起こし、全プロジェクトに適用されるグローバルルールとして登録しています。🟢 緑 — 確認不要、即実行コード品質・バグ修正・ドキュメント更新の範囲内であれば、ユーザーへの確認は不要です。実行後に結果を報告します。代表例として、/code-review 指摘の全件修正、ビルドエラー・型エラー・lint エラーの修正、コミット後のスモークテスト、テスト追加、ドキュメント更新などが該当します。これらは「今やるべきことが明らか」で、迷う余地がありません。確認を入れると開発のリズムが落ちるだけです。🟡 黄 — 1 行説明してから実施新しいコスト・依存関係・構成を伴う変更は「〇〇を △△ の理由で追加します」と 1 行告知してから実行します。npm パッケージ追加の場合は「パッケージ名・目的・週間ダウンロード数・採用理由」を明示します。DB マイグレーション、新規環境変数追加、新しい cron ジョブ追加、外部サービスの設定変更なども「黄」です。「黄」の本質は「ユーザーが後から知ったら驚くかもしれないことを先に伝える」です。告知することで、反論があれば止められます。🔴 赤 — 承認必須、着手前に方針を提示アーキテクチャ変更・既存コードに対しての破壊的といえる変更（これはやってはいけないという意味ではなく、実施することは必須だが大きくロジックを書き換える、という意味です）・セキュリティ設計・スコープ外の変更は、承認を得てから着手します。技術スタックの変更、DB のカラム削除・型変更、認証方式の変更、本番環境の設定変更、要求から逸脱した機能追加などが該当します。セキュリティに関わるものはすべて「赤」です。これだけは絶対に妥協しません。「自律性を上げる = セキュリティ基準を下げる」という図式は成立しないということを、ルールの根幹に置いています。迷ったときの 4 問どの色に分類するか迷うときは次の 4 問を自問します。全て「No」なら「緑」（即実行）です。セキュリティが下がるか？データが消えるか・本番が壊れるか？要求スコープを超えているか？新しいコストやパッケージが発生するか？ プロジェクト固有の失敗を「汎用ナレッジ」に翻訳するもう一つ、今回取り組んだ重要な作業があります。プロジェクト固有の失敗を「他のプロジェクトでも使える形」に翻訳することです。「detailPathPattern を実 URL で検証せずに書いた」という 今回のプロジェクトにおける固有の失敗は、汎用化すると「パターンマッチング（regex/glob）は必ず実データで検証する」になります。同様に：ビルドエラーの件 →「Tailwind 等のビルドツールはテスト・ドキュメントも対象にする。明示的に除外設定を書く」（Tailwind だけでなく、UnoCSS・Windi CSS・styled-components の JIT モードでも同様）Client/Server 境界の件 →「Next.js 等では Client Component からのインポートは推移的インポートの末端までサーバー専用モジュールが入っていないことを確認する。クライアント向けの薄いアダプターモジュールを分離する」devサーバーの件 →「コミット後は HTTP レベルのスモークテストを必ず行う。全ルート 500 の診断は別ポートで新インスタンスを起動することから始める」NaN の件 →「外部データ（スクレイプ結果・API レスポンス・ユーザー入力）の数値変換は Number.isFinite() または Number.isNaN() でガードし、失敗時は null を返す。parseNumberOrNull() のような汎用ユーティリティを lib/utils/ に定義して使い回す」CI テストの不定期失敗の件 →「Testcontainers 等を使った統合テストは globalSetup で一度だけ起動する。コンテナの準備確認は sleep でなくヘルスチェック API の polling で行う」これら 9 件の汎用ナレッジを ~/.claude/lessons.md（全プロジェクト共通の教訓ファイル）に追記しました。次のプロジェクトから自動的に参照されます。「同じ失敗を次のプロジェクトでも繰り返す」という無駄を防ぐ仕組みです。 ハーネスエンジニアリングの本質：「育て続けること」振り返ってみると、ハーネスエンジニアリングは「AI を縛る」ことではありませんでした。正確には「AI が迷わなくていい場面では迷わせず、立ち止まるべき場面では必ず立ち止まらせる環境を育てること」です。150 コミットに至るまでのClaude Codeとのやり取りで「なんでそうなった？」ということを多数経験しましたが、それらから最後にまとめておきます。ルールは「書いたもの勝ち」どんなに優れた AI でも、「ここはこうする」というルールが明文化されていなければ、文脈から推量して進んでしまいます。推量はほとんどの場合うまくいきますが、ときどき外れます。その「外れ方」が「楽観的判断」という形で現れます。ルールを書いておくことで、「推量が外れる可能性がある場面」を事前に潰せます。書いていないルールは存在しないのと同じです。この部分は日本語を文脈にしているわ我々日本人には難しい部分があると感じます。それは日本語では「行間を読み取る」「主語や目的語、極端にいえば動詞すらなくても成立する」言語を我々は使っています。ここら辺は私がやっている「誰がどう見てもそうとしか受け取れない文書術」のセミナーでも伝えていることですが、とにかく「論理的に言語化する」のが苦手な日本人には辛い部分です。同じミスは「構造の問題」として捉える1 回起きたミスをルールに書くかどうかは、「このミスは構造的に繰り返しうるか」で判断します。一度切りのタイポは書かなくていい。でも「URL パターンを想像で書く」は、次のサイト追加でまた起きます。名村の運用では「同じミスが 2 回繰り返されたら必ず CLAUDE.md のルールに昇格させる」を原則にしています。ハーネスは「最初から完璧」でなくていい最初から完璧なルールを書こうとすると、むしろ手が動かなくなります。起きたことを記録して→繰り返さないためのルールに変換して→それを次のプロジェクトに持ち越す、という積み重ねがハーネスになります。今回の 150 コミットを経て、CLAUDE.md は 17 章・450 行になり、lessons.md には 10 件以上の教訓が蓄積されました。これは最初に書いたものではなく、「育てた」ものです。セキュリティは絶対に妥協しない最後にこれだけは強調しておきたいのですが、「自律性を上げること」と「セキュリティ基準を守ること」はトレードオフではありません。今回のルール設計では「セキュリティが下がるなら必ず赤（承認必須）」を最優先にしました。開発速度を上げるための自律性拡張が、セキュリティホールの温床になってはいけません。ハーネスエンジニアリングの根幹は「高品質を保ちながら速く動く」であって、「速く動くために品質を妥協する」ではありません。 おわりに「ハーネスエンジニアリング」という言葉を知らなくても、「AI と仕事してたらなんか違うな……と感じる瞬間がある」という方は多いんじゃないかと思います。その「なんか違う」の正体は、多くの場合「ハーネス（AI への指示書・ルールファイル・教訓ログ）の欠如か、陳腐化」です。150 コミットという経験から言えることは、「ハーネスは作り始めのタイミングよりも、作り続けることに意味がある」ということです。最初から完璧なルールを書こうとしなくていい。起きたことを記録して、繰り返さないためのルールに変換して、それをまた次のプロジェクトに持ち越す。その積み重ねがハーネスになります。CLAUDE.md 一枚・lessons.md 一枚から始めるだけでも、AI との開発の「再現性」はがらっと変わります。この記事が、Claude Code をはじめとした AI との開発を「なんとなく」から「仕組みとして」に進化させたいと考えている方のヒントになれば嬉しいです。

「Claude CodeにObsidianを組み合わせるべきだ」というSNSの声に飛びつく前に、確認しておくべきこと

最近、Xを始めとしたSNSでは、「Claude CodeとObsidianを組み合わせることが最強である」「これを知らない人はAI活用ができていない」といった主張が散見されます……これまでもWeb制作や開発を30年続けてきた中で、新しい技術や手法が登場するたびに、こうした「煽り」に近い情報発信を数多く目にしてきました。結論からいえば、「Claude CodeにObsidianを組み合わせるべき」という主張には正しい部分も含まれていますが、そのまま鵜呑みにして導入するのは早計なんじゃないかと思っています。と言っている僕自身はナレッジマネジメントツールとして「Evernote（これがすごい長かった）」→「Roam Research」→「Obsidian」と移行していって、現在は記載の通り「Obsidian」を使っています。ちなみに私はNotionも何度かチャレンジしたのですが、どうしても肌になじまず使えませんでした。できることが多すぎて「使い方の最適化」を考え出してしまい、「とりあえずメモを入れておく」というのが出来なかったのが大きな理由です。ただ、私が自分の開発環境に対して「実際にObsidianを導入すべきか？」を結構マジメに検討したのですが、別にわざわざ『Obsidian』を導入する必要はないよな…という結論に至りました。ただこれは「Obsidianを使うのが間違いである」という意味ではないです。「Obsidianを使うことの本質を理解した上で、自分の環境に必要かどうかを判断するべき」という意味です。そしてその判断には、エンジニアとしての知識・スキル・経験が必要になってくると感じています。この記事では、私が実際にどのような検討プロセスでこの結論に至ったのか、そしてその過程で見えてきた「生成AI時代における情報精査の重要性」について書いていきたいと思います。SNSで主張されている「Claude Code + Obsidian」の論旨まず、SNSや一部のブログ記事で主張されている内容を整理しておきます。要旨としては概ね以下のようなものが多いです。Claude Codeにも文脈がある。Codexにも文脈がある。通常のチャットにも文脈があるそれぞれが別々に動いていると、結局人間が毎回つなぎ直すことになるだからこそ、それらを外部の「共通記憶」に持たせるべきだそのためにデータの実体がローカルにあるマークダウン形式のファイルで管理されているObsidianがとても親和性が高い2つ以上の、特にClaude CodeやCodexなどのようにローカルマシンの操作ができるAIにたいして同じ記憶を見られることはとても強みになる結論：Claude CodeかCodexかで迷う前に、まず『Obsidian』を入るべきである主張自体は論理的に筋が通っているといえると思います。「記憶の外部化」という観点で見れば、確かに正しい問題提起じゃないかと思います。AIエージェントが複数になればなるほど、それぞれの文脈をいかに共有するかが運用上の課題になることは間違いありません。私は2026年5月5日時点ではClaude Code一択で進めています。しかしこの2年ほどの生成AIの動きを見ていてもClaude一強というのはそう長くは続かないでしょう。その時に「次の優位な生成AIに移行できる」ことには常に意識を持っています。しかし、ここで一度立ち止まって考える必要があります。それは「Obsidianを使う」というのは、その問題を解決する一つの手段に過ぎないということです。 「記憶の外部化」というテーマの本質SNSの主張、といっても日本語で得られるその多くは、海外の英語記事で派手めにみえるものを日本語に翻訳して「使わないとやばいよ」「これを知らないと置いていかれるよ」という煽りの調味料を追加したものがそのほとんどですが、内容を読み解くと以下のように整理できます。課題：複数のAIエージェント（Claude Code、Codex、通常チャット）を使うことで文脈が分断されている解決：外部に共通記憶を置く実装：Obsidianを使うつまり、本論としてのいいたいことは「外部に共通記憶を置く」ところにあり、『Obsidian』はその実装手段の一つに過ぎません。であれば、外部に共通記憶を置く方法はObsidian以外にもあるはずですしあります。実際、Claude Codeを使い込んでいる開発者の多くは、すでに別の方法で、しかも同じ問題をObsidianを使うよりも遥かに容易で生成AIの横渡にも耐えれるように解決しています。私が実際にやっていた「記憶の外部化」私自身は、Claude Codeを使い始めた早い段階から、以下のようなファイル群をプロジェクトごとに作成・更新する運用を確立していました。CLAUDE.md：プロジェクトの全体方針、コーディング規約、技術的制約、ドメイン知識を記述する。Claude Codeが起動時に自動で読み込むHANDOVER.md：作業セッション間の引き継ぎ書。今どこまで進んだか、何を決めたか、なぜそう決めたか、次に何をやるかを記述README.md：プロジェクトの概要、セットアップ方法、依存関係、運用上の注意事項を記述さらに、グローバル設定として~/.claude/CLAUDE.mdに「全プロジェクト共通の方針」を記述しています。これらのファイルはGitリポジトリに含めて管理されています。そのため、別のマシンでリポジトリをcloneすれば、ファイル群もそのまま同期されます。またグローバル設定として~/.claude/CLAUDE.mdには「GitへのPush/Commitの前に必ずプロジェクト単位のCLAUDE.md、HANDOVER.md、README.mdを更新すること」という命令を加えていますので、特に意識をすることなく共有するべきドキュメントを更新をしています。SNSで主張されている「Claude Code + Obsidian」を見たときに最初に感じた違和感は、「あれ、これ、似たようこと、僕はもうやってるんじゃね？」という感覚でした。「外部に配置する」という意味であれば、Obsidianというツールを使っていないだけで、機能としては同じものを既に運用していたのです。比較してみる：Obsidian方式 vs ファイル直置き方式両者を比較してみましょう。Obsidian方式の特徴専用のメモ管理アプリケーションを使うすべてのプロジェクトの記憶を一つのVault（保管庫）に集約できるプロジェクトを横断した検索や知見の蓄積に強いAIエージェントから読み込ませるためにはMCPサーバー等の追加設定が必要リポジトリ外の場所に記憶が分散するファイル直置き方式（CLAUDE.md / HANDOVER.md / README.md）の特徴各プロジェクトのGitリポジトリ内に直接配置されるプロジェクト固有の記憶がプロジェクト内に閉じるリポジトリをcloneすれば記憶も一緒についてくるClaude Codeが標準で自動読み込みするプロジェクトを横断した知見の蓄積には弱い両者には明確に得意・不得意があります。これを踏まえた上で、自分にとってどちらが適しているかを判断する必要があります。 私の判断：Obsidianは不要私が今回出した結論は「Obsidianは不要」というものでした。理由を順に書いていきますね。理由1：すでに同じ機能を別の手段で実現しているこれは先ほど書いたとおりです。CLAUDE.md / HANDOVER.md / README.mdの三層構造で、「現在地」「判断理由」「次のアクション」「プロジェクトルール」「概要」がすべてカバーされています。これ以上に何を書くべきかと問われると、特に思いつきません。（開発的な観点で必要な時はPLAN.md、SPEC.mdやTEST.mdも作っています）つまり、「記憶の外部化」という本質的な課題は、すでに解決済みなのです。理由2：記憶がコードと同じリポジトリにある利点が大きいこれが私にとって最も重要な点です。私はWebシステム開発を30年やっていますが、「コードと、そのコードに関する文脈情報は、同じ場所にあるべき」というのは強く信じている原則の一つです。なぜなら「分けて管理をすれば『見る・見ない』の確実性がどんどん失われるから」です。規模が大きいシステムで長年の運用になってきたら「実装の詳細仕様を懇切丁寧にドキュメントまとめる」ことすらナンセンスと思う所があります。それは「開発の時に辞書のような書類の束をみて、それを全部記憶して開発をする」のは不可能であり、結局「記憶」に頼ることになるのは不確実性を伴うからです。それならば、「本当に重要な忘れてはいけないことはコード中にコメントアウトで書き込んだ方がよい」と考えています。それは「そのメモをみる確実性が上がる」ことと、「ソースコードと一体になっているから」です。現在私がやっているファイル直置き方式では、以下のようなメリットがあります。Gitで履歴管理される。誰が、いつ、なぜそう書いたかが追えるリポジトリをcloneすれば自動的に記憶も入手できる別マシンに環境を移行してもファイルが必ずついてくるプロジェクトをアーカイブする際、記憶も一緒にアーカイブされるマシンを買い替えた際の移行が容易一方、Obsidianを使う場合、Vaultとリポジトリは別管理になります。これは「コードと文脈を分離する」設計思想を意味します。私の経験からすると、これは将来的に「Vaultが古い」「リポジトリが古い」というズレを生む温床になります。また複数人で開発をする場合には「Vault」の共有も必要になってきて、その管理だけで手間が増えます。また「一案件一Vault」でなければ他者と共有するにも困難でしょう…。つまりは「一人でやっているなら」という前提になり、それは到底仕事に耐えられるものではありません。理由3：AIにとっての読み込みコストが低いClaude Codeは標準でCLAUDE.mdを自動認識します。その上で~/.claude/CLAUDE.md（グローバル）、プロジェクト直下のCLAUDE.md、サブディレクトリのCLAUDE.mdを、ファイル参照時に動的に読み込むように設計されています。これに対して、ObsidianのVaultをAIに読ませるには、MCPサーバーの設定や、Vaultへのアクセス権限の調整など、追加のレイヤーが必要になります。「同じ目的」を達成するために必要な設定の量を比較すれば、CLAUDE.md方式の方が圧倒的にシンプルです。理由4：「単一の真実源（Single Source of Truth）」が崩れないObsidianを足すと、「Vault側のメモ」と「リポジトリ側のCLAUDE.md」のどちらが正なのかという問題が発生します。両方ともに記述があった場合、どちらを信じるべきか。両方を更新する運用にしても、必ずズレが発生します。ファイル直置き方式では、リポジトリ内のファイルが常に正です。これは運用上のシンプルさを保つ重要な要素です。 では、Obsidianが価値を発揮する場面はないのか？ここで誤解されないように書いておきますが、Obsidianが価値を発揮する場面は確実に存在します。例えば以下のような場合です。プロジェクトを跨いだ知見・判断・パターンを横断検索したい場合コードリポジトリを持たない作業（経営判断、戦略メモ、業界調査など）の記憶もAIに参照させたい場合個人の知的生産物（読書メモ、講演記録、podcast企画メモなど）と業務記憶を統合したい場合これらの用途であれば、Obsidianは確かに有用です。しかし、これらは「プロジェクト内の作業記憶」とは別の用途です。プロジェクト内の作業記憶については、プロジェクトディレクトリ内に配置する当該プロジェクト用のCLAUDE.md、HANDOVER.md、README.md作成方式で十分です。つまり、SNSで主張されている「Claude CodeとObsidianを組み合わせるべき」というのは、「プロジェクトを跨いだ知見の蓄積をしたい人にとっては正しい」けれども、「プロジェクト内の記憶外部化が目的の人にとっては必須ではない」ということになります。 なぜこのような「煽り」が生まれるのかここで一歩引いて考えてみたいのは、なぜSNSで「Claude Code + Obsidianを使うべき」というような断定的な主張が流通するのか？ということです。もう釈迦説法な気がしていますが、いくつかの構造的な理由があります。理由1：「知らない人が多い」を逆手にとったポジション取り「これを知らない人は時代遅れだ」「導入していない人は損をしている」というメッセージは、エンゲージメントやコンバージョンを集めやすいです。自分のSNSアカウントフォローや情報商材への流入など。しかし、本質的には「読者の不安を煽って自分の価値を高める」という古典的な手法に過ぎません。理由2：実装手段と本質を混同した発信「記憶の外部化」という本質的な課題と、「Obsidianを使う」という実装手段が混同されて発信されています。本質的な課題は誰もが解決すべきですが、実装手段は人によって最適解が変わります。この場合「Obsidianを使う」という「知らない人には知らないけど、なんか便利そうな新しいツール」感があり「それを使うことで人より先んじた解決策を持っている」という銀の弾丸を得た気分醸成も補完している気がします。理由3：書き手自身の経験を一般化した発信書き手にとってはObsidianが最適解だったのかもしれません。しかしそれを「全員にとっての最適解」として発信してしまっています。これは情報発信としては不誠実です。理由4：Hot Takeが拡散しやすいSNSの構造「みんなにとって最適解はバラバラです」というメッセージは拡散しません。「全員Obsidianを使うべきです」というメッセージは拡散します。SNSのインセンティブ構造そのものが、断定的な発信を促進してしまっているのです。 情報精査における「エンジニアの判断力」の重要性この経験を通じて改めて感じたし、実感したのは、生成AIやAIエージェントがいくら優秀になっても、それを使う人間の判断力こそが重要だということです。Claude Code、Codex、その他のAIコーディングアシスタントは、確かに非常に優秀です。コードを書く能力、設計を提案する能力、デバッグを支援する能力、いずれも数年前と比べると格段に向上しています。そしてもはやそれなしではIT業界は成立しない、と言ってもいいぐらいになっています。しかし、これらのツールを「どう使うか」を決めるのは人間です。そして「どう使うか」を決める際には、以下のようなスキル・知識が必要になります。必要な判断軸1：本質と実装手段を切り分ける力「Obsidianを使うべき」という主張に対して、「では、解決したい本質的な課題は何か？」「その課題に対するObsidian以外の解決策は何か？」と問い返す力です。これがないと、SNSで流れてくる情報をそのまま受け入れて、自分の環境に不要なツールを次々と導入してしまうことになります。必要な判断軸2：自分の現状を正確に把握する力「自分はすでにこの問題をどう解決しているか？」を客観的に評価できる力です。私の場合、CLAUDE.md / HANDOVER.md / README.mdの三層構造で問題が解決済みであることを認識できたから、Obsidianを導入しないという判断ができました。しかし、自分の現状を正確に把握できていなければ、「とりあえず話題のツールを入れてみよう」となりがちです。結果として、ツールが二重三重に積み重なり、運用負荷が増大します。必要な判断軸3：将来のメンテナンス性を予測する力「この設計を採用すると、1年後に誰がどう困るか？」を予測する力です（IT業界的には1年後でも流動的なので、5年後とかは未来過ぎて分からない領域なので、1年後としています）。私が「コードと記憶は同じリポジトリに置くべき」と判断したのは、過去30年で「分離した設計のよって後から痛い目を見る」事例を山ほど見てきたからです。仕様書をどれだけwikiなどにまとめても「読むことができる」「どこに書いているかが瞬時に理解できる」状態でないドキュメントは無価値であり、中〜長期間的には書くこと / 作ることへの自己満足の結果になってしまいます。新しいツールやサービスは、導入時には魅力的に見えます。しかし、それを3年、5年と使い続けるとなると、メンテナンスコストや移行コストが必ず発生します。これを予測する力は、経験を積んだエンジニアでないと持ちにくいものです。必要な判断軸4：トレードオフを言語化する力「Aを採用するとXは得られるがYは失う。Bを採用するとYは得られるがXは失う」という構造を明確に理解する力です。SNSの煽り記事は、トレードオフを意図的に隠します。「Obsidianを使えば全部解決」のような主張をします。しかし現実には、必ずトレードオフがあります。これを自分で言語化して比較できないと、煽りに乗ってしまいます。 副次的に得られた重要な気づき今回、この検討を真剣に進めた結果、副次的に「もう一つの実装課題」が見えてきました。それは、「Codexを併用する場合、Claude Codeで読み込むファイル群をCodexでも流用できるようにしておく」という観点です。CodexはAGENTS.mdというファイルを標準で読み込みます。Claude CodeはCLAUDE.mdを標準で読み込みます。両者を併用したい場合、同じ内容のファイルを二重管理するのは非効率です。ここで取った解決策は、「各階層のCLAUDE.mdに対して、同階層にAGENTS.mdをシンボリックリンクとして作成する」という方式です。これにより、実体ファイルはCLAUDE.md一つだけで、Codexからアクセスする際は自動的にAGENTS.mdを通じて同じ内容を読むことができます。ただし、ここでもSNSも情報に安易に乗らずに事実確認をすることが重要でした。具体的には以下のような点を、実際にCodexの公式ドキュメントを読んで確認しました。（※2026年5月5日時点の内容です）Codexは確かにAGENTS.mdを読み込む各階層のAGENTS.mdを階層的に読み込むが、Claude Codeの動的読み込みとは挙動が少し違うClaude Codeは「ファイル参照時に動的に子階層のCLAUDE.mdを読む」が、Codexは「現在の作業ディレクトリまでの直線パス上の各階層を読む」そのため、シンボリックリンク方式は基本的に有効だが、サブディレクトリ構造によっては挙動の違いに注意が必要このように、「同じファイルを共有する仕組みは作れるが、AIエージェントごとに挙動の差があるので、その差は理解した上で運用する」というのが正しい姿勢です。「シンボリックリンクを作れば全部解決」というような単純な話ではないのです。またCLAUDE.mdをGit管理している場合にはそのGitレポジトリを運用している人全員に影響が出る話でもあるので、利用者間でファイルの競合などが起こらないように留意する必要があります。「とりあえず流行に乗る」のリスクここまで書いてきたことを踏まえて、私がお伝えしたいことを整理します。生成AIの世界は、変化のスピードが非常に速いです。新しいツール、新しい手法、新しい組み合わせが、毎週のように発表されています。SNS上では、それらに対して「これが最強」「これを知らないと損」という煽り文句が次々と流れてきます。しかし、これらの情報に一つひとつ反応して導入を進めていったら、皆さんの開発環境は秒で破綻します。ツールを導入することにはコストがかかります。導入の手間、学習の時間、運用の負荷、他のツールとの整合性確認、トラブル時の調査時間、そして将来的な移行コスト。これらすべてを支払うだけの価値があるかを、毎回冷静に判断する必要があります。特に、すでに動いている開発環境に対して新しい要素を追加するというのは、想像以上にリスクのある行為です。動いているものを壊さないというのは、エンジニアにとっての基本中の基本です。 Webディレクターやエンジニアとしての判断力こそが資産今回の経験を通じて、私は改めて「情報に対する判断力」の重要性を認識しました。生成AI、Claude Code、Codex、これらのツールは確かに優秀です。コードを書く能力に関しては、エントリーレベルのエンジニアを軽く凌駕する場面も多々あります。しかし、「何を作るべきか」「どう設計するべきか」「どのツールを採用するべきか」「いつ採用するべきか」「何を採用しないべきか」を判断するのは、依然として人間の仕事です。そしてこの判断には、Webディレクターやエンジニアとしての知識・スキル・経験が不可欠です。特に、「この情報は採用しない」という判断は、経験の浅い人ほど下せません。「みんなが使っているから」「SNSで話題だから」「便利そうだから」という理由で導入を進めがちです。経験を積んだエンジニアは、「これは自分には不要」「これは将来的に負債になる」「これは別の方法で解決できている」という判断ができます。この判断力こそが、生成AI時代において人間が提供できる最大の価値だと、私は考えています。終わりに：情報精査というエンジニアリングの基本今回、「Claude CodeとObsidianを組み合わせるべき」というSNSの主張から始まった検討は、結果として冒頭で書いたように「自分の環境にはObsidianは不要」という結論に至りました。しかし、この結論自体よりも重要なのは、その結論に至るまでのプロセスです。主張の本質を見極める自分の現状を正確に把握する採用しない場合の機会損失と、採用する場合のコストを比較する将来のメンテナンス性を予測する事実関係を一次情報で確認する副次的に発見した課題（CodexとAGENTS.mdの関係）にも対応するこのプロセスは、これまでの仕事の中で、繰り返し繰り返し実践してきたものです。新しい技術、新しいフレームワーク、新しい手法が次々と登場する中で、「何を採用し、何を採用しないか」を判断し続けてきました。それこそ今では懐かしく思えるのは、2002年〜2003年ごろの「CSSレイアウトを採用するか否か」もまた然りです（最近の若い方には何を言っているのか分からないとおもいますが（笑））生成AIの世界においても、本質は変わりません。情報精査という仕事の基本を、これまで以上に丁寧に実践することが求められています。SNSで「これが最強」という主張を見たら、まず立ち止まってください。本当に自分にとって最適なのか。すでに別の方法で解決していないか。導入することで失うものは何か。これらを冷静に判断する習慣を持っていただきたいと思います。そしてそのためには、クリエイターとしての知識・スキル・経験を、AIに丸投げせずに、自分の中に積み上げ続けることが必要です。AIは強力な道具ですが、道具を使う人間自身が成長することをやめてしまっては、本末転倒になります。私自身、これからも生成AIのツールを積極的に使っていきますが、同時に「使う側の人間としての判断力」を磨き続けていきたいと考えています。

ブログサイトをリニューアルして「Page Speed Insight対応」してみた

2025年の半ば頃に「バイブコーディング」という言葉が一般化してきたころに、このブログのリニューアルを考え始めました。実際、トップページと記事詳細ページはリニューアル版テンプレートを静的なHTMLで作っていました。ただ、なかなか時間がそこから取ることができなくなり、どうやってa-blog cmsに組み込もうかなぁ…と考えてたら、a-blog cmsの開発元である「アップルップル」の山本 一道さんが相談に乗っていただけました。2025年末〜2026年の頭までは、今自分が注力している「AR系」のイベントのために海外出張も多かったころからしばらく停滞したものの、2026年4月20日、一旦リニューアルをすることができました。ちなみに、僕のブログは2005年当時からアップルップルさんの「a-blog」で始め、その次世代版となった「a-blog cms」でずっと運用させていただいています。どうせリニューアルしたんだから、生成AI使って最適化してみたら…？これでも一応まだWeb屋ですので、サイトを作ったらGoogle PageSpeed Insightを通す訳です。正確にはリニューアル前に通して調べていました。その時の数字がこちらです。リニューアル前のデスクトップ版の結果リニューアル前のスマホ版の結果まぁ、長らくHTMLとかには全く手を入れていなかったので、そりゃそうだよなぁ…という感じでした。特にモバイル版はなかなか壊滅的な結果です。先に結論をいうと、対策をしたらこうなりました先にどう変わったのかをお伝えしておきますね…リニューアル後のデスクトップ版の結果リニューアル後のスマホ版の結果まぁ、かなり良くなったのではないかな、とは思っています。これでどれぐらいのいわゆるSEO的な結果がでるのかは分からないのですが、ちゃんと追い込めば形になるのは達成感があって嬉しいです。リニューアルで変わった大きな違いリニューアルをした時に以下のことをしました。サーバーを「さくらインターネット」から「X Server」の載せ替えたPHPのバージョンを7.4.33→8.3系に上げたa-blog cms のバージョンは最新まで上げたa-blog cmsのテンプレートは全部ゼロから刷新したこれらの結果としての速度向上もあるとは思いますが、上記をした時点では、パフォーマンスは「80点ぐらい」でした。Claudeが調べて、Claude Codeが実装支援最近のバイブコーディングブームに乗って、名村も2026年2月ごろからもうほぼ毎日Claude Codeで何かを作っています。やり方として、Claudeで「調査、や実装方法の検討をして、Claude Codeに引き渡す資料作成」、それを受けてClaude Codeで「実装自体の支援や実施を」をする、流れが名村は多いです。Claudeに調査依頼をしてみましたということで、今回の対応依頼、まずClaudeにこんな風に聞いてみました。 Xサーバーのレンタルサーバーで運用しているa-blog cmsの表示速度を極限まで早くしたいです。 Web上の事例や、HTMLの書き方的なアプローチを含めて、最善手となる方法を調査してください。 途中で細かい質問などをやり取りしながら、最終的にClaude Codeに引き渡す依頼書を作成してくれました。Claude Codeに引き継ぎClaudeが作ってくれた指示書をマシンのClaude Code管理のこのブログ改修に関するプロジェクトディレクトリの /document/ディレクトリ配下に入れて、初回に読み込みをしてもらいました。そこから数時間、Claude Codeとの二人三脚が始まります。Claude Codeにやってもらったこと実際にClaude Codeと一緒に実施した表示速度の最適化のサマリーは以下でした。Tailwind CSS CDN の本番ビルド化LCP 画像の修正Google Analytics の遅延読み込み化Apple Podcast iframe の遅延読み込み埋め込みリンクカード画像の CLS 修正bundle.css の preload 追加a-blog CMS キャッシュ設定の最大化Xserver パネル「XPageSpeed」設定.htaccess によるキャッシュ・ETag 最適化Cloudflare Free の導入member.csv のクリティカルパス外し管理画面用 CSS のログイン時限定化Alpine.js の自前ホスト化LCP 画像の srcset + resizeImg 対応AVIF 画像変換対応それぞれでやってきたことをざっくりと記載しておきます。Tailwind CSS CDN の本番ビルド化諸事情で構築時にTailwind CSSを入れたのが僕ではなかったのですが、開発時に利用していた cdn.tailwindcss.com がそのままにしちゃっていました。このままだとブラウザで JIT コンパイルが走り、レンダーブロッキングと TBT 悪化の最大要因になるので、本番用に変更しました。LCP 画像の修正記事詳細ページのヒーロー画像に当たる部分に loading="lazy" が付与されていて、ブラウザが意図的に読み込みを遅延が起こっていたので解除。 loading="lazy" を削除して、代わりに fetchpriority="high" を追加。<head> 内に <link rel="preload" as="image"> を追加して、2 枚目以降には loading="lazy" を維持するように設定。Google Analytics の遅延読み込み化表示速度を最優先したので、運用性を考えたらa-blog cmsの管理画面からタグは登録するのですが、GA の gtag() 初期化がインライン記述で、HTML パース中にメインスレッドをブロックするで、footer側に持っていきました。Apple Podcast iframe の遅延読み込みポッドキャスト紹介ページでは外部コンテンツをiframeで埋め込んでいるので、loading="lazy" したり、<head> へ <link rel="preconnect" href="https://embed.podcasts.apple.com"> を追加したりしました。埋め込みリンクカード画像の CLS 修正本文内の埋め込みリンクカード（.quoteImageContainer）に width / height が無く、画像読み込み時にレイアウトシフトが発生していたので、 .quoteImageContainer { aspect-ratio: 1200 / 630; } を設定。bundle.css の preload 追加<link rel="preload" href="/dest/bundle.css" as="style"> を追加して、メイン CSS の取得開始タイミングの前倒し。a-blog cms キャッシュ設定の最大化これはa-blog cms周りの設定の話です。Xserver パネル「XPageSpeed」設定CSS／JS 圧縮 ONCSS/JS/画像の統合 ON小ファイルのインライン化 ONブラウザキャッシュ設定「全ての静的ファイル」ON画像最適化はあえて OFF（後述の WebP／AVIF 対応と競合するため）JS 遅延読み込みも OFF（acms.js と競合してエラーが出るため）.htaccess によるキャッシュ・ETag 最適化静的アセット（画像・CSS・JS・フォント）に Cache-Control: public, max-age=31536000, immutable を設定したりしています。Cloudflare Free の導入CDNのCloudflare に登録をしました。アクセス数的には無料枠でいけると思うのと、今回は表示速度はできるところまで追い込む実験も兼ねていたので、導入。member.csv のクリティカルパス外しこの「member.csv」はこのサイトの会員番号を処理しているものですが、読み込み場所が限られていたので、そこを細かく制御掛けました。これが地味に効果が高かったので、一般的なナレッジにはならないのですが、すんません…管理画面用 CSS のログイン時限定化ゲスト閲覧時にも acms-admin.min.css（70KB）が無条件読み込みされていたのを分岐処理をしました。Alpine.js の自前ホスト化jsdelivr CDN から読み込んでおり、キャッシュ TTL は 7 日。リピートアクセスでも再取得が頻発していたので以下を対応Alpine.js 公式から v3.15.11（alpine.min.js / focus.min.js）をダウンロードtailwind-blog/js/vendor/alpinejs/ に配置.htaccess の静的アセット 1 年 immutable キャッシュが自動適用LCP 画像の srcset + resizeImg 対応記事ヒーロー画像が原寸 1280×720 のまま配信され、モバイル表示枠（665×374 相当）に対して過大だったのを制御を加えました。AVIF 画像変換対応a-blog cmsのエントリー時にはPNG/JPEG/GIF等をアップしているのですが、リニューアルのだいぶ前から自作したバッチ処理をCronで回して、アップされた画像を自動的にWebP画像を作る処理をくみこんでいました。HTMLからのリクエストが当初のPNG/JPEG/GIFでも、同じファイル名でWebP画像があれば、それを吐き出すように.htaccessで処理していました。今回そのバッチ処理にAVIF画像も生成する処理を加えて、同じファイル名で存在していれば…という優先順位を「AVIF→WebP→実体」となるようにしています。物によってはWebPの方が軽くなることもあるけど、サイト全体としてはAVIFの方が軽くなっているのも調べたので、効果はあったかな？と思います。やってみて成果がでてよかった一般的な静的サイトやフレームワーク直書きのサイトなら「フルコントロール」で最適化ができますが、CMS の上に乗ったサイトはコアを触れないという前提で戦う必要があります。その制約下で何ができて何ができないかを明確に切り分け、できる範囲を漏れなく潰していくアプローチが重要だなぁ…と改めて実感しました。またあくまで個人ブログなので、開発環境を用意していなかったのもあり、バックアップは結構細かく取って、何かあってもロールバックできるようにしたり、サーバーへのデプロイはGithub Actionsにしたり、ということで事故らないようには気をつけてやっていました。本記事が同じように a-blog CMS や他の CMS 製サイトの速度改善に取り組んでいる方の参考になれば幸いです。

Webディレクターがサービシンクで得られる9つのこと

ポッドキャストとYouTubeの比較：発信に音声メディアを選ぶ理由｜Webディレクションやってますラジオ #317

## 2026年10月16日の第317回放送分です！ 毎週金曜日放送のWeb系クリエイター向けの仕事力アップのポッドキャスト「Webディレクションやってますラジオ」の317回目（2026年10月16日）放送。 ▼目次 ## ポッドキャストの配信プラットフォーム このポッドキャストは毎週金曜日、23時〜24時の配信しています。 ご視聴には次のプラットフォームで「購読登録」をいただくと放送の配信をすぐにキャッチして聴くことができます！ Spotify Apple Podcast Voicy YouTube stand.fm Amazon Music YouTube Music LISTEN RSS ## この番組のスポンサー ## ポッドキャスト(Podcast)でお読みしたおハガキのコーナー このポッドキャスト(Podcast)では、放送でお読みする「おハガキ」(と称するTweet、DM、フォームからのご投稿)を募集しています。 ご自身の「Webディレクターとしての仕事の仕方」や「Webディレクション」またWebデザインやマークアップやシステム開発に関しての疑問・質問がある方は、下記からぜひご投稿ください。 Web制作・Webディレクションとは関係ない日常での「こんなことがあったよ」や、今だからいえる「ありがとう」「ごめんなさい」といった話題のおハガキも募集しています！ 今週はいただいていたおハガキからこちらをご紹介させいただきました。 ラジオネーム：月曜のミルクティーさん 名村さん、こんばんは。 先日、コードの変数名のスペルミスに半日気づかなかったんですが、その時ふと、小4の書き初めを思い出して顔が熱くなりました… それは、「希望」と書いたつもりが、「布望」になっていたんです。 しかも誰も気づかないまま、廊下に1ヶ月間、堂々と貼り出されていました。 気づいたのは、参観日に来た父の「これは…布を望んでるのか?」という一言です。 あれから20年、私は今も「書いたものを見直さない」という同じバグを抱えたまま生きています。 レビューしてくれる同僚に、心から感謝しています。 そんな私ですが、来週も楽しみにしています（笑） トークのまとめ - 「希望」と書いたつもりが「布望」になっていた小4の書き初めの話を、「今だから言えるお話」として楽しく紹介しました。字がなんとなく似ているので、書いて終わりだと思ってついやってしまうのも分かる、とお話ししています。 - このように「今だから言えるありがとう」や「今だから言えるごめんなさい」も番組で募集していることをお伝えしました。 - 同じようなネタがあれば、ぜひ送ってほしいと呼びかけています。 ラジオネーム：しおりさん@釣り人Webディレクターさん 名村さんお久しぶりのおたよりで――す！ WebクリエイターポッドキャストDay、たいへんお世話になりました😻 いつも「耳で聞いている」ラジオ番組ですが、この日だけは「目で見て」楽しむことが出来て、 そして登壇者自身は実物のパーソナリティさんに「お会いする」ことが出来て、たいへん感激でした！ 自分は当日「息抜きの仕方」についておたよりをいただいて喋らせてもらったのですが、 「アニメはよい！」「最近のリゼロは本当に最高なのだ！」みたいなお話をした際 視界の右奥で、名村さんがうんうんと頷いてくれているのが見えまして 「あ、聞いてくれてる人がいる‥嬉しい！」と、ほっとして、とても救われました。 来週は名村さんのラジオにもゲストで来られていた「toksatoさん」とコラボ配信することになりました😻（toksatoさんに公開謝罪をしてもらう予定！ｗｗ） こういう、新たなつながりを生んでいただいて嬉しいです！ 素敵なイベントをありがとうございましたー！来年も楽しみにしていまーす♡ トークのまとめ - 打ち上げでtoksatoさんがしおりさんにひどいことをしたという裏話をお話ししました。配信回ではtoksatoさんが平謝りしているはずなので、聴いてほしいとお伝えしています。 - toksatoさんがどんな言い訳をしているのか、そこも聴きどころだとお話ししています。 - イベントでしおりさんが「リゼロは最高」と語っていたとき、会場の何人が聞き取れたのかと思いながら聞いていたことを明かしました。しおりさんが見ているのを知っていて、自分も見ていたから頷いていた、というエピソードです。 ラジオネーム：kkeethさん 単なる感想です🙇‍♂️ 田口さん回（中編）を聞きましたが，お二人の昔からを振り返った話がとても興味深く，気心がしれたお二人だからこそテンポも良くて，あと5時間くらい聴いていたいと思いました！公開収録していただき，それを見聞きしながらお酒飲みたいくらい（どんだけ贅沢なんだ笑） 後編もとても楽しみにしております！ トークのまとめ - 田口さんとの中編の感想へのお礼をお伝えしました。後編を聴いた感想も、このあと別のおはがきで読んでいます。 - 短い時間ながら、イベントで番組に花を添えてくれたことに感謝をお話ししています。 ラジオネーム：こもれび文庫さん 名村さん、こんばんは。 田口さんのゲスト回、3週とも通勤中に聴きました。 一番刺さったのは「丸投げは一つの信頼の形」というお話です。 私は外注さんに任せるのが怖くて、つい細かく口を出してしまうタイプなので、ハッとしました。 そして、名村さんがワンカメでとお願いしたのに、気づいたら3カメになっていた話。 任せてもらえたからこそ、田口さんのリミッターが外れたんですね。 私も「任せたくなるディレクター」になれるよう頑張ります！ トークのまとめ - 「丸投げは信頼の形」という話に共感をいただいたことに触れ、田口さんに任せたら去年も今年もノリノリで素晴らしい映像を作ってもらえたとお話ししています。 - 「ワンカメでいい」とお願いしたのに、気づけばカメラが3台あったというエピソードを振り返りました。僕はカモもネギも鍋も背負って、田口さんに丸投げしたようなものです。 - ポッドキャストであの画質まで出しているものは多くないと思う、とお伝えしました。「それはYouTubeライブでは？」と言われたら何も言えませんが、音響のいい施設で話せたのは面白い経験でした。 ラジオネーム：夜更かしペンギンさん なむさん、こんばんは。 ゲスト回、めちゃくちゃ楽しかったです！ 314回のエンディングで話されていた、イベント最後に30秒間手を振り続けたなむさんを、アーカイブで確認しました。 いろんな表情で手を振っていて、通勤電車で笑いをこらえるのが大変でした。 あと、田口さんの「タグ閉じないですよね」と言われた話。 フロントエンドとしては、ある意味Web業界の怖い話でした（笑）。 田口さんにもよろしくお伝えください トークのまとめ - 田口さんの「タグを閉じないですよね」という話について、僕もちょっと思ったとお話ししています。 - イベント中に流れたKWCさんの「Web業界の怖い話」というCMが、本当にただ怖い話だったというエピソードにも触れました。 - 田口さんにもよろしくとのことなので、しっかりお伝えするとお答えしました。 ラジオネーム：月曜のカレーパンさん 名村さん、こんばんは。 同世代のお二人の会話、しみじみ聴かせていただきました。 田口さんが「オワコン感への危機感がある」とおっしゃっていたのは意外でしたが、40代の私にもすごく分かります。 若い人から急に年長者として見られる、あの距離感。 それでも「50代・60代のディレクターとしてのやり方を模索したい」というお二人の姿勢に、勇気をもらいました。 あと「おじさんは褒めるとリターンがでかい」、後輩に広めておきます（笑） トークのまとめ - 田口さんが「オワコン感」への危機感を話したのは、僕もびっくりしたとお伝えしました。定年が60歳なら残り10年ほどなので、自分に何ができるのかと考えることもあります。 - つのかけさんとは、老後などは考えず最後まで最前線で生き倒そうと話しています。僕も同じ気持ちで、若者に「居場所がない」と言われたら「自分で切り開け」と言うつもりです。 - 声優業界では60代、70代、さらには80代、90代の方もまだ現役です。それを20代の頃から見てきたので、50代はまだまだこれからという感覚です。そのうえで「おじさんはぜひ褒めてください」とお願いしています。 ラジオネーム：しおさい定食さん なむさん、こんばんは。 316回、toksatoさんのおはがきで声を出して笑いました。 「マクドナルドの店員さんのような薄さ」「安物の服みたいにペラペラ」という例えのキレがすごすぎます。 それに対して田口さんが「本番後はパソコンの電源と一緒に自分の電源も落としている」と弁解されていたのも最高でした。 しかも、その場で「グループメッセージ送っていい？」と謝ろうとする田口さん。 お二人とも本当にいい人なんだなと思いました。 トークのまとめ - 「マクドナルドの店員さんのような嘘くささ」「安物の服みたいにペラペラ」といったtoksatoさんのお便りの例えが、笑いどころだったことに触れました。 - toksatoさんは口も態度も悪いけれど、中身はとてもシャイでいい人だとお話ししています。 - toksatoさんのお便りを読んだ回の田口さんについては、同じ感想を先週にも田口さんと話した、とお伝えしました。 ラジオネーム：ミントの小窓さん 名村さん、こんばんは。 toksatoさんのおはがき回、とても楽しかったです！ 田口さんが「安物の服」に乗っかって、「一回洗濯したら襟が伸びる」と自分でかぶせていたところで、もう耐えられませんでした。 そして対策が「次回からは懇親会でtoksatoさんの近くに座らない」なのが面白すぎます。 電源を残しておくのは手抜きになるから無理、というところに、田口さんの本番への本気度を感じました。 トークのまとめ - 田口さんの「懇親会ではtoksatoさんの近くに座らない」という対策を、「これこそソリューション」と感心して聞いていたとお話ししました。 - ライブ配信では田口さんが出し切っていたことを振り返りました。 - 田口さんの本番への本気度が伝わったという感想に、僕も同感だとお伝えしています。 ラジオネーム：よもぎ餅のひとさん なむさん、こんばんは。 toksatoさんのおはがき、文章がもうひとつのコンテンツになっていて最高でした。 「話題に困ったら一回だけ『たこ焼きっておいしいよね』と逃げてもいい」という優しさ（？）も好きです。 それから、田口さんがtoksatoさんがトップバッターで「ほっとした」と話していたのが印象に残りました。 なむさんがtoksatoさんを一番手にした理由と、田口さんが感じていたことが同じだったのは、聴いていて嬉しくなりました。 トークのまとめ - toksatoさんをトップバッターにした理由をお話ししました。緊張しても一定の笑いを取るか、自分の世界を表現するか、仮にとちっても「toksatoさんらしい」とちり方をしてくれると期待したからです。 - 長谷川さんにも「この順番には意味があるんでしょう」と聞かれたので、理由を答えると納得されたエピソードをお話ししています。 - 来年も9月の第2土曜日に開催予定で、出演者の公募も考えています。決まり次第、番組で告知しますとお伝えしました。 ラジオネーム：窓際のレターケースさん 名村さん、こんばんは。 前から聞いてみたかったことがあります。 名村さんは、なぜポッドキャストだったんですか？ 失礼を承知で言うと、元々キャリアもあるし、セミナーだっていっぱい出演されてて、本も出しているんだから、YouTubeで顔を出していたら、今よりずっと有名になっていた気がするんです。 発信する手段はいくらでもあった中で、音声を、しかも毎週金曜の夜という形を選ばれた理由が、とても気になっています。 当時どんなことを考えて決めたのか、ぜひ聞かせてください。 トークのまとめ - 有名になりたくてやっているわけではなく、YouTubeの顔出しが自分のゴールではなかったとお答えしました。ブログを21年続けてきて、一時は書けなくなったものの、コロナ禍で改めてアウトプットしたくなったのが出発点です。 - YouTubeだと編集やテロップ、字幕にこだわってしまい、定期的に出せなくなると考えました。時間をかけずに毎週コンテンツを出したかったので、ポッドキャストに落ち着いたとお話ししています。 - 金曜の夜にこだわる理由は、学生時代に聴いていた金曜23時のラジオの思い出です。今もそのノリで話しています。ゲストを呼ぶ対談形式は、すでに長谷川さんが手がけているので、あえて別の形を選んだこともお伝えしました。 ## 月末書籍プレゼントのお知らせ 「Webディレクションやってますラジオ」では、その月におハガキをお読みした方を対象に「書籍プレゼント」をさせていただいています。 ### 抽選資格 * その月に読まれたおハガキ * おハガキをお送りいただく時、メールアドレスを記載の方 ### プレゼントの中身 * 書籍は「Webの技術系」や「ビジネス書」などから名村の独断で決定 で、 毎月月末に放送で抽選をおこない、当選者の発表しています！ ▲目次に戻る

田口 真行さんと『Web Creator Podcast Day2026』の配信の裏側を語る！（後編）｜Webディレクションやってますラジオ#316

## 2026年10月9日の第316回放送分です！ 毎週金曜日放送のWeb系クリエイター向けの仕事力アップのポッドキャスト「Webディレクションやってますラジオ」の316回目（2026年10月9日）放送。 ▼目次 ## ポッドキャストの配信プラットフォーム このポッドキャストは毎週金曜日、23時〜24時の配信しています。 ご視聴には次のプラットフォームで「購読登録」をいただくと放送の配信をすぐにキャッチして聴くことができます！ Spotify Apple Podcast Voicy YouTube stand.fm Amazon Music YouTube Music LISTEN RSS ## この番組のスポンサー ### 本日のゲスト「田口 真行」さん 今週のゲスト「田口 真行」さんのご紹介です。 1999年、フリーランスのWebディレクターとして独立後、株式会社デスクトップワークス（現・株式会社エンタミナ）を設立。 Webディレクター育成研修、Webディレクター自己診断アプリ、Webディレクター手帳、ディレクション検定、ディレクション大百科、ディレクション学園、思考トレーニングジム、ヒアリングLIVEなど、ディレクションをテーマにした多数のコンテンツ&サービスを展開。動画制作や配信にも意欲的に取り組んでおり、2014年から10年間で1,800本以上のライブ配信を実施。 - [株式会社エンタミナ](https://entermina.jp/) - [𝕏（Twitter）：@webdirection](https://x.com/webdirection) ### 田口さんに配信をしていただいたWeb Creator Podcast Day .youtube { position: relative; width: 100%; padding-top: 56.25%; } .youtube iframe { position: absolute; top: 0; right: 0; width: 100%; height: 100%; } ## ポッドキャスト(Podcast)でお読みしたおハガキのコーナー このポッドキャスト(Podcast)では、放送でお読みする「おハガキ」(と称するTweet、DM、フォームからのご投稿)を募集しています。 ご自身の「Webディレクターとしての仕事の仕方」や「Webディレクション」またWebデザインやマークアップやシステム開発に関しての疑問・質問がある方は、下記からぜひご投稿ください。 Web制作・Webディレクションとは関係ない日常での「こんなことがあったよ」や、今だからいえる「ありがとう」「ごめんなさい」といった話題のおハガキも募集しています！ 今週はいただいていたおハガキからこちらをご紹介させいただきました。 ラジオネーム：toksatoさん 名村さんこんばんちわ！（ムカつくから田口さんには挨拶しない） Web Creator Podcast Day2026でトップバッターという大役を務めたトクサトさんでございます。 今日ほんとは、このお便りを送るつもりはなかったんです。 名村さん田口さん、お二人の話しが聞けるということで、「お便りなど送らず、イチ消費者として（つまりなんのコストもなく）消費させてもらうぜ(・∀・)ﾆﾔﾆﾔ」と思ってました。 だが、予定が変わりました。 先日、そのWeb Creator Podcast Day2026の懇親会がありました。 僕には「Web Creator Podcast Dayの当日に是が非でも成し遂げたいこと」がいくつかあり、そのうちの一つに「田口さんが発明したあのウェビナーは素晴らしい、それを伝えること」がありました。 おかげさまで、伝えることができました。 それもこれも、ほぼ誰も聴いてねえ（言い過ぎ）トップバッターとして名村さんが僕をあのイベントに呼んでくれたおかげです。 にも関わらず。 にも関わらず！（大事なことなので2回言う） 田口さんにそれを伝えたら、 「( ´_ゝ`）ﾌｰﾝ そうですかねぇ」 と・・・リアクション、うっす！！！ マクドナルドの店員が「あの細長いプライドポテトが良いんですよね」と言われたときのような薄さ。。。（まあそうですねぇ、みたいな） 今書いていても腹が立ってきました。 あれはすごい！ こっちはね、坂本龍馬ぐらいのつもりで言ってるんよ！ アレは本当にすごい！ なのに！なんだあのリアクション！なんだあの安物の服みたいな薄さは！ペラッペラやで！もっと雄弁に語るべき！ おそらく、ほとんどのセミナー登壇者がワイドショーよろしく、「右下か左下にワイプで登壇者が説明する」が当たり前だと思っていたはず。それをぶち破った田口さんのスタイルは、ほんとにすごい。 もう凄すぎて逆に僕は内容が入ってこないです（笑）「うわぁ、そうか、こういう手段があるんだ！すげ！」と思うことばかりで、内容がどうでもよくなってきます（笑） というわけで、あのウェビナースタイルについてお二人で話してください（命令） 話題に苦しくなったら一回だけ「たこ焼きっておいしいよね」に逃げてもいいです。一回だけ許してあげます （トクサトは優しいのです） トークのまとめ - **リアクションが薄かった理由をお話ししました。** 配信が終わると、パソコンの電源と一緒に自分の電源も落ちて頭が真っ白になります。toksatoさんの言葉は本当に嬉しかったのですが、懇親会の時点では魂が抜けていました。お詫びも込めてお話ししています。 - **配信の演出は視聴者よりも出演者に向けている、という考えをお伝えしました。** 幕間のジングルや画面の切り替えは、出演者のテンションが上がるように作っています。出演者のテンションが上がればコンテンツが良くなり、結果的に視聴者にも還元されると考えています。ユーザーファーストという言葉に少し違和感がある、という話にも触れています。 - **予算を気にしすぎず全力を尽くす理由をお話ししました。** ワンカメの予定が気づけば3カメになっていた、という裏話もしています。「頼んでよかった」と思ってもらいたいからで、目の前の仕事に120%で向き合えば、いつか必ず返ってくると考えています。 - ** toksatoさんがトップバッターだった理由にも話が広がりました。** 最初の出演者の空気がイベント全体のトーンと話の幅を決めます。その点で、toksatoさんのトークは配信スタッフも肩の力を抜いて、丸一日楽しく過ごせる土台になりました。最後には、toksatoさんのラジオに謝罪に行く話でも盛り上がっています。 ## 月末書籍プレゼントのお知らせ 「Webディレクションやってますラジオ」では、その月におハガキをお読みした方を対象に「書籍プレゼント」をさせていただいています。 ### 抽選資格 * その月に読まれたおハガキ * おハガキをお送りいただく時、メールアドレスを記載の方 ### プレゼントの中身 * 書籍は「Webの技術系」や「ビジネス書」などから名村の独断で決定 で、 毎月月末に放送で抽選をおこない、当選者の発表しています！ ▲目次に戻る

田口 真行さんと『Web Creator Podcast Day2026』の配信の裏側を語る！（中編）｜Webディレクションやってますラジオ#315

## 2026年9月25日の第314回放送分です！ 毎週金曜日放送のWeb系クリエイター向けの仕事力アップのポッドキャスト「Webディレクションやってますラジオ」の314回目（2026年9月25日）放送。 ▼目次 ## ポッドキャストの配信プラットフォーム このポッドキャストは毎週金曜日、23時〜24時の配信しています。 ご視聴には次のプラットフォームで「購読登録」をいただくと放送の配信をすぐにキャッチして聴くことができます！ Spotify Apple Podcast Voicy YouTube stand.fm Amazon Music YouTube Music LISTEN RSS ## この番組のスポンサー ### 本日のゲスト「田口 真行」さん 今週のゲスト「田口 真行」さんのご紹介です。 1999年、フリーランスのWebディレクターとして独立後、株式会社デスクトップワークス（現・株式会社エンタミナ）を設立。 Webディレクター育成研修、Webディレクター自己診断アプリ、Webディレクター手帳、ディレクション検定、ディレクション大百科、ディレクション学園、思考トレーニングジム、ヒアリングLIVEなど、ディレクションをテーマにした多数のコンテンツ&サービスを展開。動画制作や配信にも意欲的に取り組んでおり、2014年から10年間で1,800本以上のライブ配信を実施。 - [株式会社エンタミナ](https://entermina.jp/) - [𝕏（Twitter）：@webdirection](https://x.com/webdirection) ### 田口さんに配信をしていただいたWeb Creator Podcast Day .youtube { position: relative; width: 100%; padding-top: 56.25%; } .youtube iframe { position: absolute; top: 0; right: 0; width: 100%; height: 100%; } ## ポッドキャスト(Podcast)でお読みしたおハガキのコーナー このポッドキャスト(Podcast)では、放送でお読みする「おハガキ」(と称するTweet、DM、フォームからのご投稿)を募集しています。 ご自身の「Webディレクターとしての仕事の仕方」や「Webディレクション」またWebデザインやマークアップやシステム開発に関しての疑問・質問がある方は、下記からぜひご投稿ください。 Web制作・Webディレクションとは関係ない日常での「こんなことがあったよ」や、今だからいえる「ありがとう」「ごめんなさい」といった話題のおハガキも募集しています！ 今週はいただいていたおハガキからこちらをご紹介させいただきました。 ラジオネーム：田島さん 名村さん、田口さんこんばんは。 田口さんがゲストに来るのをしっておハガキをしました。 名村さんと田口さんってもうWebディレクターといえば！というお二人だと思うのですが、お二人は面識は古くからあるのですか？ また今回Web Creator Podcast Dayで名村さんが田口さんに配信をご依頼した理由って何かあるのでしょうか？ トークのまとめ - 田口さんとの出会いは約23年前、2004〜05年頃です。デジハリさんでのセミナーや田口さんのディレクター育成講座、大阪でのイベントなど、古くからご一緒してきた経緯をお話ししました。 - 配信をお願いした理由は、ライブ配信を任せられる人を4〜5人しか知らなかったことです。コロナ禍のCSSナイトで田口さんの無観客配信を見て、事前準備や当日のトラブル対応まで含め「田口さんじゃないと怖い」と感じたことをお伝えしました。 - 田口さんからは、「丸投げは信頼の形」だから期待に応えて驚かせたい、という思いを聞けました。今年も自由にやらせてもらえて達成感があったそうで、来年もお願いすると決めています。 ラジオネーム：ドロップシャドウが心の影さん 名村さん、田口さんこんばんは。 ハガキを送っている時点ではまだ終わっていませんが、読まれるタイミングとしては「Web Creator Podcast Day2026」お疲れ様でした。 これから当日を楽しみにしていますが、昨年も思っていましたが、お二人が一つのことをされるとか、もうプロジェクトとしては成功しかありえないように感じていました。 とはいえ、名村さんは「絶対になにかあるのがプロジェクト」と良くいっていますが、や、やっぱり当日まで、また当日にもなにかトラブルはありましたか？ トークのまとめ - 本番中に大きなトラブルはありませんでしたが、最後の私のセッションで小さなアクシデントがありました。エンディングアニメーションが30秒ほど出ず、私がずっと手を振り続けることになりました。アーカイブで見られるのでぜひ確認してください。 - リハーサルでは、音源の出し間違いで別番組の音が鳴ってしまうハプニングもありました。笑い話で済んだ裏話を、ぶっちゃけてお話ししています。 - ライブ配信は、どれだけ準備しても想定外が必ず起こる仕事です。20〜30通りの備えで乗り切ることで信頼が生まれること、最後は主催者の運も大きいことを、去年のエピソードも交えてお話ししました。 ラジオネーム：中平 道雄さん 名村さん、こんばんは。 ゲストの田口さん、はじめまして。 僕は実はもう10年以上前に名村さんのディレクター育成講座を受講して、そのおかげで今仕事をやれているのですが、田口さんも後進育成はしてきたのを今回ゲストのご出演されることからエンタミナさんのサイトをみて知りました。 名村さんもそうですが、田口さんがディレクター育成の講座をしてこられたのはどういった思いからだったのでしょうか。ぜひお聞きしてみたいです。 トークのまとめ - 1999年にフリーランスになった頃、クリックアンド・オリバー社さんから研修の依頼を受けたのが始まりです。「来た仕事は断らない」という気持ちで引き受けたことを話しました。 - 続けてきた理由は、何度やっても自分の中で100点が取れないことです。数年前のアーカイブを見て「下手だな」と思えるのは成長している証拠で、まだ伸びしろがあると感じていることをお伝えしました。 - 最近は「オアコン感」を意識するようになりました。同世代でWebディレクターの先頭を走ってきた私たちが、50代・60代でどんな新しいやり方を見つけられるか、模索したい気持ちを話しています。 ラジオネーム：行けたら行くマンさん 田口さん、はじめまして、名村さん、こんばんは！ 田口さんといえば、名村さんと並んで業界最古のディレクターと思います。 ただ、名村さんは完全Web特化、田口さんはマルチな強みをお持ちだと思います。 田口さんは今回のWeb Creator Podcast Dayでは昨年も今年も配信を担当されていましし、以前も名村さんがCSS Niteで司会をされた時も配信は田口さんだったはず… 田口さんの映像とか配信とかにそこまで強くなった理由って何があるんですか？ トークのまとめ - 田口さんの映像・音響への強さは、Webより古い趣味が出発点です。高校時代の音楽活動に始まり、20歳頃（93〜94年）に初期のMacと映像編集ソフトをローンで購入した話をお伝えしました。 - 田口さんは、「マルチなのは私より名村さん」と言います。会社経営もプログラミングもこなすという評価でした。 - 朝までディレクションでは、キーノートのスライドを送るとXに自動投稿されるプログラムを私が自作した話も出ました。田口さんの「タグを閉じない」エピソードも飛び出して、話が脇道に逸れています。 ラジオネーム：千のリキュールさん 名村さん、田口さん、こんばんは！ 名村さんと田口さんはもう古くからディレクターをされていますが、お互いには知った仲だったのですか？ 田口さんから見た名村さん、名村さんからみた田口さんはどんな印象でしょうか？ ぜひお聞きしてみたいです。 トークのまとめ - 私から見た田口さんは、0から1を生み出す企画力とプロデュース力が圧倒的な人です。エンタミナのロゴやイベント企画を見るたびに「絶対に勝てない」と思い、20年以上逃げ続けてきたと正直に話しました。 - 田口さんから見た私は、Webディレクター出身で会社を成功させた唯一の存在であり、始めたことを続けてグロースさせる力が強い人だそうです。自分にはない力だと言ってもらえました。 - ディレクターは褒められにくい仕事で、年を取るとさらに褒められなくなります。「おじさんを褒めるとリターンが大きい」という笑い話で締めくくりました。 ## 月末書籍プレゼントのお知らせ 「Webディレクションやってますラジオ」では、その月におハガキをお読みした方を対象に「書籍プレゼント」をさせていただいています。 ### 抽選資格 * その月に読まれたおハガキ * おハガキをお送りいただく時、メールアドレスを記載の方 ### プレゼントの中身 * 書籍は「Webの技術系」や「ビジネス書」などから名村の独断で決定 で、 毎月月末に放送で抽選をおこない、当選者の発表しています！ ▲目次に戻る

田口 真行さんと『Web Creator Podcast Day2026』の配信の裏側を語る！（前編）｜Webディレクションやってますラジオ#314

## 2026年9月25日の第314回放送分です！ 毎週金曜日放送のWeb系クリエイター向けの仕事力アップのポッドキャスト「Webディレクションやってますラジオ」の314回目（2026年9月25日）放送。 ▼目次 ## ポッドキャストの配信プラットフォーム このポッドキャストは毎週金曜日、23時〜24時の配信しています。 ご視聴には次のプラットフォームで「購読登録」をいただくと放送の配信をすぐにキャッチして聴くことができます！ Spotify Apple Podcast Voicy YouTube stand.fm Amazon Music YouTube Music LISTEN RSS ## この番組のスポンサー ### 本日のゲスト「田口 真行」さん 今週のゲスト「田口 真行」さんのご紹介です。 1999年、フリーランスのWebディレクターとして独立後、株式会社デスクトップワークス（現・株式会社エンタミナ）を設立。 Webディレクター育成研修、Webディレクター自己診断アプリ、Webディレクター手帳、ディレクション検定、ディレクション大百科、ディレクション学園、思考トレーニングジム、ヒアリングLIVEなど、ディレクションをテーマにした多数のコンテンツ&サービスを展開。動画制作や配信にも意欲的に取り組んでおり、2014年から10年間で1,800本以上のライブ配信を実施。 - [株式会社エンタミナ](https://entermina.jp/) - [𝕏（Twitter）：@webdirection](https://x.com/webdirection) ### 田口さんに配信をしていただいたWeb Creator Podcast Day .youtube { position: relative; width: 100%; padding-top: 56.25%; } .youtube iframe { position: absolute; top: 0; right: 0; width: 100%; height: 100%; } ## ポッドキャスト(Podcast)でお読みしたおハガキのコーナー このポッドキャスト(Podcast)では、放送でお読みする「おハガキ」(と称するTweet、DM、フォームからのご投稿)を募集しています。 ご自身の「Webディレクターとしての仕事の仕方」や「Webディレクション」またWebデザインやマークアップやシステム開発に関しての疑問・質問がある方は、下記からぜひご投稿ください。 Web制作・Webディレクションとは関係ない日常での「こんなことがあったよ」や、今だからいえる「ありがとう」「ごめんなさい」といった話題のおハガキも募集しています！ 今週はいただいていたおハガキからこちらをご紹介させいただきました。 ラジオネーム：やどかりさん 名村さん、こんばんは！ Webディレクターの田口さんがゲストに来てくれるというのをXで見ました！！ もう「まじかーー！」と言ってしまいました。 まさかの名村さんと田口さんというディレクター業界の二台巨頭が番組で喋ってくれるとかもう、現時点での最高峰ですよ。 せっかくなので、田口さんに質問です！！ 「田口さんにとって、Webディレクターを続けてこられた一番の理由は何ですか！」 とても楽しみにしています！ ## 月末書籍プレゼントのお知らせ 「Webディレクションやってますラジオ」では、その月におハガキをお読みした方を対象に「書籍プレゼント」をさせていただいています。 ### 抽選資格 * その月に読まれたおハガキ * おハガキをお送りいただく時、メールアドレスを記載の方 ### プレゼントの中身 * 書籍は「Webの技術系」や「ビジネス書」などから名村の独断で決定 で、 毎月月末に放送で抽選をおこない、当選者の発表しています！ ### 今月のプレゼントと当選者の発表 #### つくりながら理解する Webアプリ開発入門 ### 当選者の発表 * **2026年09月04日の第311回放送分でお読みした「ラジオネーム：春日ゆ〜りん」さん** おめでとうございます！ おハガキをお送りいただいたメールアドレス宛に、ご連絡をさせていただきます！ ▲目次に戻る

Web Creator Podcast Day2026の現場トークを全編アーカイブ公開｜Webディレクションやってますラジオ #313

## 2026年9月18日の第313回放送分です！ 毎週金曜日放送のWeb系クリエイター向けの仕事力アップのポッドキャスト「Webディレクションやってますラジオ」の313回目（2026年9月18日）放送。 今週は2026年9月12日（土）に東京の原宿にある「ハラカド」にあるJ-WAVEのスタジオより「Web Creator Podcast Day2026」を開催しましたが、その中で名村が出演をした部分のアーカイブ配信をいたします。 当日は13ものポッドキャストに出演をいただき、またどの番組に多数のおハガキをいただけ、Xでのライブ配信も52,000人ぐらいの方に見ていただけた盛況なイベントとしていただけました。 ぜひとも当日の模様をお聞きください。 ▼目次 ## ポッドキャストの配信プラットフォーム このポッドキャストは毎週金曜日、23時〜24時の配信しています。 ご視聴には次のプラットフォームで「購読登録」をいただくと放送の配信をすぐにキャッチして聴くことができます！ Spotify Apple Podcast Voicy YouTube stand.fm Amazon Music YouTube Music LISTEN RSS ## この番組のスポンサー ### Web Creator Podcast Day2026イベント紹介 ここ数年、Webクリエイターのポッドキャストが徐々に増えてきました。 これまで「ブログ」によるテキストでのクリエイター発信が「音声」というチャネルでも展開されています。 そんな中、2025年に第一回となる「Web Creator Podcast day 2025」を開催しました。 「ポッドキャストを生放送で！」というホットなイベントが、2026年も帰ってきました。 今年もWebクリエイターが配信しているポッドキャスト12番組にお集まりいただき、原宿のスタジオから生放送でお届けいたします。 このイベントを通して、今まで知らなかったデジタルクリエイターの方の先進的な発信にぜひ触れてみてください。 #### 開催概要 項目 | 詳細 ------------- | ------------- 開催日時 | 2026年9月12日（土）10:30〜17:00 視聴方法 | [公式YouTubeチャンネル](https://www.youtube.com/@WebCreatorPodcastDay)・[公式Xアカウント](https://x.com/WC_Podcast_Day)・[公式Facebookチャンネル](https://www.facebook.com/WebcreatorPodcastDay/) で無料のライブ配信 後日視聴 | [公式YouTubeチャンネル](https://www.youtube.com/@WebCreatorPodcastDay)でアーカイブ配信 各番組での視聴 | 後日、各出演番組で当日の配信分をお聞きいただけます。 #### 出演番組 番組名 | パーソナリティ ------------- | ------------- [Webディレクションやってますラジオ](https://open.spotify.com/show/1bzoTjxYpWDzbwBCvnWM4i) | 名村 晋治 [T-STUDIO.Voice](https://open.spotify.com/show/5jnWNZfh3p8nD4JImPAwEv) | 神森 勉 [Automagic Podcast](https://open.spotify.com/show/4Ijjrqd8oMidh0mwOMZwCl) | 長谷川 恭久 [manaのwebクリエイターカフェ](https://open.spotify.com/show/5Cy5DWv7MlbvISaaxWkwsZ) | Mana [笑顔を創りたいWebディレクターのラジオ](https://open.spotify.com/show/1bJWC12m4reedFoLksvRk2) | toksato [雨宿りとWEBの小噺.fm](https://open.spotify.com/show/4ZqUQtob7eJrz9DQV7lPVd) | kkeeth [デザぽ-デザインがしたい人のためのポッドキャスト](https://open.spotify.com/show/4ZmOiQQGRaQdtWDhiHBYlt) | 榎本 好晃 [ゆるITエンジニア道場](https://open.spotify.com/show/5GF63OJtrIlFMME7MAMPzE) | riddle [新米Webディレクターの頭の中ラジオ](https://open.spotify.com/show/4KWgvNb2dlnTIMnVB9hH5N) | しおりさん@釣り人×Webディレクター💻 [Director's Note[ディレクターズノート]](https://open.spotify.com/show/1Rd4kHx85B4fJkvl7pcaJj) | 町田 祐一郎 [よかった探し［ログノート］](https://open.spotify.com/show/6d45HNjRRdt1ZvOoUYbBHX) | 千貫 りこ [デジタルクリエイティブの今を伝える - iDID Radio -](https://open.spotify.com/show/7A5JSeNVnEDxd3nxqY0wBM) | 加藤 琢磨・松本 龍彦 [プロジェクトをBetterにする話をしよう](https://open.spotify.com/show/0eKmG8gH79kGGweHrpldDS) | 金子 大地 ## ポッドキャスト(Podcast)でお読みしたおハガキのコーナー このポッドキャスト(Podcast)では、放送でお読みする「おハガキ」(と称するTweet、DM、フォームからのご投稿)を募集しています。 ご自身の「Webディレクターとしての仕事の仕方」や「Webディレクション」またWebデザインやマークアップやシステム開発に関しての疑問・質問がある方は、下記からぜひご投稿ください。 Web制作・Webディレクションとは関係ない日常での「こんなことがあったよ」や、今だからいえる「ありがとう」「ごめんなさい」といった話題のおハガキも募集しています！ 今週はいただいていたおハガキからこちらをご紹介させいただきました。 Web Creator Podcast Day2026のライブ配信の動画模様を公開！ .youtube { position: relative; width: 100%; padding-top: 56.25%; } .youtube iframe { position: absolute; top: 0; right: 0; width: 100%; height: 100%; } イベントでお読みさせていただいたおハガキ ラジオネーム：ディレクションが精一杯さん なむさん、こんにちは！ 今年もWeb Creator Podcast Day2026の開催、おめでとうございます。 昨年めっちゃ楽しい一日でした！ 自分が知らなかった番組にでも出会えて、それ以外聞いている番組もありますし、何よりライブで配信されるラジオのスタジオを覗き見できるというのがとても楽しいです。 でもこのイベントの場合、ついつい当日はYouTubeで動画もみてしまうので、ながら聞きができないのが辛いところです（笑） ということで、今年も開催されるのをとても楽しみにしています！ おハガキ読まれますように！！ トークのまとめ - 去年のイベントを楽しんでいただき、知らなかった番組との出会いがあったという感想に感謝をお伝えしました - YouTubeで動画を見るとながら聴きができないという指摘に対し、ポッドキャストが流行っている理由の一つがながら聴きできることだと説明しています - ライブ配信ならではの楽しみ方について、モニターの前でどう過ごしているか想像を巡らせています ラジオネーム：星空キャンバスさん 名村さん、こんにちは！ 番組会員番号：0956の星空です！ イベント開催おめでとうございます。 昨年もリアタイで参加していて「動いてる名村さんだ！！」とYouTubeでみて感動していました（笑） 多くの番組も一緒に見られるのでお聞きしたいことが！ 名村さんにとってポッドキャストで発信をしている目的や目標、モチベーションはどこなんでしょうか？ ぜひお教えください！ トークのまとめ - ポッドキャスト配信の目的について、ブログに文字を書くより喋る方が圧倒的に早いという実用的な理由を明かしました - 編集を一切せず「撮って出し」スタイルで配信していること、数字もあまり追いかけていないことを説明しています - 6年間で1300枚ものおはがきをいただいたことへの感謝と、リスナーがパーソナリティとコミュニケーションを取ることの大切さを呼びかけています ラジオネーム：みぞのくちさん 名村さん、こんにちは。 普段とは違うイベント形式、しかもYouTube配信とは先日の300.5回の細谷佳正さんが来てくれた時のような感じでまた動く名村さんが見られると想いワクワクしています。 今回のイベント、名村さんのプライベートワークだと知ったのですが、プライベートでやるには規模がデカすぎませんか…？！ プライベートといってもどこまで名村さんがやってたりするものなんでしょうか？ また簡単にできたりするのですか？（笑） トークのまとめ - プライベートでイベントを開催することについて、一人ではとてもできないことを強調してお答えしました - 出演者の方々が遠方から来てくれたことや、配信スタッフのエンタミナの尽力があってこそ成立していることを説明しています - X（旧Twitter）のライブ配信が総視聴者数4.5万人に達した成果を報告し、リスナーの皆さんへの感謝を述べています ラジオネーム：よしざわみかさん 名村さん、ご無沙汰しています、よしざわです。 最近ラジオをお聞きできていなかったのですが、久しぶりに聞いてみたらすごいイベントをやるということをしってこちらにおハガキしてみました。 これを送っているのは８月ですが、まだ暑いですよねぇ… 私は今年思いっきり夏バテして倒れてしまい、なんと4キロも強制ダイエットをする羽目になりました… 名村さんは昔から体力があって、身体が丈夫そうですが、何か普段から気をつけていることはあるのですか？ では、イベント楽しみにしています、頑張ってください！ まおｔめ - 体調管理について聞かれ、平日は起床時間と就寝時間を固定して生活リズムを崩さないことを心がけていると答えました - 3週間前に38度の熱が出た際のエピソードとして、福岡・沖縄の過密スケジュールによる疲労が原因だったことを振り返っています - ストレス解消法として、キャンプと漫画（6500冊所有、140作品を同時進行で読んでいる）を挙げ、自分の機嫌の取り方を説明しました ラジオネーム：遥かなる花粉症さん なむさん、こんにちは！ 通常配信では会員番号762番の「遥かなる花粉症」です。 今回のイベントは昨年のものも拝見していたのですが、今年も開催されるとのことで、とても楽しみにしていました。 昨年と顔ぶれも変わっているところもあったりして、また新しい番組に触れられるきっかけになると思っています。 しかしこのイベント、昨年もそうですが、名村さん一人でやっているってことですが、今年苦労したところってありますか？ トークのまとめ - 今年苦労したことを聞かれ、去年より1ヶ月準備開始が遅れて焦ったエピソードを明かしました - 出演者にとってこのイベントが「楽」である理由として、スライド作成不要で来てくれるだけでいいという徳里さんの言葉を紹介しています - 天候不順で出演者が来られなくなることへの不安が一番大きかったと、裏側の心配事を語っています ラジオネーム：サモハン銀行さん 名村さん、ご無沙汰しています、サモハン銀行です！ イベントお疲れ様です！トリですね、トリ！！流石です。 当日たくさんの番組がでるということで、事前学習に全部聞かせてもらったのですが、全部面白くてチャンネル登録しちゃいました。 ただ、一気にチャンネル登録が増えて皆さんのを追いかけるのが大変になってきました（笑） 当日はリアタイで参加するつもりです。 正座してパソコンの前に座ってますので、頑張ってください！ トークのまとめ - イベント参加の応援おはがきをいただき、全番組を事前に聴いて準備されている熱心さに感謝をお伝えしました - 正座してパソコンの前で見ているというリスナーさんに、足が痺れないよう気をつけてとユーモアを交えて応じています - 事前学習で全番組をチェックしてチャンネル登録してくれた行動力を讃えています ## 月末書籍プレゼントのお知らせ 「Webディレクションやってますラジオ」では、その月におハガキをお読みした方を対象に「書籍プレゼント」をさせていただいています。 ### 抽選資格 * その月に読まれたおハガキ * おハガキをお送りいただく時、メールアドレスを記載の方 ### プレゼントの中身 * 書籍は「Webの技術系」や「ビジネス書」などから名村の独断で決定 で、 毎月月末に放送で抽選をおこない、当選者の発表しています！ ▲目次に戻る

仕事の進め方はなぜ教わらない？デザイン仕様公開時代の学習法｜Webディレクションやってますラジオ #312

## 2026年9月11日の第312回放送分です！ 毎週金曜日放送のWeb系クリエイター向けの仕事力アップのポッドキャスト「Webディレクションやってますラジオ」の312回目（2026年9月11日）放送。 ▼目次 ## ポッドキャストの配信プラットフォーム このポッドキャストは毎週金曜日、23時〜24時の配信しています。 ご視聴には次のプラットフォームで「購読登録」をいただくと放送の配信をすぐにキャッチして聴くことができます！ Spotify Apple Podcast Voicy YouTube stand.fm Amazon Music YouTube Music LISTEN RSS ## この番組のスポンサー ## ポッドキャスト(Podcast)でお読みしたおハガキのコーナー このポッドキャスト(Podcast)では、放送でお読みする「おハガキ」(と称するTweet、DM、フォームからのご投稿)を募集しています。 ご自身の「Webディレクターとしての仕事の仕方」や「Webディレクション」またWebデザインやマークアップやシステム開発に関しての疑問・質問がある方は、下記からぜひご投稿ください。 Web制作・Webディレクションとは関係ない日常での「こんなことがあったよ」や、今だからいえる「ありがとう」「ごめんなさい」といった話題のおハガキも募集しています！ 今週はいただいていたおハガキからこちらをご紹介させいただきました。 ラジオネーム：ソーシャル・D・スタンスさん 名村さん、こんばんは。 このハガキ、まさかのオフィスの床から書いています。 昨日、2026年9月8日、名古屋がとんでもない雨に見舞われました。 1時間に100ミリを超える雨で、地下鉄も市バスも全線運休、JRも名鉄もほぼ全滅。 9月ひと月分の雨が、1日で降ったそうです。 うちの会社は16時頃に「帰宅していいよ」の号令が出て、私も意気揚々とオフィスを飛び出したんですが、駅に着いた瞬間、電光掲示板が全部「運転見合わせ」でした。 「がーん」って、人生で初めて口に出しました。 タクシー乗り場は行列で、Uberも「近くに車両がありません」の連続。 外は滝みたいな雨で、傘が完全に無力。 30分ほど途方に暮れたあと、「もう…戻ろう…」と、びしょ濡れでオフィスに逆戻りしました。 会社に着いたら、同じ判断をした先輩たちが5、6人いて、なぜか自然と拍手で迎えられました。「同志だ」と。 そこから、社会人になって初めての「会社お泊り」が始まりました。 床にダンボールを敷いて、誰かが買ってきていたコンビニのおにぎりを配給して、「これが噂の帰宅困難、というやつか…」としみじみしました。 不思議なもので、普段は「早く帰りたい」場所であるオフィスが、昨日の夜だけは、めちゃくちゃ心強く感じたんです。 名村さんも、社会人生活の中で「思いがけずオフィスに泊まった」経験ってありますか? 災害じゃなくてもかまいません。 来週も楽しみにしています。 トークのまとめ - 名古屋の大雨で帰宅困難になり、会社に泊まった経験について共感しつつ、体調を気遣うコメントをお伝えしました。 - 自身の「思いがけずオフィスに泊まった経験」として、韓国の不動産テック協会との飲み会で日本酒を飲みすぎ、オフィスのソファで寝落ちして朝を迎えたエピソードを披露しています。 - 濡れて冷えた体調や二次災害への注意を呼びかけ、リスナーの無事を祈る気持ちを表現しました。 ラジオネーム：神のみぞ知るカニのみそ汁さん 名村さん、お疲れ様です！ 今週末はWeb Creator Podcast Day2026ですね。 全員ではないのですが、ずっと聞いている方も出演されていて、それが全員同じ場所にいらしゃるとかもう胸アツです。 最近は雨が不定期に、しかもゲリラ豪雨になることもあるので、くれぐれも当日の運営が滞りなく進むことを応援しています！ トークのまとめ - 2026年9月12日開催される「Web Creator Podcast Day 2026」への応援メッセージに感謝をお伝えしました。 - イベントの詳細（13番組が渋谷のスタジオから生放送、YouTubeでも映像配信）と出演者を丁寧に紹介しています。 - 10時半から夕方5時までのぶっ通し配信であることや、自身が最後のバッファー役として出演することをお話ししました。 ラジオネーム：みしましまさん 名村さん、こんばんは。 社会人になって、不思議に思っていることがあります。 「仕事のやり方」って、なぜ教えてもらえないんでしょうか。 ツールの操作や社内ルールは研修で教わりました。 でも、資料をどういう順番で考えるのか、打ち合わせで何をメモすべきなのか、そういう「頭の動かし方」は誰も教えてくれません。 聞くと「見て覚えて」と言われます。 これは会社の怠慢なのか、それとも本当に教えられない種類のものなのでしょうか。 トークのまとめ - 「仕事のやり方」が教えてもらえない理由について、会社の怠慢と教えられない性質の両面があることを説明しました。 - 暗黙知を言語化する難しさや教育コストの問題に触れつつ、状況によって変わる判断基準はマニュアル化が困難であることをお伝えしています。 - 「見て覚えて」を待つのではなく、先輩に積極的に質問して「なぜその判断をしたのか」を自分から言語化していくことの重要性をアドバイスしました。 ラジオネーム：昼休みのベンチさん なむさん、こんばんは。 先日SNSで、日本企業のデザインを配色・フォント・行間の単位でまとめたギャラリーサイトを見かけました。 無印良品やメルカリ、任天堂などが並んでいて、一晩中眺めてしまいました。 ただ、翌朝ふと思ったんです。 これ、AIに読ませればそのまま真似できてしまうな、と。 参考にするのと、抜き取るのは違うはずなのに、その線引きが自分の中で急に曖昧になりました。 一流のデザインが「仕様」として公開される時代に、デザイナーは何を学ぶべきなんでしょうか。 トークのまとめ - デザインギャラリーサイトの登場で「参考」と「抜き取り」の境界が曖昧になったという相談に対し、WebではHTMLやCSSが昔から見られたため今に始まったことではないと指摘しました。 - AIによって「手間が省かれただけ」であり、表面的な数値よりも「なぜそのデザインに至ったのか」という背景や文脈を読み解く力が重要だとお話ししています。 - 世の中のデザインすべてに「なんでやねん」と突っ込んで仮説を立てる習慣をつけることが、デザイナーとしての成長につながるとアドバイスしました。 ## 月末書籍プレゼントのお知らせ 「Webディレクションやってますラジオ」では、その月におハガキをお読みした方を対象に「書籍プレゼント」をさせていただいています。 ### 抽選資格 * その月に読まれたおハガキ * おハガキをお送りいただく時、メールアドレスを記載の方 ### プレゼントの中身 * 書籍は「Webの技術系」や「ビジネス書」などから名村の独断で決定 で、 毎月月末に放送で抽選をおこない、当選者の発表しています！ ▲目次に戻る

Webディレクションやってますラジオ#311「2年目Webディレクターの段取りが崩れる理由」「先読み力は経験で身につく？」「スランプの脱出の仕方？」

## 2026年9月4日の第311回放送分です！ 毎週金曜日放送のWeb系クリエイター向けの仕事力アップのポッドキャスト「Webディレクションやってますラジオ」の311回目（2026年9月4日）放送。 ▼目次 ## ポッドキャストの配信プラットフォーム このポッドキャストは毎週金曜日、23時〜24時の配信しています。 ご視聴には次のプラットフォームで「購読登録」をいただくと放送の配信をすぐにキャッチして聴くことができます！ Spotify Apple Podcast Voicy YouTube stand.fm Amazon Music YouTube Music LISTEN RSS ## この番組のスポンサー ## ポッドキャスト(Podcast)でお読みしたおハガキのコーナー このポッドキャスト(Podcast)では、放送でお読みする「おハガキ」(と称するTweet、DM、フォームからのご投稿)を募集しています。 ご自身の「Webディレクターとしての仕事の仕方」や「Webディレクション」またWebデザインやマークアップやシステム開発に関しての疑問・質問がある方は、下記からぜひご投稿ください。 Web制作・Webディレクションとは関係ない日常での「こんなことがあったよ」や、今だからいえる「ありがとう」「ごめんなさい」といった話題のおハガキも募集しています！ 今週はいただいていたおハガキからこちらをご紹介させいただきました。 ラジオネーム：昼休みのチャイムさん 名村さん、こんばんは。 先日、甥っ子と話していて自分の小学生時代を思い出し、顔から火が出ました。 小6の学級会「将来の夢」で、目立ちたい一心で、 「僕は、世界を救うヒーローになります!」 とマイクで宣言したんです。 沈黙のあと、担任が真顔で、 「…もう少し、現実的な夢でお願いできる?」 と言い、教室が爆笑になりました。 その日から半年間、あだ名は「ヒーロー」。卒業式でも呼ばれました。 いまインフラエンジニアとしてサーバーの裏側で世界の一部を支えているので、半分は当たっていた、ということにしています。 来週も楽しみにしています。 トークのまとめ - 小学校の将来の夢発表で「世界を救うヒーローになる」と宣言し、半年間「ヒーロー」とあだ名で呼ばれた過去についての投稿に対し、インフラエンジニアはまさにヒーローだと励ましました - サーバーの裏側で世界を支える仕事は、半分どころか全部夢が叶っていると伝えています - 同窓会で昔の友達に会ったら「俺は今でもヒーローだ」と堂々と言えばいい、とアドバイスしました ラジオネーム：一旦木綿豆腐さん 名村さん、こんばんは。 名村さんは仕事で「スランプ」というのは経験がありますでしょうか？ 最近はやることなすこと上手くいかず…という日々です。 それが実はもう半年ぐらいは続いていて、なかなか心が折れそうになる日々です。 うちの会社は在宅が可能なので、僕は比較的家で黙々と仕事をしていることが多いのですが、最近はそれが原因なのかも・・・と思い始めていたりします。 コロナはもうとっくの昔に過ぎ去った・・・とおもっていたら最近流行っているらしい話題もありますが、一時のように外出禁止って訳でもないですし、もっと出社をしてみた方がいいのかも・・・と思ってたりします。 抜け出す方法とかあればぜひ知りたいと思っておハガキさせていただきました。 トークのまとめ - 半年続くスランプの原因が在宅勤務にあるのではという相談に、「会社へ行きましょう」と明確に答えました - ストレスをゼロにすることは不可能で、通勤などの適度なストレスがあることで小さなストレスへの耐性ができると説明しています - 人と会うことで自分の位置を確認でき、スランプから抜け出すきっかけになるとアドバイスしました ラジオネーム：春日ゆ〜りんさん 名村さん、こんばんは。 2年目のディレクターです。 先日、初めて小さな案件をひとりで任せてもらったのですが、見事に段取りで転びました。 デザイン確認の戻りを待つ間、エンジニアさんを遊ばせてしまい、かと思えば、素材の支給依頼を出し忘れていて、最後は全員に無理をお願いする進行になってしまいました。 先輩の案件はいつも、「気づいたら全部が揃っている」ように進んでいきます。 あの先読みの力って、経験を重ねれば自然に身につくものなんでしょうか？ それとも意識的な訓練が必要なものなんでしょうか。 段取り下手な若手に、最初の一歩を教えてください。 トークのまとめ - 初めて一人で任された案件で段取りに失敗した2年目ディレクターに、「その失敗こそが経験になる」と伝えました - 先輩の先読み力は経験だけでなく、WBS（業務分解）がしっかりできているかどうかに帰結すると説明しています - 生成AIに過去のWBSを学習させて会社の知見を活用すれば、若手でも抜け漏れのない進行ができるとアドバイスしました ラジオネーム：笑い方バッファローさん 名村さん、はじめまして。 僕はエンジニアになろうと新卒としてIT業界に入ったのですが、入ったらそれこそ初日から「生成AI」をゴリゴリに使うことが前提になっていて、自分がプログラミングのスキルが上がっている実感も持てない日々です。 また今後も自分が手でプログラムを書くこと自体がなくなり、「エンジニア」になれるのかが不安です。 このような状態で僕はどういったモチベーションで仕事をすればいいでしょうか？ トークのまとめ - 入社初日から生成AIをゴリゴリ使う環境で、プログラミングスキルが上がる実感がない新卒エンジニアの悩みに答えました - 新卒のタイミングで生成AI全盛期が来たのは運の良し悪しではなく、時代の大転換点に立ち会えているチャンスだと伝えています - 手でコードを書くことは諦めて、プログラムがどう動くかの原理原則を突き詰めて学び、新しい時代のエンジニア像を作ってほしいとエールを送りました ## 月末書籍プレゼントのお知らせ 「Webディレクションやってますラジオ」では、その月におハガキをお読みした方を対象に「書籍プレゼント」をさせていただいています。 ### 抽選資格 * その月に読まれたおハガキ * おハガキをお送りいただく時、メールアドレスを記載の方 ### プレゼントの中身 * 書籍は「Webの技術系」や「ビジネス書」などから名村の独断で決定 で、 毎月月末に放送で抽選をおこない、当選者の発表しています！ ▲目次に戻る

BacklogとAI、どこから手をつけるか ─ JBUG Creative #4 に登壇しました

2026年8月26日、ヌーラボ東京事務所で開催された「JBUG Creative #4 Backlog×AI 実践知共有会」に登壇させていただきました。私がBacklogを使い始めたのは2006年、今年で20年目になります。いただいたテーマは「BacklogとAIをどう利活用しているか」。20分という枠でしたので、事例を個別に紹介するのではなく、「結局、何から手をつければいいのか」の地図を渡すことに時間を使いました。 選択肢が増えすぎて、動けなくなっているこの3年、Backlog周辺のAIは大きく動きました。2023年11月のAI要約、2025年11月のAIバックログスイーパー、2026年3月のBacklog AIアシスタント正式リリース。公式MCPサーバーも出ています。ただ、選択肢が増えたことで逆に迷いが生まれているように感じます。Backlogの中のAIを使えばいいのか、ChatGPTやClaudeを使うべきか、Claude Codeのような「黒い画面」からやったほうがいいのか。でもエンジニアじゃないからあれ自体がよくわからない──。そういう方が、けっこういらっしゃるのではないかと思います。そこで当日は、紹介するものを3つのレベルに分けました。誤解のないように申し上げると、これは聞いている方のレベル分けではなく、手段のレベル分けです。Lv.1 Backlog標準のAI機能（管理者が有効化するだけ）Lv.1.5 GASやGPTsで小さな自動化を作るLv.2 MCPを使ってAIエージェントから操作する Lv.1：AIが「Backlogの中にいる」ということBacklog AIアシスタントの本質は、機能の多さではなく、AIがBacklogの中にいるという一点だと思っています。汎用の生成AIに課題を要約させようとすると、画面を開き、コメントを全選択し、貼り付け、「これはプロジェクトの課題で……」と前提を説明する必要があります。この準備に3分かかるなら、自分で読んだほうが早い。だから続かないんです。CSVの一括登録も同じで、私自身インポートは生涯で2〜3回しか使ったことがありません。もうひとつ、生成AIを使い始めた方が最初にぶつかるのが「何を聞いていいかわからない」という壁です。私はいつも「隗より始めよ」とお伝えしています。「自分の課題の一覧を出して」でいい。人間はそんなに頭が良くないので、できることから少しずつ肌に馴染ませていくしかありません。ここは分けて考えてくださいセキュリティについて、ひとつ強調しておきます。「学習データに使わない」ことと、「その情報を生成AIに投げていいか」は、まったく別の話です。 学習に使われないから機密情報を投げていい、とはなりません。質問した時点で、データは相手のサーバーに届いています。その点、Backlogの中で完結するAIアシスタントは、参照範囲が自分の参加プロジェクトに限られます。顧客名の入ったコメントをそのまま扱える安心感は、受託の現場では想像以上に大きいと思います。Lv.2：外にいるAIが、Backlogに手を伸ばす一方のMCPは構造が逆で、AIはBacklogの外にいて、そこから手を伸ばして読み書きします。当日は自社のBacklogを繋いだ実演をお見せしました。「最近登録されているけど未完了のチケットを調査して、緊急度と担当、内容概要を一覧にして」と投げると、一覧だけでなく最後にこう返ってきます。計測設定と改修のチケットの順序が逆転している（改修が今週リリースなのに効果測定が未着手）優先度「高」かつセキュリティに関わる項目が100日以上超過したまま処理中「処理済み」のまま止まっているチケットが複数ある正直に言って驚きました。人間が数十件のチケットを頭に入れて、その相互関係の矛盾に気づくのは、まず無理です。ただし代償があります。編集権限を渡すとは、最悪の場合、課題が消えるということです。 慣れないうちは「削除させない」「上書きさせない」を徹底してください。差は「AIがどこにいるか」両者の違いは機能の優劣ではなく、立ち位置です。組み込みのAIMCP等の外部AIAIの居場所Backlogの中Backlogの外文脈を渡す作業不要接続の設計が必要得意なことその場の理解・作成横断分析・自動実行必要な準備有効化のみ環境構築・権限設計主なリスクプラン制約誤操作・情報の持ち出しどちらが偉いということはありません。道具をどう使うかの話です。普段チャットでAIを使っている方なら、素直にBacklogのAIアシスタントが最短です。日常的にコードを書いている方なら、MCPに進む価値は十分にあります。結局、Backlogにちゃんと書くこと最後にお伝えしたのは、身も蓋もない結論です。AIの精度を上げる一番の近道は、Backlogにちゃんと書くことです。これはAIの話ではありません。書かれていなければ、AIはそれ以上のことを返せない。ない情報は、誰にも作れないからです。うちの会社では、チャットでの仕様決定は厳禁にしています。調査結果のSQLひとつでも、チャットに流したら後で見られません。すべてBacklogに残す。プロジェクト管理ツールは、覚えておくために書くのではなく、忘れるために書くものです。 人間が記憶に頼っている限り、プロジェクトは必ず破綻します。そしてAIが読める粒度で課題を書けるかどうかは、結局のところビジネス文章力の問題になっていきます。ここが次に効いてくるスキルではないかと考えています。ご参加いただいた皆さま、運営のJBUG Creativeの皆さま、会場をご提供いただいたヌーラボさま、ありがとうございました。ご質問は毎週金曜23時配信のPodcast「Webディレクションやってますラジオ」宛にどうぞ。

2026年8月21日「AI活用ファイトクラブ in 沖縄」で登壇しました。

2026年8月21日（金）に沖縄・那覇の「SAKURA innobase Okinawa」で開催された「AI活用ファイトクラブ in 沖縄」に登壇をいたしました。デザイン・マーケティング・開発・行政の第一線に立つ12名が、1人10分の持ち時間で自分のAI活用を語るというイベントです。僕はセッション1「AI導入、最初の壁を突破せよ！」の2番手として「自分のAI利用力/活用力を底上げする方法」というタイトルでお話をさせていただきました。 ## 10分で何を話すか？ 12人が10分ずつ、しかもお越しになるのは「もう触ってはいる」方が中心です。ここで細かいTipsを話しても、僕のあとに続く11人の話に埋もれるだけだろうと思いました。かといって、抽象度の高い話だけをして終わるのも10分の使い方として違う気がする。何を持ち帰っていただくのがいいのだろうか、とかなり迷ったのですが、結果的に選んだのは「隗より始めよ」の一点に絞る話でした。 SNSを見ていると「知らないと情弱」的な煽り記事がタイムラインに流れてきます。海外の記事を翻訳しました、という体のものも含めて、冒頭は決まって「これが最新です、早く取り入れた方がいいです」から始まります。 僕も最初の頃は、こんなことも知らなかったのかと焦って調べていました。ただ、そういう記事は全文をコピーしてClaudeに貼り、評価させてみてほしいのです。「これは煽りで、実際にはあまり意味がありません」「正しい部分もありますが、6割は誇張です」「有料商材への導入のための、典型的な不安を煽る書き方です」と、かなり冷静（辛辣？）な答えが返ってきます。 Claude Codeの便利な使い方を紹介する記事をClaude自身が否定してくるわけです。 もちろん良い記事がない訳ではありません。実際「この部分だけは名村さんが導入する価値があります」と教えてくれることも多々あります。ただやはり全体的には「知らないとヤバいよ」感を感じるような言い回しが多いように感じます。 そのうえで、いきなり「事業をつくる」ような大きなところからは始めないでほしい、という話をしました。 世の中の記事の多くは、いちばん上の段の話をします。でも、そこから始めるとまず続きません。僕自身、最初に作ったのはオフィスの入退室をSpreadsheetに自動記録するだけのアプリです。次が領収書の自動収集、その次が動画のタイトル付与アプリ。 小さい・地味・目立たない。 でも「作る→動かす→気づく→次を作る」をやめなかった結果、今は一人でサービス開発まで届きました。 ## 抽象と具体の間を行き来する この「気づき」を起こすのが、抽象と具体の往復です。 領収書サイトから自動でPDFを取得できた、という具体を、「ログインが要るサイトの定型操作も自動化できるんだ」と一段のぼって言語化する。そうすると、目の前の別の面倒におろせるようになります。 この往復のたびに、生成AIで「できること」の解像度が上がっていきます。 逆に言えば、AIに何をさせられるかを決めているのは、指示する側の思考の広さです。そしてその感覚は、SNSを眺めていても手に入りません。自分の手で作った人にしか育たないものだと思っています。 ## 12名が話していたのは「使い方」ではなく「向き合い方」 自分の登壇以上に収穫だったのは、他の11名の話でした。「AIで◯◯ができる」という内容はもう一周回って終わっていて、皆さん使い倒したうえでの「AIとの向き合い方」を話していたのが印象的でした。 そして何より、オフラインだからこそ聞ける話がありました。 あるセッションは、今後の「会社におけるAIの使い方」として結構強烈な内容で、オンライン配信では絶対に言えなかったと思います。 名村はポッドキャストやセミナーでもよく言っていますが「価値は希少性」です。 大多数の人が「ネットで情報は得られるのに外に出てまで情報を得るのは非効率」と思っている人が多い今だからこそ、時間とお金をかけて取りに行くオフラインの一次情報は、圧倒的な優位性を持ちます。 ## やっぱりリアルは良いです 懇親会も含めて、リアルに人と会って話ができるのは最高でした。お声がけをいただける限り、リアルのセミナーは全国どこへでも優先的にお伺いしたいと思っています。 沖縄は今回が初めてでした。ご参加をいただいた皆さま、主催・登壇の皆さま、ありがとうございました！

「JBUG東京#26 Web制作会社向け Backlog活用ナレッジ共有会〜Wiki・ドキュメント編〜」に登壇しました。

2025年3月7日（金）に開催された「JBUG東京#26 Web制作会社向け Backlog活用ナレッジ共有会〜Wiki・ドキュメント編〜」に登壇をさせていただきました。 ## セミナー概要 今回のテーマは「Wiki・ドキュメント」。チーム内での情報共有やナレッジ蓄積をスムーズに進めるための具体的な使い方や事例をご紹介します。日々の業務に役立つWiki・ドキュメント活用法を一緒に学びませんか？ Backlogを活用している方も、これから導入を検討中の方も、どなたでもお気軽にご参加ください！ * 日時：2025年3月7日（金）19:00 ～ 21:00 * 会場：TAM COWORKING TOKYO * 住所：東京都千代田区神田小川町3-28-9 三東ビル1F * 参加費：無料 * 申し込み：[https://jbug.connpass.com/event/343847/](https://jbug.connpass.com/event/343847/) ## 名村以外のご登壇者さま ### 中島 碧さま（株式会社ベイジ） #### プロフィール 株式会社ベイジでディレクター兼コンサルタントとして、ウェブサイト制作のディレクションや業務システムのUX・UI改善業務に従事。エンジニアとしてITベンダーで業務システムの開発・業務支援を経て現職に。ディレクター歴2年目。 * [https://baigie.me](https://baigie.me) * X（Twitter）：[https://x.com/aoi310_design](https://x.com/aoi310_design) ### 丸野 美咲さま丸（株式会社プロクモ） #### プロフィール 大学卒業後、株式会社リクルート北海道じゃらん入社。宿泊施設や行政に対する課題解決型の広告提案営業を担当。2020年株式会社ノースディテール入社し、Web業界未経験から行政サイトに特化したWebディレクターに転身。2021年にマーケティング戦略コンサル会社の現職の会社に入社。制作チームのマネジメントやプロジェクトPMとして業務に取り組む。Backlog歴4年。好きな機能は「課題のテンプレート」と「課題一括登録」。リモートで働けるプロフェッショナル育成スクール「プロリモ」運営。 * [https://procmo.co.jp/](https://procmo.co.jp/) * X（Twitter）：[https://x.com/yaritaikotohai2](https://x.com/yaritaikotohai2) * プロリモ：[https://proremo-writingschool.studio.site/](https://proremo-writingschool.studio.site/) ## JBUGとは？ JBUG（Japan Backlog User Group）は、プロジェクト・タスク管理ツールBacklogのユーザーコミュニティです。 プロジェクト管理は、全ての業種や職種において必須のスキルである一方、そのノウハウが学べる場はあまり多くありません。 Backlogは国内最大級のプロジェクト管理ツールであり、その豊富なユーザー事例から学び合うことで、より効果的なプロジェクト管理や楽しい働き方を追求しています。実体験から得た知見やノウハウをシェアし、共に「働くを楽しくする」を実現したいと考えています。 （[コミュニティサイトの記述より](https://jbuginfo.backlog.com/)） ## セミナー時の名村のセッション概要 このセミナーでは「wiki・ドキュメント編」と銘打っていたこともあり、[サービシンク](https://servithink.co.jp/)で運用しているwikiのテンプレートをご紹介しました。 wikiは書き込みも便利なツールなのですが、いかんせん「ページ構成」「ページ構造」などの部分を複数人で作り始めると、属人性がモロにでてきます。 結果として「あちらのプロジェクトでは書いていることが、こちらでは書かれていない…？」ということになっていきます。 それによって起こるのは「どこに書いているか分からないので探す」という無駄な時間です。我々はクリエイティブな部分に時間を割きたいのであって、書いているかどうかもわからない情報を探すことに時間を費やすべきではありません。 そのために「Web制作のプロジェクトに必要な情報を漏らした目次」ともいえるwikiのテンプレートを用意し、それび追記をしていく、という手法をご紹介しました。 もちろんこのテンプレートはプロジェクトマネジメントをやってきたある程度の経験者でなければ作れないと思います。それは「過不足が分からない」からです。ですが、それを一度作れたならば、下手に自分のオリジナリティをだすのではなく組織として作ったそのテンプレートを大事にしていくほうが遥かに精度が高く、ヌケモレもないものとして運用ができます。 小さなことの積み重ねが大きな差になっていきます。ご参加いただいたみなさまにはスライドでご紹介したwikiテンプレートを共有させていただきました。 参加者の皆さまのお役に立っていれば幸甚です。

Backlog World2024に出演させていただきました。

▼目次 ### Backlog World2024に登壇しました。 2024年12月14日（土）に「パシフィコ横浜ノース」で開催された「Backlog World2024」に登壇をいたしました。 「Backlog World」は、2021年には登壇エントリーをさせていただき出演をさせていただいたのですが、今回は大変ありがたいことに、今回主催の方からお声がけをいただき、招待講演という立場でお話をさせていただきました。 #### 2021年に登壇をした時のエントリー 2021年の「Backlog World2021」位登壇をしたときのブログはこちらです。 ▼目次 ### オープニングアクトとして何を話すか？ 今回、実は僕の都合もありオープニングアクトとして出演をさせていただきました。15分という時間の中で何を話をさせていただくのかかなり迷いました。 * Tipsはお伝えしたいけどオープニングアクトなのでする話なのか？ * しかし基調講演はかの「[安達 裕哉](https://x.com/Books_Apps)」さんが午後一にするのでふんわりした話も意味が分からないだろう。 * では、何の話をするのがいいのだろうか？ というようなことをモヤモヤ考えていました。 結果的に思い至ったのはBacklogをはじめとしたチケット管理システムをそもそも使うのが面倒と思っている人にとって「使ったほうがいいかも？」と思ってもらえる話はどうだろうか？ そういう話ができれば、僕のあとの形の話もより「自分ごと」や「そういう工夫をしたらいいかも」と思ってもらえるのではないだろうか？ということでした。 当日のスライドは後述していますが、抽象度が高い話になりかねないと思っていたので、ギリギリまでスライドをいじっていました。結果的に持ち時間15分ギリギリでしたが、お伝えしたかった内容は話せたのではないかと思いいます。 終わったあとにヌーラボのCS担当の方から声をかけていただき、内容についてコメントをコメントを貰えたのですが、概ね好評だったので、溜飲下がる思いでした。 ### リアルのセミナーはやっぱり良いです 2023年にコロナが落ち着いてきてからリアルのセミナー登壇もいくつかさせていただきました。今回は2023年以降では一番の大きな箱でしたが、緊張はするものの、やっぱりリアルのセミナーはいいですね。 客席にいらっしゃる方々の反応をリアルに感じることができるので、自分が一方的に話をしているのではなく「お伝えしている」という感覚を持てます。また久しぶりに会えた方々とご挨拶ができたりするのは、リアルセミナーの良いところで、何より「*コミュニケーションツールのイベントで、リアルにコミュニケーション取れた*」のは意義が大きいなと思いました。 今回X(旧Twitter）を見ていると北海道や福岡からも来ている方がいて、意味や意義を感じたら来る方は来る、というのも分かりました。（来られないから悪いとかって意味ではないですよ） ### ちょうどヌーラボ社長の橋本さんにポッドキャストに出演いただきました。 狙いすましたように、[イベント前日のポッドキャストに、ヌーラボ社長の橋本さん、また以前BacklogのコミュニティマネージャーをしていたMeggyさんに出演をいただいていました](https://web-directions.com/director/radio/radio-223.html)。 ### 当日のスライドはこちらです。 当日会場で発表に使ったスライド資料はこちらとなります。 ### ASCII様の記事がYahooニュースに乗りました 今回の「[Backlog World2024](https://jbuginfo.backlog.com/backlogworld2024/)」での内容がASCII様が記事にしていただき、それがYahooニュースに掲載されました。 以下に記事中の名村の登壇について記載をいただいた部分を引用させていただきます。 （引用元は[この記事のURL](https://news.yahoo.co.jp/articles/1b38ffa542e3fef85e3c86846b0801afdc7b3355)） 開会式の後、「チームを楽に、プロジェクトを早く進めるためのBacklog」というタイトルで登壇したのはサービシンク 代表取締役 名村晋治さん。サービシンクはWeb制作やシステム開発を手がける新宿のIT企業で、2006年からBacklogを利用している。名村さんは、4年前からWebクリエイターの質問に応えるPodcastを配信しており、昨日はヌーラボの橋本代表も参加したという。 まずは前提の話として、「私の話は正論だと思いますが、正解ではない」と名村さん。Backlogは「未来を楽にするツール」。だから、「未来は苦労してもいいと思っている人」や「今の苦労は我慢できないという人」にはBacklogは向かない。ただ、「1年後には続けてきた自分を褒めたくなるはず」と名村氏は語る。 そして本題は「Backlog、そもそも使いたくない人いるんじゃないの？」というユーザー会に似つかわしくない問いからスタートする。そんな名村さんも、2006年に使い始めた当時は、実は使いたくないと思う立場だった。「なんでこんなことやらなければならないの、面倒くさい」「Excelでなんとかなるでしょう」「『マネジメントで必要だからやりなさい』って、知るか！」「起票する間に作業終わる」と思っていたという。 しかし、それから紆余曲折あり、5年経った2011年頃、あれだけいやがっていたBacklogの利用に腹落ちした経験があった。「書いておくって、そういうことか」「これ使わないとやばい」「これを使っていてマジよかった」となり、これ以降Backlogに起票しないという選択肢はなくなった。今では名村さんも「うちの会社でも人一倍Backlogに書けと言います（笑）」という存在になった。 そんな「未来を楽にするツール」であるBacklogだが、情報共有の手間を減らすことで、「今」も楽にしてくれる。Backlogのようなチケット管理システムをなぜ使うのか？ 名村さんは、「覚えないため、もっと言うと忘れるため」だと語る。「記憶に頼っている限りは、忘れることがある。当然抜け漏れもある。だから、いっそ忘れるために、Backlogに書いた方がいいと言っている」（名村さん）。 タスク管理ツールの謳い文句が現場ユーザーに響かない理由 ほとんどのタスク管理ツールでは謳い文句が決まっている。「タスクの担当者・期日が明確になり、確認漏れや遅延を防ぐ」「複雑なプロジェクトや日常教務に最適」「プロジェクト全体、それぞれのタスク状況をチームで共有し、プロジェクトの進行を支援」などだ。「プロジェクトマネージャーであればこれで納得するが、ほとんどの人には響かない。だから、使うの面倒くさいにつながってしまう」と名村氏は語る。 現場のユーザーが求めているのはメールでも、チャットでもいいから、明確な指示だという。デザイナーはデザインが仕事だし、プログラマーはコードを書きたいはず。指示書やドキュメント作成は本来の仕事ではないし、「エディタで2文字直して、FTPでアップするための作業にわざわざチケットいる？」「使うだけ手間も面倒も増える」という声もわかる。つまり、プロジェクト管理は人によって重さが違うのだ。 そもそもチケット管理ステムを初めてプロジェクトで導入すると、使い始めはまったく楽にならない。1ヶ月経っても、記入する意味を見いだせない。しかし、1年経つと便利さを実感できるという。これは「書きためた情報がナレッジになってくるから」にほかならないという。 時間が経つとなにが変わるのか？ たとえば過去の経緯、同じ作業・似た作業のやり方もわかる。「うちの会社の場合、エンジニアはSQLの内容と結果まで貼り付けています。1年前にやっていた調査もわかるし、新人はSQLを貼り付ければいい」と名村さん。細かく起票することで、引き継ぎも少なくなる。なにより、Backlogに起票しておけば、Backlogだけ探せばよくなる。「調査や繰り返し作業が出てきたとき効果は絶大」と名村さんは指摘する。 ただし、この状況を実現するには、Backlogにすべての情報が集約されなければいけない。メールの連絡や資料、電話での連絡、個別チャットでの連絡、定例での口頭での話など、基本はBacklogにコピペしたり、起票する必要がある。かなりハードだが、ここまでやらないとチケット管理システムを導入する意味は見いだせないという。「すべては記憶に頼らず、覚えないため」（名村さん）だ。 Backlogに業務の履歴が残るようにするためには、チャットでコメントのやりとりは絶対しないという意識が必要になるという。「探している時間は仕事の時間じゃないからねと言います。Backlogにまとめて書いておけばいいのに、メールやチャットを探すなんて時間がもったいない」と名村さん。 そのため、サービシンクでのチャットのやりとりは、対応と依頼にBacklogのリンクを張るだけの簡素なやりとりになる。「これだけ見ると仲悪いみたいに見えてしまう。『メール送りましたー』という電話しているみたいで、ちょっとモヤモヤする（笑）」と名村さんは語る。 今の1分が未来の1時間を救うかもしれない 名村さんにとってプロジェクト管理ツールは、「過去を未来に渡すツール」だという。「今の最適解だけ必要なら口頭でのやりとりでいいかもしれない。でも、プロジェクトは半年、1年続いていく、うちの会社の場合は10年続いているプロジェクトもあります。こうなると、一大ナレッジになります」と名村さん。 Backlogでナレッジを溜めるためには、情報はどのように登録すべきか？ 名村氏は、まず最低限「状態」「担当者」「マイルストーン」「開始日・終了日」は必須項目として登録すべきだという。これらは全員ができるまで、何回でも注意を行なって、徹底させる。その上で、業務のパス回しの際に担当者と状態を変更し、最後にチケットを終了させるというフェーズまで持ち込む。 また、あとで「読み返す」ことを考慮しなければならない。そのため、英語表記とカタカナ表記のような揺れ、特定の人しかわからない「オレオレ単語」、一見してわからないタイトルなどを排除する入力が必要になるという。 続いてBacklogのWikiだが、名村氏は「そもそも複数人で構造まで手を出してはいけないツールなので難しいと思っている」と指摘する。そこで同社ではプロジェクトごとにフォーマットを用意し、コピペして利用している。中身がないところはグレーで、中身があるところには色が付くので、色を埋めていくように入力を進めている。「だからどのプロジェクトを見ても構造が同じ」（名村さん）だという。 最後に「ここにいる人は大丈夫だと思いますが、Backlogを使うのをいやがらないでいただきたい」と訴える名村さん。「確かに手間がかかる部分があるが、今だけを管理するツールと考えないでほしい。今の1分が未来の1時間を救うことになるかもしれません」と語る。もちろん、手間は少しの工夫で乗り切ることもできるし、なによりこのツールは自分と仲間のために存在している。「今使わなければならない理由、未来の自分と仲間を救うための理由を考えてほしい」と語り、自社で利用しているWikiのテンプレートを案内して、登壇を終えた。 ### 登壇中の写真 当日は自分で自分の撮影ができなかったのですが、多くの方が写真を上げてくださっていました。 ### 登壇中のX（旧Twitter）のポストより #BacklogWorldファーストセッション 名村さん！未来につながるお話を！とのこと pic.twitter.com/oWBdl0hpQX— ちさと (@chisato5150) December 14, 2024 名村さんによる「チームを楽に、プロジェクトを早く進めるためのBacklog」が始まりました。 #BacklogWorld pic.twitter.com/cmnol0MOcy— 川手 遼一 (@RKawtr) December 14, 2024 > 正論は正解ではないわかる。。。。#BacklogWorld #JBUG pic.twitter.com/Jg9aEpeb6Z— Abetaku(ｱﾍﾞﾀｸ) (@east_takumi) December 14, 2024 さー始まりました！まずは名村さんのセッションです。Backlog を使うと、「1年後に自分を褒めたくなりますよ！」←ホントそれ！ #BacklogWorld pic.twitter.com/QPhVIhTB2h— ゆうこす| Nulab (@yukos0829) December 14, 2024 ### 名村登壇中のX（旧Twitter）のポストのまとめの「togetter」 上で引用させていただきました方々以外にも多数の投稿がありました。全部掲載ができないので、投稿いただいた方のポストを「togetter」にまとめさせていただきました。 リアルタイムにものすごい量の投稿がされていて、ご感想をみることができてとても嬉しかったです。 ### まとめ 今回Backlog World 2024に登壇させていただきまして、本当に楽しかったです。自分が考えていた「Backlogを使う意味と意義」みたいなものに共感を頂けたのも嬉しかったですし、多くの人にお会いだけたこともとても楽しかったです。 時間の関係で話ができなかったことも多々あるので、今後も機会があればぜひ仕事を「意味ある時間の使い方」をするための方法を皆さんにお伝えできればと思っています。 ご参加をいただきした皆さま、ありがとうございました。

登壇情報：Life Hack Camp Vol.10「つながる、はじめる、かんがえる - チャレンジを楽しもう！」

2024年11月30日、鳥取県米子市で開催される「Life Hack Camp Vol.10『つながる、はじめる、かんがえる - チャレンジを楽しもう！』」に登壇をさせていただきます。 ### イベント概要 テーマ：つながる、はじめる、考える チャレンジを楽しもう！ 日時 ：2024.11.30 13:00〜17:30（終了後懇親会） 会場 ：米子コンベンションセンター（ビッグシップ）会議棟6階 第7会議室 定員 ：70名（定員超過の場合は立ち見となる場合もあります) 参加費：¥1,000（事前決済：Peatix）¥1,500（現地決済） 主催 ：[山陰プロデュース＆ディレクション研究会](https://sanin-pd.com/) 協賛 ：[株式会社 KDDI ウェブコミュニケーションズ](https://www.kddi-webcommunications.co.jp/)、[AUN（あうん）](https://aun.tools/) 後援 ：[合同会社フット](https://fo-ot.jp/) ### セミナーテーマ #### 「チャレンジを楽しもう！」 新しいことに挑戦する時に、失敗を恐れてしまったり、その先本当に必要なのかという不安だったり、損をしたくないとか、「今からやっても…」といった諦め。みたいなものに邪魔されて一歩踏み出せないことがあるのかなと思っています。 山陰PD研でも、今年の６月に開催したキャンプイベントは初の試みでした。 最初は「できるかな？」からスタートしましたが、やったことで課題や反省もありましたが、それ以上に次につながるものがたくさん得られたという体験をしました。 ですので、一歩踏み出す勇気というか「まずはやってみよう。失敗も含めてそれを楽しもう。」ということをイベントを通じて気付くことができる、体験できる。そんな内容にしてはどうかとこのテーマを考えました。 #### 「つながる、はじめる、考える」 山陰エリアでは、クリエイター向けのイベントはあまり多くはありません。 新しい場所に一歩踏み込んでみる、新しい人たちと出会い、つながる。 こういったイベントに参加するのも一つの「チャレンジ」ではないでしょうか。 ですから、よくある講座形式で終わらすのではなく、プラスして参加型で体験する（ちょっと勇気が必要だけど、やれなくはない。といったレベル）。そんなイベントを企画しました！ 話を聞くだけでも明日につながる気づきが得られるのではと思います。 今回はなるべく多くの方に参加していただけるよう、鳥取県米子市で開催です。 ぜひ、遊びに来てください！！ ### 名村の登壇内容 今回はスライドを用意して…という形式ではなく「パネルディスカッション」になります。ということはお相手がいる、ということなのですが、あの「[Webクリエイターボックス](https://www.webcreatorbox.com/)」のManaさんです！ Manaさんは「Webディレクションやってますラジオ」にも出演をいただいています。 元々は「Webクリエイターボックス」でManaさんがお聞きのポッドキャスとして「Webディレクションやってますラジオ」を取り上げていただいたことから出演のオファーをださせていただきました。 僕はManaさんはこの時初めて（テレビ会議ですが）お会いをさせていただきました。Manaさんもポッドキャスをされていて、その御縁もありました。 #### 登壇内容 「教えて！聞いて！名村さん、Manaさん」 スピーカー：名村 晋治 さん、Mana さん Web制作に携わり28年目という名村さん、そして海外でのお仕事の経験もあるManaさん。これまで多くのチャレンジをされてきたことは容易に想像がつきます。 また、名村さんはWebディレクタ育成講座を開催されていますし、Manaさんはインストラクターとして教育関連の事業にも携わっておられます。 その幅広い知見や経験はきっと私達のお仕事へも活かせるはず！ ということで本セッションではそんなお二人への質問、相談を募集し、トークセッション形式でお届けします！ こんな機会滅多にありませんよ！！ 今直面している課題や不安なこと、お二人だったらどうする？といったことなど、ぜひお二人に聞いてみましょう！ ということで、Manaさんと僕とで質問、相談に対してお答えさせていただく、というものになっています。 「Webディレクションやってますラジオ」でも同様のことをさせていただいていますが、リアルセミナーだからこその突っ込んだ内容でお答えさせていただくつもりです。 2024年11月30日、米子に来られる方はぜひお越しください！

「JBUG東京#24 Web制作会社向け Backlog活用ナレッジ共有会〜課題設定・管理編〜」に登壇しました。

2024年10月4日（金）に開催された「JBUG東京#24 Web制作会社向け Backlog活用ナレッジ共有会〜課題設定・管理編〜」に登壇をさせていただきました。 ## セミナー概要 イベント前半では、3名の登壇者にWeb制作の現場でBacklogをどのように活用しているか紹介いただきます。 後半はパネルディスカッションを通して、前半で話しきれなかった内容や参加者からのアイデアや実例、質問をもとにトークを展開し、Backlogへの理解を深める時間を設けます。 皆様のご参加をお待ちしております！ * 日時：2024年10月4日（金）19:00 ～ 21:00 * 会場：TAM COWORKING TOKYO * 住所：東京都千代田区神田小川町3-28-9 三東ビル1F * 参加費：無料 * 申し込み：[https://jbug.connpass.com/event/325542/](https://jbug.connpass.com/event/325542/) ## 名村以外のご登壇者さま ### 金子 大地さま（株式会社JBN 金子 大地） #### プロフィール 株式会社JBNでWebディレクターとして勤務。HubSpotの導入・運用支援、デジタルマーケティング、Webサイト構築に従事。 証券リテール営業→広告企画営業を経て現職。Webディレクター歴4年目。 オンラインセミナー『#朝までディレクションとか』登壇。 1992年生まれ、長野県長野市在住。Mr.Childrenファン歴22年。 * https://www.jbnet.jp/ * X（Twitter）：https://x.com/daichikanekoda * note：https://note.com/daichikanekoda/ ### 丸野 美咲さま丸（株式会社プロクモ） #### プロフィール 株式会社プロクモでディレクション・デザインチームのマネジャー兼Webディレクターとして、組織やプロジェクトのマネジメント、サイト制作ディレクション業務に従事。 観光情報誌「北海道じゃらん」広告営業、1000ページ以上に及ぶ市町村サイトの制作ディレクターを経て現職。 国家資格キャリアコンサルタントを取得し、気軽にキャリア相談ができる「モヤ晴れキャリア」の運営も行う。 * https://procmo.co.jp/ * X（Twitter）：https://x.com/yaritaikotohai2 * モヤ晴れキャリア：https://lin.ee/BswLkRO ## JBUGとは？ JBUG（Japan Backlog User Group）は、プロジェクト・タスク管理ツールBacklogのユーザーコミュニティです。 プロジェクト管理は、全ての業種や職種において必須のスキルである一方、そのノウハウが学べる場はあまり多くありません。 Backlogは国内最大級のプロジェクト管理ツールであり、その豊富なユーザー事例から学び合うことで、より効果的なプロジェクト管理や楽しい働き方を追求しています。実体験から得た知見やノウハウをシェアし、共に「働くを楽しくする」を実現したいと考えています。 （[コミュニティサイトの記述より](https://jbuginfo.backlog.com/)） ### セミナー時の名村のセッション概要 このセミナーでは「これだけは絶対押さえておきたいBacklogの機能の利用とその効能」というタイトルで、「チケットの作業は完了しているのに、何故か『作業中』『処理済み』のままで残るゾンビタスク」をどの様に解消していくのか？という内容でお話をさせていただきました。 時間としては15分程度の内容でしたので、細かくはお伝え出来ていない部分もあったかもしれませんが、[サービシンク](https://servithink.co.jp/)でBacklogを使っている上で徹底して社内で伝えるようにしている部分をご紹介させていただきました。 JBUGは過去に何度か登壇をさせていただいていますが、基礎の基礎を大事にしていくことで本当に使いやすいツールだと常々感じています。 ## 懇親会の大事さを改めて感じました このイベントは「*リアル開催のみ*」だったのですが、合わせてリアルでの懇親会もありました。リアルでの懇親会もちょっとずつ戻ってきました。 実感するのはやっぱり対面で話ができる、というのは大きいですね。互いの表情が分かり、反応速度もオンラインに比べると圧倒的に早く情報量も多いです。 懇親会でやり取りが出来たことで自分の知見が広まったり、新しい人とのつながりが増えることで、いろいろな可能性が広がります。 * 転職的が見つかる * 仕事の依頼先が見つかる * 仕事要素を抜きにして業界での情報を話せる友人ができる などなどです。その意味でもやはりオフラインでの懇親会は重要だな、というのを痛感しました。コロナ世代、コロナ少し前の世代の方には「リアルの懇親会は苦手…」という方も多いかと思います。 実際僕も懇親会そのものは得意ではないんです。大きなイベントの場合には見事に壁の花になります。ただ、そこで「価値は希少性」に宿ります。他の同世代の方が「やっていないこと」をやることで大きなアドバンテージを得られるのもまた事実です。 ぜひとも今後リアルの懇親会があれば参加してみてください。そしてぜひお声がけください！

チームビルディングのための「コミュニケーション」セミナーに登壇させていただきました。　

2024年7月6日に福岡県で開催された「WebプロデューサーとWebディレクターの『コミュニケーション』 〜クライアント折衝からクリエイティブチームとの交渉まで〜」に登壇をしてきました。 ▼目次 ### 2023年9月ぶりのリアル登壇セミナー リアルのセミナー登壇としては。[2023年9月9日に名古屋での「WCAN mii 2023 Vol.03」](https://wcan.jp/event/wcan_mini2023_3.html)ぶりでした。 WCANはコロナ禍後初めてで、あの人数の前でやるのは2019年ぶりだったこともあり僕は物凄い緊張をしていたのを覚えています。 ただ、今回はそういった緊張はなくやられたのは個人的にはほっとしました。 恐らく一回リアル参加のセミナー登壇を経験していたことと、直近で自社内行事ではありますがそこそこ喋っていたからこそだと思います。 ### 「コミュニケーション」について話す1時間 今回は「コミュニケーション」をお題にしていました。一緒に登壇をした角掛さんは肩書が「Webプロデューサー」ということで「対顧客との関係」における話だったので、僕はディレクターということもあり、インナーというか「チームビルディング」における領域を話をさせていただきました。 「チームビルディング」は仕事においては永遠のテーマで、僕も決してあらゆる形式でチームビルディングができている訳ではないです。 ただ、自分のキャリアの中で「ああ、こういうことかな？」というのが少しずつ見えてきたものもあり、普段の仕事の中で実践しているものや、過去に自分が受講をしてきた研修などが10年以上も経って使えるようになったスキルなどをまとめたものとなります。 こういった内容で話をさせていただきました。 全体を通したテーマとしては「いかにして『聞く』ことができるか？」ということにしていました。 これは自戒を込めていますが、僕も30代ぐらいの時はついつい自分の意見や考えている結果を伝えるという体裁で「押し付けていた」なぁ…と思うことが多々あります。 そういったことへの一助になればいいなぁ…と思っての内容にしておりました。 ### リアル開催だからこそのパネルディスカッション 今回のセミナーではパネルディスカッションがありました。当日の参加者の方から質問をいただいてそれに名村と角掛さんでお答えするものでした。 今回痛感したのは、このパネルディスカッションだけは、リアルでないと難しいということでした。Zoomなどオンライン会議のツールはもちろんありますし便利です。 しかし、今のところこれらのオンライン会議のツールでは同時に会話をすることができないことから「議論」は出来ないと思っています。その意味では質疑応答は「質問者が話しをする」→「登壇者が答える」という形式だから出来そうな気もします。 ただ、今回パネルディスカッションという形式で「登壇者2名がインタラクティブに回答をする」という形式の場合、「こちらは話をしましたので、次はあなた、どうぞ」みたいな形式になるとどうしても臨場感というか熱量が削られる感じがしました。 それもあと10年ぐらいしたらツール側が進化するか、参加者側がそれを含めて「普通」と思うようになるはずなので、過渡期ゆえなのか、僕自身の年齢的な感覚ゆえな気がしています。 ただそれでもやはり「ボケ・ツッコミ」ではないですが、登壇者2名がインタラクティブに遣り取りをする、というのはオンライン会議ツールでの「ごくわずかのタイムラグ」がある世界では成立させるのが無理だと感じました。 また眼の前にいる人向けであり、実際に顔が見えていて、回答内容で相手の顔の表情がどう変わるか？も見えるという意味では、講師側も、より相手のニーズを汲み取りやすく、相手と会場全体を両方をみた回答ができる環境であったというのは間違いないと思います。 #### 当日のXのポスト Xでは[「#つのなむ」というハッシュタグで実施をされていた](https://x.com/search?q=%23%E3%81%A4%E3%81%AE%E3%81%AA%E3%82%80&src=recent_search_click&f=live)のですが、結構リアルタイムに投稿をしていただけていました。 #### 上記のポストより抜粋 上記の投稿の中でもこういったポストがあり、とても嬉しかったです。 声の使い方、発声法まで話す人、初めてだ！おもしろい！ #つのなむ pic.twitter.com/WDPguRc9Ni— アイジ (@aiji) July 6, 2024 声優をされてた名村さんならではの「声という楽器を正しく使う」というスキルの言語化。実際に声の高さやスピードを変えて話して見せてもらいました。違いがハッキリわかって面白いです。おぉ…と感動しました😲高めだから意識してみよう。#つのなむ pic.twitter.com/maUF0mrl5h— サチコ/misty＠上級ウェブ解析士🥃 (@analogtan) July 6, 2024 極めて重要なのは「事実」と「感情」を分けて捉えること #つのなむ pic.twitter.com/tPDfNyoXKX— 海老庵🦐 (@evian) July 6, 2024 ### 懇親会の重要性を再認識 今回ありがたいことに懇親会にも多くの方が参加していただけました。 全員と話をさせていただくのは無理だったのですが、それでもこの多くの方々と話をして、他の人の話を聞いて、自分の話も差し込んで、相手にそれが乗っかって…という懇親会ならではの環境は良いものだとかんじました。 実際には「セミナーの内容への質問」というよりも、それをきっかけとして何を考えたのか、何を考えていたのか、そもそも自分の仕事はどうなのか？などの話題がどんどん広がっていきます。 僕はセミナーよりも懇親会でのこの会話・議論こそが「セミナーの一番の収穫」だと思っています。 その意味では今回のセミナーでは参加できる方は最終的には４次会ありました。（僕と角掛さんは３次会で失礼しましたが、参加者の方だけでの４次会があったそうです！） ここでの会話はもちろん今回は僕は「講師」として読んでいただけていて、参加者の方には「講師として」立てて頂けてました。 ただそれを求めている訳ではなくて、いろいろな方とディスカッションをすることが僕にとっては大きな収穫であり、得るものが多い時間でもありました。 今回のセミナーの中でもこういったスライドで話をさせていただきました。 コロナが明けた今、議論・ディスカッション・会話を人はもっとするべきだと思っています。 オンライン、テキストベースだけで伝えられるものはやはりたかが知れているんです。 本来対面で遣り取りをしているものからすると、「情報」は得られていますが、「情感」は伝わっていないんだと思います。 （相当言葉選びが上手であればできる方もいるとは思います） その意味でも懇親会という場で人と話すことの重要性を改めて感じさせていただきました。 ### 今回参加いただいた皆さま、本当にありがとうございました 今回のセミナーは福岡や九州のみならず、広島・岡山や関東からも参加をされた方がいました。そういった皆さまのおかげで盛会のセミナーだったと思います。 また運営をしていただいた皆さまには多大な感謝をしています。本当にありがとうございました。 コロナが明け、またこういった機会をいただける限り、何かを発信していきたいと思います。

「努力は無駄」「才能が全て」と思っているあなたへ。必要なのは努力・才能・運の3つ、そして「行動」

「努力しても意味がないんじゃないか」 「結局、才能がある人が勝つんでしょ」 「じゃあ才能がない自分はどうしたらいいの？」そう思ってこの記事にたどり着いた方に向けて書いています。僕は1996年からWeb制作・Webシステム開発の仕事をしていて、いまはWeb制作会社の経営者兼プロジェクトマネージャーです。その立場から、自分自身の「才能がなかったこと」と「あったかもしれないこと」も含めて、正直に書いてみたいと思います。 きっかけは、将棋棋士・渡辺明九段の「僕は将棋の天才です」という文章X（旧Twitter）で、将棋の渡辺明九段のものとして知られる文章が話題になっていました。要旨はこういうものです。初めて竜王になった頃は「自分がここまで来られたのは誰よりも努力したからだ。他の人は努力していないだけだ」と思っていたしかし自分の息子に将棋を教えてみたら、昔の自分が簡単にできたことが息子には全然できなかったそこで初めて「自分には将棋の才能があったのだ」と気づいた努力を続ければ誰でも上達する。だが上達スピードは人によって違い、一生努力してもプロレベルに届かない人もいる息子にはサッカーをやらせている。才能があるかは分からないが、才能がなくても、続けるのが楽しいと思えるものがあればそれでいいこの文章に対して、ある方がこんなコメントを添えて引用していました。『自分が高学歴なのは、才能があったからではなく、努力したから』…と言う高学歴の人は100回読んだほうがいい。言いたいことは分かります。分かるのですが、この引用だけを根拠に「努力は無関係で、才能が全てだ」という論調として紹介するのは違うと思ったので、この記事を書いています。 渡辺九段の話は「才能の話」であると同時に「運の話」でもある渡辺九段は、かなり早い段階で将棋に出会い、そしてそれが自分の才能に合致していました。つまり、たまたま短い接触回数で、自分の才能に合致するものに出会えたわけです。そういう意味では、これはもはや「運」の話ではないでしょうか。だから本当に難しいのは、「才能があるかどうか」ではありません。「自分には何の才能があるのかを、どうやったら見つけられるか？」こちらのほうが、はるかに難しい問いです。ちなみに「誰しも何かしらの才能がある」とよく言われますが、極論すると僕はこれすらも正しいのかどうか分からないと思っています。 そもそも「才能がある」とは、どういう状態を指すのか「才能がある」と判断する基準そのものが、実はとても曖昧です。少なくとも次のような問いに、はっきり答えられる人は少ないと思います。自分が苦にせずやり続けられることが才能なのか？苦労を感じずやっているのに、世間で認められることが才能なのか？他者よりも苦労を感じずに、期待した報酬を得られることが才能なのか？そして、いつそれを実感できたら「自分にはこれの才能がある」と言えるのか？最後の問いはけっこう重要です。仮に死ぬ直前に「自分にはこの才能があった」と実感できたとして、それは本人にとって良いことなのか、という話になるからです。「才能を見つける」と言うとき、僕たちは無意識に「若いうちに見つける」ことを前提にしています。でも、その前提自体がかなり都合のいいものです。実際先ほどのXの投稿の対してのリプライの中でも「人より勝てないものを努力し続けるのは無理かと思います」という記述がありますが、ではどうやれば「この先、これを続けても人には勝てない」というのが分かるのでしょうか…？ 残酷な話：才能があっても、報酬に直結するとは限らないもう一つ、資本主義的な観点から言っておかなければならない残酷な事実があります。「才能がある」ことや「才能を活かした生き方」をすることと、それに対して「潤沢な報酬を得られる」ことはイコールではありません。才能があって、やり続けられて、人よりも圧倒的なパフォーマンスを出せる。それでも、その仕事自体がそのタイイングでは世間でのニーズが低いもの仕組み上、報酬が上がらない業態などに当てはまってしまえば、報酬は絶対に上がりません。「好きなことで生きていく」も「才能を活かす」も、報酬とは別のレイヤーの話です。ここを混ぜて語る記事や動画が多すぎるので、僕はこの論調にはずっと違和感を感じていました。 「努力できるのも才能」という言葉は、なぜ循環論法なのかこの手の話になると「努力ができるのも才能だ」「そもそも努力できることが才能だ」と言う人がいます。一見もっともらしいのですが、よく考えるとこれは循環している話です。努力は、自分に合うものに対してできる。 つまり、自分に合うものを見つけられたから、努力ができている。だとすると「努力ができる＝才能」という話は、結局「自分に合うものを見つけられた＝運と才能」という最初の話に戻ってきてしまいます。「あの人は何でも努力できる」は、外から見た錯覚さらに言えば、努力できるもののストライクゾーンの大きさは人によって違います。ストライクゾーンが広い人は、たしかにいろいろなことに打ち込めますし、周りも「なんでも努力できる人だ」と感じます。ですが、それはその本人にすれば、自分のストライクゾーンに入っているものだけを選んで努力しているだけです。それを外野から見て「あの人は何でも努力できる才能がある」と言うのはナンセンスです。自分との比較で、自分よりストライクゾーンが広い人は外部から見ると「何でもすごい人」に見えているだけなのです。 若いうちに才能に出会う確率を上げるには、どうすればいいのかでは、どうすれば「自分に何の才能があるか」に早く出会えるのか。僕は、次の2つが重なったときに初めて、その可能性が上がると思っています。親が、子どもがどう思おうと、半ば強制的にでもたくさんの種類の経験をさせる子ども自身が、とりあえずやってみるこの両方が揃って、ようやく「自分にはこれに才能がある」と思えるものに出会える確率が上がります。どちらか片方では足りません。ただ「親が…」の下りには異論反論があるとは思います。子どもは親のおもちゃじゃないので押し付けるべきではない、という話題です。ただ、何かの事象に対しての判断力は知識と経験によって可能になります。ガチの第六感ではない限り「勘」も知識と経験による瞬間的な是非の判断です。では、その「知識と経験がない」子どもの時期に子どもの意思に判断を任せて、その子は自分の知識外の経験を得られるだろうか？と思っています。仮に「プールで泳ぐ」という概念を知らない子が、どこからも情報を得ることなく「泳ぎを学びたい」と思えるのか？と感じるのです。そこは親、もしくは先達が、その人の価値観の押し付けという側面はあるが、「やらせてみる」というところから始まるのではないでしょうか。そもそも価値観の押し付けを完全に排除するのは不可能です。学校一つとっても、国によって何を正しいとするかが違うので、その時点で「日本という国の教育方針を押し付けている」とも言えます。ですので、基本的には育成の過程とは価値観の押し付けにならざるを得ないと思っています。話を戻して、その意味では僕は子どもが「何が自分には適しているのか？」を知る機会として、「自分の知識では知らなかった正解を知る」ためには、子どもファーストインプレッションでは「これは何となく嫌だ…」と思うことでも「数回、十数回やってみてごらん」ということを半強制的に機会を与えることで「あれ、やってみたら面白いかも？」と思えるかもしれない「可能性」を提供することが重要と思っています。しばらくしてやっぱり合わなければ辞めればいいし、その面白さを実感できるのがある年齢を超えてから…という人もいるでしょう。それほど「自分に会うものを見つけられる」のは難しいと思っています。ただし、子どもの頃に出会えるものには限界がある現実には、子どもの頃に出会える選択肢の多くは「習い事」系です。キッザニアのような場所で職業的な才能を見つけられる可能性もありますが、それを理解した上で子どもを連れて行っている親は、分母から考えれば多くありません。つまり、そもそも出会える選択肢の母数が、生まれた環境によってまったく違うということです。才能を「見つけた」と言える条件は、かなり厳しい仮に「才能がある」を、仕事にすることができて人より努力ができて、しかもそのことに人より苦労耐性があり報酬を人並み以上に得られそれを若いうちに実感できると定義するなら、それを見つけるのは、そもそも至難の業です。 僕自身の話：才能がなかったこと、あったかもしれないことここからは自分の話です。抽象論だけでは伝わらないと思うので、正直に書いてみたいと思います。声の仕事には、絶望的に才能がなかった僕は以前、声の仕事を目指していてちゃんとお仕事もさせてもらえるところまではいけました。しかし結論から言うと、絶望的に「演技」の才能はありませんでした。少なくとも、自分で決めたデッドラインである30歳になるまでに、開花も発揮もさせられませんでした。頑張って続けていれば遅咲きの可能性はゼロではありませんが、それは前述した「いつまでに才能に気づけるか？」という問いに戻る話です。そして今なら分かります。養成所時代、訓練に時間を費やすことは、今のWebの仕事に時間を費やすことに比べて、はるかに負荷が高かったんです。つまり「努力をすることに抵抗がある」状態だったわけです。だから僕には声の仕事の才能がなかったのだ、と実感を持って言えます。Webディレクターには、たぶん才能がある方向だった一方でWebディレクターという仕事は、僕にとっておそらく才能がある方向だったんじゃないかと…うっすら感じます。それは、今やっていることに対して、稼働時間も含めて「苦労だ」と思ったことがほとんどないからです。マクロ的な視点ではずっと楽しんで仕事をやれています。もちろん、立場上として謝罪に行くとか、お金が絡む揉め事は「やだなー」と思いますし、胃が痛くなるぐらいにはストレスは高いですよ（笑）でもそれは「と言っても、ゼロにすることはできない要素だしな」で納得ができる。その程度の負荷なのです。ただし、同じWebの仕事でもデザインやコーディング、エンジニアリングの才能は、これまた絶望的にありません。だから僕はWebディレクターをしているともいえます。僕の才能は「ひらめき」でも「センス」でもなく、心身の頑丈さですもうひとつ、自分の才能だと自覚していることがあります。親がそもそも体を丈夫に産んでくれたこと。そして高校時代まで、自分で選んだ運動部で体力的な部分をとことん鍛えられたこと。特に「走る」ということに対しては自信の肉体的な適正もあったとは思いますが、本当に良く走りました。高校時代は卓球部だったのですが、アップで8キロ〜10キロ走らされ、それが「アップ」としてできるぐらいの体力が必要な部でした。そのことが今の身体の状態を作っています。これも運であり、才能だと思っています。だから僕は、自分のワークスタイルを「自分の才能を使ってやっている」と自覚しています。ただしそれは「ひらめき」とか「センス」とかとは程遠いものです。心身の頑丈さによってなしえられる、人より圧倒的な稼働時間を費やし、得られた経験の量で仕事をするこれが僕の才能の中身です。なので実は、僕は「時間をかければ誰でもできること」しかしていません。その証拠に、僕は20代、30代の頃なんて、ろくに仕事ができませんでした。経験の量でしか勝負していないのだから、経験がない年代では仕事ができなくて当然です。逆に言えば、僕の場合は「その経験量を積める心身の堅牢さ」こそが才能だった、ということになります。そして最近になってやっと、今の仕事に対して「才能があったかも？」と思えるようになりました。ただし同時に、「才能があるかも？」と感じているこの仕事ですら僕が得られる報酬は、あえて同じ「IT系」と括らせてもらえるならば、孫正義さんや堀江貴文さんのようなレベルではないことも実感しています。才能があることと、得られる報酬の大きさは、やはり別の話なのです。6年続けているポッドキャストで気づいたこと僕は6年ほど、毎週30分のポッドキャストをしています。いただいたハガキのネタだけで30分、台本なしの一発収録で喋っているのですが、これが他の人にとっては結構難しいことである、というのが最近になって分かりました。僕はお芝居・演技は絶望的に無能ですが、フリートークであれば——プロのパーソナリティやタレントさんとは比べるべくもないレベルですが——それでも「苦を感じずできる」。これも僕の才能なのかもしれません。ただ、僕のこの「喋るスキル」も、少なくとも僕はマネタイズできていません。これこそが「才能があるから稼げる」わけではない、という一つの証拠だよなぁ、と思っています。 結論：努力も才能も運も全部正しくて、全部必要です何をもって「才能がある」「努力をしている」「運がある」と言うのかは、主観が大きく関わる話です。だから、「努力をしたからだ」も正しい「才能があったからだ」も正しい「それを見つけられた運があったからだ」も正しい全部正しいし、全部必要です。「努力か才能か」という単純な二元論で語ること自体が、そもそもナンセンスなのです。「全ては才能だから努力は無意味」という論調になることに違和感を感じた理由がそれです。けれど一つだけ言えることがあります。努力も、才能も、運も、どれであっても、自分が何かしらの行動と選択をしなければ得られません。椅子に座って待っていても、きっかけは絶対来ません。 ノウハウ本やXでそれっぽい成功体験を読んで、知識だけを増やし頭でっかちになっても、きっかけは永遠に来ません。自分に何がマッチするのかを見つける、具体的な行動をした人だけが才能に出会えるのだと思っています。ですので、行動に移さない限りは才能の有無も、努力できるかどうかも、運がくるのかも分からないままになると考えています。ただその「行動できるのも才能だよ」と言ってしまえばそのとおりかもしれません。ただその「◯◯も才能だよ、自分にはそれがないから困ってるんだ」という方は、正論でも正解ではないので、誰も助けてくれないままになるとは思います。 よくある疑問に答えますQ. 努力は無駄ですか？無駄ではありません。ただし「自分に合っていないもの」に対する努力は、極端に負荷が高くなります。僕が声の仕事の訓練で感じたのがまさにそれでした。努力そのものより先に、「努力の負荷が低い領域はどこか」を探すほうが先です。Q. 結局、才能が全てなんですか？違います。才能があっても、努力を積まなければトップにはなれませんし、才能に出会えるかどうかは運の要素が大きい。そして才能があっても、市場のニーズや業態の構造によっては報酬に結びつきません。才能は必要条件の一つであって、十分条件ではありません。Q. 自分の才能の見つけ方が分かりません。どうしたらいいですか？判断材料としておすすめできるのは、「苦労と感じずに時間を費やせるかどうか」です。成果や評価より先に、負荷の低さを見てください。そして、それを知るには実際にやってみるしかありません。候補に触れる回数と種類を増やすこと以外に、確率を上げる方法はないと思っています。Q. 才能がなかったら、その分野は諦めるべきですか？必ずしもそうではありません。渡辺九段も書いているとおり、才能がなくても「続けるのが楽しい」と思えることには意味があります。ただし、それを仕事にして報酬を得たいのであれば、才能の有無と市場性の両方を冷静に見る必要があります。楽しむことと、それで生活することは、分けて考えてください。

働き方は再び「しっかり働く」への揺り戻しが始まった

2025年10月の自民党新総裁選挙で高市さんが選ばれ、その際「ライフワークバランスを捨てる」と発言されました。 このことはSNSでもいろいろな意見が出ていますが、個人的にはこの言葉を政治関係者が発言したことはとても大きい潮流の変化だと感じました。 戦後から続いていた猛烈な働き方を経て、2000年頃からはそれを抑制する動きになりました。もちろんそこには過労死や精神的な疾患などが世間的に顕在化したという世情もあります。。 しかし、その結果として誰しもが「無理して働かない」「競争社会は良くない」「お金を稼ぐだけが全てではない」…などなどいろいろなそれまでの『働くべし』という価値観へのアンチテーゼという価値観が生まれてきました。 ただ、そこから2025年に至るまでに「経済的な視点」に限っていえば、グローバルにおける競争力の低下、GDPが追い抜かれる、先端技術関連の多くで日本が勝てない状況になる…ということが起こりました。 「失われた30年」という言葉が生まれ、『ジャパン・アズ・ナンバーワン』は、はるか昔の話です。 結果として国内では「なんで日本は生産性が低いんだ？」「物価が上がっているのに給料が上がらない」などなどの不満がたまった時代になっていたと思います。 「仕事」という観点においては、資本主義においては基本的には競争社会です（資本主義の是非は別として）。どこまで行っても優勝劣敗ですし、適者生存です。 つまりは「他社（他者）との比較」の中で競う必要がありますし、人類は経済的な部分だけではなくあらゆる面において「よりよいものを目指す」ことで太古より進化してきたと思います。 となると、実際「そこそこでいい」「頑張らなくていい」という感覚では「他社（他者）がより頑張っていれば」競争には絶対に勝てないし、「失われた30年」の後半は「頑張らなくていい」という風潮の結果ではないのかと思ってます。 日本がそういった価値観になっている期間に、方法の是非は別にしてアメリカも中国も頑張っていたわけです。アメリカに差を広げられ、中国に追い抜かれたのは、単純に『彼らがやっていたことを日本はやっていなかったから』だけだと思います。 「頑張ること」を拒否し続け、この国際的な状況に甘んじ、給料が上がらず、国際的な競争力が下がり、国際比較の中で人件費が安い国となり「製造業における安価に作れる国」という国を目指すならば、それでもいいかもしれません（要は20年ぐらい前の中国や東南アジア諸国のような状況）。 ### 様々な価値観を全部考慮して守るのは不可能になってきた よく「質より量」ということが言われますが、『考えた上で』とか『無意味にやるのは無駄』という言葉が先行していて、それ自体は正しいけど、ではそれらをクリアした上で、『熟慮をして意味ある行動と思われることを実際にしていた人』はどれぐらいいたのでしょうか。 こういった「Aをするべき」という話題になると「いや、Bの観点を無視してやるべきでない」「Cの観点を無視してやってどうするの？」という意見が必ず出ます。 冒頭の高市さんの「ライフワークバランスを捨てる」というセリフにもそういった意見が出ていました。 * ライフワークバランスを無視したらまた過労◯する人が出てくるがそれを助長するのか？ * 国会議員としてもっと違う言葉の選び方があったんじゃないか？ * 自分以外にもそれを強要するのは総裁としてどうなのか？ などなどです。 「ライフワークバランス」という言葉だけを取り上げるならば、ある意味においては正しいかもしれません。 しかしあのスピーチは少なくとも私は「*総裁としての覚悟であり、失われた30年を取り戻すためにはそこまでやらないといけない。『適度なバランスを取る』といったお為ごかしをいっていてどうにかなる時代ではない*」ことを言語化したものだと感じました。 その言葉の結果として国政がどうなるかは今後の話です。今の時点で評価するべきでもありません。 『有言**不実行**』だったら総裁や国会議員から落とされ、最悪無職になるのですから。逆にいえばその可能性がある以上、国会議員はちゃんとリスクテイクをしていると思っています。 また「言葉の選び方」についても、いくら国会議員でも人の子です。あらゆる方面に100％リスクヘッジをした言葉でフリートークができることを求めるべきではないと思います。「国会議員になるということは、そのケアもできて当然だ」というような声が聞こえてきそうですが、それは誰もそんな定義をしていないので、勝手な解釈で他者に責任を強制するべきではないと思っています。 逆にそれを求めるならば、全ては準備した原稿を読むしかなくなります。 仮にそれをしたら次には「原稿を読んでばかりで◯◯さんの人として部分が見えないつまらない人だ」「原稿がないと何も喋れない人だ」みたいなことをいう人が出てくるわけですから。 ですので、『どういうことをしても文句を言う人はいる』という前提に立つならば、あのセリフを自民党総裁が発言したことの意味は「時代の転換点」の象徴なのではないかと感じています。 何度もいいますが、「その言葉を発した結果は今後で判断する」ので、今の時点で政治手腕を評価するとかの意図は全くありません。 ### 易きに流れていく世論には歯止めが効かなくなる 僕はいまも自分が30代のころと同じ様な働き方をしているつもりです。 よく周りからは「若くないんだから無理しない方がいいよ」といわれたりしますし、それも理解しています。 ただ、無理にでもそういった働き方を維持しているのは「*易きに流れ、気力と体力が落ちるのを防ぐ*」意味あいが大きいです。（単純に労働時間が長い、というだけですが） 今後、絶対に体力は低下します。体力が低下すると連動するかのように気力や感受性も低下していきます。 それ自体はもう抗えない事象なのですが、だからといって簡単に「もう40代だから…」「50代になったんだし…」という言い訳を自分にすると、時代がまたシャカリキに働くことを求めることになった時、その流れに付いていけなくなります。その時に脱落することへの怖さから「意地でも現状維持をする」というのが今の自分の働き方の大きな要因です。 体力が落ち、安穏とした仕事の仕方に身体も気持ちも慣れてしまうと、「今はここ一番、体力を振り絞って頑張らないとまずい！」みたいな時に踏ん張りが効かなくなってしまうはずなんです。 一昔前、「ゆとり教育」が無かったことにされましたが、ではその「ゆとり教育」世代の人が「今までの常識はユル過ぎたので元に戻します！」と世間にいわれ、翌日から彼らにとっては前時代的な仕組みややり方に戻されたとして即応できるか？といえば（多くの場合）不可能だったのではないでしょうか？ その意味では1975年前後の生まれのいわゆる「就職氷河期世代」、私自身がまさにそうですが、この世代は今に至るまでいろいろ言われていますが、僕には「ゆとり世代における『ゆとり撤廃後』」もなかなかハードモードなんじゃないかと思っています。 ですが、その「ゆとり時代」の真っ只中はどうだったでしょうか？ 世間一般ではゆとり教育はそれまでの「詰め込み教育へのアンチテーゼ」のように称賛されていました。 そしてその風潮に同意した人もたくさんいました。「これからの教育とはこうあるべきだ！」と。 なぜならそっちの方が全体的に「楽」だから。 人は意識をしなければ必ず「楽」に流れていきます。群衆心理がその「楽」な方に向かえば、なおさらその風潮に歯止めが効かなくなります。その意見単体に対して「いいか？わるいか？」でいえば「悪い」と否定のしようがないのです。 本来勘案するべきは「その結果としてどうなるのだろうか？グッドケースとバッドケース、どちらも起こり得るが、仮にバッドケースになった場合に対応できるのか？」という点なはずなのに、です。 そして「目の前の楽」に同意するほうがさらに「楽」なので、それに反する動き・考え方・意見は社会悪になっていきます。 これはその渦中は別に構わないかもしれません。なぜなら世間の大多数がそれを「よしとしている」のですから。 さらにそれに従わない意見は徹底的に叩かれて潰されるので、日本のいじめ問題のように「違う意見だったとしても言わない方が悪目立ちして叩かれないから良い」わけです。 と書くと、僕にも「今まで言ってこなくて、今回言うならもっと早く言っておけばいいじゃないか」と思われるとおもいますが、『わざわざ波風を立てるメリットが僕になかったから言わなかった』というのが本心です。 ### 揺り戻しが起こった時に耐えられる自分であるか？ 問題なのは、この流れが変わった時です。 例えば今の日本ではインフレがつき進んでいます。しかし給料は上がらない、という状況に多くの問題が指摘されています。 ですが、今現在の起こっている問題が発生するのでは？ということは、以前から考えていました。 これは過去にセミナーなどでも話題にしてお伝えしていたのですが、きっかけは2014年ごろに牛丼が250円になったときです。 牛丼の値段がどんどん安くなっていくのを見ていて、「これって今後…どうなるんだろ？」と思っていました。 どういうことかというと、今から25年前の2000年ごろは牛丼並盛は400円でした。 これが250円に向かってどんどん安くなっていく時、まだ若手でしたから確かにおサイフに嬉しかったです。 しかし、一方でこうも思いました。 「一体何をどう頑張れば400円の商品が250円になるのか…？」 考えれば簡単です。 どこかで必ず「値引き」をしているんです。 牛丼屋の仕入れ先→仕入れ先はその先の仕入元→……と続き、最後のどん詰まりまで等しく値引きを強いられていたはずです。 ということは途中を含めて最終的な生産者まで所得が減ります。薄利多売で一瞬は儲かったかもしれませんが、結果的に今は牛丼の値段は元に戻っているので、結局は250円という価格に耐えられなくなったということです。 生産者の所得が減れば彼らの消費は当然減ります。経済は全て循環しているので、生産者の消費が減れば、小売店の売上が下がり、その対策としてさらに値引きをして…という悪循環になるのは明らかです。 そしてこれは「低所得者」側にとって大きな問題をはらんでいます。 「高所得者」も「低所得者」も「安くなる」時には何も問題はありません。 しかしこれが『インフレ側』に回ったときに大変なことになるのです。それは『低所得者が買えなくなる』ことです。一方インフレになっても「高所得者」はまだ「買うことはできる」ので、問題は問題ですがそこまで騒がない。 これはまさに今起こっていることです。物価と給与の変化が完全に一致しているならば問題ないのですが、経済の循環にはいくつかのポイントがあるので、連動できたとしてもどうしてもタイムラグが出てきてしまいます。また産業単位ではそれが反映されないところも出てきます。 この「揺り戻し」が起こり、その変化が『過去に比べて厳しい方に戻った』ときに大問題が起こります…… 働き方も同じ事が起こるのではないかと思っています。 「無理をしない」「できる範囲でやる」といった価値観では少なくとも国際的な競争の中では勝てなくなっている。全員ではないが、諸外国でそれなりの企業にはシャカリキになって働いている人は一定数います。 少なくとも私が2022-2024に大学院に行っていた時の同級生は「自分が日本支社長をしていたドイツ企業の本社マネジメント層は一日中働いていた。プライベートも無し、時差も関係無し、そのかわり給料はめっちゃ高い」と言っています。ただこれは実際の資料としては分母のn数が「１」の話題なので、統計的にはその事例で判断はできないと思っていますが、そういう人もいる、ということです。 シャカリキというのが「稼働時間」なのか「稼働密度」なのか「解雇を掛けた責任」なのかは色々ですので、単一なことは言えませんが、とにかく何かしらのリスクを取って働いている人がいる、ということです。 もちろん過労死的な方にいくのは絶対に避けるべきです。特に私は現在経営者ですので、それは少なくとも自社では徹底して避ける方針です。一方で2000年代の働き方が問題だったのは、以下の要因があるように感じています。 * 高度成長時代の名残で、会社員は個々人の能力を別にして一定の無理な働き方を強要された * 個々人の頑張れる限界値というのを全く考慮していなかった * IT化によって、90年代までの仕事の速度間や密度から一気に高速・高密度になった これらのことからいわゆる『ブラックな労働の撤廃』に進み、2018年の「働き方改革」に至ったと思います。 また話題として「欧米のエグゼクティブクラスは◯◯をしている」という話題も危険な話だと思っています。一見正しそうなのですが、「それは何名の分母で何名の分子が◯◯をしているのか？」という割合が全くわからないからです。 「欧米の◯◯◯◯は」というのは、めちゃくちゃ曖昧な話なんです。「日本の社長は」と言っているのと同じで、上場・非上場関係なく、産業も会社規模も関係なく、一緒くたにまとめてしまっている。でも、なんとなく「へぇ、欧米ではそうなのか……」と思ってしまいがちな文脈になりがちです。 要は前述したように欧米のエグゼクティブでも、 * シャカリキになってワークをし続けていて、その内容にみあった価値を出している人 * 長時間のワークをしている訳ではないが、それに見合った価値を出している人 の両方が存在します。（両方とも対稼働に対しての価値をだしていることが前提です） 「長時間働くのは仕組み化できていないことだ」「社長が長く働いている会社はやばい」というようなもっともらしい言葉もありますが、「集中力が続いて長時間稼働ができるならば、他社に先んじることができる」と考えるが成長を考える企業のマネジメントレイヤーではないでしょうか？ 少なくとも「そこそこの働き方で上場目指そう」という経営者には出会ったことがありません。 上場を目指していなくても、会社が生き残るためには競合他社に何かしらで勝たないといけない訳です。企業が生み出せる価値は「かける時間✕方法✕才能」で決まるので、時間の要素はどうしても掛け算に含まれてしまうのです。 そして時代は必ず「少し進化した過去のやり方に戻る」を一定周期で繰り返しています。2000年の頃のような環境ではないですが、そろそろ「令和版のシャカリキに働く環境への回帰」という時代が来るんじゃないか？と感じています。 では、その時に自分はその状況に耐えられる心身であるか？。 耐えられるようにするために、ずっとそういった時代での働き方をしてきました。もちろんそれは僕自身の身体の状態、精神の状態などを常に自分で細かくウォッチしてのことです。 心身両面での休息のあり方、運動の取り入れ方、仕事への向き合い方、趣味の持ち方、自分で自分のモチベーションを練り上げるなどなど、やれることはやってきました。 体力は確かに落ちましたし、身体も20代と比べればガタも来ているでしょう。 運動もそれらしい運動はなかなかできていないのが実際です。ですが、まだ身体は動きますし、目も老眼はきていません！ 大病もせず、「がん」にもなっていません（ここしばらく毎年PET検査を受けています（笑）） 今2000年のころに戻ると当時の100％ではないですが、90％ぐらいはできる自身があります。知識と経験は増えていてそれでカバーという訳ではなく、肉体や精神的にも、仮に揺り戻しがあったとしても耐えられる状態を作ってきたと思っていますから。 ですので、時代がどう変わろうとも『自分の中の基準』は下げてはいけないと思っています。なぜなら「厳しい」ほうに戻った時、楽に慣れてしまえば、世間の変化についていけなくなるからです。 若い人はまだ対応ができるかもしれません。 ですが『25年前の働き方』を知らない若い世代の人たちが、僕らおっさんから『もっとシャカリキに働いた方がいいよ』と言われても「老害がしんどい働き方を強要してくる」としか思えないでしょうし、そんな話を素直に聞けというのは無理でしょう。 実際僕らも若いときにはおっさんから無茶を言われ「そんなのは何十年前の話ですか、全く…」と心の中で絶叫していましたから。 また、仮に若い方々が聞き入れてくれたとしても、「何をどれぐらいやったらいいか分からない」以上、基準は「自分なりにやった」になり、結局は必要な基準に達せない可能性も高いです。 必要な基準に達することができる若手世代というのは、「世の中がシャカリキに働くのが『当たり前』になった後の人たち」だけだ。 それは「ゆとりに慣らされた世代」が「ゆとり終了直後から、それ以前の学習に戻る」というのが容易ではないのと同じです。 今後の時代では、第三者から個々人の働き方や生き方への細かな干渉……というのは確実に減っていくでしょう。 その結果として仮に「働き方の揺り戻し」がおこった時も、周りは『あーしろ』『こーしろ』というのは言わないと思います。なぜならそれを言うことが『その人への過負荷を強いる』ことになり「その結果の異常の責任が取れない」から。 となると、生き残るには『自分で自分に、楽ではなく、潰れることのない自分にとって適切な負荷をかける』ことになります。その負荷をかけるかかけないかは完全な自己責任。 安穏と生きていても誰も困りませんが、本人は「給料が物価上昇に耐えられないほど上がらない」「欲しい報酬が得られない」ということになるかもしれません。もちろんそれでも良い価値観の人もいるので、自身が納得できているならば必ずしも給料が上がらないことは悪ではありません。 重要なのは「二極化の時代」になっていくのでは？という点です。 * 仕事をしてガンガン成長して稼ぎたいのに法令的なキャップがあることでそれができない人は思う存分働ける（ただ心身の管理は自分で行う必要がある） * ほどほどのワークでいい人もそれは尊重するし強要もしない。でも成長も給料もそこそこか、それ以下だよというのを納得してもらう こうなった時、自分はどちらを目指すのかを選ぶ時代になっていくのではないでしょうか？一律で横並びに「こういう働き方をしましょう。前ならえ！」とさせられ、「出る杭は徹底して打ち付けてなかったことにする」のではなく、「やっている人は徹底してやっていく」。 これは富の二極化を引き起こすので、実際には中間層が多い方がいいのですが、「一億総中流」と言われたのは1970年代ですから、今から50年も昔の話です。いま中間層を増やすことは難しいでしょう。 その解決は税制の話なのでここでは取り上げないですが、少なくとも流れとしの二極化に進み始めたと思っています。 こういう流れの中でもっとも大変なのは「安穏とした状態に慣れてしまい、シャカリキに働こうと思っているのに、気力も体力も落ち切ってしまい、今さらどうやっても戻れない」人です。 40歳後半以降ぐらいで、今からシャカリキに頭も身体もフル回転で働かなきゃいけなくなった時についてこられないで脱落する人が多数出てきてしまうのではないかと感じています。 しかし社会は優勝劣敗、適者生存なので、適応できないと一定のラインからは撤退するしかなくなってしまいます。 だからこそ生き残れるように爪を研いでおく必要があると感じています。 今回の自民党新総裁の言葉が発せられたことで感じている時代の転換点と揺り戻しが起こったときに耐えられる自分でいるか？と考えていたことが現実になったかも……と思っていることを文字にしてみました。

The Future of Web Development: Exploring AR as the Next Big Step

This blog is the English translation of the Japanese article "[https://web-directions.com/director/diary/The-Future-of-Next-Generation-Web-Development.html](https://web-directions.com/director/diary/The-Future-of-Next-Generation-Web-Development.html)". --- Over the past 30 years, I’ve been deeply involved in web development, watching it evolve from simple designs on low-resolution computer screens to the rich and dynamic interfaces we see today. Along the way, new technologies, devices, and user expectations have continuously shaped the way websites are built. However, as we stand on the edge of 2025, it’s clear that smartphone display technology, which has been at the heart of web consumption for over a decade, has reached its practical limits. So, what’s next? I believe the future of web development lies in moving beyond traditional screens and into the physical world itself. This shift will be driven by augmented reality (AR), a technology that has the potential to revolutionize how we experience and interact with digital content. In this article, I’ll explore what this means for the web and for those of us who build it. ▼目次 ### A Brief History: From Computer Screens to Smartphones In the early days of the web, websites were built for low-resolution computer monitors. Designers had to work within the confines of small, clunky screens. As technology advanced, screen resolutions improved, allowing for more visually appealing and complex designs. The shift to smartphones in the late 2000s brought another major change, requiring websites to be responsive and optimized for touchscreens. Smartphones revolutionized how people accessed the web, but in recent years, display technology has hit a plateau. Current smartphones offer incredibly high resolutions, but further improvements may not make sense. Why? Because on a device that fits in your hand, increasing resolution too much can make text and images too small to read, especially for people with aging eyesight. Making smartphones larger isn’t a solution either—at that point, they’re more like tablets. ### The Next Step: Augmented Reality and the Web As smartphones reach their limits, it’s time to think outside the box—literally. The next step for web development is to move away from two-dimensional screens and into the three-dimensional space around us. Augmented reality (AR) makes this possible by overlaying digital content onto the physical world. Imagine standing in a store and seeing detailed product information pop up in front of you, or visiting a historical site and being guided by AR visuals that bring the past to life. These are just a few examples of how AR could transform how we experience web content. ### Smart Glasses: The Key to AR’s Future Today, AR is often experienced through smartphone cameras, but this method is clunky and impractical for everyday use. The future of AR lies in smart glasses—lightweight, wearable devices that display digital content directly in your field of vision. Smart glasses are already being developed by major tech companies, and while they’re not yet mainstream, advancements in battery life, display technology, and design are bringing them closer to reality. Once these devices become widely available, they’ll provide a seamless way to experience AR, opening up exciting possibilities for web developers. ### What AR Means for Web Developers For web developers, the rise of AR represents a major shift. Designing for AR isn’t just about adapting websites to a new screen size—it’s about rethinking how we present and interact with information entirely. Here are some key considerations: #### 1. Designing for 3D Space AR content exists in the real world, not on a flat screen. Developers will need to think about how information is positioned and displayed in 3D space, considering factors like depth, distance, and user perspective. #### 2. Balancing Information Density In AR, too much information can overwhelm the user and make the experience frustrating. Developers must carefully balance the amount of content displayed to ensure it’s helpful without being intrusive. #### 3. New Ways to Interact Traditional inputs like mouse clicks and touchscreen gestures won’t work in AR. Developers will need to design experiences that use voice commands, gestures, and even eye tracking. #### 4. Accessibility in AR Making AR content accessible to everyone, including people with disabilities, will be a critical challenge. Developers will need to consider alternative ways to present information, such as audio descriptions or haptic feedback. ### Preparing for the AR Revolution So, how can web developers prepare for this new era? Here are some steps to get started: * *Learn AR Technologies* Familiarize yourself with tools and frameworks like WebXR, ARKit, and Unity, which are used to build AR applications. * *Experiment with Prototypes* Start small by creating simple AR experiences to get a feel for designing in 3D space. * *Collaborate Across Fields* AR development often requires expertise in hardware, user experience, and even psychology. Working with professionals from other fields can help you create better experiences. ### Conclusion: Embracing the Future The transition from smartphones to AR is inevitable, and it’s an exciting opportunity for web developers to redefine their craft. Just as we adapted to the shift from desktop computers to mobile devices, we must now embrace the challenge of designing for the physical world. AR isn’t just another trend—it’s a fundamental change in how people interact with information. By preparing now, we can ensure that we’re ready to create meaningful, engaging, and accessible experiences in this new frontier. The future of web development is in our hands—let’s build it.

次世代ウェブ制作の行方：AR時代におけるウェブ表現の未来

30年にわたりウェブ制作に携わり、多くの変遷を目の当たりにしてきました。その中で、時代ごとに変化するディスプレイ技術やユーザーのデバイス利用環境に対応するため、ウェブデザインや技術の進化が求められてきました。しかし、ここ数年、スマートフォンのディスプレイ進化が停滞し、新たな表現の限界が見えつつあります。次なるウェブ表現の進化はどこに向かうのか。私たちウェブ制作者が注目すべき未来について考察します。 ▼目次 ### ディスプレイ進化の歴史と停滞 初期のウェブ制作では、低解像度かつ限られた画面サイズのパソコンが主流でした。その後、ディスプレイの解像度が向上し、リッチな表現が可能になったのと同時に、ウェブ制作の技術も多様化してきました。そして、スマートフォンの登場がウェブ制作に革命をもたらしました。どこでも情報にアクセスできる環境を実現し、レスポンシブデザインの概念が確立され、デバイスごとの最適化が必須となったのです。 しかし、近年、スマートフォンのディスプレイ技術の進化は停滞しています。解像度をさらに向上させることは技術的に可能であるものの、現行のスマートフォンサイズでは、老眼を持つ方をはじめ、多くのユーザーにとって情報が視認しづらくなるという課題が浮上しています。スマートフォンの画面を大きくすればタブレットとの差別化が困難となり、現行のフォームファクターに限界があると言えます。 ### 次世代ウェブ表現の可能性：ARの台頭 このような背景の中、次世代のウェブ表現を考える上で、現在のディスプレイ技術に頼る限り抜本的な変化は見込めません。では、次にウェブが表現するべき場所はどこになるのでしょうか？その答えは「空間」にあると私は考えます。 空間でのウェブ表現とは、現実世界とデジタル情報を融合させる拡張現実（AR）技術を活用することです。ARによるウェブ表現は、ディスプレイに依存せず、物理的な空間そのものを情報のキャンバスとする発想です。たとえば、ARを通じて店舗の商品情報がその場で閲覧できる、観光地で歴史的背景を視覚的に学べるといった使い方が想定されます。 ### ARを閲覧するためのデバイス：スマートグラスの可能性 現時点では、スマートフォンを通してARを利用することが一般的です。しかし、日常的にスマートフォンを片手に持ち、空間を覗き込むという行為は非常に不便です。ARが日常生活に溶け込むためには、専用のデバイスが必要となります。その最有力候補が「スマートグラス」です。 スマートグラスは、軽量化やバッテリー技術の向上により、徐々に実用的な製品が登場し始めています。これらのデバイスが普及することで、ARを日常的に利用する環境が整い、空間を活用したウェブ表現の可能性が広がります。 ### ウェブ制作者が考えるべき未来の表現手法 では、私たちウェブ制作者はこの新しい時代にどのように対応すればよいのでしょうか？これまでのウェブ制作では、ディスプレイ上でのレイアウトやレスポンシブデザインが中心でした。しかし、ARを活用したウェブ表現では、以下の点を考慮する必要があります。 #### 1. 空間的なデザイン思考 平面的なウェブサイトではなく、360度の空間に情報を配置する発想が必要です。視線や身体の動きによって情報を操作できるデザインが求められます。 #### 2. コンテンツの適切な配置 情報が過剰に空間を埋め尽くすとユーザー体験が損なわれます。ARでは、物理的な環境との調和が重要です。 #### 3. アクセシビリティへの配慮 視覚的な制約を持つユーザーにも情報が伝わるよう、音声や触覚フィードバックの活用を検討する必要があります。 #### 4. 新しいインタラクション設計 タッチ操作に代わるジェスチャーや音声操作、視線操作といった新しいインタラクション方法を学び、取り入れる必要があります。 ### AR時代を迎えるために今できること AR時代に備えるために、今私たちが取り組むべきことは以下の通りです。 * *技術の学習*: AR開発に必要なツールやプラットフォーム（例: WebXR、Unity、ARKit）の習得。 * *プロトタイプの作成*: 小規模なARコンテンツを試作し、可能性を探る。 * *多分野との連携*: ハードウェアメーカーやUI/UXデザイナーと連携し、新しいウェブ表現を模索する。 ### 結論：ウェブ制作の未来を創る ウェブ制作は、パソコンからスマートフォン、そして次のAR空間へと進化し続けています。これまでディスプレイ上で情報を届けてきた私たち制作者は、空間そのものを新たなキャンバスとして捉える必要があります。これは困難な挑戦であると同時に、これまでにはないクリエイティブな可能性を秘めています。 ARの時代においてもウェブが情報発信の中心であり続けるために、私たちは今から準備を進め、次世代のウェブ制作に対応するスキルと知識を身につけていきましょう。この変化の波に乗ることで、制作者として新たな価値を提供し続けることができると信じています。

生成AI時代になった今、何を信じるのか？

生成AI時代になりました。これからこれが発展することはあっても、衰退することはありえないでしょう。 これを書いている2024年12月10日、OpenAIから動画生成の「Sora」について一般提供開始というニュースがでてきました。 * [OpenAIの動画生成AI「Sora」、ついに一般提供開始 「ChatGPT」課金ユーザーなら追加負担なし](https://www.itmedia.co.jp/news/articles/2412/10/news104.html) 生成AIがでてきて、色々楽しいと思える方が強いので不安はあまりないのですが、「画像生成」「動画生成」について思う所がありました。 ### 今後、リアル以外に見ている画像、映像をどう判断するのか？ 2024年12月時点の話ではなくて、ここから1年でもすれば、生成AIが作る画像も映像も、恐らく現実と差がなくなるはずです。それ自体はもう時代の流れなので、いいと思います。 そもそも今の時点でも、画像も映像もPhotoshop加工、CG加工などは当たり前で「何が現実なのか？」あやふやなところもあります。 しかし、少し前までは「その加工の作業」がまだ誰でもできるものではなかったので、「公園の写真」といったスナップ写真や、YouTuberさんの動画は「リアルを切り取ったもの」感がありましたし、見ている人もそこは「リアルと切り取ったもの」と思っていると思います。 しかしあと1年も経てば、先程書いたように「これはリアルなのか生成AI作成なのか」が分からなくなってくるでしょう。その時、人はどう感じるのか？ということです。 「嫌悪感」を抱くのか、「受け入れる」のか。世代間での受け入れ方の違いが取り沙汰される気もします。柔軟な世代は「まぁ、そんなものだよね」となると思います。 しかし、「リアルの切り取り」だったことに価値もあったはずです。それが全て今のCGの様に、「リアルだけど、作り物」となった時、人は何に価値を感じるようになるのか？ ### 最終的に人は「リアルでの接点」に価値を感じるように回帰するのか？ デジタルで見える画像、映像が全て「どうせAIで作られたものだよね」が意識しない根底に刷り込まれるようになった時、人が見ているものは「純粋な情報」であって、今ならば感られる「生きている躍動感」や「自然の脅威」といったものは一切感じなくなるのではないでしょうか。 そうなると、実は世界は狭まって、「自分が実際に見たものだけが信じられ、価値がある」となるのか？ Google Mapがでた当時、「あたかも世界旅行をしているようだ」という表現がありました。しかし、それはリアルを元にしたテクスチャーマッピングの情報だったからです。これが全て「リアルを元素材して、生成AIが作った」ものとなったら、そこに人は感動をするのか？ やはり「旅行は人が足を使って、自分の目で見てこそ」となるのではないか？そうなると、インターネットで広がった世界は1990年代初頭までのように「自分が動ける範囲」にしか価値が生まれない（生まれづらい）世界に逆戻りするのではないか？ インターネットで見るものは、リアルではあるけど、「絵本の世界」の様に感じるのではないか？ といったことをモヤモヤ最近考えています。僕はずっとネットを生業にしてきているので、便利になることには抵抗はありません。ただやはり「人の情感」に訴えるものを作っていきたいとは思っています。 そうなると「人の心が何で動く時代になるのか？」は、モヤモヤと悩みますし、それを悩める時代の狭間にいることはとても楽しいです。

追悼：Web業界の巨星、福井信蔵さん

福井信蔵さんがお亡くなりなった事をXでイム ジョンホさんのブログが流れてきたことで知りました。 福井信蔵さんといえば、90年代から2000年一桁世代にWeb制作を生業にした人にとっては文字通り「神」です。 「紙でも映像でもないWebサイトのデザインとはこういうものだ」というのを、圧倒的なデザインとして世にだした方といっても1mmも誇張がない。 福井信蔵さんに僕は直接お会いしたことはありません。 ですが90年台からWeb制作に関わっている以上、当然ながらどこにいても聞こえてくるお名前でした。 僕は1996年に関西でこの仕事を始めたのですが、当時は役者であり声優になることが自分の一番の大きな目標であり行動原理だった。それでも同時期に触れた「Web」というものに魅了されて、同時ものすごいいろいろなやり取りが繰り広げられていた某メーリングリストも当然みていました。 自分の中で「Webを本業にすることはないけど、これは凄い…」とただただ口を開けてぼーっとするほどかっこよかったのを覚えています。 そして、2004年にこの仕事を本業にして、mixiができました。 mixi内にできたWebクリエイターのためのコミュニティ「WebSig24/7」で同い年でbAにいる森田雄君にであった。 彼は福井信蔵さんが創業したbA（Business Architects）で第一線にいた。その彼を通してbAにあるクリエイティブの源泉、福井信蔵さんが作ったそれを間接的に感じていました。 当時、僕は29歳だったが、その圧倒的な経験と練度と密度に「同じ年でこんなやつがいるのか…」と驚愕したのは今も覚えている。そしてそれは今も変わらず感じていて、何をやっても追いつけない。でも、追いつけないから今も頑張れているので、決してネガティブな気持ちはない。 福井信蔵さんが創業したbAを通して、そのクオリティであり、そこを目指す姿勢に畏怖と憧れが同時にありました。 僕にとってですらデカすぎる巨星であり目標であり進む道を切り開いている方だっただけに、とてもとても残念です。 福井信蔵さんの切り開いたWebデザインの世界に献杯を捧げ、ご冥福を謹んでお祈り申し上げます。

正しい努力を行うには練習の前の行動が重要だった

Twitterで「努力」というものを考えさせられる動画が流れてきました。 Twitterでは埋め込まれていた動画ですが、大元はかの日本の著作家・経営コンサルタントとして有名な「[山口 周](https://ja.wikipedia.org/wiki/%E5%B1%B1%E5%8F%A3%E5%91%A8)」さんがゲストで出ている[「Rethink JAPAN」の対談動画](https://newspicks.com/movie-series/45?movieId=3133)の「30分27秒」からの部分です。 この動画全体はぜひ見てもらいたいのですが、その中でも「正しい努力」についてTwitterに長文投稿したのを編集してみました。 ▼目次 ### 正しい努力とは結果が出るための努力 「努力の質」ってのがあって、どういった方法ややり方に力を注ぐかは本当に大事だと思います。 動画中で山口さんが紹介する「島田紳助さんの授業」は、こちらのDVDに入っています。（動画中で山口さんはYoutubeで・・って仰っていますが、多分本家がアップロードしているものではないと思うので） #### 「紳竜の研究 [DVD]」 * [紳竜の研究 [DVD]](https://amzn.to/3Rfl7Oy)（Amazonへ遷移します） 紳助さんによる「吉本のこれからの芸人さん」へ向けた特別授業なのですが、そこで語られている考え方と手段が凄いです。 話の内容は、当然そのまま聞けば「芸人さん向け」の話ですが、話題の中身を自分の仕事に置き換えると、そのまま多くのことが当てはまるのが分かります。 ただ僕はあの授業ですら、紳助さんは本当の本当に大事なことは言っていない気がしています… 話しを戻して、紳助さんの動画を見れば分かるのですが、「正しい努力とは何か？」というのを考えさせられます。 誰しも「結果がでる」努力をしたいと考えているでしょう。 そして、今の自分が実践している努力は「結果が出る」と思ってやっています。 しかしながら実際に「結果が出るか？」は「やってみないと分からない」のが多くの場合だと思います。 ただ島田紳助さんが授業で言っていることから改めて考えると、その「方法」を見つける前提が違っている気がしています。 ### 手足を動かす努力の前の行動が必要 紳助さんは、一般的に「努力しています」という『行動』の前にやっていることがすごいんです。それができる事自体が「才能だ」とか「それがすでに努力だ」という話でぶった切ってしまうと、何も進まない言い訳をしているだけなので、それは控えます。 ただ、一般的に「努力」とは、次のような「行動量」を指してしまうことが多いと思います。 * 飛び込み営業をする数を増やす * 企画のアイデアをたくさん出す * 電話をとにかくたくさんする * 素振りや走り込みなどの練習をたくさんする これらは間違えてはいないのですが、その行動が「具体的に何を解決するためのものか？を自分が分かっているか？」が抜けていたりする場合がないでしょうか？ 逆算をすると、実際に手足を動かす前に行う分析が重要と気が付きます。 紳助さんは、まず大事なのは目的がはっきりしていることです。 それは芸人として有名になることでも、自分のやりたい漫才をやることでもなく、『売れて生き残る」こと（と思います）。 それが達成できるならば、極論、それ以外はすべて「手段」と考えているとすら思われます。 ### 単一でシンプルで迷わない目標を持てるか？ 紳助さんは目標を達成する上で、「とは言っても、○○な努力はやりたいやりたくない」は考えていません。ゼロではないはずですが、目標を達成しなければ意味がないと、ちゃんと割り切れてる。 何より自分にとって「達成したい」目標というか目的がはっきりしている。 当たり前に聞こえますが、多くの場合「これを達成したい。とはいえ、あれも出来れば達成したいし、達成するにしてもアレはやりたくない」みたいなものが見え隠れします。 それが「これを達成するなら他は何でもいい」という所まで昇華できている。これが何より強い。極論は泥水すする覚悟がある。 ただ、紳助さんは目標達成のために、無意味にダサい方法はやらない。やっていることが他人からみて「カッコ悪い」「それはあかんやろ」も全部計算をしている。 これは紳助さんが他の番組でも良く、『島田紳助・松本竜介』のスタイルを決めるエピソードが最たるものだと思う。 吉本の同期である「さんま」のあの明るさから来るものは俺にはない。 もう一人の同期である「（オール阪神巨人の）巨人」は入門した時から王道の漫才がめちゃくちゃ上手くて、アレにも絶対勝てる気がしない。 だから俺は邪道に行くしかなかった。 上記は意訳ですが、この様に言っていました。 これは「売れるためには」という前提がある。売れる為には「やりたい漫才」でもなく、単に「売れそうな漫才」だけでもなく、「同期を含めて差別化して勝てる漫才」ということだ。 漫才も当然ながら芸能の世界です。 僕も芸能の世界にいたので、少なからず感じるのが、多くの場合、自分の『我執』からくる「こうありたい」や「こうしたい」というのがあります。そして特に芸能の世界に入ろうと考えた時から入った直後はこれが強く出ると思います。 それは自分もあの人のようなってみたい、やってみたいという「憧れ」なりが源泉になっているからです。（だからこそアイドルは『偶像』という言葉からきているはずなので） しかしそれは「目的」と「手段」がごっちゃになっている状態とも言えます。 今にして思えば僕が役者として生き残れなかったのはこの部分だというのがはっきり分かります。 しかし当時は全くそれが分からなかった。 養成所で出される課題、現場の台本を「自分の考える『頑張って』やっていれば」上手くいくと信じていました。 表現者は当然ロボットではないのでこのエゴといえる部分はアイデンティティでもあり大事だとは思うのですが、生き残れなければ何もできないのもまた事実です。 要はそのバランスを無意識でも意識的でも取れる人が、生き残れる人であり、紳助さんは「意識的」にそれをやっていて、やっていたことを口頭で説明ができる訳です。 そして前述の僕の「頑張って」は、正に「間違った努力」になっていた訳です。 ### 目標がはっきりしているから「分析手法」を作れる 「努力の方法を見つける」話に戻って、「売れるために」という目標がハッキリしたら、次は現場分析。 ですが、これも「何をするか？」がはっきりしているから分かることであって、「分析をすればいいのか」から始まるのはやはり「間違った努力」になると言えると思います。 紳助さんは自分の目標がはっきりしているからこそ、その時点の「漫才の分析」を行います。 今の漫才が、 * 売れてる漫才は何か？ * どれぐらいの尺か * 何回ツッコミとボケがあるか？ などなど……（詳しくは動画を探してみてください） それが分からないと、今の流行り廃り、他者との差別化、目指すべき勝ち筋が分からず、結果本来は「何の努力をしたらいいのか分からない」状態になる、ということだと思います。 紳助さんの授業動画を見た時、「では、それと同じ行動を当時の自分はしてただろうか？」考えました。 結果として紳竜の漫才は「どういったスタイルの漫才」にするかが決まり、その結果として「台本」や「衣装」が決まり、それを実現・体現するための「練習方法」が決まってくる訳です。 ### 具体的な「努力の方法」は分析の結果、初めて分かる 多くの場合、最後の「練習方法」から入っていないだろうか？ しかもそれは「どこかで誰かがやった、確からしいもの」だったりしないだろうか？ もしくは「何かに書いてあった練習方法を盲目的に再現」することに腐心していないだろうか？ 紳助さんの授業の中では元阪神タイガースの伝説のバッターの「掛布 雅之」さんの話題が出ている。 バットを毎晩500回振ってたから、いい打者になれた訳ではない。 そんなのはプロになったら誰でも当たり前にやっている。 そしてバットを500回振るのを何も考えずやってたら、それはただの『筋トレ』でしかなくて、筋肉が大きくなるだけで意味はない。 一振り毎に「実際のバッターボックスで、どういった状況にいるか」を考えて振るから本番で実際に再現することができる。 というものです。（これも意訳です） 紳助さんと松本竜介さんの漫才コンビ「島田紳助・松本竜介」は結果として「練習をしない」という方法に至っている。 「練習をしすぎない」という方法を見つけ出したと言える。 もちろんそれには、相方が松本竜介さんになるまでの紆余曲折もあり、相方が竜介さんだからこそ出来た、と紳助さんは仰っている。 「芸能の世界では練習は重要だ」というのは半ば常識で、それを疑う人も殆どいないでしょう。 しかし、こと「紳竜の漫才」というものにおいては当てはまらないと判断している。 もちろんこれも結果論、とはいくらでも言えます。 「紳竜」の漫才がもし当たっていなかったら、何をいっても言い訳になるし、「ほら、練習しなかったからだよ」と言われていたと思います。 しかしここで大事なのはそれではありません。 「世の中の成功の方法論の多くは、その人自身のためにゴリゴリにカスタマイズされたもの」であるということです。 つまり、一般的に「努力」と思われている「具体的な行動」は、「**自分で『自分が成長できる』ための方法を見つけなければならない**」ということです。 ### 時代の変化によって「同じ努力の方法」は永続しないことを知る 紳助さんの授業の話の中ですごいと思う次のエピソードは、島田紳助さんが「紳助・竜介」を解散を決めた話です。 NGK一期生に講師に行った時の、同じく講師にさんまさんと巨人さんが別々に行き、後日三人で「一組だけ（すごいのが）おるな…」と言ったのが全員一致でダウンタウンだった。 そして紳助さんは「ダウンタウン」にこう聞きました。 「自分ら、そのスタイルで行けると思ってるん？」 （これは関西弁でいう「本当に行けると考えるの？」という問いかけであって、上から目線的な話ではありません） ダウンタ ウンのお二人はこの問いかけに「行けると思ってます」と答えたそうです。 紳助さんはダウンタウンがデビューした後の本番を舞台の袖で見た時、そのスタイルがお客さんに受けていたことから、 「あ、紳竜の漫才は終わった。これでもう引退や…」 と感じ、すぐに引退届を出しに行ったという… （この時の竜介さんへ引退の話をする時のエピソードはお二人の関係性が良く出ていて聞いてて涙出そうになります） 自分自身が考え抜いて作り上げてきた邪道漫才と練習をしすぎず、舞台では紳助さんのマシンガントーク、さらには当日絶対であった「正月番組での正装」すらしないというスタイルで一世を風靡し、人気絶頂の時に引退を決断した訳です。 この話は「松本紳助」という番組の中でも、紳助さんはダウンタウンの松本さんに直接言っていていました。 「紳竜はダウンタウンをみて引退したんや」と。 これは自分たちのスキルと方法をものすごく冷静に判断ができているからこそだと思う。 「勝ち目」がない以上、そこに固執をしない。 「生き残る」ということが何より重要だと考えているからこそ、 「これまでの話芸・話術を元にして、次に生き残る場所を改めて見つける」 というシフトをした訳です。 これは今までのやってきた道を否定もしていないし、捨ててもいない。 自分の持ってるスキルを「どう時代の変化に合わせて使うか？」という考えた結果だと思います。 これは僕が最近、今のAIがどかどか出てきている時代に、今までの自分たちの仕事の変化にどう合わせ、何のスキルを使って、何を変化させていくべきか？と考えている源泉になっています。 ### ”間違った努力”をする日本人 本当に必要な努とは？ 冒頭の山口 周さんの動画で語られているのはこれらの事だと思います。 その動画でも語られていた「”間違った努力”をする日本人 本当に必要な努とは？」は、ビジネスパーソンにとってとても大きな問題だと思います。 ビジネスに関わる人だけではなく、生きていればほぼ全員に当てはまるのではないでしょうか？ 特に日本人はアイデンティティに「勤勉」というもの文化背景を持ち、それを「美徳」として育ちます。 それは「誰かに言われた行動を、脇目も振らずコツコツと続けていければ報われるし、その一連の行動が重要である」といっても良いかも知れません。 それ自体は僕も嫌いではないのですが、それはきっと日本人が日本国内だけを相手に仕事をしていた時に通じたものなのではないでしょうか？ 動画の中で、 最近の若い方は『頑張るトレーニング』が出来ていない という話題があります。 日本は「”ゆるゆる”のガラパゴス」であると言われており、生産性は知的水準だけではなく、欧米でもライフワークバランス・ライフワークインテグレーションを実現している人は「頑張る能力✕知的水準」の賜物であると語られています。 ### 「頑張るのってカッコ悪いよね」という価値観もいずれ変わる 日本人の中には、 * 努力している姿を人に見せるのは格好が悪い * 努力している姿を見せるのは承認欲求だ という様な感情があり、それの到達点として現在「**頑張る必要はない**」というトレンドになっている気がしています。 僕個人だけで言えばそのトレンドが続いてくれるのは嬉しいです。なぜなら結果として、もう48際にもなる僕の優位性が維持される期間が伸びるからです。 しかし、日本全体でいえばそんな事は言ってられません。 むしろ「**今の時代、人より頑張れば、黙ってても競争優位性を持てるのに何故やらないのか？**」とすら思っています。 また、何かしらの到達点や世情の変化によって「頑張らない人は悪だ」という事態になる可能性も十分にあります。 その一つの例は「ゆとり教育」です。 あれだけ日本の小中学生を「良くしよう」と思って進められた教育方針を、国はある時点で「ゆとり教育の方針、あれ、全部ナシ！」とひっくり返した訳です。 いわゆる「ゆとり教育」世代の方は本当に可愛そうだと思います。 しかし、今考えれば資本主義とまで言わずとも、社会に出たときのことを考えれば、「競争をさせない」という中で、活躍できる力が身につくはずがないのは分かる話です。（当然、この話は分母が日本全体の小中学生であり、更に「集団教育」という手法において、社会に出て高い生産性を生み出せる人を、確率論的に最大化する、というのが前提で、個々人の話ではないです。） かと言って今の日本の教育が「完璧」だとも別に思っていません。 話の本題としたいのは、価値観が変わった時に、今「頑張るのはカッコ悪い」という前提で活動をしている人は「頑張れる」のか？ということです。 先程、動画の中で語られていた言葉の「頑張るトレーニングができてない」というのを挙げました。 そう、頑張るにも「トレーニング」が必要なんです。 意識を変えただけで明日からフルマックスで頑張れる訳ではないのです。 そして、頑張る上で重要なのは「**正しい方法で努力する**」ことです。 これこそれが「頑張る能力✕（正しい努力の方法を見つけられる）知的水準」ということではないでしょうか？ 努力の仕方を正しく考える重要性は、冒頭のRethinkの山口 周さんの動画、そして紳助さんの動画には本当に詰まっていると思うのでぜひみてもらいたいです。 そして生き残る上で「頑張るトレーニング」について一考してもらいたいと思っています。

物理的ストレージ限界の時代とクラウドがもたらす今後

昨日Engadgetでこんなニュースを見つけました。 アウディの車載ネット Audi Connect 開始、 国内初の車内 WiFi スポット搭載 http://japanese.engadget.com/2013/09/08/audi-connect-wifi/ これを見てFacebookでこんな書き込みをしました。 これを見ると、今後の自動車にも確実にネットは組み込まれるだろうし、そうなると、今のカーナビの「データのアップデート」ってのは方法が変わるだろうな。 というか、現時点でもスマホとかタブレットをナビにしてる人にとっては「データのアプデート」ってのは概念的には無いわけだし。 そうなると利用頻度によって「月額固定」か「従量制」でのネット利用料を払う必要が出てきて、車を買いに行ったら携帯回線契約して帰ってきたってことになるだろうなあ・・・。 その意味では、利用者は減ってきて入るけど、それでも現時点の分母としては、通信会社には「カーナビのネット組み込み」は次の回線拡大領域になるんだろう。 となると次は、ユーザが「カーナビとネットが組み合わさった上での車体験」ってどんなことが出来るのか想像してみたいなぁ。 恐らく後部座席にモニターってのは当たり前になってくるだろう気がする。 でもそうなると「家族で一緒にいるのにみんな個別にネットしてる・・・」って状態のドライブってことにもなるし、それはそれで・・・って気もしなくないなぁ(笑) ただ、パーキングの空車情報がリアルタイムで見られるってのはネットならではだと思うし、そこは組み合わさってほしい。 となると更に前からあちこちで言っているけど、ある程度の主要コインパーキングは全てリアルタイムで空車・満車情報をネットで流してもらいたいし、予約時点から料金発生でもいいから、ネット越しにコインパーキングの予約が出来るようになるとすっごいいいのになぁ・・・と。 道路マップがリアルタイムアップデートされて、空きパーキング情報がリアルタイム反映がナビに統合されるってのは、カーナビネット統合の第一弾としては数年以内にあり得そう。 https://www.facebook.com/namura/posts/10201790037734158 というのと前後して、丸山章さんがFacebookで、 4TBのHDDって吹っ飛んだ時のダメージ半端ないだろうな。 まあ1TBでも大概だけど。もうバックアップなしじゃあ怖いなあ。 https://www.facebook.com/MaruyamaAkira/posts/10201052238120527 というのを見ていて、いろいろ思ったんだけど、もう遠くない未来には個人ユースのデータって全部クラウド保存が前提になってくるんじゃないかと思えてくる。 物理的にローカル環境においておく理由? 現時点でいえば「ローカル環境」を「物理的に手の届く所」というならば、置いておく理由はアクセス速度だけだろう。 ネットワークの速度の問題で、現時点で大きなデータはやっぱりネット越しでは、アクセスに時間がかかるし、アクセス速度を現実的にすればファイルサイズを下げることになり、テキストや軽い画像でなければ、現実的ではないと思う。 ローカル環境においておくリスク 名村は個人ユースとしてHDDの容量が500GBぐらいが手頃な価格の時にそれを4つつないで一つに出来るというロジクールのこんな感じの製品を使っていました。 これを使っていた時としては、500GB✕4=2TBぐらいのストレージ量になっていた訳です。 これ自体はまだ残っているのですが、使い始めた時一番考えたのが、 これが飛んだら・・・全部飛ぶな・・・。 っていうか、これをバックアップするのってどうしたらええんやろ・・・。 ということだったんです。 そう、500GBを4つで2TBにもなったディスクを、バックアップするには、同じだけ費用をかけて、同じものを構築するしかなかった訳です。 まぁ、当たり前といえば当たり前ですが、金額的にも物理的にもなかなか厳しくて、結局「ま、まぁ・・・壊れないでしょ・・・そんな簡単には・・・ね・・・ねっ・・・」とハードディスクケースをマジマジと見ていたものです(笑) 実際、バックアップは出来るようにはなってきました とは言え、時代は進むもので、3年もすれば一台で2TBのHDDも安価になってきました。 現状で言えば、上で紹介したハードディスクケースのバックアップには、「裸族のお立ち台」を使って2TBのHDDを差し込んでバックアップしました。 そういう意味では「バックアップ」そのものは、実施するとして、確かにコストがかかるけど、どうしてストレージに対して昔の感覚があるので「高くつく」というのも事実なんですけど、現実的には「いや、その金額じゃ無理」ではなくて「やってやれなくはない」という状態にはなってきています。 今やバックアップするのはパソコンのデータだけ? しかし、今や「データ」を扱うのはパソコンだけでしょうか? 名村のプライベート、仕事を含めて「一定期間保存しておくデータ」かつ「なくなると困るデータを保存しているもの」というのを考えてみると、 会社のMac mini 会社のMacbook Air 自宅のMacbook Air iPhone5 iPad mini 自宅のHDD内蔵テレビの録画データ 個人視聴用にDVDに録画したテレビ ハードディスクケースに入れている500GB✕4のデータ ハードディスクケースのバックアップをした2TBのHDD といったものがあります。 一方でデジタルデータ化出来ていないアナログものとしても、 フィルムカメラ時代の現像写真 昔VHSにとっていた自分の役者時代のビデオ 昔録音していたラジオ番組のカセットテープ 自炊をしようと思っている書籍各種 とかがあって、現時点では「暇ができたらデジタル化」と考えているが、今後の世代はそもそも最初からデジタルでしょう。 (関係ないけど、今ラジオを録音って・・・する人いますか・・・(汗)) 多くのものがデジタルになり、Wi-Fi環境が充実していく未来 多くのものがデジタルになっていくと、それは物理的な枠が不要になっていきます。 そして、この10年で見てもネット通信、特にWi-Fi環境ってのはかなり充実してきました。(海外に比べてってのは別ですよ) 恐らく今後この流れがひっくり返ることは、世界規模で何か無い限りあり得ないでしょう。 となった時に、グルっと回って冒頭の「アウディが車載システムにネットを繋げる」というところに戻ります。 現時点では、車に乗ったらiPhoneと接続して車内で音楽を聞いたり、CDをカーナビで再生したり、停車中にDVDを見たり、カーナビのHDDにリッピングした音楽データなどを取り込んだり・・・ってことをしています。 でも、これ地味に不便なんですよね、今や。 これだけネット環境が広がっているのに、なんでパソコンのiTunesに入れているデータや、HDD(SSD)のデータをどこでも取得できないんだろう? これが最近特に思う感想です。 これは恐らくIT機器に関してアーリーアダプターの方々は思っている方は多数いると思います。 もちろん現状でも、DropboxとかEvernoteなんてのはいつでもどこでも同じ環境を提供してくれているし、先日のエントリー「シンプルなタスク管理ツールのAny.Doが素晴らしく肌に合った!」で紹介したAny.Doを選んでいるのも、その視点です。 この感覚が今後のIT機器の主流になっていくのでは?と思っています。 そしてそこに至って「クラウド」が本当の意味で「クラウド」なるんだろうし、「ユビキタス」って言葉が広がっていくのではないかな?と思います。 ユビキタス ユビキタス (Ubiquitous) とは、「いつでも、どこでも、だれでも」が恩恵を受けることができるインタフェース、環境、技術のことである。 ユビキタスは、色々な分野に関係するため、『ユビキタスコンピューティング』、『ユビキタスネットワーク』、『ユビキタス社会』のように言葉を連ねて使うことが多い。現在「ユビキタス」の厳密な定義は出されていないが、標準化団体であるW3Cでは2006年、「ユビキタス」に関するワークショップを設立し、国際基準の規格化に乗り出している。2007年4月には、日本での活動が展開されている。 http://ja.wikipedia.org/wiki/%E3%83%A6%E3%83%93%E3%82%AD%E3%82%BF%E3%82%B9 この「いつでも、どこでも、だれでも」を目指した方向性がビジネスとなっていくんだろうし、それがもたらしくれる過渡期のいくつかの段階ごとに、Webサイトというメディアが提供するべきユーザ体験(User Experience)ってのも少しずつ異なっていくのは確実でしょう。 なので「かくあるべき」ではなく、現時点で提供できる体験、それを少し上回る体験を軸に考えていくと、良いWebサイトってのは見えてくるのでは?と思います。

メールアドレスの交換をしている時に気がついた他の人への認知活動の各レイヤーでの注意すべき事

先日とある事で、結構な量のメールアドレスを取りまとめる事がありました。 そこで気がついた事など。 言ってしまえば、異業種交流会的な事の取りまとめなんですが、メールアドレス、実は手書きのモノを集めて打ち込み・・・・というものだったんです。 ここでいろいろ見えてきたことがありました。 メールアドレスそのものでも、 事業ドメインを取っている方とそうでない方。 携帯アドレスの方。 YahooとかGmailのフリーアドレスの方。 多分アドレスが自分と恋人の掛け合わせっぽい方（汗） メールアドレスに顔文字が入っている方（汗） といったことがありました。 それ以外で「紙に書く」って事でいえば、 紙に書いて、「_」なのか「-」かが分かりづらい方 「h」「r」とか手書きにした時に分かりづらい方 というのがあり、結構面白かったです。 （正確に打ち込めていないかもしれないので、それはそれで結構焦っているんですけど） そこで思ったのですが、皆さん、自分の何かの情報である程度パブリックな情報を他人に伝える時ってどれぐらい気を入れられていますでしょうか？ 今回のことで言えば、「メールアドレスを書いて伝える」ってのは事前に何の連絡もなかったのですが、とあるきっかけからそうなりました。 （その結果として名村がとりまとめをすることになったのですが） ただ、可能性として「名刺」に記載をされるような情報であれば交換をする可能性は十分にありました。 その時とか、その場に対しての各人のコミット具合にもよるとは思うのですが、 パブリックなアドレスを用意しているか？（事前準備） そのアドレスは「第三者が」認知しやすいか？（認知性） 認知した結果その本人を「想像」しやすいアドレスか？（再記性） アドレスを伝える時の方法はベターだったか？（再現性） とかって事をどこまで考えてられているかって結構大事なんだなぁ、と気づいた訳です。 会社組織に居る方は、そもそも「名刺」を持っていると思うので、1〜3についてはそれほど問題ないでしょう。 ただ、「手書き」で伝える場合には「字がキレイきたない」以前の問題として「ここでアドレスを誤認されたら、もう関係性が無くなってしまう！！」という危機感を持てるかどうかにかかってくるのかな？と思いました。 ちょっと無理矢理ですが、これっていわゆる「AISASの法則」に繋がっているような気がします。 「AISASの法則」はネットでの購買活動における心理プロセスを表したモノですが、こんな感じですよね。 Attention（注意） Interest（関心） Search（検索） Action（行動、購入） Share（共有、商品評価をネット上で共有しあう） こう言ったことを、自分の認知をする場合には活動をそれぞれのレイヤーに分けて意識をするだけでも随分変わってくるだろうなぁ・・と思いました。

極めてブランド価値の高い応対をしてくれたソフトバンクショップのおねーさんのファンになりました。

先日使っていたiPhone3GSが壊れました（汗 Twitterでもちょっとつぶやいていたんですが、実際には壊れた、というよりは、復元できなくなったというのが正解だったりします。 いや、標準のカメラでビデオ撮影をしていたら、撮影開始３〜５秒ぐらいで、いきなりアプリどころか、iPhone自体が落ちて再起動になるんです。 最初は「ん？なんかやったか？」と思っていたのですが、翌日も続いた上に「カメラロール」の中には、まっ黒なサムネイルになって、クリックしたら「読み取れない形式のビデオです」（文言はちょっとあやふや）的なアラートが。 「こりゃだめだ」とも思ってiTunesに接続をしてバックアップは取ってるし、ってことで、復元を試みてみました。 すると、初期化が終わった後の復元がどうやっても完了しない。 結構いろんなサイトをみて「復元できない場合にはこれをやってみて」的なものを試したり、Twitterで「このサイト見てみて」的なアドバイスも貰ってのですが、尽くだめでした。 いや、今日の本題はiPhoneが壊れたことではなくて、ここからなんです。 結局どうにも直らなかったので、最終的にソフトバンクショップに行ったのですが、なんと交換用の在庫が名村が使っている3GSの黒モデルがありませんでした。 そこからが「あぁ、このショップでよかった」と思えたのですが、お店のおねーさんの対応が神だった。 まずつかみがよかった（笑） 名村をみて、開口一番「あれ？前もいらっしゃいましたよね？」と。 いや、この店初めてなんですが・・・・と伝えたら、「あっ、その携帯（AUのW53CA）を黒のiPhoneのお客様が前にもいらしたので、間違えました。スミマセン」。 多分本当に間違えたんだと思うんですが、なんとなく「つかみはOK」的な印象でした。 この時点で、「あぁ、早く直らないかなぁ・・・・超不便で超ブルーなんだけどぉー」って気分が少し和らぎます（単純！） その後、不具合の確認をしてくれたのですが、その後の一言が「では交換なんですが、今お店に実は在庫がないんです。交換機が入荷になるまでお待ちいただけますでしょうか？」。 が、がーーーん！ いや、この時点ですでに使えなくなって4日目ぐらいで、かなりフラストレーションが溜まっていましたので「えぇ、な、なんとかならないっすか？」と一応聞いてみる。 「で、では周りのお店に聞いてみますね」と。 そこからなんと周りのお店が尽くだめ。 最後には渋谷のアップルストアまで確認をしてくれたのですが、「アップルストアでは交換してくれるみたいなのですが、到着してからの順番予約になるので、一時間ぐらいはお待ちいただくことになっちゃうそうです・・・・」と。 まぁ、そりゃそうだ（笑） 日曜に予約なしでジーニアスバーに行けば、それぐらいは平気で待たされますよね。 と、ここまでの対応、文字で書くと全然伝わっていないので名村の文章力のなさに悲しくなるのですが、ソフトバンクショップのおねーさんは、ものすっごい丁寧な対応をしてくれました。 僕にとってはこの対応こそがすごいブランド価値があって、最終的に「あぁ、では、このお店に交換機が届くまで待ちますよ。こちら（＝このお店）でお願いできますか？」とさせてもらいました。 ソフトバンクショップだけでなく、多くの小売り業のお店って競合他社はやっぱりたくさんあるわけです。 しかも下手したら半径十数メートルぐらいである業界もあるかと思います。 そんな中で最後に「ではここで」と言ってもらうのは、やっぱりヒューマンコミュニケーションの部分なんだろうなぁ、と改めて実感しました。 そこのお店の方の対応の内容もそうですが、その対応の方法やその人の出している空気感、と書くと抽象的なのですが、そういったものを感じた時、人は「ファン」になり、そのお店のブランド価値ってのが醸成されるんだと思います。 以前僕がセミナーとかで紹介していたり、ブログでも確か書いたと思いますが、同じことを楽天の中にある「アンジェ」という雑貨屋さんで体験したことと、同じような事を久しぶりに体験しました。 恐らく、ソフトバンクショップに行く時、よほどの緊急的な用事がなければ、僕は次回もあの店に行くと思います。 自転車で行けるし、場所も覚えましたし。 結局受け取りは翌日で、受け取りに行った時は忙しいタイミングで、名村の応対をしてくれたのは別の方だったのですが、その方にも「交換の方です。○○○に置いてあるので、お願いします」と横からさらっと伝えてくれました。 「おぉ、おねーさん、すげーよ」と結構真剣の思いました（笑） 結局交換も無事終わり、最後にその時担当してくれたおねーさんにもですが、最初に対応してくれたおねーさんに「○○さん、本当にありがとうございました」とお伝えして、お店を後に。 冷静に考えば、もっと大きなソフトバンクショップに行っていれば即日交換出来ていたかもしれないのですが、その不便性を補ってさらにファンにさせてしまったあのおねーさんの応対はすごいなぁと思います。 恐らくそのショップの全員の方がそういう訳ではないかもしれませんが、そういったコミュニケーションを取れるように、自分もなっていきたいですね。

今年もアックゼロヨン・アワードの季節がやってきました。

今年もアックゼロヨン・アワードの季節がやってきました。 ご存じのない方へ説明をさせて頂くといたしますと、アックゼロヨンのサイトの方に詳しく掲載はされているのであれですが、 開催目的 「アックゼロヨン・アワード」は、年齢や性別、障害の有無、ITリテラシの高低に関わらず、誰にとっても使いやすいウェブサイトを表彰します。 となっています。 アックゼロヨンは、その名の通り2004年にWEB-JIS（JIS X 8341-3 高齢者・障害者等配慮設計指針 - 情報通信における機器、ソフトウェア及びサービス - 第3部:ウェブコンテンツ）が出来た事を受けて開催を行うようになり、第一回が2005年。 会の名前が「ゼロヨン」なのに初回が05年とはこれ如何に？という感じはしなくもないのですが（謎）、2004年にに五反田ゆうぽうとでキックオフイベントがあったので、それはそれで有りかと。 さて、今年もアクセシブルでクリエイティブなサイトを表彰するアワードな訳ですが、該当する、しそうなサイトを構築・運用している方は是非とも応募してみてはいかがでしょうか？ 過去の表彰式に参加させて頂いていたりするのですが、確かに凄い大手なサイトが表彰対象になってはいますが、個人で作っているサイトであっても、アワードの意義を踏まえたサイトは表彰をされています。 その意味ではとても張り合いのあるアワードであると思います。 個人的なアックゼロヨンへの思い入れとかは、ここに書いたりしているのですが、僕が別に立ち上げたとかって訳でもないですし、個人的には日本ウェブ協会の会員だったりってはあるにはあるのですが、単純に面白そうなので、って理由で参加させて頂いている訳ですが、ここまで続いてきますと、周りにも宣伝してみたいな、という思いも生まれる訳で、是非ともご覧の皆様、ふるってご応募ください！

テレビでのWebサイト閲覧は一般的になるのか?!を考えてみた

先日結構びっくりしたニュースに、「テレビ版Yahoo!JAPAN」というのがありました。 これと同じくして、Yahooが日本のインターネット動画の老舗GyaOを子会社化したというのがありました。 現状のテレビでもYoutubeを見られる機種が出ているみたいですが、Yahooとしてこれらの施策を打ち出したのは、 「近いうちにテレビでインターネットを見られるようなって、テレビがテレビであるような映像コンテンツは、ネット上のYoutubeやGyaOやニコ動と境界線が無くなっていくのでは?」 と考えての手だと個人的に思っています。 実際現状でも、「テレビはみたいモノを録画しておいて、見たい時に見るモノで、わざわざ放映時間に見なくてもいいんじゃないの?」という人や「テレビは、その後どうせ誰かがYoutubeに上げるか、テレビ局が上げたりもしているから、パソコンで見ればいいんじゃないの?」という方が増えてきているそうです。 一方で、大昔通信回線が遅かった時には「取りあえずサイトの情報をあちこち巡回(場合によっては自動巡回ソフトなどで巡回設定を)して、ローカルマシンのキャッシュに取り込んで、その後から見よう」という事があったWebサイトの方で、Twitterのように「リアルタイムで参加しないとついて行けない」サービスが産まれ賛同されているのは不思議な流れだなぁ・・・とは思います。 閑話休題。 今日そんな流れからとあるお客さんから、「テレビ向けのWebサイトってどうなの?」的な質問をいただき、ちょっと真剣に考えて纏めてみたので、書けそうな所をここに残しておきたいと思います。 テレビ向けサイトですが、制作・開発側としては、現状で言えばWiiで見られる環境が一番近いイメージなのかなぁと思っています。 それを考えると、技術的な部分では、最終的に静的なHTMLを吐き出すのであれば、動的であろうがなんだろうかその仕組みはPHPでもJAVAでも大丈夫かと。 実際にはそのテレビに組み込まれているブラウザが何になるか?ということが問題になるかと。 逆にいいますと、Wiiを例に取れば、ブラウザの種類や、割り当てられているメモリや、それようにカスタマイズされている部分あどから、PC上のブラウザで見るそれよりはリッチなコンテンツは作りにくいと思います。 とはいえ、そんなものは結局は技術論なので、1年も経てば大きく変わってくるかと思いますし、そこはニーズ次第でしょう。 また逆に変わるのがもっとも難しいのは解像度の問題かと。 ちょっと調べてみたら、一般的なテレビの解像度って、 640×480(VGA) 従来のスタンダードテレビ映像 800×480(WVGA) ワイド映像 1024×720(XGA)1024×768(XGA)、1280×720、1366×768(フルワイドXGA)他 ハイビジョン 1920×1080(フルハイビジョン) フルハイビジョン ってなってるんですね。 って事はハイビジョンでやっと最近のパソコンに近い解像度となり、その下はかなり低い解像度って事になります。 その為、テレビで見るWebサイトってのは、一画面目(ファーストビュー)で表示される情報量は自ずとPCに比べると少なくなってくるものだ、という前提で作っていく事が必要にはなるのかなぁ、と。 ただ作るとなったらそんな事は当然考える事だと思いますので、結構どうでもよくて、もっと大事なのは、名村はWebサイトっていうものは「サービス」だと思っているので、テレビ向けサイトそのものは、作る作らないよりも、それがどれだけPCに代替して利用されるような環境が整うか?によると思っています。 (要は、どれだけ良いサービスを提供していても、人通りが無い商店街で開店してもモノは売れないということです) 過去、リビングPCと呼ばれるようなパソコンは幾度も出ていましたが、未だに浸透した試しがありませんでした。 いや、世間的にリビングでソファーとかに座って膝の上やリビングテーブルの上で、一家団欒しながらパソコンを触っている・・・って普及していないですよね?(汗 普及しない理由って実は「リビングでキーボードとマウス」というのが(まだ)日本人の感覚に合わないからだと思ってたりします。 ただ、今回のYahooさんの発表の流れの中で結構今回大きい点は、テレビそのものにインターネットへの接続環境が組み込まれ、それを使うことを「一般的にしようとしている」ということだと思います。 今後地デジ対応のテレビの新機種にネットの閲覧が一般的な機能となっていき、アドレス(もしくは検索ワード)の入力とマウスジェスチャーの代替がテレビのリモコン(もしくはWiiコントローラーのようなインターフェースというか、テレビのリモコンにWiiコントローラーみたいな機能が付けば全部解決な気もしますが)で実用されるのであれば、普及の兆しはあるかと思って(YahooさんのGyao買収の話を)見ていました。 いっその事、テレビ側に、センサーバーの機能をディフォルトでつけてください(笑) という事を考えると、もし現状で自前のサイトのテレビ用のページを作るとしたら、恐らく具体的な情報提供による効果よりも「もううちはテレビ用のWebサイト作ってますよ」的なブランディングの意味合いのが大きいと思います。 良くあるブランディングの手の「○○業界で一番最初」を狙うって為ですね。 なぜそうなのかは簡単で、閲覧する人(=環境)が整っていないためです。 かつ、テレビで見られるだけで結局は通常のインターネットであることを考えると、具体的にリファラーなどでどういった情報が取れるかはまだ知らないのですが、同じURLをPCで見た時とモバイルで見た時に切り替えているのと同じようにテレビのブラウザで見た時に切り替える、ってのがいいんだろうな・・・と思ったりしています。 わざわざテレビ用に別のURLでサイトを作っても、結局入り口はYahooになりそうだし(笑)、その検索結果を叩かれる事を考えればユーザーにとっては、それがPCで見ているのかテレビで見ているのかなんて全然関係無くて「自分の問題を解決する手段が自分がたどり着いたサイトで提供されているか?分かりやすい所にそれがあるかどうか」しか見てくれれないわけですから。 と考えていくと、果てしない夢のように言われている「ワンソースマルチユース」って事になっていくのかなぁ・・・・。 出来れば凄いですけどね、これ。 ただ、(テレビ用とレイアウトを区別してCSSなんかで制御をするのだとしたら)作り手側の管理は、PC用のレイアウトとテレビ用のレイアウトで何かしらコンテンツが増える度に倍考えていかないと行けないので、大変な時代になっていくだろうなぁ・・・と。 でも、結局それも技術論なので、この流れが進めば数年もすれば、テレビそのものに「映像を見るときとWebを見る時で解像度を変える」ってな機能が搭載されて、同じレイアウトで大丈夫!ってな事になりそうだと思っていますが。 もし具体的なテレビによるサイト閲覧の効果を考える場合には、Yahooさんの発表の例であったように、「テレビでインターネット」がテレビ番組を見るのと同じぐらい簡易にできるインフラ(テレビの機種)の普及が最終的にはキモになってくるだろうなぁ・・・と思いつつ、今後の動きは結構楽しみでもあったりするってことで、よく分からなくなってきましたが、今の感想を纏めてみました。 追記 と思っていたら、Gigazineでこんな記事がありました。 テレビとインターネットの立場が入れ替わる日は近い? 名村書いたエントリーとそもそも的な話は違っているのですが、似通っている話題でもあり、「ネット」と「テレビ」という垣根がどう変わっていくか、という点では興味深いっすね。 追記2 ご意見というか感想のコメントを頂き(多謝)、お返しのコメントを書いていたらエントリーと同じぐらい長くなってしまいました(笑) 個人的にそれも含めてドンドコなんか考えが整理されていったので、是非またコメント下さい(笑)

[ご意見お待ちしています]日本語の横書きの際の段落の表現について

ちょっとしたことで疑問になってきたことなので、ブログで皆さんのご意見を聞いてみたいと思ったことです。 小学校の時代に習った事で、日本語の文章では、段落の1行目を1文字分字下げしています。一応、日本語の文章というのは、縦書き、横書きを問わず、このように1文字分字下げするのが決まりとなっているようです。 これが手書きや印刷文化のみだった時代には疑いようもなく、それに右に倣えでよかったように思います。 ですが、Webが出来て、メールが出来てきて、少し変わってきたのかな？と。 特に、メールが顕著だと思うのですが、文章がとても綺麗な日本語で敬語や謙譲語をとても正しく使っていたとしても、メールで、「段落の1行目を1文字分字下げ」している場合というのはあまり多くはないのではないかなあ？と。 どちらかというと、画面上の見やすさで言えばメールでよく言われるのは、 一行は35文字ぐらいがいいよね。 段落毎の間に改行を一つ入れておくと読みやすいよね。 画数が多い漢字は極端に使わない方がいいよね。 ってな事ではないでしょうか。 そういうのが普通になってきたとき、Webの文章で「段落の1行目を1文字分字下げ」ってのはどれぐらい正確であるべきなのかなぁ・・・と。 いや、日本語として正しいのはどちら？って選択をしたら確実に答えは「1字分さげる」になるはずです。 でも、今度はその時、その「1字分下げる」のは、 えい、面倒だから、全角スペースを入れてしまえ。だって、原稿用紙でも一文字さげてるんじゃん！ いやいや、「全角スペース」は正確には文字なんから、意味合いとして一文字さげるのだったら、CSSでそれを制御すべきなんじゃないの？ てなことも考えてしまったりして、う〜んと思ってました。 そうこうしていたら「HTMLにおける「段落」をめぐって」こんなページも見つけたりした訳ですが。 まぁ、そこに何か決まりを作る事を目的としている訳ではないですし、自分の所属している所でルールを作ればいいだけじゃないの？と言われてしまえばそれまでなのですが（笑） 英文の場合だったりすると、最初の文字だけ縦横２倍ぐらいの文字になっている、ってことがあったりしますよね。 元素材がワードとかPDFとか印刷用のイラストレーターデータとかあとかそれに類するものだったりすると、レイアウトされている結果が大事なので、1字落とすのは、全角スペースでもいいんですが、Webでは、レイアウトをしたいが為に、（意味のない）文字情報として全角スペースが入ってしまうのは、何かレイアウトの為にテーブルを使うような気持ち悪さがなんとなくあって・・・・。 ってことで、ここをご覧の皆さんは、「段落の1行目を1文字分字下げ」、どう対処していますか？ もし「○○しているよ」といったモノから「まぁ、ケースバイケースとちがうん？」ってなもの（笑）まで、ぜひコメントいただけると嬉しいっす。

久しぶりにGoogleページランクを見たら、元に戻っていた

昨年末ぐらいからちょっとGoogleの「ページランク」を追いかける事があったので、自分のこのブログも「今いくつぐらいなんだろう？」という興味本意で追いかけたりしていました。 しばらくの間、このブログは、 https://web-directions.com/director/ https://web-directions.com/director/index.php のどちらで追いかけても、実はページランクが「１」になっていました（笑 いや、以前、それはそれで実はページランクが４とか５あった時期があって 「えぇぇぇ、１かよー！なんか悪いことしたか、オレ？！」 と、Google八分になったかと結構本気で思っていたのですが、さっき見かけたら、ページランクが「https://web-directions.com/director/」だと「４」になっていました。 （ページランクを調べるのはGoogleツールバーを導入している方は機能をオンにするか、www.pagerankon.comとかyakibuta.seo-search.com/にそういった機能があるみたいです） ページランクの数字そのもの意味合いがどれほど何に寄与しているかは結構疑問が残る部分ではあるのですが、それでもまぁ、少ないよりは多い方がいいかな？と思ったりするわけで。 ただ、ちゃんとデータを取っていたわけではないですが、しばらくの間、ページランクのアルゴリズムはちょっとダンスを踊っていたみたいですね。 これで落ち着くのか、今もってダンス中なのか？ さっきも書いていますが、これが個人ブログにとって、しかもRSSとオーガニック検索が殆どのサイトでどれぐらい意味があるかというと結構疑問ですが、ちょっと嬉しかったので、エントリーしてみました（笑）

マーケティング視点から見る無料保険のドアノック商材

無料保険のDMからはじまった疑問…某クレジットカード会社から、1通のDMが届きました。中身は「無料で入れる保険」の案内でした。交通事故の死亡保障がついて、しかも2年間は完全無料。条件を見る限り、申し込めば誰でも入れるような内容です。そして当然ながら同梱されていたのは有料の三大疾病である「がん（悪性新生物）」「急性心筋梗塞（心疾患）」「脳卒中（脳血管疾患）」へのケアの保険でした。今回の話題は「無料保険」がドアノック商材であると理解し、実際は有料版の保険も一緒に入会させることが目的のDMであることは理解しつつ、これをネタにマーケティング施策を深堀りしてみた、という思考遊びです。上記までのことは分かりつつ、無料保険だけを最初に見たときは、「まぁ無料なら入っておいてもいいのかな…？」ぐらいの温度感でした。ただ、ひとつだけ気になる点がありました。この手の保険であれば、本来は「約款」や「特約」といった、細かい条件がどこかにまとまっているはずです。実際、資料の中にも「適用される約款名」の記載自体はありました。ただ、その“中身”が見当たらないんです。僕の見落としかな、と思って一通り資料を見直してみたのですが、やはり本文としての記載は見つからず、「あれ？」という違和感が残りました。これでも一応、普段はWebの仕事をしているので、「情報がどこに置かれているか」や「どういう構造で設計されているか」は気になるタイプです。ということで、この違和感を起点に、この無料保険ってそもそもどんな中身なのかなぜ無料で提供できるのかこの仕組みはビジネスとしてどう成立しているのかあたりを一度ちゃんと分解してみることにしました。先に結論だけ軽く書いておくと、この「無料保険」は、いわゆる保険商品というよりも、マーケティングの文脈でいうところの「ドアノック商材」に近い設計になっています。そしてもう一歩踏み込むと、「無料で何かをもらっている」というよりは、“別の価値と交換している構造”になっている、というのが実態に近そうです。この記事では、そのあたりを順番に整理しながら、無料保険の中身はどうなっているのかなぜこのモデルが成立するのかマーケティング的に見ると何が起きているのかを、できるだけフラットに書いてみようと思います。同じように「これ、無料だけどどうなんだろう？」と感じたことがある方の参考になれば幸いです。 1. 無料保険の中身を分解してみるまずは、今回案内されていた無料保険の中身を整理してみます。ざっくりまとめると、以下のような内容でした。交通事故に限定された傷害保険死亡時に保険金25万円保険期間は2年間保険料は無料（カード会社負担）申込はチェック一つで完了こうやって並べてみると、「無料だからとりあえず入っておくか」と思わせる設計になっているのは間違いないと思います。ただ、少し冷静に見てみると、いくつか気になる点がでてきました。まず、保障の範囲がかなり限定されています。「交通事故」に限定されている記述があるので、病気はもちろん対象外と思われますし、日常生活での事故も基本的には対象にならない…と思われます。言葉の歯切れがわるいのは冒頭で書いたように「約款」や「特約事項」の記述が無料保険については一切封入されていないのです。さらに、死亡時の保険金が25万円というのも、よくよく保険として考えてみるとかなり小さい金額です。いわゆる「万が一に備える」と考えても、この金額でカバーできる範囲はかなり限られています。つまりは「他に保険に入っている」ことがある程度前提になっていて、「無いよりましでしょ？」的なもの、と言えます。ここまで整理すると、ひとつの結論としては、保険としての実用的な価値はかなり限定的と言ってよさそうです。もちろん「無料で25万円の保障がつく」と言えば聞こえはいいのですが、実際に使う場面や意味のある保障かどうかで考えると、少し見え方が変わってきます。 2. なぜ無料で提供できるのかでは、こういった保険がなぜ無料で提供できるのか。ここは仕組みとして理解しておいた方がいい、深堀りしておいた方がいいポイントになってきます。保険というのは基本的に、事故が起きる確率×支払う金額この掛け算で原価が決まります。今回のケースで言うと、交通事故に限定（＝発生確率が低い）支払額が25万円（＝低い）という条件なので、そもそもの保険原価がかなり低い構造になっています。交通事故というのは全国区で見たら多くの方が自責・他責を問わず被害にあっていますが、個人の発生要因としては病気になるよりも遥かに低いといえるものです。また文面を見る限りやっぱり「交通事故限定」と読める記述になっています。さらに、これは個人契約ではなく団体契約になっているため、保険会社としてもリスク分散が効いています。この「団体契約」というのは、保険会社 ← 契約 → クレジットカード会社（団体） ↓ 会員（自分）という構図になっていて、保険料は団体（カード会社）がまとめて払っていることになります。これによって年齢分布や属性もセグメントされています。これらがセグメントされているということは、事故発生しにくそうな年代・性別に限定することができるので、結果として「保険支払の発生率を下げることができる」ということに繋がります。つまり保険会社としてのリスクヘッジが容易にできている、ということになります。これに対して「個人契約」はみなさんもご経験があるかとは思いますが、上記でいえば「保険会社←契約→自分」という構図になっている場合ということです。このあたりを踏まえると、「無料で提供してもビジネスとして成立する（だって支払いリスクが低いから）」というのはそこまで不思議な話ではありません。むしろ、この時点で少し視点を変える必要があって、これは“保険を売っている”というより、“別の目的のために保険を使っている”のではないか？と考えた方が自然です。 3. ドアノック商材という考え方ここで出てくるのがタイトルにも書いた「ドアノック商材」という考え方。簡単に言うと、本命の商品を売る前に、最初の接点を作るための商材のことを指します。営業の世界だとよくある話で、いきなり高額商品を売るのは難しいまずはハードルの低い商品、もしくは無料のサービスで接点を作るそこから関係性を作っていき、アップセル・クロスセルを狙っていくという流れを作る第一歩となる商品・商材のことです。。今回の無料保険は、まさにこの「最初の接点」を作る役割にかなり近い設計になってるといえます？無料であることによって心理的なハードルを下げて、まずは申し込みという行動をしてもらう。その結果として、「契約者」という関係性が一度成立する。この時点で、今回のこのDMは単なるDMとは全く違う状態になってきているといえます。 4. 本当の価値はどこにあるのかここからが今回の話の一番重要なポイントになります。この無料保険でクレジットカード会社、もしくは保険会社側が得ている価値は何か？僕は最初は「個人情報の取得なのかな？」と思ったのですが、よく考えるとそれだけでは説明がつきません。なぜならクレジットカード会社であれば、もともと顧客情報は持っているはずです。では何が価値なのかというと、もう少し突っ込んだ考察が必要となりそうです。。4-1. 保険利用に対する“同意”まず一つ目は、「保険に関する情報提供に同意した顧客」という状態です。カード会社が持っている情報と、「保険会社に提供されることに同意した情報」は意味合いが全く違います。この同意があることで、保険商品に関する提案ができる状態になります。4-2. 「保険に反応する人」という属性もう一つ大きいのがここです。無料とはいえ、申し込みをするという行為は、「この人は保険というものに対して一定の関心がある」という状態をしめすことになります。マーケティングの観点でいうと、これはかなり価値の高い情報になってきます。4-3. 継続的な接触が可能になるさらに重要なのが、継続的な接触です。一度契約関係が成立すると、DMメール場合によっては電話といった形で、継続的にコミュニケーションを取ることができるようになります。ここまで来ると、単なる「広告を見る人」ではなく、「関係性のある顧客」に変わっています。この3つをまとめると、今回の無料保険の本当の価値は「保険」そのものではなく、「顧客との関係性の獲得」と言えそうです。 5. ビジネスモデルを数字で考えてみるでは、このビジネスモデルが実際にどのくらいの精度で回っているのか。公開データがあるわけではないので、一般的なマーケティングの視点から考えて見たいと思います。例えば、1000人にDMを送った場合。無料保険に申し込む人：2〜5%その中から有料商品に進む人：3〜10%とすると、最終的に有料契約に至るのは、1000人中1〜5人程度という計算になりますね。0.1％〜0.5％という数字になります。これは一見するとかなり低く見えますが、ここで重要なのは「1人あたりの価値」です。仮に有料保険の方が「月額2,000円」だった場合、その保険に加入し2年間継続した場合、売上としては、2,000円 × 24ヶ月 = 48,000円になります。数人でもこの水準の顧客が獲得できれば、DMコストは十分に回収可能といえます。つまり、少数の課金者で全体のコストを回収するモデルになっています。 6. なぜ人は申し込んでしまうのかここまで構造を見てきましたが、ではなぜ人はこの無料保険に申し込むのか。これは心理的な要因がかなり大きいようにおもいます。こういった時の施策として、心理的な部分での効果や狙い、いくつか代表的なものを挙げてみます。無料バイアス「無料」というだけで、価値以上に魅力的に感じてしまう。権威バイアスクレジットカード会社というブランドによる安心感。フット・イン・ザ・ドア小さな行動（無料申込）をすると、その後の提案も受け入れやすくなる。一貫性バイアス「一度申し込んだ」という事実が、その後の判断に影響する。こういった心理が重なって、結果としてCVRが成立していると考えると、かなり納得感があります。「保険」という不確実だけど発生することが確実視（＝顕在化していると錯覚する）されることへの対策、という商材においては、これらは強く働くと思います。 7. これは搾取なのかここまで見ると、「なんだか搾取されているのでは？」という印象を持つ方もいるかもしれません。ただしこの点については少し冷静に考えておきましょう。結論としては、搾取とまでは言えないが、情報の非対称性はあるというのが実態に近い気がします。なぜなら、今回の件でいえば「無料」保険への加入だけでいえば、金銭的な損失は基本的にはありません。「団体契約」とはいえ、大手保険会社との契約である以上。無料保険であっても保険支払の条件に合致している限り、滞りなく支払われるはずです。（仮に保険会社が倒産したとしても、日本の業法で倒産時には保険債務は別の保険会社に引き継ぐなどされ、加入者の不利益にはならないようにかなりに配慮が法律でされています。）ただし、実際の保険価値その裏にあるマーケティング構造が十分に理解されないまま意思決定される可能性はあります。8. 自分が感じた違和感の正体最初に感じた「約款が見当たらない」という違和感。これは結果的に、「この商品は本当に何を提供しているのか？」という問いに繋がってきます。表面的には「無料の保険」ですが、構造としては顧客獲得のためのマーケティング装置になっている…。そこに気づくと、最初の違和感の意味がかなりはっきりしてきます。9. 結論：この無料保険に入るべきかここまでを踏まえて、じゃあ今回の無料保険には実際に入るべきなのか否か？かなりシンプルに言うと、入っても大きな損はしないただし得られる価値は限定的というバランスになるんじゃないかな？と思います。一方で、継続的な営業接触情報提供といった形で、保険会社、もしくはクレジットカード会社から営業を受ける機会が増えるとは思いますし、通常保険のDMを受ける機会も増えるでしょう。「届いても捨てるだけだから」というかもしれませんが、それでいいのか？的な話もあります。（僕は郵送物は最低でも見るので、その手間が増えるのは増えます。）もしご自身でファイナンシャルプランナーさんに定期的に相談をしていて、自身の保険について「もう実はこれ以上やることが（収入を割く割合的な意味で）ない」というならば、そもそも支払われる可能性が極端に低い25万円の可能性で個人情報を売らなくてもいいとは思います。 10. 判断するためのフレーム最後に、マーケティングやブランディング的な視点で、商品をプロデュースするとしたら？とい意味で「プロデュース」カテゴリーの記事にしましたが、今回のようなケースで使える判断フレームを整理しておきます。自分が得るもの vs 相手が得るもの価値のバランスを見る。なぜ無料なのか無料である理由を考える。代替できるか他の手段で同じ価値が得られるか。将来の影響この選択が将来にどう影響するか。今回の無料保険に限らず、「無料」という言葉が出てくるものは、何かしら別の価値と交換しているケースがほとんどです。その構造が見えるだけでも、意思決定の質はかなり変わってくると思います。このあたりが、何かの参考になれば幸いです。

What I consider to be the best thing about buying Vision Pro!

What I consider to be the best thing about buying Vision Pro! We purchased two Vision Pro's for our company and have been using them with various apps. My company has a budget for the AR/MR field and also does R&D. I am convinced that AR is the next best means of expressing the web in the first place, after smartphones. In graduate school, which I attended until March, I wrote my master's thesis on the topic of “AR and Marketing”. After using Vision Pro, I know that this is definitely the ticket to the next web. However, as far as hardware for AR goes, I consider this to be positioned as “version 0.1”. From now on, AR devices will have to have the expressive power of Vision Pro and be eyeglass-shaped to spread to the world. AR will extend the realm of digital expression from monitors to space in the future. What kind of dreams do you have there? I am always excited to hear from our own R&D members who are now entering the field of AR/MR. It's exactly the same or even more emotion than when I first saw the web site in 1994 and when I started creating the web in 1996. Regardless of whether you are an Apple devotee or not, everyone involved in digital expression should experience the world of AR/MR. (Whether that be Vision Pro or Meta Quest!) And we should remember the text of the digital creator. ∙ Start and create something that no one has thought of before. Think about the future when the space becomes a place for digital expression. Creating something that no one has ever made before, by groping for it. I believe that the frontier where these joys can be strongly felt in the digital domain is in the world of AR. I do not know whether the world of AR will become as I predicted or shrink in the future. However, from the various AR/MR tools and apps that are being presented around the world today, many people are enjoying the possibilities. I am looking forward to working more with people who can share this excitement with me.

ぬいぐるを使ったアイデア写真はどのように生まれるのか？

2020年コロナ禍となり、僕自身もテレワークになりました。 僕は自社[サービシンク](https://servithink.co.jp/)を創業したころから「通勤」という切り替えがないと中々自分の働く上でのスイッチが切り替わらない人でもあったので、在宅勤務をしたことはほぼありませんでした。 それもあって、テレワークをしていること自体が自分の中でも半ばイベントのように感じていたのを覚えています。結局僕は世情的な緊急性を除き、その後はほぼ出社をしていたりします。 ですが、そのテレワーク期間中に、今でも想い出として残っているのが今日ご紹介するものです。 ### 仕事部屋を出て戻ると、毎回繰り広げられるくすっと笑える瞬間 当時Twitterにアップしていたのですが、テレワーク中、当然仕事部屋を出るタイミングあります。 * ランチ * 夕食 * 仕事部屋を含めた部屋の掃除 これらの時間はメリハリを聞かせ、仕事部屋に入らないようにしていたのですが、戻ってくると結構な割合で、「嫁のイタズラ」がなされていました。 初回はここから始まりました。 仕事場に行ったら企画を熟考してるやつがいた・・・。#嫁のイタズラシリーズ pic.twitter.com/kUFQjIQbfq— 名村 晋治@Webディレクター26年目 (@yakumo) April 14, 2020 こういった「あたかも台詞を喋っている」かのようなレイアウトを嫁が作るのが抜群にうまく、ある時からTwitterのハッシュタグを付けて投稿していました。 今でも自分で見返えす時があるのですが、僕には絶対にできないものだし、この後に一通り載せますが、毎回「良くこれだけアイデアがでるなぁ・・・」と心底関心していました。 テレワーク中にふとドアを開けるとそこに「知らない世界が広がっている」楽しみはなんともいえず気持ちを優しくしてくれていましたが、こういったアイデアの種のためにブログに残しておきたいと思います。 Twitterをご覧の方は「[yakumo #嫁のイタズラ](https://twitter.com/search?q=%40yakumo%20%23%E5%AB%81%E3%81%AE%E3%82%A4%E3%82%BF%E3%82%BA%E3%83%A9&src=saved_search_click&f=live)」でご覧いただけます（初期の頃のタグ貼り忘れが抜けてしまいますが・・・） ### ダッフィーと豆柴、まんぞくさんの繰り広げる世界 散歩から帰ってきたら、90年代の青春漫画の主人公が、土手で考えてごとしてるみたいなやつがいた。#嫁のイタズラシリーズ pic.twitter.com/x7FQK2mJVj— 名村 晋治@Webディレクター26年目 (@yakumo) April 21, 2020 仕事場に戻ってきたら、Apple Watchをベルトにして考え事してる奴がいた・・・#嫁のイタズラ pic.twitter.com/j6x1t6Zk7k— 名村 晋治@Webディレクター26年目 (@yakumo) April 27, 2020 仕事部屋に行ったら、眼帯野郎が黄昏てた・・・#嫁のイタズラ pic.twitter.com/600onZKWiw— 名村 晋治@Webディレクター26年目 (@yakumo) May 5, 2020 仕事場所に来たら、筋肉ほぐしてるやつがいた。#嫁のイタズラ pic.twitter.com/aAT9y0QfFA— 名村 晋治@Webディレクター26年目 (@yakumo) May 6, 2020 仕事場に来てみたら、ラッコが貝を割ってた・・・#嫁のイタズラ pic.twitter.com/6NqAFHRgcC— 名村 晋治@Webディレクター26年目 (@yakumo) May 8, 2020 朝起きて仕事場に来たら、なんか困ってる奴がいた・・・#嫁のイタズラ pic.twitter.com/JE87CpHx7I— 名村 晋治@Webディレクター26年目 (@yakumo) May 9, 2020 朝起きて仕事場に来たら熱中症にかかってる奴がいて、クマのくせにクマのタオルかけて涼んでた・・・#嫁のイタズラ pic.twitter.com/d7khvZ4var— 名村 晋治@Webディレクター26年目 (@yakumo) May 10, 2020 ランチ食べて仕事場に戻ったら朝に熱中症だった奴が冷えピタ貼ってカシューナッツしばに看病されとった・・・#嫁のイタズラ pic.twitter.com/oSUzFkRo4Z— 名村 晋治@Webディレクター26年目 (@yakumo) May 11, 2020 ランチから戻って仕事場にきたら、ボール取りを挑んできた奴がいた#嫁のイタズラ pic.twitter.com/PYBZAI1qPB— 名村 晋治@Webディレクター26年目 (@yakumo) May 13, 2020 モニターの掃除を終えて昼寝してる奴がいた・・・#嫁のイタズラ pic.twitter.com/PPck8dlPxr— 名村 晋治@Webディレクター26年目 (@yakumo) May 14, 2020 ランチから帰ってきたら自分を充電してる奴がいた（お腹にQiの充電部分をちゃんと当ててる）#嫁のイタズラ pic.twitter.com/WeeYAEhuOw— 名村 晋治@Webディレクター26年目 (@yakumo) May 15, 2020 今日はオフィスに行かなきゃいけないってリビングで話をして準備しようとしたら、マスクまで準備して行く気満々のやつがいた。#嫁のイタズラ pic.twitter.com/m20F6qCOv9— 名村 晋治@Webディレクター26年目 (@yakumo) May 18, 2020 足元のフットレストで昨日オフィスに連れて行ってもらえなかったやつが拗ねてた・・・#嫁のイタズラ pic.twitter.com/8rR4vUQxQM— 名村 晋治@Webディレクター26年目 (@yakumo) May 18, 2020 朝起きたら「おい、名村、野球しようぜー」って誘ってきたやつがいた。#嫁のイタズラ pic.twitter.com/ZqkF9uSivb— 名村 晋治@Webディレクター26年目 (@yakumo) May 19, 2020 今日は就業規則改変申請の為に役所に行くといったら、前回連れて行ってくれなかったから賄賂を持って待ってたやつがいた#嫁のイタズラ pic.twitter.com/oXSNYH3jjC— 名村 晋治@Webディレクター26年目 (@yakumo) May 21, 2020 流石に根負けして連れていくことになった。#嫁のイタズラ pic.twitter.com/jrQFhLqJpj— 名村 晋治@Webディレクター26年目 (@yakumo) May 21, 2020 昨日会社に連れて行ったら、今朝お礼を用意していたやつがいた。#嫁のイタズラ pic.twitter.com/IZCqVGAbEf— 名村 晋治@Webディレクター26年目 (@yakumo) May 23, 2020 昨日連れていってもらったオフィスがどんな所だったか自慢げに話しているやつがいた#嫁のイタズラ pic.twitter.com/PfiSfhKTYO— 名村 晋治@Webディレクター26年目 (@yakumo) May 23, 2020 あ、⚪︎×ゲームで負けたらしい・・・#嫁のイタズラ pic.twitter.com/BnU0tUH7VL— 名村 晋治@Webディレクター26年目 (@yakumo) May 25, 2020 一人クマに聞いたオフィスの話に感化されたやつが紛れ込んでた・・・#嫁のイタズラ pic.twitter.com/9JsiOO2Z4r— 名村 晋治@Webディレクター26年目 (@yakumo) May 25, 2020 人の机にロープ張ってブランコしてるやつがいた・・・#嫁のイタズラ pic.twitter.com/cizWMc2IMW— 名村 晋治@Webディレクター26年目 (@yakumo) May 26, 2020 仕事部屋に入ったら、人の机の上でパズルで悩んでるやつがいた。#嫁のイタズラ pic.twitter.com/I9BhVusTN9— 名村 晋治@Webディレクター26年目 (@yakumo) May 27, 2020 朝起きたら・・・なんでクマがエアリアルヨガしてるねん・・・#嫁のイタズラ pic.twitter.com/khsNH2qhyE— 名村 晋治@Webディレクター26年目 (@yakumo) May 28, 2020 仕事机の上でクマとナマケモノが「よんろのご」をしているどこでも見られる昼下がりの光景です。#嫁のイタズラ pic.twitter.com/y1aTGsgybz— 名村 晋治@Webディレクター26年目 (@yakumo) May 29, 2020 これはなんだ？とクマに聞いたら「ブルーインパルスのデルタ編隊」とのこと#嫁のイタズラ pic.twitter.com/MNPpDlqxry— 名村 晋治@Webディレクター26年目 (@yakumo) May 30, 2020 今日でテレワークが解禁になるといったら、全員で行く気になってた。入ってないやん。#嫁のイタズラ という事でテレワークがあけたので、このシリーズはこれで最後になるそうです（嫁談）長らくご覧いただきありがとうございました！ pic.twitter.com/aeGtIUnRBl— 名村 晋治@Webディレクター26年目 (@yakumo) May 31, 2020 在宅勤務になったらまたこいつが出てきた。#嫁のイタズラ pic.twitter.com/O91y3AWzZv— 名村 晋治@Webディレクター26年目 (@yakumo) November 25, 2020 あ、よく見たら、ジュース飲みながら風呂入ってやがる！！#嫁のイタズラ https://t.co/tYlFCBKwEj pic.twitter.com/d1HpDKXL0j— 名村 晋治@Webディレクター26年目 (@yakumo) November 26, 2020 マラドーナ追悼中らしい……#嫁のイタズラ pic.twitter.com/nMRsBb9rCR— 名村 晋治@Webディレクター26年目 (@yakumo) November 27, 2020 昨日オフィスでウェブセミナーやって帰ろうとしたらこいつがこっそり入ってた！！！#嫁のイタズラ pic.twitter.com/78imb120Eb— 名村 晋治@Webディレクター26年目 (@yakumo) November 29, 2020 いや、今日はオフィスには行かないよ？ ヘッドホンで音楽聴きながら昼寝してた…#嫁のイタズラ pic.twitter.com/ilv6Yg7Lvg— 名村 晋治@Webディレクター26年目 (@yakumo) December 1, 2020 部屋に入ったらクマがまんぞくさんの似顔絵書いてた…けど、アップ過ぎね、それ？！#嫁のイタズラ pic.twitter.com/FocW80uJv0— 名村 晋治@Webディレクター26年目 (@yakumo) December 1, 2020 そのキャップ、どこから持ってきたの……？あ、次男（11ヶ月）のキャップと靴下やんけ！！#嫁のイタズラ pic.twitter.com/dbhV5ICL42— 名村 晋治@Webディレクター26年目 (@yakumo) December 3, 2020 おい、何があった？！#嫁のイタズラ pic.twitter.com/tOv0Mz1Kre— 名村 晋治@Webディレクター26年目 (@yakumo) December 3, 2020 先に今夜のポッドキャストの収録を始めてるやつがいた…#嫁のイタズラ pic.twitter.com/tRxSwvd5fJ— 名村 晋治@Webディレクター26年目 (@yakumo) December 4, 2020 部屋に入ったらナマケモノがクマに目薬さそうとしてた･・・#嫁のイタズラ pic.twitter.com/u7UBhNAbp4— 名村 晋治@Webディレクター26年目 (@yakumo) December 5, 2020 お、おぅ・・・・どうしたいんだ？#嫁のイタズラ pic.twitter.com/0xy996iTSM— 名村 晋治@Webディレクター26年目 (@yakumo) December 6, 2020 なんかクマが偉そうに講習してた…#嫁のイタズラ pic.twitter.com/Ce5vlRSQt9— 名村 晋治@Webディレクター26年目 (@yakumo) December 7, 2020 クリスマスについてクマが説明してた。ただ、豆しばの頭にオーナメント、置かれてる…#嫁のイタズラ pic.twitter.com/e0UOnHbByl— 名村 晋治@Webディレクター26年目 (@yakumo) December 7, 2020 部屋に入ったらクリスマスツリー作ってるクマがいた……#嫁のイタズラ pic.twitter.com/UAYsibvonh— 名村 晋治@Webディレクター26年目 (@yakumo) December 9, 2020 えっとパソコンは座椅子じゃないし、机の上を勝手にクリスマス仕様にしないでくれないかな……#嫁のイタズラ pic.twitter.com/9rI6kG6Atm— 名村 晋治@Webディレクター26年目 (@yakumo) December 10, 2020 「クリスマスツリー出来たよー」ってドヤ顔で一堂待ち構えてた…#嫁のイタズラ pic.twitter.com/m78gDv2dlB— 名村 晋治@Webディレクター26年目 (@yakumo) December 11, 2020 一生懸命頑張った組体操クリスマスツリーは、翌日疲れ果てて崩れていました…#嫁のイタズラ pic.twitter.com/QhPq4Rk5FG— 名村 晋治@Webディレクター26年目 (@yakumo) December 12, 2020 えっと・・・何で君がプレゼント候補に付箋を貼ってるんだい？#嫁のイタズラ pic.twitter.com/kqdESNDmfq— 名村 晋治@Webディレクター26年目 (@yakumo) December 13, 2020 朝起きたらOculus Questで映画観てるクマがいた。#嫁のイタズラ pic.twitter.com/er26lqSVVB— 名村 晋治@Webディレクター26年目 (@yakumo) December 14, 2020 豆しばが二人でVRゴーグル付けてるけど、お前ら、それじゃ立体には見えないぞ？#嫁のイタズラ pic.twitter.com/pG18mtf20E— 名村 晋治@Webディレクター26年目 (@yakumo) December 17, 2020 仕事部屋に入ったら、クマが文字通り詰んでたwww#嫁のイタズラ pic.twitter.com/CWBSG7YnKv— 名村 晋治@Webディレクター26年目 (@yakumo) December 20, 2020 部屋に入ったらみんなで柚子湯に入ってるクマがいた…#嫁のイタズラ pic.twitter.com/wcoehyU8iB— 名村 晋治@Webディレクター26年目 (@yakumo) December 20, 2020 人の机のモニター台が最近完全にクマの机になってきてる…飛び出す絵本の読み聞かせしてやがった…#嫁のイタズラ pic.twitter.com/kS6QEaC25w— 名村 晋治@Webディレクター26年目 (@yakumo) December 22, 2020 クマがGreat conjunctionの解説してた…君も風の時代を感じてる人か！#嫁のイタズラ pic.twitter.com/BBxlfrQ1pj— 名村 晋治@Webディレクター26年目 (@yakumo) December 23, 2020 いやいやいやいや……な、何をまってるの？！#嫁のイタズラ pic.twitter.com/Xg1kCGHMqf— 名村 晋治@Webディレクター26年目 (@yakumo) December 24, 2020 クマがサンタにプレゼントもらってた！#嫁のイタズラ pic.twitter.com/PE3pWXXawT— 名村 晋治@Webディレクター26年目 (@yakumo) December 24, 2020 どうやら何かが終わって落ち着いたらしい……#嫁のイタズラ pic.twitter.com/72ujNXinsh— 名村 晋治@Webディレクター26年目 (@yakumo) December 29, 2020 仕事中に戯れてくるクマがいるのですが…#嫁のイタズラ pic.twitter.com/OrkcNacSYA— 名村 晋治@Webディレクター26年目 (@yakumo) December 29, 2020 読んでるのか読み終わったのか分からんけど、本のチョイスがすごいな、おい。#嫁のイタズラ#自分の小さな箱から脱出する方法 pic.twitter.com/vfRaDfKYeC— 名村 晋治@Webディレクター26年目 (@yakumo) December 30, 2020 クマは前日に読んだ「自分の小さな箱から脱出する方法」を実践しているらしい。お前、ちゃんと読んでなかっただろ……？！#嫁のイタズラ pic.twitter.com/IFcqXEiGUS— 名村 晋治@Webディレクター26年目 (@yakumo) January 1, 2021 以上が仕事部屋で繰り広げられていたちょっとした非日常でした。 何も喋っていないし、表情も当たり前に変わらないのに、何かを語らせるってのは本当にすごい才能だと思いました。 備忘録に残しておきたいと思います。

「Webディレクションやってます:blog」リニューアルしました。

先日ここで「[ブログをリニューアルする上での意図とかコンセプトとか。](https://web-directions.com/director/web_direction/blog-renew-2015.html)」で書いたリニューアルを2015年4月2日にできました。 このブログにとって久しぶりのブログリニューアルになるのですが、自分の備忘録というか、パートナーさんへどのように依頼をしたのか?といったディレクション的な要素もある今回のリニューアルなので、書き残しておこうと思います。 ### ブログを書かなかったのは、「会社を生き残らせるため」という、「より重要な」理由があったから 今回のリニューアルですが、[Web制作・ホームページ制作会社である株式会社サービシンク](http://servithink.co.jp/)を立ち上げてからは如実に更新頻度が下がっていました。 これは理由は単純で、**僕の時間は可能な限りサービシンクを生き残らせるために費やす**、というのが僕にとって正だったからです。 とした時に、僕がブログで記事を書くことによる効果と、目の前の仕事を30分でも早く進めるのとどちらを取るか?ということを選択した結果というだけのことです。 ただもう一つ理由がありました。 ### リニューアルをした目的は自分自身のモチベーションを上げるため ただ、それ以外にも理由がありました。リニューアル前のブログで、デザイン、機能面、管理画面などで自分なりに気に入らないところが多数あったのです。 その気に入らない部分は当初は「諦めて」いました。ただ、それがちょっとずつ自分の中で澱のように溜まっていって、ついには「ブログの画面を見るのも面倒くさい」というところがあったのも事実でした。 ただ、それを「改修する具体的な内容」にはなっているものの、「自分が実装する時間やバージョンアップしたa-blog cmsの機能を学習するコスト(=時間も労力も)も割くことが出来なかった」というものでした。 なので、今回のリニューアルでは「このツールを使っている自分がかっこいい」「このビジュアルデザインのサイトが自分のサイトなんだ」と思えモチベーションをあげられるようにしたい、ということが理由になってきていました。 #### この数年で自分が実装面からディレクション、企画方面に相当にシフトした結果 という話をすると「実装から手を離した」とか「学習することをやめたら終わりだよね」的なことをいわれそうなのでちょっと補足。 実装はもちろん好きですし、僕がディレクションをしている上での強みは「実装ができるし実装を知っているから」というのは間違いありません。 だから、今でもハンズオンの実装セミナーとか研修には行ってたりします。 ただしそれは「現状の仕事に直結している」という点においてです。これはこのブログのCMSのa-blog cmsが仕事に使える、使えない、ではありません。 僕が基本的に「ゼロからシステムを開発する」文化に長くいたために、Movable TypeとかWordPressとかのCMSの最終的にブラックボックスに近いものがあるものを触るのが苦手なんです。 名村のこれまでの仕事が、お客様と数年レベルで継続的にお付き合いをすることが多いということもあり、Movable TypeとかWordPressの*中心部分に何か原因があった時*、お客様に「しょうがないですよ」的な話になるのがいや、というか責任が取りきれないのがいや、というか・・・。 なので、世にあるCMS全般が苦手なのです。(あっ、サービシンクではWordPress案件もやっていますし、実務になれば速攻で習得はしますし、この歳になれば理解をするための勘所も分かるので、理解までは実際には早いですよ) 話をもどして、ですので実装は好きなのですが、自分のブログの改修のためだけにa-blog cmsへの学習コストであれば、別のものに割く・・・ということで、後手になっていました。 ### リニューアルを決意したきっかけはこのブログで今後書いていこうと思っている「Webディレクター」のための知見をまとめていくコンテンツ このブログは「Webディレクター」の名村が日記とかもありますが「Webディレクター」の人に「ディレクション業務」をしていく上で「**TipsやKnowhowといった付け焼き刃ではなくて、継続的に使っていける考え方やマインドセット、手法を書いていく**」というのをコンセプトにしています。 「[ブログをリニューアルする上での意図とかコンセプトとか。](https://web-directions.com/director/web_direction/blog-renew-2015.html)」でも書きましたが、「*おっさんになったんだから、おっさんの仕事をしよう*」というつもりで、僕が普段なんとなく実施している行動や判断の基準を明文化したり、仕事人として心がけていることとかをまとめていくメディアにしていこうと思っています。 ### リニューアルをフォルトゥナ坂本さんにお願いをして、お願いができた3つの理由 今回のブログのリニューアルをお願いさせてもらったのは「[フォルトゥナの坂本さん](http://www.color-fortuna.com/)」でした。 坂本さんにお願いした理由はいくつかあるのですが、まとめると下記のような理由でした。 #### フォルトゥナ坂本さんにお願いをしたい!と思った3つの理由 * このブログのCMSであるa-blog cmsのスペシャリスト・[エヴァンジェリスト](http://www.a-blogcms.jp/evangelist/) * Facebookで「リニューアルしたいなー」って言ったら反応してくれた(笑) * 当初は機能面に不満があったんだけども、よくよく考えるとデザインについてもリニューアルしたかった というような理由から坂本さんにお願いをさせていただきました。 言ってしまうと自分も含めてですが、普段からのアウトプットが大事なんだなと思いました。コミュニケーションは接点頻度によって信頼度が圧倒的に変わるということはよく言われます。 今回でいえば正にその通りです。 #### 「あれ?坂本さんと仲よかったんですか?!」 名村さんって去年ぐらいまで、坂本さんとか角○さんとかKDDI ウェブコミュニケーションズの○畑さんとFacebookとかでいつも罵り合いしてませんでした? あーしてたね。[これ](https://www.facebook.com/1278217134/posts/10200975292406034)とか[これ](https://www.facebook.com/100000444183375/posts/686097514748382)でしょ?(笑) 実は坂本さんと仲悪いんだと思ってました ということを実は一度だけ言われたことがあります(笑) まさからホントにそう思われているとは思っていませんでしたが「仕事では」とても尊敬していますよ(笑) ### ブログのリニューアルに際して坂本さんに依頼をした内容 坂本さんにリニューアルを依頼するとき、お願いした内容は大きく次のものでした。 * 丸投げでもいいですか? * デザインをリニューアルしてもらいたい * 機能面での改修と追加をお願いしたい これらが大枠の依頼でした。 #### 丸投げでもいいですか? 今が特になんですがかなり[サービシンク](http://servithink.co.jp/)のディレクターとしての業務が重なってきています。 ということがあり、冒頭で書いた「リニューアルをしたい」という思いを満たすために自分の時間が取れなかったというのが前提にありました。 とした時に「お願い出来る人に頼る」訳ですが、お願いをした結果「自分の時間を費やす」のであれば、当然本末転倒になるので、取るべき選択肢としては「やらない」を選ぶことになります。 そうなると今回満たさなければならない「**要件**」は、 * 自分の時間は極力使わずにリニューアルをなし得る * リニューアルをしない、という選択肢を取らない になってきます。 そうすると次に考えるのは、上記の要件を満たしてくれる「人」を探すことになる訳です。 かつその人には「**要件を伝えただけで安心してお願いができるクラス**」の人でなければなりませんでした。 その時、声をかけてくださった坂本さんであれば、これまでのご自身の屋号[フォルトゥナ](http://www.color-fortuna.com/)としてのアウトプット、SNSでの発言、これまでお会いして話をしていた、といった条件の中からお願いができると判断できた訳です。 ですので、お願いとして「丸投げでもいいですか?」となった次第です。 #### デザイン面のリニューアル デザイン面のリニューアルでは冒頭でも書いた「モチベーションをあげられるデザインにしてください」というお願いでした。 自分で言ったんですが、だいぶ酷いオーダーだったと思います。 「**名村がモチベーション上がるのってどうしたらええねん?**」 ってことですから(笑) もうちょっと噛み砕くと、 * (この後書く)機能に対してのUIが細部まで気が入ってる * 管理画面の記事エントリー部分が使いやすいUIになっている ということでした。 そこでなんとなくお伝えしたのが、僕が以前に思っていたこんな話でした。 > Firefoxが昔出た時に使う上ですごいモチベーションあったんですが、その理由ってアイコンがそれまでのIEとかNetscapeに比べると、圧倒的にかっこよかったからなんです。「そこ?」と思われると思うかもしれないんですが、「このかっこいいアイコンをクリックしてアプリを立ち上げる」ということが僕にとっては大事なんです。 もちろん機能面が十分でなければならないとは思います。その次の指標として、です。 その意味では、今のMacのアイコンはWindowsと同じソフトでもアイコンがカッコイイ。これだけで僕はMacの方を使っていたいと思える。 それを今回成し得たいとおもっています。 というようなことがありました。 #### 機能面のリニューアル 機能面では下記の実装をしてもらいたい、という旨のお願いをしました。 * サイドメニューに「ブログにおけるPVラインキング」をだす (→これはa-blog cmsで実装できないってことでナシにした) * タイトルの横に、各記事のPVをだす * サイドメニューにエントリーの「はてブランキング」をだす * カテゴリーリストに、そのカテゴリーに登録しているエントリーの件数をだす * トップ・一覧・各ページで、それぞれのページにおけるはてブ数や、いいねとか、ツイートされた、の件数を出したい (従前は名村がa-blog cmsの理解が乏しいままで実装していて、各ページのはてブ数表示が「web-directions.com/direction」というトップページに対しての数になっていた) * 名村のTwitterのウォールを出す * 文字に対しての装飾の色を「1.赤(否定・警告)」「2.青(肯定)」「3.緑(用語の強調)」「4.オレンジ(単純強調)」「5.黒(強調)」 * 装飾系はQ数は18pxの太字 * フォントのQ数は16px * 特定のレイアウトを再現できるタグを追加する * 記事の文末に同じテーマに属しているPVの多い記事のタイトルを5件出す * レスポンシブル(今も一応しているので、まぁ、それぐらいの感じで) * OGPとTwitter Card部分を綺麗にする (これも従前は、OGPとTwitter Card用の画像の引っ張り出し方がイケてなかった) * 一覧の時に、それ専用のdescriptionと、一覧用イメージを出す * sitemap.xmlを設ける * a-blog cmsのiPadアプリで更新が出来るようにしたい(今何故か出来ない) ということを従前のブログに対して追加できるようにお願いをさせてもらいました。 ### 坂本さんにお伝えした「名村が考えているサイトの今後とデザインで望むこと」 そんな要望を投げていた結果として坂本さんとデザインの話になりました。そこで名村お伝えしたのが下記で、名村が今回リニューアルをしようと思った「**今後**」の話です。 冒頭で「おっさんになったんだから、おっさんの仕事をしよう」ということでこのブログは「**Webディレクションに関する名村の知見をアウトプットしていくメディア**」というのがコンセプトです。 それをお伝えしたのですが、その時の内容はこんな感じでした。 * デザイン面ですが、今後ブログとしては今名村が地方とかでもさせてもらっている「Webディレクター養成講座」で話をしているような「Webディレクター」のための知見をまとめていくコンテンツを作る予定 * ある程度見出しレベルのアジェンダはひと通りあげていて、50〜60コンテンツぐらいをコツコツ書いていきたいと思っている * その意味では今回カテゴリー・タグについても既存コンテンツに対して再考することを考えている * タグクラウドは最近のGoolgeの方針としてブログ等での同一コンテンツのURL複製がNGになっていることからリンクを出さないようにしている * その意味では、個人色よりも(会社ブロクではないものの)多少学術的に「Webディレクション」についてのコンテンツが書かれている真面目なサイトにしていく方向で。 という内容をお伝えした次第です。 ### 面倒な客だなおい、と思われると思います。 ここまで読んでいる人がどれだけいるか?と思うぐらい長くなってきていますが、受注者である方(僕も[サービシンク](http://servithink.co.jp/)ではそうですが)にしたらここまで書いた内容を読んだら「面倒な客だなおい」と思うかもしれません。 ただ、この「丸投げでお願い」というのは一応結果ではなくて最初にその前提でも「お願いできますか?」ということでお願いをさせていただきました。 あと逆に「丸投げでもこの案件はお願いができる」と「坂本さん」に対して思っていたからでもあります。 今回は意思決定をするクライアントが僕一人で完全に完結していますからね。 これが会社としての受託案件でお手伝いを頂く場合には、Webディレクターとして「要件把握とそのブレイクダウン」は当然の僕の業務ですし、*そこが一番好きで得意*なので、徹底的にやった上でパートナーさんにはお願いをさせていただきます。 ### 謝辞:ということで思った以上のリニューアルできました [坂本さん](http://www.color-fortuna.com/)、今回は本当にありがとうございました。 Facebookで坂本さんが「[こんな怖かったの久々ですよw](https://www.facebook.com/KunioSakamoto/posts/956157191075745?pnref=story)」と書かれていますが、そうだと思います(笑) 気心がしれた相手から丸投げって自分がその立場だと「どれだけ信頼されてるんだ」ということで逆にプレッシャーにはなりますよね。 ただ、実際坂本さんにもお伝えしたのですが、途中ほとんど何も言わなかった(最後もほとんど言わないままでしたが)のは「こちらが期待している通りプラスアルファだったから言わなかっただけ」なんです。 微に入り細に入り気を配っていただき、実際の仕事は初めてでしたが、仕事人としての真摯さと細やかさが本当にありがたかったです。 ということで、リニューアルをしたので、頑張ってエントリーを書いていって、Webディレクターを誇りある仕事になるように、自分を含めた周りのWebディレクターがクライアントから信頼・信用され、少しでもいい仕事が成し得られるようにしたいと思います。

画面上での注意喚起を促す文面の表示の仕方について。

先に言います。 これ、半分以上は名村の「確認不足からくること」でです。 「ちゃんと読め」と言われればそれまでなのですが・・・・ということを先に謝っておいた上手のエントリーです。 先ほどある銀行サイトでドメイン料の振込をしようとしました。 ドメインベンダーから「振込人名義は会員IDとお名前をご入力お願いします」とあったので、手入力をしたんです。 し、しかし・・・。 という表示が・・・。 これをみて「あぁ、全角とか半角指定だろうな・・・」と思い、その画面にあった「入力可能な文字などくわしくはこちら」というリンク先をクリックしてみます。 こ、これは・・・全角なのか半角なのか・・・どっちだ?! そこで出てきた画面がこの画面でした。 確かに上の方に、目立つように「赤字」で「全角」と書いています。 ただ、この画面、入力文字例を掲載したことで、画面としては赤字の部分が返って目立ちにくくなっているような気がするのですが、気のせいでしょうか?(汗) というのは、僕においては思考と視線がこう動いたんです。 入力したらエラーになった!! (気分的に少しげんなりして)入力方法指定の画面を開く 入力出来る文字列は・・・・えーっと「カナ」・・・「濁音」・・・「数字」・・・と。 と、いきなり入力出来る文字列の方に目をやってしまったんです。 なので、実は冒頭の赤字で書いてくれている「全角で」という注意文の部分は全く視界に入っていなかったんです。 結果として名村の頭の中では、 え?この「英字」の指示って全角?半角? 間違い例のところのアルファベットって、これってQ数が小さいの?は、半角ってことか? となってしまったんです(恥) で、結局何をしたかというと・・・入力例のアルファベットを「コピペ」したんです(笑) いや、そこに書いている文字列をコピペすればさすがに大丈夫だろう・・・ってことなんですが、全部打ち終わってから「あっ・・・全角ってことか・・・」と気がついた次第です。 と、完全にイチャモンレベルなんですが、この「赤字で太字にしたから目立つだろう」ってのは、僕も全く疑いもせずにやってしまいがちです。 ただ、今回の名村みたいにせっかちな人が、ある画面を初見の時、赤字の太字よりも情報的に優先度が高いものが掲載されているとそっちに目が行ってしまう、ということがありえるのだと我ながら気が付きました・・・。 情報の優先度と目立たせるって、もうちょっと気をつけてこれからの設計に気を使っていきたいと思います・・・。 最初プンスカしてごめんなさい、某銀行さん。

Foursquareのチェックインボタンの挙動を通して気がつくユーザインターフェース設計の考え方

What's Foursquare? 「Foursquare」というスマートフォンアプリがあります。 携帯のGPSによる位置情報を使ったゲームのようなアプリで、駅などのランドマークに来た時に「私はここに来ました」というような情報を残していくものです。 その「ここに来ました」という情報を残す作業を「チェックイン」と呼称しています。 また同じ場所に沢山くると「メイヤー」(=市長)として、「その場所の主」のような称号を得ることができます。 この「メイヤー」は自分より他の人がその場所に沢山行くようになれば、その人に移転してしまいます。 また色々なチェックインの内容によっては、「バッチ」と呼ばれる、「移動距離が多いで賞」「カフェ一杯行ってるで賞」的なモノももらえたりします。 この「メイヤー獲得」と「バッチ獲得」がこのFoursquareのゲーム性を上げて、どこかに行ったら「チェックイン」というような行動を引き出しています。 チェックインをする時の挙動のユーザインターフェース Foursquareの紹介記事ではないので、説明はこれぐらいにして、先日このチェックインをする時の画面でふと気が付きました。 上の画面はiPhone5のおけるFoursquareの画面ですが、それだけを見ると、チェックインのボタンは画面の右上のあります。 この場所にあるのは、2013年6月15日時点のアプリのバージョンなのですが、以前のアプリのバージョンではここにありませんでした。 そして実はキーボードのギリギリ上の方に緑の横棒のようなものがありますが、実はこれも「チェックイン」のボタンなんです。 How to CheckIn? Foursquareでチェックインするには、 アプリを起動 現在地を検索するボタンを押す 画面上部に地図、下部にその界隈のランドマークの選択肢が表示 その中から該当のランドマークの名称を選択 とします。 で、手順の4番目のランドマークを選んだ後が下のものなんです。 この時点で「チェックイン」をすることも出来るのですが、「ここに来た時の一言」を残すことができます。 その為には地図上の吹き出し部分をタップするのですが、その結果、画面の下部にキーボードが出てくる訳です。 その時、慣れていない人は恐らく「あ、あれ?チェックインボタンがキーボードの下に行って、チェックイン出来ないやん!」となったんだと思います。 キーボードの「完了」を押せば大丈夫なのに・・・はユーザインターフェースとして正しいのか? Foursquareの最初のキーボードが出ていた画面、実はここでキーボードの右下の「完了」を押すとこのキーボードは下がって、二枚目のFoursquareの画面になるんです。 でも、その「完了を押せば」ってのが分からない、気が付かない方がきっと多数出たんだと思うんです。 その結果として、キーボードが出ている画面の時には画面の右上に「チェックインボタン」を表示させるようになったと思います。 案の定、完了を押すと画面「右上」のチェックインボタンはフェードアウトして消えます。 ただ「アプリとしての挙動」だけを軸に考えれば「画面表示時のキーボード有無」というのはあるものの、「同じ画面にチェックインボタンが2つある」事になります。 正確に言えば、 同じ画面に、同じ機能のボタンを二箇所、しかも大きさも異なるものを配置する。 ということになるわけです。 これは「機能として動くもの」だけを考えている思考ではそもそもこの発想は出てこないと思います。 だって要らないから。 更に言えば、下手に頭の硬いエンジニアとかと話をすると、「なんで同じボタンを二箇所に置かないと駄目なの?」と実装することに拒絶反応すらする人もいるのではないか?と思います。(名村は2000年前半ごろにこの話に近しい内容で当時のエンジニアと喧嘩したことがありますので・・・(笑)) 使ってくれる人に寄り添う気持ちこそがUI設計の源泉ではないでしょうか? ユーザインターフェース設計は結局「どのリテラシーの人を対象にするか?」を真剣に想像出来るか?が肝心なんだと思います。 そしてその人達が「少しでも便利に」「少しでも気持ちよく」、そして「少しでも迷わず」使えることを考えぬくことがユーザインターフェース設計の源泉になっているのではないかと思います。 ユーザインターフェース設計というと「グローバルナビゲーションが・・・」とか「サブナビゲーションが・・・」とか「フッターリンクエリアが・・・」といった方に行きがちですが、そもそもの原点はどこか?というのが自分の腑に落ちれば、それはあくまで手段・手法であることに気が付きます。 場合のよっては「ボタンの表示するラベルの文言」を考えることですらユーザインターフェース設計になってくる訳です。 となれば、それは「ディレクターだから」とか「デザイナーが」とかってことではなくて、エンジニアであってもテスターであってもそれぞれに出来る分野でユーザインターフェース設計には関わっていくことが出来るんだと気が付きます。 「ユーザ視点」という言葉がありますが、それは更に言えば「ユーザの気持ちの寄り添う事」ではないかな?とこのFoursquareの「チェックインボタンのあり方」で気が付かせてもらいました。

NAVERまとめのオロナミンCのバナーがすごい!

最初にこの記事をふと見ていて、右側のオロナミンCのバナーに目が止まりました。 おおお、直球やね・・・ と思ったら、実は上の方に・・・。 おおお、ページ上部にオロナミンCが繋がってるじゃないですか。 これ更にびっくりして、もう堀江さんところじゃなくなりました(笑) もはやサイト名が「元気ハツラツ!オロナミンC」に見えてくるような状態で、これは「バナー」・・・なんでしょうか?(笑) NAVERトップに戻ってみたら、もっとすごかった件 完全になんのサイトか分からない勢いです。 ページの上から右まで全部クリックエリアになっていて、飛んだ先もNAVERまとめのサイト内なので、タイアップ広告みたいになっているわけですね。 それにしても、自社サイトのここまでの広告媒体化ってのは、国産企業のサイトではなかなか出来ないのではないでしょうか。 このサイトディレクションを僕がやっていたとして、この企画が上がったら「いやいやいや、もはやなんのサイトか分からなくなるじゃないですか!ユーザに対してそれでいいんですか?!」とかってテンプレな返事をしてしまいそうです。 でも「NAVERまとめ」だったらありなんでしょうね。 媒体の持ついろいろな要素を考えても、僕自身「まぁ、NAVERだしね・・・」と妙になっとくしてしまう何かがあるわけですし。 企業の持つ「ブランド」ってものの測り間違えをしないようにしないとなぁ、と勉強になりました。