RESTより普通にGraphQLが好き

GraphQL のメリット・デメリットが話題なので推してる人として考えてることを書いてみる。技術には優劣はなく、フィットするシーンや技術者の信念と共振するかどうかだけであると思ってるのでそこのところよろしく

他と比べて

ぶっちゃけ言うと推してはいるが元は消去法的にである。他のツールではスキーマ管理の徹底と開発生産性のバランスが合わなかった

REST API

• スキーマを管理、強制する術が弱い
• Open APIが代表的だが、スキーマの定義をコードとは別に作る構成。疎結合なメリットもあるかもしれないが、実態との差が生まれる構造
• スキーマの差を発見するためのテストコード書くのは本末転倒感あった。テストコードあっても発見できないケースがあり漏れる
• Open API Client使えばまだマシ。だけどその徹底はレビュー等でしかできない
• APIがすでにある→ Open APIでドキュメントを整備する、というケースが、自分の生きてきたタイミング上多くあったというバイアスはある

gRPC Web

• protobuf使う副作用がキツい
• ブラウザ単体でデバッグ出来なくなりWeb FEの開発中に面倒
• protobufの自動生成コードがJS/TSっぽくなく書きにくかった

この辺りの消去法が理由でGraphQL推しに落ち着いた

何が好きかで語る

GraphQLのメリット、他の構成のマイナスポイントの裏返しや純粋に良い点を書くとこうなるのかな

• API側がスキーマに準拠するのが強制される
  • 技術の構成上スキーマに合わせないと成立しない
  • 自作でリゾルバ作って緩くする人もおらんやろう
• 一定以下の労力でAPIリクエストが絡む動作のデバッグ、トレースができる
  • gRPC Webよりはだいぶマシ
  • とはいえ Network が query だらけになるので拡張の助けがあると楽になる
• クエリであることで、どこで何を参照してるか分かる
  • とりあえずで全部取得ってしてたらそうはいかないが、影響範囲がありそうくらいは分かる
  • そうすると拡張、削除時にバグを静的解析できるチャンスがある
  • さらに高度なこともできるそう（よくわかってない）

    GraphQLですが、
    ・Fragmentで、各UIコンポーネント（および関数）が外部由来のどのデータに依存するかを書ける
    ・Fragment Maskingを使えば、特定のコンポーネントの依存にのみ含まれるデータを、バケツリレーの途中で使われるのを防げる
    という点で快適すぎるので、なるべくこれありの生活をしたい

    — syumai (@__syumai) 2026年1月31日

• こういった硬め、静的解析しやすい構成はAgentic Codingと相性がいい。GraphQLに限らず

  GraphQLよりよいものがありえるのではないか、というのはまあそうだと思うんだけど、一方で agentic coding 時代は「自動テストさえできるなら何とでもなる」みたいなところがあるから、agentic codingと相性はいいと思うんだよな。

  — FUJI Goro (@__gfx__) 2026年2月1日

ただ、この辺りがバランスをとして求めないプロダクト、スピードを優先する事業状況もあるのも理解できる。そうするとオーバースペック感があるし、バックエンドの負担が高くなるだけなのも理解できる。

---

2026/02/03追記

orpc.dev

こういうアプローチもあると知った。End-to-End Type Safety, First-Class OpenAPI (= Schemaと理解), Contract-First Development が実現できるってのは期待。

僕はロックなんか聴いてきた 〜ゴッホより普通にニルヴァーナが好き! 〜 (リットーミュージック)

Figmaとワルツを

プロダクトのフロントエンド開発をしてるとUIデザインツールをどう読み解くか、UIデザインツールの内容と実装都合のどちらを優先するかの悩みはよくある。最近所属チームでもよく出る。

自分の経験上どうだったかを振り返って物を言う老害ムーブをかましたくなったので色々考えて書いてみる

Figma for デザインシステム デザインを中心としたプロダクト開発の仕組み作り

前段として

まず自分のUIデザインツールで作られたブツへの想いやあれこれを語っとく

• アレはドキュメントであり実装ではない。アレを完璧に作るよりも動くソフトウェアを作る方が価値が高い。アジャイルにいきましょ
• 叩き台として試行錯誤をハイスピードで実行できることに価値がある
• Layer、Auto Layoutなど高機能で便利ではある。だけどそれを完璧に使ってカンプを作り上げるのは時間がかかりすぎる ¹
• ↑と関連して、コードの自動生成に期待できるのは小さなコンポーネントまで。ページや一定規模の塊のコード生成に期待してはいけない

溝があるとこ

UIデザインツールで具体化していくフェーズとプログラムを書いて実装するフェーズとでは色々違いがある。実装時には配置の厳密性 ² や共通化、構造化などの視点が強くなる。その手前の段階では決まってないことも多い。

経験上のあるあるを書いてみた。

コンポーネントの配置、スペース

パーツレベルでは意識さてれるし、全体の構成でも考えて配置してる。ただUIデザインツールでは配置は、Webのそれよりも自由度が高い。なので数値化するとおかしい、他と作り揃ってない、などが起きがち。共通のルールを適用する徹底が難しい要件の一つ ³

FigmaのAuto Layoutはだいぶ便利ではある。ただ完全に信頼とはいかない。例えば1階層上のLayerと2階層上のLayerのサイズがズレてて、その状態で見た目のバランスを合わせてるなどのケースもある。そうするとFlexboxなどだけでは再現できなくなる。

Figmaを試行錯誤の場として使うとLayerの構造を完璧に維持するのは時間がかかる。最終的な状態をまとめる際にきれいにするのも微妙なんだよな。Figmaの成果物は動くプロダクトではない。アジャイルにプロダクト開発をするなら優先度が落ちるところ。

トランジション

これってみんなどのタイミングで誰が決めてます？

大枠完成した後に動かしてみる中で考えたり、気が効くフロントエンドエンジニアが入れてくれてる、過去の類似機能をマネる、あたりでふんわりと決まることが経験上多い印象。

UIデザインツールの時点では静止した状態に最適化している。状態遷移がある画面、要素の場合でも遷移前後のイメージはあるが遷移中は作られない。ツールに機能もあるけど作り込まないよねー。

この領域の専門家って誰なんだろうという疑問もある。UIデザイナーなら微妙なとこ。UXデザイナーを名乗るなら考えて欲しい ⁴

フロントエンドエンジニアから派生した「デザインエンジニア ⁵ 」は割とフィットしそうだが存在がレア。

議論・試行錯誤が何度もあった要素

そういうコンポーネントには要注意。

繰り返し調整をする中でLayerやスペーシングが複雑になる。最終案になるものも議論の過程でざっと作ってそのまま採用ってなると再構成せずに次の作業に移ったりする。

そうするとLayerが無駄に深かったり、逆に使わず絶対位置で配置してたりする。一個一個の案にコストを割けないから必然そうなりやすい。

なので実装時に気をつけて読み、しっかりコミュニケーション取って作っていくのが大事。

振り返って

会社でFigmaのアレがーみたいな話が出ることがたまにあり、自分がWebフロントエンドがっつり書いてたころの反省と実践してたことを思い浮かべながら書いた。

デザイナーさんに怒られたりし、この調整めんどくせーと思ったりたのが懐かしい。けどそれも誰が悪いとかではなく、会社やプロダクトのフェーズ、各々の専門性や重視ポイントの違い、忙しさ、などなどチームで開発進める中での構造的に起きるものなんだろうなと改めて思った。

作って学ぶFigma入門［完全版］　ステップ・バイ・ステップで身につくWeb/UIデザインの基本

---

1. UIデザインツールのブツを作り込むとしたらUIコンポーネントライブラリのサンプルを提供する場合とかはあり得るかも。大企業がLPなどを外部に発注する時とかは作り込んだりするんだろうか↩
2. 別に厳密だから偉いってことはない。ITエンジニアが厳密になれるのは他の誰がが土台を固めてくれてるから↩
3. そういえば昔デカいデザインファームからゲスト来て、デザインシステムの作り方についてなんか言ってたことあったな。レイアウトや余白の取り方もシステム化できるんですか？って質問にそれは難しい、センスですね、って回答してて微妙な気持ちになったのを思い出す。難しいのはわかるがそれが一番重要じゃねと↩
4. 過去にそういうことを経験した訳じゃないし特定の個人を思い浮かべたり攻撃する意図はないです。UXってUIとの対比で抽象度高いことに絡めて言いがちだけど、インタラクションなど具体な部分も含むはず。ふんわりしたポエムをSNSで描いてる人を煮詰めて藁人形にして殴ってる意図はある。↩
5. この言葉は数年前よく見かけたけどあまり定着した印象はしないんだよな。コストをかけれるフェーズの企業もプロダクトが限られるので椅子が少ない、UI/UXデザインとコーディング両方のスキルが一定以上ある人材もレア。なのでスターはいても波にはならないのかな。↩

見積もりについて俺にもグダグダ言わせてくれ

先日からソフトウェア、プロダクト開発での見積もりについて話題になってる。関心は当然あるし内容には賛同するところも多かった

www.seangoedecke.com

「スタッフエンジニアとしてどうやって見積もりしているか？」(How I estimate work as a staff software engineer)という記事。

・ソフトウェア開発の見積もりが正確にできるという考えは、業界の「丁寧な嘘」
・経験豊富なエンジニアほど、プロジェクトの正確な見積もりは不可能だと知っている…

— iwashi / Yoshimasa Iwase (@iwashi86) 2026年1月24日

この流れに乗っかって見積もりについての思うあれこれを吐き出しておく

一つ目。見積もりとリリーススケジュールについて

• ビジネス領域のメンバーから「もっと早くなりませんか」と言われるが、最速の方法は見積もらずに作ること
• 正確には事前にリリース日を決めずに作り、できた時点でリリースとする
• 基本的にリスクヘッジのため見積もりはバッファを持たせる。不確実度が高い要素ほどそう
• なので約束する期日はリリースできる可能性が十分に妥当だと想定できる時期
  • 熊とワルツをに図解あったな
• リリースが可能になる最速のポイントに本当にリリースできる可能性はある。だけどユーザーと商談、案内する日程の候補にはできない
• 極論ではあるが、スコープが決まってて動かさないならあり得る
• 逆に言うとスコープを決めるために見積もる、というのは元記事と同じ結論

2つ目。より正確な見積もりはできないのか？

• ビジネスを作るには他者と同じ物を作るのではなくブルーオーシャンを狙う、真似して改善点を入れる、という側面が必要
• IT業界の性質としてはブルーオーシャンが比較的広いこと、内部構造の予想がしにくいこと、などがある
• そうすると、作る物は新規性が強く過去の事例を参考にしにくい
• 建築に例えると、建売りの住宅を建てるよりも、難易度の高い橋をかけるプロジェクトみたいなイメージか
  • 建築は素人なので例えが変だったらごめんなさい
• なので予想が難しく、不確実性はとても高い
• 巨大な橋を建てる方が求められる安全性がシビアで難しそうだが、それだけに調査、見積もりに時間とコストをかけている
• スピード感が求められるIT領域のビジネスではそこまでやれない
  • 10年構想してリリースしました、とやってうまくいくプロダクトやマーケットがどれだけあるか
  • 先進領域や個人開発ゲームなどはあるかもしれないが、今回はその領域ではない

3つ目。そもそも見積もりって何なの？

• Coten Radioの番外編#93 聞いててすごく共感した
• ビジネスシーンでは合意、実行に移すのための儀式的な要素がたくさんあるって話
• ポッドキャストの内容は資金調達と事業計画について
• プロダクト開発の見積もりと開発着手の関係もそう
• 誰も妥当性の検証はできないが、外部からも求められるし、内部の人間も作成をする意味を感じる
  • 嘘。意味ねーよこんなんと思いながら作ることもある。
  • その中間くらいの、このくらいが妥当なラインかな？と思いながらが多いかも
• なので見積もりって
  • 自分の「やるぞ」って宣言
  • 見積もりとディスカッションのプロセスを通したからOKという儀式
  • のような側面が強い

取り止めないし構成も何もないけど勢いで書いてみた

いつか体系的に整理したりできたらいいなと思う

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

Agile Fluency Modelをわかった気になった

Agile Fluency Modelって気になるけど日本語情報も少なく、The art of Agile development (2nd) を読んでみたが自分の英語力だと章間の繋がり気にしつつ読むにら至らず挫折してた。

The Art of Agile Development (English Edition)

※ 1stは日本語版があるけど2ndは別物らしいので注意

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

最近思い立ってLLMで解説まとめてもらい、ScrumやXPとの関係、開発チームのストーリー仕立てで説明を作ってもらったら多少理解のきっかけができた気がする。自分が見落としてた（≒みんな引っかかりそうな）ポイントをまとめてみる

• Agile Fluency Model (AFM)は実践のためのフレームワークではなく、チームの状況を測るための指標集
  • XP, Scrumなどのフレームワークの選択はチーム、実現したいモードによって決める
  • 選択のヒントやチーム状況の分析・課題発見・改善のためのヒントになるのがAFM
• モード1-4があり、モードが進むとチームはより大きい流動性、不確実性を許容できる。プロダクト、ビジネス価値の最大化のために柔軟性を持つ
• モード間の変化は線形じゃなく、モードを進めるごとに新しい領域を開拓するイメージ
  • 1はビジネス価値の反映、2はソフトウェア設計やDevOpsによるデリバリーの最大化、と違う領域への発達
• モードは達成したい目標、プロジェクトのサイズに応じて適したレベルがある

断片だったのが繋がった感じあって楽しかった。AFMの価値も感じた。そのうち改めて本読んでみよう。

「デザイン」って言うな

仕事でWebアプリケーションの画面を考えている際に、良いプロダクトにするには多様な視点からのアプローチが必要だと感じた。

けど重要な割に仕事に名前付いてなくね？毎回この辺で混乱してね？って思ったので考えつつ書き散らす。整合性も論理の飛躍もとりあえず気にせず適当に書いてみる

専門性、チームのことを考える

とりあえずこの3つはプロダクトのUIを考える際の要素として挙げていいと思う

1. ビジュアルデザイン/グラフィックデザイン: レイアウトやカラーの整備。統一感を失わない全体設定。UXやブランディングも考慮してのビジュアル面を作っていく
   • 求められるスキル: デザイナーの専門性
2. 情報設計: IA（情報アーキテクチャ）を考慮したブロック間の関係整理、プロット方法の決定、ページ役割の設計
   • 求められるスキル: ディレクター的な思考力
3. 構造設計: オブジェクトのステータス、可変部分について設計する。実装ツールや技術的制約を意識する
   • 求められるスキル: エンジニアリングの一歩手前の要素。工業デザインに近い領域かも

UI Stackなんかは領域を跨いだ整理するフレームワーク。

note.com

今回想像してるのはもう少し詳細な部分まで踏み込む。ソフトウェア側の作りとビジュアルのいいバランスを早期から探りたい。例えば - データサイズや時間に応じて色や面積を変える場合、階段状の閾値とパターンの対応表を考えるよりも計算式で滑らかに算出する方がシンプルに作れる - WebだとCSSで実現しやすいかの判断とビジュアル上のこだわりの強さのバランスを判断し、重要な要素を作り込むリソースを確保する - データの階層とページやコンポーネントのネスト関係を意識する。揃えた方がプロダクトの完成が早く、拡張性も高く維持できる - UI/UXを無視しろという話ではない。ビジュアル、ディレクション領域の人がデータを意識する方がより良いUI/UXを作れる説

同じ過ちを繰り返す

複数の専門性が絡み合うはずなのにカバーし合えない状況をたくさん経験してきた気がする。

専門性の間にあるものって往々にして難しいけど、それにしてもプロダクトの画面設計ってずっと同じポイントで似たような過ちを繰り返してるような気持ちになった

見えにくくしてるのは誰

UI設計のオーナーシップが過度にレイアウトデザイン担当に集中してる感覚がある。他の専門性を持ち寄って多角的に判断すべき場面がもっと存在してたのかもしれない。

こういうのって思考が言葉に引っ張られてしまうケースがある。そこを考察、整理してみると

• 日本の現場では「デザイン」はビジュアル領域の専門家と強く結び付いてる
• 英語の「Design」はUIだけでなく、ソフトウェアアーキテクチャやデータ構造の決定など、広く「設計」を指す概念
• なので日本語でもプロダクトデザイン（包括的な上位概念） ⊃ ビジュアルデザイン（その一要素）という分解はできる
• しかし「デザイン」「デザイナー」という言葉を使うことで、レイヤーを区別せずに議論してしまう
• 結果として何でも（ビジュアル）デザイナーの領域と思い込んでしまう。その専門性の範囲内だけで議論が止まる

という状況が起きてる気がする。自分の言葉が粗いことでミスコミュニケーションやオーナーシップの空白を作っている。

だから

どのレイヤーについて議論しているのかを意識しながらプロダクトの設計を進めると失敗を繰り返すのを防げるかも。 その意識付けのために「デザイン」って言わずに何を設計しているのかを明確に言葉にする習慣あると便利そう。

すべてをカバーできる人材はそういない。なのでチームを作り、各々の専門分野を活かし、うまくコラボレーションしてくのが大事なんだろうな

アメリカをはじめ他国のプロダクト開発組織では、プロダクトデザインでの役割分担や用語の使い分けをどう整理しているのか。調べてみると良いヒントが得られるかもしれない。そのうちやるかも

Disclaimer

自分はソフトウェア設計、プログラミング、プロダクトマネジメントが専門領域なので、その視点から語ってます。他の専門領域にケンカを売る意図は全くなく、むしろ雑に任せすぎてきたのではないかという反省がある。