予約システム作った会社のこの記事読んだ。 goodf.co.jp/blog/message/4… 要約すると「我々は協会から指定された仕様通り作った。我々には非がない。むしろよく頑張った」。 ここに日本のデジタルモノづくりのダメが集約されている気がする。 お金もらう立場なので、下請けマインドが強過ぎて、本質的に良いものをつくる体制になっていない。協会はシステム屋に、システム屋は協会に罪をなすりつけて、結局、どちらも反省することなく、「我々はよく頑張った」で誤魔化してしまう。 受注側だからと、与えられた仕様の中でのベストでokにするのではなく、「この仕様ではこういう問題が発生する。もっとここに予算をかけてサーバー増強を」とか、そこまで説得できて初めてプロの仕事だと思う。 発注側も、ベストな体験提供できるように発注先の知見を取り込んで仕様を改善するくらいの姿勢でいないと。 でも、日本の大企業、大組織のそこら中にあるダメパターン。 2007年に書いた「iPhoneショック」では、日本の携帯メーカーの現場は「いい提案しても上司に潰される」、経営層は「下からろくな提案上がってこない、でも、そもそも携帯の仕様はキャリアが決めるから我々には工夫の余地がない」と言っていて、携帯キャリアの重役に話聞くと「我々はメーカーからの面白い提案待っているが、出てこないから我々が仕様を決めている」というすれ違いぶり。 このすれ違いをなくすには、これらのレイヤーに横串を刺す、ユーザー体験のデザイナーを入れて、そこでの議論をベースに開発することだと思うが、日本の大きな組織の意思決定者たちは音痴で自分の過去の経験にないから、そこごわかってない気がしている。
2025-10-12 12:48:29やはり、すべての根本原因はITシステムで大事なのは「テクノロジー」という誤解があまりにも根強く広まっていること。 テクノロジーは現時点での一時的な最適解/とりあえず形にする方法に過ぎない。そもそも何を大事にするのかを考え、状況変化にも対応できるようにしているのは「デザイン」の視点で、これ無しのITシステムは一時凌ぎのやっつけ仕事でしかない。
2025-10-12 12:59:38確かに使いにくかった
@nobi なんか1日券、平日券、夜間券があって〜、抽選が〜、着券処理が〜、って複雑そうに書いてますけど、ちゃんと設計すれば、複雑な話ではないと思います
少なくとも3日前予約は不具合だし、Getメソッドでの日付渡しはありえない設計だと思います
しかも瑕疵担保期間があるはずなのに対応が遅いと思います。
@SWMGR_Crew @nobi 日付をGETだろうがPOSTで渡そうが別に重要じゃない、バリデーションがすごく残念なだけ
2025-10-12 22:16:07大阪万博の予約システムのUI/UXは確かに相当良くなかった印象。
言いたいことはめっちゃわかる。
でも、やっぱ発注側の方にもかなりの課題があったと思うなー。
受託側が問題提起しても発注側がそれ無視して無理矢理作らせた所もありそうな匂いはプンプンする x.com/nobi/status/19…
発注側の問題では?
@nobi 実際に作る側をやるとわかるけど、この仕様だとこういう問題起きるからこうしてくださいって言っても聞いてくれないことが多い。 何度提案しても聞いてくれないの繰り返すと、提案するだけ時間の無駄にしか思えなくなる。 結果として、与えられた仕様を満たすことに注力するのが一番効率良くなる。
2025-10-13 01:06:31@nobi そうは思わない。発注側に具体的なイメージがないから、キメラみたいな成果物が出来上がるのでは。似たような事例ではデザインに対する無理解もありますよね。丸投げするのかマイクロマネジメントするのか、まずその時点で腰が据わってないのが根本にあると思います。
2025-10-12 18:56:16@nobi 大枠だけ決めて、仕様策定から任せてくれるならいいけど、実際は半端な仕様投げてくれた上に、その通りのものができるかどうかが優先で余計な提案は却下、まして提案実現に金がかかるとか納期が延びるとか問答無用で却下。 到底良いものを二人三脚でなんて状況じゃないと思うけどな。
2025-10-12 21:54:59@nobi あと、ここがそうかはわからないけど、中抜きだけして下請けに投げる、を何段も重ねて、最終的に実務担当する会社には発注金額の1/10以下しか渡らないとかあるから、いい加減政府は下請け段数に関する規制をネズミ講並みに厳しく規制すべきだと思う。 儲からないなら技術者目指す人間も減るんだし。
2025-10-12 23:22:59これは逆で、日本は大抵発注者側に当事者意識がないんよ。 受託開発という特性上、要件は発注者が責任を持つのが基本。(IPAもそう言ってる) 自分たちで要件定義ができないなら、ちゃんと金払って要件定義の支援を依頼するんだよ。 x.com/nobi/status/19…
2025-10-12 16:41:31@Eseshinpu そもそも自分たちがどういう物が欲しいのかわかってないのにそのまま発注するのがよくわからないですよね。
2025-10-13 01:17:18@aoimidori1 自分たちが使う(お客様に使わせる)システムなのに、丸投げできる神経が信じられないんですよね。 安くても数百万円の買い物なのに。
2025-10-13 01:25:30要件定義がしっかりしていれば…
これね。最近はそこそこ変わってきたけど、要求定義・要件定義もできない状態からベンダーに丸投げして「何故察してくれないのか」レベルのことを後出しでいいまくるユーザー企業は非常に多い。 x.com/Eseshinpu/stat…
2025-10-12 18:30:15万博の予約システム見る限り「自分たちが要件定義できてるかもわかってない」レベルの発注者だったと思われるので要件定義の支援が必要だという発想にすら至ってなさそう x.com/eseshinpu/stat…
2025-10-13 00:16:05これはそう。受注側がそうやって助けすぎると、そこに金がかかることが認識できない。要件定義はタダじゃないし、ちゃんとしたUI・UXは金がかかるのだ。とは言ってもあまりにクソ仕様を受注しちゃうと作るのも大変クソなプロジェクトになるから、多少のFBはするが… x.com/Eseshinpu/stat…
2025-10-13 10:52:45同意です。お金払ってくれるのならSIerはちゃんと要件定義しますよ。基本設計書通りにシステム作って文句言われる理由が分からない。仕様書通りに動作させるのがプロの仕事。顧客の頭の中にある要求を可視化するのは全く別の仕事。それを含めて請け負うのはSIerには自殺行為。会社とSEが潰れる。 x.com/Eseshinpu/stat…
2025-10-13 08:34:31これはホントそう お客さんはやりたいこと全部盛り込もうとして、初見が操作できるかまで考えてない 開発依頼する前にUIのプロを加えて導線と機能検証しっかりすべきなんだけど、発注者があるべき姿を開発前に想定できないから有名なブランコ図になりがち x.com/Eseshinpu/stat…
2025-10-13 09:57:32双方向のコミュニケーションが必要だった
この投稿への反応見てると、発注側が要件定義をちゃんとできてないことが問題というSE的な人の意見をそれなりに見かける。 発注側に問題があるのは確かにそうだと思う。 でも、問題なのは要件定義の質ではなく、そもそも要件定義でコミュニケーションしようとしていること。 少し前、ちゃんとコンピュータプログラムの設計というものをちゃんと学問として勉強した人たち(つまりシロウトではないプロ)のシステム設計屋なら大学とかで絶対に読んでいるはずのD.A. ノーマンの「誰のためのデザイン」(日本語の改訂最新版は @igaiga が翻訳 amzn.to/48Y0wZo ) その英語原書の表紙を飾るティーポットがわかりやすい。 このティーポットを要件で見ると: 要件1. 持ち手がある 要件2.注ぎ口がある 要件3.蓋がついている すべて要件通りに作られている。でも、これが使い物にならないことは誰にでもわかる。 ユーザー体験の「デザイン」を出発点にして仕様をつくり、その上で要件定義をするのが正しい順番。 ちゃんと勉強してないシステム屋はデザインこそが大事という大前提理解しておらず、そういう人たちの吹聴で政治家とかもITシステム設計がテクノロジーだけでできると誤解している。 優秀なデザイナーのいないシステム屋には発注してはならない、と思う。
2025-10-12 23:28:20
そもそも決定権を持っている年齢層が、ITを理解していないからね。そして、IT化したら、やり方も変わるっていうことを理解しないといけない。麻酔チャートのアプリ開発の時に、中堅をずっと貼り付けたら、かなり使いやすいものができたんだけれど、いかんせん、売り方がわかっていなくて、売れなくて本当に可哀想だった。
発注側に、UIの基本コンセプト「何をどのように見せたい、操作させたいか」が無いから、受注側も具体的な改善や実装ができないのでは無いか、と正直思いますけどね