この記事は、最近の私の考えを綴ったものです。まだまだ土台が固まった思いや考えではなく、思っていたことを一度文章にしました。
情報に押しつぶされそうになる時がある自分と同じような不安を持つ方へ向けて。
「なぜ」と言う問いかけの個人的な使い方
物事に関して「なぜ」と思うことは大事だなと思っています。エンジニアリングでもそういう文脈はありますし、何かものを作る上でも、そういう文脈はあると思います。 「なぜそれが必要なのか」「なぜそう書かなきゃいけないのか」と考えることは、間違った判断や最善ではない判断をし、物事の方向性がブレてしまうことを防いでくれる…かもしれません。
もちろん、毎回それが最適なわけではありません。現実の仕事や開発が、最初からきれいに構造化されているわけでもないですし、きれいに構造化しづらい時もあります。それでも、なぜと思ったときに、どこにその答えを求めるかを考えることは大切です。
ここでいう「なぜ」を重ねる思考は、トヨタ生産方式で知られる「5回のなぜ（5 Whys）」にも少し近いです。「5回のなぜ」は、1つの事象に対して「なぜ」を繰り返し、表面に見えている原因より奥にある真因を探る方法です。トヨタ財団の講座レポートでは、具体的な課題をもとに「なぜ」と「だから」を往復する考え方も紹介されています。
ただ、自分の場合は、このフレームワークをそのまま踏襲しているわけではありません。目的や背景を確認するために上流へ戻り、実装や影響を見るために下流へ降りる、そんな使い方をしています。
例えば、「なぜこのサイトを直さなきゃいけないのか」と考えてみます。上流に行くと、「誰がどんな目的でお願いしているんだっけ」「直してその目的は達成されるのだろうか」「より最善な方法はないか」などという疑問が出てきます。さらに上流へ行くと「そもそもなぜこのサイトがあるんだっけ」「本当に必要なんだっけ」という問いにつながってきます。
上流へ行くと、こういう背景や歴史があって、このサイトを求められたことが見えてきます。その時点では、サイトを作って運営すること以外にもいくつか選択肢があったけれど、その中でサイトを選んで作っていた。例えばそういう経緯です。そうなれば、今回はこういう目的があって、ここをこう直したらこういう結果が出るかもしれない。そういう仮説をもとに、ここを修正します。それどころか大元の目的がわかれば、一回の修正だけでなく、自分から「〇〇のような作業もした方がいいのでは？」のようなことも提案できるかもしれません。
一方で、下流に行くことも必要です。実際にどの画面をどう変えるのか、利用者の行動はどう変わるのか、コードや運用にどんな影響があるのかを見ていきます。上流の目的だけでも、下流の実装だけでも足りません。上流と下流を行き来することで、物事をフローやツリーのような構造として考えやすくなります。
ある意味「具体」と「抽象」の行き来とも言えるかもしれません。
自分も、これをまだ完全に使いこなせているとは言えないと感じます。「なぜ」と重ねて考えれば、必ずきれいに答えが出るわけでもありません。それでも、物事を分解し構造的にする見方が大事だということは、年々強く感じるようになっています。
Figma MCPをきっかけに、生産性について考える
ここで急に実務で取り組んでいる話をします。言った側から軸がぶれている話題の転換な気はしますが、お手柔らかに。 また、Figmaを今回は例に出していますが、あくまで一例です。
最近、業務でFigma MCPに触れる機会がありました。もともとFigmaには触れていましたが、Figma MCPを使うことで、デザインと実装の間にある作業をどう変えられるかを考えるようになりました。というか自分の中では前から考えているテーマの一つではあります。
Figma MCP Figmaのデザイン情報をAIエージェントに渡したり、AIエージェントからFigmaへ内容を書き戻したりする、いわゆるツールの接続点や入力点のようなものです。公式ドキュメント
これを使って、デザインをスムーズに作れないか、デザインから実装へ起こせないかと考えました。一度作ったデザインをうまく再利用できないかとも考えました。AIを絡めて、制作や開発の生産性をどう上げていくか。そういう話です。
ただ、そうなったときに「なぜ生産性を上げなきゃいけないんだっけ」という問題も出てきます。そもそも生産性を上げるべきなのか、「生産性って何だっけ」という疑問もあります。
ビジネスにおいて生産性を上げること自体は、おそらく正しい気がします。同じ時間にどれくらいアウトカムを生み出せるか、そしてお金を稼げるか、というところに生産性は関係していると思います。
ただ、成果を上げるために、必ずしも量をめちゃくちゃ生み出さなきゃいけないわけでもありません。AIに素早く大量のものを作らせることを中心にしたいわけではありません。実際は、人間が関わらなくていいところをうまく自動化して、人間がよりクリエイティブな作業に集中できる状態をつくることが、今回の目的、落とし所としては一番適切なのかなと思っています。
ここで、アジャイルソフトウェア開発宣言にある「プロセスやツールよりも個人と対話を」という言葉を思い出します。プロセスやツールに価値がないという話ではなく、それ以上に人や対話を重視するという整理です。
AIや新しいツールも、それ自体を目的にするものではありません。今回でいえば、Figma MCPを使うことより、人間が判断やクリエイティブな作業に集中できることを優先したいです。その目的に合うかを、小さく試しながら確かめる手段として考えるのが、自分には合っていそうです。
一方で、Xをよく見ていると、Figmaがもう不要なのではないか、という意見も目にします。Figmaが不要とまでは言っていなくても、AI用のデザインシステムやFigma以外のツールを使おう、という話です。Pencilのようなツールも出てきています。それらに伴い、これまでのツールが相対的にいらなくなる、という見方が出てきているわけです。
また、そもそもAIにクリエイティブなことをさせるのは無理、もしくは得意ではないから、させるべきではない。そんなに自動化を急ぐべきではない。人間が介在することはやめちゃいけない。そういう意見もあります。
これももちろんそうだなと思います。物事にこだわりを持ってやれる方ほど、そう思うだろうとも思いますし、私もここはこうするべきと思うこともあります。こういう考えや意見は、アップデートこそすれ、捨ててはいけないと感じます。
このように、いろんな軸で、いろんな視点で、いろんな意見があります。いろいろ見ているうちに、自分が何をすべきなのか、どれが正しいのか、不安に駆られるときがあります。なぜと思えば思うほど、これが極まっていく気がして、結構迷子になるときもあります。
迷ったら、原点と仮説に戻る
そうなったときに、やっぱり上流に戻る、原点に戻るということは、以前より重要になってきています。ただ戻るだけではなく、戻りやすくする仕組みを作っておくことや、最初に自分の中で原点を決めておくことも重要です。その原点自体を、あとから変更しやすくしておくことも大事だと思っています。
自分の中では、その戻る場所を「目的・背景・価値・仮説」の4つとして捉えています。
今回の例でいえば、原点は「Figma MCPを使うこと」ではありません。人間が関わらなくていいところをうまく自動化して、人間がよりクリエイティブな作業に集中できる状態をつくることです。
整理すると、何かをするときに仮説思考はもちろん大事です。ただ、その仮説へのアクセスのしやすさと、仮説の変更の容易性もすごく重要だと思っています。
なぜそれを始めたのか、何を変えたいのか、いまどんな仮説を置いているのかを、短くても残しておく。仮説が変わったら、変わった理由も残しておく。そうすれば、新しい意見やツールが出てきたときにも、いったん原点へ戻って考え直せます。
仮説は、正しさを証明するためのものではなく、次の行動を決めるための足場です。足場なら、必要に応じて組み替えていい。目的が変わっていないなら、手段や仮説だけを変えればいい。目的そのものが違っていたなら、さらに上流へ戻ればいいと思っています。
自分もまだ、常に物事を分解して構造化して見れているわけではありません。現実はとっても複雑で、その上もちろん最初から目的や仮説がきれいに整理されていることも少ないです。それでも、物事をフローやツリーとして捉え、原点と仮説をいつでも見える状態にしておくことは、これからますます大切になると感じています。
新しいツールや意見に触れて迷ったときは、まず「なぜこれを始めたのか」に戻る。そこから、いま必要な手段を選び直す。迷ったら基本に立ち返るというのは、思考を止めることではなく、もう一度考え直すための場所を持っておくことなのだと思います。