付け加えると、なぜプロダクトマネージャーが#3にお金を払いたがらないかというと、過去の試みがほとんどコストやスケジュールのオーバーランにつながっているからだね。未完の結果が多いのも事実。そう思わない人は、自分のお金で証明してみてほしい。これがスタートアップってやつで、ほぼ全てのスタートアップは失敗する、つまり重要なリソースが尽きてしまうんだ！じゃあ、賢いプロダクトマネージャーはどうすればいいのか？簡単な答えはないけど、業界の平均的な結果を見ればわかるよ。努力が足りないわけじゃない。個人的には、ソフトウェアの提供は解決された問題じゃないと思う。でも、ソフトウェア提供の専門家として「ソフトウェアの提供方法がわからない」と言って回るのは、本当にお金を稼ぐのが難しい。

4. さて、あなたが本当に求めているものが明確になったら、全部捨てて、より良くエレガントでパフォーマンスの高い方法で全体を再構築する。

「捨てるつもりで作れ。どうせ捨てることになるから。」- フレッド・ブルックス、『神話のマン・マンス』。私が生まれる数十年前に書かれたソフトウェア工学の本で、大学で25周年記念版を課題に出されたんだけど、数年ごとに再読しては新しい問題にその教訓を適用する方法を見つけてる。

すごく同意。2はテストスイートを構築することに関するもので、これができれば3は楽勝になる。私は多くの場所で、SITチームが手動でエンドツーエンドテストを行うところで働いたことがあるけど、彼らは一度合格したテストを再実行するのが大嫌いなんだ。こういう人たちは3のアイデアを嫌って、PMにかかるコストを過大評価して、やらなくて済むようにする。

個人的には、このリーン手法が自分には合わないって感じてるんだ。自分の中でうまくいくマントラがあって、それは「全部画面に出せ」ってこと。あらゆる機能、あらゆるバリエーション、可能な限りの設定、未来の状態も含めてね。見た目や感じは気にせず、全部そこに置いちゃえ。できるだけ多くを、できるだけ早く作り出して、どうせ捨てることになるって分かってるから。その後、削ぎ落としていくんだ。組み合わせたり、削ったり、グループ化したり、再編成したり、隠したり、削除したり、追加したり。途中で、本当に目指すべきものが見えてくるんだ。で、だいたい最初に作ろうとしてたものとは全然違う方向に行くんだよね。それが分かったら、ステップ3はほぼそのままになると思う。これはリーン開発の批判じゃなくて、10年リーンでやろうとした結果、自分の脳みそには合わないってことを受け入れたって感じ。

PMの視点からすると、2から3に移行するのはあまり意味がないよね。その開発者たちはこのアプリに何週間も何ヶ月もかけてきたのに、今さら全部捨てるって？それってお金を窓から投げ捨てるようなもんだよ。新しいアプリが前と同じように動かないリスクや、締切に間に合わないリスクもあるし。安全策としては、（2）を繰り返すのがいいと思う。

3回作るってアイデアには完全に同意だな。年を取るにつれて、2回で済ませることが多くなってきたけど、それは自分がコーディングが上手くなってると思いたいから。だから、ステップ2はそんなに急がなくてもいいかなって。3回のイテレーションをこう考えてるんだ：1) 何をしているか分からない。このイテレーションは問題の領域を理解することがメイン。2) 何をしているかは分かってるけど、どうやってやるかは分からない。このイテレーションはプログラムの設計方法を考えること。3) 何をしているか、どうやってやるかが分かった。だから、あとは作るだけ。

俺はこれを「プログラマーがデザインしたもの」って呼んでる。これがあまりにも一般的だから、シリコンバレーのテレビ番組でもストーリーの一部として使われてた。初期のインターネット時代にコンサルタントとして働いてた時も、「顧客は自分が何を欲しいか分からない、何が欲しくないかを見るまで」ってよく言ってた。人々はウェブのGUIに慣れていなかったし、今見られるような共通のパターンもなかったから、半分動くバージョンができるまでフィードバックをもらえなかったんだ。だから、早めのフィードバックが必要だったんだよね。今でもそれは当てはまるけど、使用パターンよりも顧客が伝え忘れた要件に関係してることが多い。

問題は、ステップ2が間違ってるってこと。ステップ1はデザインを作ること、ステップ2はそれをテストすること。紙のプロトタイプを作って、顧客にそれを使ってもらうんだ。もし気合い入れるなら、Figmaで綺麗なプロトタイプを作ってもいい。いいデザイナーと協力的な顧客がいれば、ホワイトボードプロトタイプでステップ1と2を組み合わせることもできる。顧客に一般的なタスクは何か聞いて、ホワイトボードにインターフェースを描いて、どこをクリックしたり、どうやってやり取りするかを聞くんだ。それから次のUI状態を描いていく。そうやって何回か繰り返したら、実際のコードを書き始められるよ。実際のソフトウェアを試す段階でも、いくつかの反復が必要だけど、ずっと良いスタート地点になるはず。

UXは難しい。通常起こるのは、- UXが苦手な開発者がソフトウェアを書いて、デザイン文書に十分に指定されていないすべてのユースケースで即興で対応する - UXが苦手なエンドユーザーがフィードバックをくれるけど、自分のユースケースに合ったものが正しいかどうかは分かる - UXが苦手なマネージャーや仕様書作成者がエンドユーザーの希望を開発者に伝えようとする その結果、無価値な仕様書ができあがって、ゴミが入ればゴミが出る。時々、星がうまく揃うと、チームの中に実際にUXが得意な人が現れることがあるって聞いたけど、私のキャリアではそんなユニコーンを見たことがない。そしてその場合でも、UXを理解していないエンドユーザー、つまりプロジェクトのためにお金を払う人が、すごくすごくペリウィンクルブルーのボタンを欲しがることがあるから、ほとんどすべてのケースでGUIは無数の書き直しや調整を経ることになる。

これらのステップは、ユーザーの作業状況や技術を理解していないプロジェクトマネージャーによってデザインされていると思う。> 顧客チームが半技術的な新卒を雇う これは、両方のキャンプに片足ずつ入れている人だね。これが最適な解決策で、一足の人よりも優れている。残念ながら、多くの組織は二足の人を好まないみたいで、単一のボックスに入れたがるんだよね。

これは部分的な解決策だと思うけど、その翻訳者やテスターの役割を「新卒」に任せるのは問題だね。理想的には、今のプロダクトマネージャーの役割そのものだと思う。顧客やクライアントの期待を管理しつつ、技術的な概念を適切に伝えたり、初期のタスク分解をコミュニケーションしたり、開発者のために調整役を務めたりする人だよね。つまり、条件付きのノーを出す役割。これは非常に重要だけど、私の意見ではあまり評価されていない。ビジネスやクライアント側はそれが開発者の仕事だと思っているし、開発者は自分たちがただの管理職だと思っているけど、実際にはプロダクトマネージャーがディフェンスラインにもなり、クォーターバックとしてランニングバックを支えて、コーチの戦略を勝利に変える役割を果たすことができるんだよね。観客がブーイングや失望するのではなく、応援してくれるように。

開発者が一番イライラするのは、要件が変わることだね。開発者がすべてをゼロからやり直す自由がない限り。

このプロセスには、ほとんど欠けている存在がいると思う。デザイナーと開発者はそれぞれのバブルやサイロに閉じ込められていて、ユーザーの視点で考えられない。デザイン、UX、コードを理解して、それを一つのまとまりのあるビジョンにまとめられる人は非常に稀だよ。私の経験では、最初からUXが正しければ、あとのことはずっと楽になる。UXは、どのように設計し、プログラムするかを決定する基盤なんだ。

GUIの本当の問題は、技術者が主に非技術者のために何かを作っていることだと思う。愚痴を言うパワーユーザーとしては、逆の問題があると思う。「共通の底辺」ユーザーがインターフェース開発を過度に単純化させてる。私たちは良いソフトウェアを持っているけど、それがGUIのニュー・スピークに翻訳され続けている。お願いだから、プログラムを単一の緑の[GO!]ボタンに精神的に縮小しないで！KDE 3.5 > 4+、GNOME 2 > 3+。オプション削除の長い習慣を持つMozilla（GNOMEプロジェクトに匹敵する）。もし今日のインターフェースデザイナーが60年前にコントロールを握っていたら、ユニックスのパラダイムは決して生まれなかっただろう（「複雑すぎる」って言われてたはず）。この分野には少しエリート主義が必要だと思う。難しいことは難しいままで、すべてのソフトウェアが難しいことを「簡単」に、単一の[GO!]ボタンに変える必要はない。

再設計のたびに多くのUIが悪化しているのは間違いない。 - Windows GUIは、Windows 7（あるいはXP）からリリースごとに悪化してる。 - Outlookは、良いから普通、そして最終的にはうざいに変わって、ついには個人用クライアントとして置き換えた。これらは私が挙げられる唯一の例ではないけど、最も目立つものだと思う。主な問題は、技術スタッフとUXデザイナーの両方が「新しい」や「ファンシー」なものを作ろうとしていることだと思うが、ほとんどの場合、使いやすさとは真逆の方向に行ってしまっている。例えば、Aeroはファンシーだったけど、アクティブウィンドウが一つのシグナルカラーのヘッダーバーを持っていて、他のウィンドウは抑えられていたのがなくなった。今はすべてのウィンドウがカラフルで、同時に私に叫んでいる。方向性が失われてしまった。そしてその後、UIはさらに「ファンシー」になっていった。ステップ13（「誰も幸せじゃないけど、誰も嫌ってはいない」）は、みんなが戦うのに疲れてしまったときの高原状態で、妥協であって、GUIが受け入れられる状態に達したわけではない。もはや開発者やUXデザイナーが誇れるほどファンシーではないけど、同時にユーザーにとってはまだうざいほど悪い。

だから、何度も完全にやり直す必要があるのは明らかなんだ。でも、管理層にはあまり浸透してないね。確かに、彼らはアジャイルのバズワードを使ってるけど、機能A、B、Cを計画に入れたり、「Bはいつ終わるの？」とか「終わった？」なんて質問をする。いや、私たちは14個のバグをサービスとして管理してるだけだから。「Bを終わらせる」ってよりは、15個のバグを管理することに移行するだけだよ。

私も同じような経験をしたことがあるよ。人間の脳って、模擬画面のレイアウトを観察して、実際にどれだけ機能するかを理解するのがすごく苦手なんだよね。これが複数の機能を持つアプリ全体に当てはまると、問題は指数的に増えていく。経験があればスピードアップできるけど、迅速なフィードバックループを使った反復がベストプラクティスだと思う。デザインって、ループの始まりをやることじゃなくて、全体のループをやることなんだよね。繰り返し。

外側からの開発もここでは役立つよね。

私もこれが進むべき道だと思うし、理論的な見解とも一致してる。これが難しい理由の一つは、デザインと開発の間で反復をサポートする（デザイン）ツールが不足しているからだと思う。現代のツールはデザインから開発への移行を楽にしてくれるけど、まだまだ一方通行なんだよね。最近のトレンドで、データからではなくコードでUIを作るようになって、さらに悪化している気がする。これには良い地元の理由があるけど、ますますウォーターフォール的な開発プロセスに押しやられているように思う（デザインがきれいなモックアップを作って、壁越しに投げる感じ）。

高品質なUIについて聞けるのがすごく楽しみだよ。今まで出会ったことがないから。

UIのための最良の機能仕様は、ビジネスの人たちが自分たちでExcelで作ったものから来てるよ。最低でも、レイアウトやどの画面にどの情報を表示するべきかのアイデアは持ってる。これによって、スタイリングではなく、コア情報に集中できるんだ。ウェブ上でGUIを作ると、UI要素のスタイリングには無限の方法があって、実際のインタラクションよりもそっちに注意が向いちゃうんだよね。

GUIの仕事をする時は、趣味や内部プロジェクトのためが多い。私は質の高いUI/UXを非常に重視してる。ここでは「分析麻痺」になりがちで、デザインと開発を同時に進めようとするから。あなたの「タイトで迅速なイテレーションが唯一の解決策」というコメントには共感するよ。最近発見した「トリック」は、UIデザインを完全に無視して、_フォーマット_に集中することなんだ。要素を適切で使いやすい方法で配置することにフォーカスして、ビジュアル面（ウィジェットデザイン、マージン、パディング、色、アニメーションなど）は最後の最後まで取っておく。私の仮説は「良いUI」＝「良いページフォーマット」＋「美しいUI要素」なんだけど、このアプローチについてどう思う？

顧客との頻繁で繰り返しの接触が普通じゃないから、こんなに多くのインターフェースがダメになって、エンジニアたちが銃を突きつけられてもまともなものをデザインできないんだと思う（正直、そんなレベルのストレスは思慮深いデザインパターンを生まないかもしれないけど）。エンジニアはマイクロビューに次ぐマイクロビューを受けて、実世界を模倣しないテストフローを使ってそれを作り上げる。そして、みんながそれを結びつけて、ユーザーにとってはめちゃくちゃなマクロビューを作り出す。ここで定期的なシャドーセッションを持つために、基本的なスケジューラーを作ってる（これがスケールでの痛点なんだけど）んだけど、3週間ごとに自分とツールを作ってる誰かを送るだけで、フィードバックは圧倒的にポジティブで、機能を少し拡張するために取り組んでる。だから、いい結果を得たい人は、小さなスケジューラーを設定して、プロダクト、デザイン、エンジニア、マネージャー、TPMたちを実際の顧客との軽いペースで回転セッションに参加させて、より大きな共感を生み出そう。そうすれば、私たち全員がより良いソフトウェアを手に入れる可能性があるんだから。夢見ることは自由だよね。

これはInputStream/OutputStreamタイプのクラスの説明に過ぎないよ。EncryptedStreamも作れるしね。「ただの文字列（または数字）だけど、前提条件が強制されて検証されたもの」というオブジェクトがあるのも意味があると思う。特にユニコードの世界ではね。

100%同意！ホワイトスペースが大好きなデザイナーは、エンジニア（やExcelで仕事する人）向けのUIをデザインしない方がいいよ。余白やパディング、ドロップシャドウ、‘round-lg’とか見た目はいいけど、ページに数字が2つしか入らないと全然役に立たないから。

他のプロフェッショナルツールについてはわからないけど、チップデザインのためのEDAツールは、電気エンジニアとベンダーがソフトウェア開発において20年遅れているから、今の状態なんだ。

UIのほとんどは、デザインの時点で壊れてると思う。インセンティブがどう作用するのか、もうよくわからない。多くの場所で自己利益が優先されてるのは確かだ。新しい理論があって、いくつかのユーザーインターフェースは意図的にジャンクに作られていて、ユーザーが常にコルチゾールにさらされて、他のダークパターンで支配しやすくなってるんじゃないかと思ってる。AzureのUI/UXがその例としてすぐに思い浮かぶ。自分のVMが実際に動いてることを確認する頃には、請求関連で確認したい他の5つのことを忘れちゃってる。こういうものの最終的な整合性は、特にマイクロソフトのように広範な経験と人材プールを持っている場合、意図的にユーザーに敵対的なデザイン選択に見える。