ハクソク

世界を動かす技術を、日本語で。

GUIは少なくとも2.5倍作成される

2025年5月31日原文(patricia.no)

概要

  • ソフトウェア開発 における「工場」や「パイプとフィルタ」などの 比喩 の限界
  • ソフトウェアアーキテクチャ における代表的なパターンの解説
  • TPS（トヨタ生産方式） や CI/CD など、現実世界とソフトウェアの構造の類似点
  • 比喩の不完全さ と「ソフトウェア独自の理解」の必要性
  • ソフトウェア開発者は「工場の作業者」ではなく「工場設計者」であるという 根本的な違い

ソフトウェア開発における比喩とその限界

  • Robert Smallshire の指摘：「工場」「庭」「農場」などの比喩から脱却し、 ソフトウェアをソフトウェアとして捉える 必要性
  • Peter Sommerlad の質問：「工場」という比喩と Pipes and Filters アーキテクチャパターンの関係性
  • ソフトウェア開発現場で パターン （設計パターン）が多用される現状
    • 心理学でいう「スキーマ」と類似した概念
  • Pipes and Filters は、出力が次の入力となる「直列処理」のパターン
    • Unix/Linuxコマンドラインや関数型プログラミングで頻繁に見られる構造
  • ただし、 意味的には完全に一致しない 場合も多い
    • 例：暗号化テキスト→復号→整形→メール送信

複雑なデータフロー：Pads, Sources and Sinks／Signals and Slots

  • 入力・出力が複数あるノード によるネットワーク型アーキテクチャ
    • 入力Pad（Slot）、出力Pad（Signal）という概念
    • 入力がないノード＝Source、出力がないノード＝Sink
  • ffmpeg などのオープンソースプロジェクトで見られる構造
  • ソフトウェア開発全体で 非常に一般的なパターン として存在

TPS（トヨタ生産方式）やTriple Bufferingとの類似

  • Triple Buffering ：描画バッファを3つ持ち、遅延やチラつきを抑える手法
    • ソフトウェアとハードウェアが 独立して動作 できる仕組み
    • 「無駄」＝遅れて表示されないフレーム
  • TPSやLean の理解がプログラマーにとって容易なのは、「プログラム」として捉えられるため

「工場」比喩の限界とDevOps／CI/CD

  • CI/CDパイプライン は「工場」的なアーキテクチャの実例
    • コード→ビルド→テスト→デプロイの一連の自動処理
    • 品質が担保できない場合は「ライン停止」（例：テスト失敗）
  • DevOps では人手を極力排除し、自動化・監査性を重視
    • 本番稼働後もメトリクスを収集し、品質向上につなげる

ソフトウェア開発者は「工場作業者」ではなく「工場設計者」

  • 比喩は本質を捉えきれない ため、Smallshireの主張は妥当
  • Lean Software Development も万能ではなく、現場の実態とは異なる
  • 開発者自身も「こうありたい」と思いながらも、現実は複雑
    • 問題を分割→部品化→組み立て→完成という理想像
  • 本質的な違い ：私たちは「工場で働く人」ではなく、「工場そのものを設計する人」
  • ソフトウェア開発の実態を理解するための 新たなメンタルモデル の模索が必要

ソフトウェア開発プロセスの本質的な理解に向けて

  • 比喩やアナロジー は説明や共通理解の助けにはなるが、 限界がある
  • ソフトウェア開発は 設計・創造活動 であり、単純な「生産ライン」とは異質
  • 開発現場の複雑性 を正しく捉えるためには、 ソフトウェア独自の枠組み や言語が必要
  • 現場の開発者自身も模索中 であり、より良い理解やモデルの確立が今後の課題
  • ソフトウェア開発の本質 を捉える新しいアプローチや議論の必要性

Hackerたちの意見

テキストをざっと読んだだけだけど、特にGUIに関しては最後のリストが的を射てるね。そういうわけで、全てのソフトウェアは（その分野にあまり詳しくない場合）、良い製品を作るために3回書かれるべきだと思うんだ。1. 最小限のプロトタイプ。何かをサクッと作ってみて、実現可能か確認する。手抜きして後で必要になる機能を省いたりする。2. 最初の素朴な実装。プロトタイプを基に作り上げるけど、実際には役立つものにするためにそんなに欠けてないと思い込んでしまう。悪いデザインの決定をして手を抜くことになる。ドメインの複雑さを完全に理解するチャンスがないから、時間をかければかけるほど、間違った方向に進んでしまったことが見えてきて、フラストレーションが溜まる。3. 自分が本当に求めているものが明確になったら、全部捨てて、エレガントに全体を再構築する。パフォーマンスにも焦点を当てる。1と3はだいたい楽しいけど、2はすぐに嫌になる。主な問題は、仕事の文脈ではほとんどの場合、2から3に移行することが許されないこと。外部の人には2が十分良さそうに見えるから、3にお金を払いたがらないんだよね。

└

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

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

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

└

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

└

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

└

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

└

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

これも関連してるね [1]: > 「この第二のシステムは、人間が設計する中で最も危険なシステムだ。彼が第三、以降のものを作るとき、彼の過去の経験がそのようなシステムの一般的な特性を確認し、その違いが彼の経験の中で特有で一般化できない部分を特定する。」 [1] https://wiki.c2.com/?SecondSystemEffect

この部分は天才的だね: > 私は何度もGUIを作ってきたけど、最良のシナリオはこんな感じだ。 > 1. デザインができて、みんながそれを気に入る。詳細な図面も作成される。 > 2. 開発者に「作れ」と言われる。 > 3. 開発者は仕様通りに作る。 > 4. みんながそれを見て、全員が嫌がる。 > 5. 会議がたくさん。ストレスがすごい。これはひどい！どうする？ > 6. 新しいデザインが作られる。すごく良くなった！詳細な図面も作成される。 > 7. 開発者に「作れ」と言われる。 > 8. 開発者は仕様通りに作る。 > 9. みんながそれを見て、誰も好きじゃない。 > 10. 会議がたくさん。ストレスがすごい。これはひどい！どうする？ > 11. 誰かが多くの会議の中で、基本的に小さな変更、何かを移動したり、色を変えたり、テキストを変えたりすることを提案する。 > 12. 開発者は仕様通りに作る。 > 13. 誰も満足していない。でも、誰も嫌ってはいない。 > 14. 開発者はイライラしている。私も似たような経験がある。GUIの本当の問題は、技術者が（主に）非技術者のために何かを作っていることだと思う。例えば、購買部門や経理部門が使う内部アプリのGUIを開発することを想像してみて。ほとんどの内部顧客は非技術者だから、彼らは開発者のように考えないんだ。それに、多くの開発者は非技術ユーザーとのコミュニケーションスキルがひどいから、期待のギャップが大きくなりがち。私が見た中で最高の体験は、内部顧客チームが半技術的な新卒を雇うこと。彼らが新しいアプリの主なテストユーザーになる。できるだけ新しいアプリだけを使って仕事をさせる。彼らは開発者にたくさんの即時のフィードバックを与えることができる。そうやって徐々に合理的なものに進化させていける。中間管理職をイライラさせる秘密は、計画を立てず、特に内部の聴衆がいる場合は有機的に構築させること。もう一つ気づいたことは、GUIのデザインと実装が得意な人がいるってこと。こういう人を見分ける方法はわからないけど、「見ればわかる」って感じ。

└

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

└

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

Hacker Newsで議論の続きを見る