Notes on making
Webの歴史とモダンな作り方、各言語の紹介、デザイン、ディレクションとプロジェクトマネジメント（WBS・ガントチャート）まで。つくる現場で使える単位で書いています。
- 2026.09.21
ダークUIで気をつけること——コントラスト・彩度・グレインの決め方
背景を黒くしただけのダークUIは、まぶしいのに読みにくいという状態になりがちです。私が実際に使っている、明度差の測り方・彩度を落とす順番・グレインでバンディングを隠す手順を書きます。
#design#modern-web - 2026.09.20
タイポグラフィの最小ルール——書体2つ・サイズ4段・行間1.6〜2.0で決める
文字まわりの判断を毎回ゼロから考えると、ページごとに見た目がばらつきます。私は「書体は2つ、サイズは4段、行間は1.6〜2.0」を出発点にして、そこから案件ごとに削ったり足したりしています。その決め方を書きます。
#design#modern-web - 2026.09.19
コーポレートサイトの情報設計は「3階層で止める」——深くしない決め方
中小規模のコーポレートサイトなら、階層はトップ・カテゴリ・詳細の3つで止めると、迷いにくく運用もしやすくなります。3クリックルールとは別の話として、私が情報設計で使っている「止め方」を書きます。
#design#direction - 2026.09.18
ペルソナとカスタマージャーニーマップは「会話の道具」として使う
ペルソナやジャーニーマップは、きれいに仕上げて納品するほど使われなくなりがちです。会議で指をさし、判断の根拠を言い合うための道具として、粗く作って何度も書き直す。私が制作案件で使っている形を書きます。
#design#direction - 2026.09.17
LP改善は「数値→仮説→デザイン」の順番で——1回に1つだけ変える理由
LPの改善が「なんとなく作り直す」で終わると、何が効いたのか誰にも説明できません。数値で詰まっている場所を見つけ、仮説を1行で書き、デザインは最後に1か所だけ変える。私が改善案件で使っている順番を書きます。
#design#direction - 2026.09.16
一人で全工程をやるときの段取り——役割の往復コストを減らす順番
ディレクションもデザインも実装も一人でやると、遅れる原因は作業量よりも役割を行き来する回数のほうにあります。決めごとを先に倒し、同じ役割をまとめ、待ち時間を前提に並べる。私が使っている順番を書きます。
#direction#pm - 2026.09.15
リリース前チェックリストは3列で作る——検証・計測・戻し手順
公開直前のチェックが「表示確認」だけで終わると、公開後の計測漏れや戻せない事故に気づけません。検証・計測・戻し手順の3列に分けて、公開前日に埋めるチェックリストの作り方を、私の実務の形で書きます。
#direction#pm#modern-web - 2026.09.14
クライアントとの「決める会議」の設計——議題・決定者・期限を先に書く
打ち合わせを重ねても何も決まらないのは、議題が「話すこと」で書かれているからです。議題を問いの形にし、決定者と期限を招集の時点で書く。私がクライアントとの定例で使っている会議の組み立て方を書きます。
#direction#pm - 2026.09.13
システム遷移図とAPI仕様書は誰のために書くか——テクニカルディレクターの仕事
遷移図や仕様書は「作ること」が目的になると誰にも読まれません。読み手を先に決め、1枚ごとに答える問いを絞る。テクニカルディレクターとして私が書き分けている3種類のドキュメントと、その使い方を書きます。
#direction#pm#modern-web - 2026.09.12
見積もりは3つに分けて出す——工数・期間・リスクを混ぜない理由
「この案件、いくらで何日?」に1つの数字で答えると、あとで削る相談ができなくなります。工数・期間・リスクを別々に出す手順と、クライアントに見せる順番を、実際に使っている形で書きます。
#pm#direction#wbs - 2026.09.11
Webサイト制作の標準WBSテンプレート——企画から公開後の運用まで
案件ごとにゼロからWBSを書くと、抜けるのは毎回「公開後」と「クライアント側の作業」です。私が使っている4区切り・約30行の標準テンプレートと、案件に合わせて削るときの考え方を書きます。
#wbs#direction#pm - 2026.09.10
バッファはタスクごとに積むか、末尾にまとめるか——置き方で変わるもの
各タスクに少しずつ余裕を足す引き方と、末尾にまとめて置く引き方では、遅れの出方が変わります。私が末尾寄せにしている理由と、合流点にだけ別途置く判断、クライアントに見せる範囲の分け方を書きます。
#pm#direction#wbs - 2026.09.09
クリティカルパスを口頭で説明できるか——依存関係の見つけ方
クリティカルパスは図の中で色を塗るものではなく、口で言えて初めて使えるものだと考えています。依存関係の聞き出し方、3文で言えるかの確認、経路ごとに違う余裕の扱いを書きます。
#pm#direction#gantt - 2026.09.08
進行管理の週次レビュー：遅れを「発見する日」を先に決める
遅れは起きた日ではなく、気づいた日に問題になります。私は週次レビューを「進捗を報告する会」ではなく「遅れを発見する日」として設計しています。曜日の決め方と、当日に見る3点を書きます。
#pm#direction - 2026.09.07
要件定義で最初に書く1枚：目的・対象・やらないことを決める
要件定義を機能一覧から書き始めると、何を足しても減らしても判断できない資料になります。私は先に「目的・対象・やらないこと」の1枚を作ります。その3項目の書き方と、1枚では拾えないものを書きます。
#direction#pm - 2026.09.06
ガントチャートは「線」ではなく「依存」を描く道具——引き方の順番
ガントを日付から引くと、遅れが出るたびに全部引き直すことになります。先に依存関係を決めてから日付を置くと、線は後から機械的に決まる。私が実務で使っている引き方の順番を書きます。
#gantt#pm#direction - 2026.09.05
WBSの作り方：ディレクターが最初に決める「分解の単位」
WBSは作業を細かく書き出す表ではなく、「何を1つの塊として扱うか」を決める道具です。単位を先に決めると、見積もりも進行管理も揺れにくくなる。私が実務で使っている決め方を書きます。
#wbs#direction#pm