日本のエンジニアが仕様書を書く時間は無駄 

アーキテクトが必要なクラスを書いて、中身をエンジニアが書いていくってのはいいですね！スピード感。真似しよう。

原因はやっぱ、プログラマの地位が日本は低いところかと。 プログラマの立場が上なら、わざわざ仕様書書く人にお伺いたてなくても、JUNさんが言われるように、どんどんコードに書いてしまった方が早い。

仕様書に最新の情報が反映されてないことがあるから、ソース見て仕様書を直すという謎の手順を踏むことが多い...

プログラミング進めるうちに生まれる「こっちの方がいいな」という方向転換が許されないなら、それがOKな他社（アメリカIT）に負けるの当たり前ですね…

仕様書はプロジェクトを整理するために描ける様になりたい

日本で下請け企業で開発してますが、元請けから丸投げされることも多く、要件定義、仕様書、設計書作成もこちらでやることが多いです。 たまに元請けが間に入りたがる場合は、顧客に説明するための説明を元請け社員に対して事前にすることになり、手間が増えます。 正直、いてくれて助かるのは顧客から怒られるときに盾になってもらえるぐらいで、中途半端な関わり方をされるぐらいならいない方が助かります...😢

おっしゃっていること、よくわかります。下請けに出すのが前提だから、仕様書が必要なんですね。それも何次もの下請けに出すから、実際にコードを書いている人は、安く働く羽目になるんですよね。

日本の上流工程って殆ど機能してない気がしますね。 日本で上流工程しかやってない人はプログラミングしたりシステム作れないけど、プログラミングできる人の方が本当は上流工程できるはずなんですよね。 更にいうと、今後chatgptみたいな自動生成ツールでプログラミング分かる人と分からない人の差が一気に拡大する気がしますね。 プログラミング分かる人は10倍速でシステムが作れるようになったりとか。 そうすると急な仕様変更にも迅速に対応できるようになるはずなんで仕様書にわざわざ書く必要なくなるんじゃないですかね。

あんなぶ厚い仕様書いるか？と思う一方で、システムを保守するときに3〜6ページの仕様書で 対応できる自信がないのは、レベルが低いからなんですかね。 特にアメリカは人の入れ替わりが激しいイメージですが、品質をどうやって保っているんでしょう。

開発体制や企業内の事情で、仕様書のレベルが変わる。 残念なのは、アメリカと日本では全く異なる点だろうと思う。 アメリカでは自分たちで作ったシステムは自分たちで面倒を見る傾向が強いので、設計書は無駄（備忘録的なドキュメンテーションはあるだろうけど）と言う考えになると思う。 日本では内製開発よりも、設計やコーディング自体がアウトソーシングされる形が多いため、設計書は納品物となり、かつその後の面倒は別の人や他社の外部業者が見ることが多くなる。 よって、設計書がしっかりしていないと困るというのが常・・・なのだ。 そういう意味で、引き継いだシステムの設計書が無くて、ソースから解析とか、訳わからずにメンテ・改修されたぐちゃぐちゃシステムを多く見てきた。 最低なのは、画面遷移がもはや矛盾してるとか、DBのキー項目が思い付きで変えられていて、ER図として書き出してみたら、支離滅裂のDB構成になってるとか、ひどいモノばかり。そういう意味では、日本のシステム開発では、ドキュメントがやはり重要だと思う。無駄ではない。 ただし、その文化ややり方はアメリカでは無駄だと門前払いされるんだろうなとは思う。 酷い企業では、開発業者へ丸投げして、金額計算もあるべき仕様をまったく伝えなかったらしく、税金の計算が、消費税計算と別項目の税項目にさらに消費税計算が入っていたとかで、めちゃくちゃだったケースがある。そのシステムはカットオーバー予定から2年遅れで稼働したが、計算がめちゃくちゃで、さらに毎日のようにデータ修正（データパッチ）を２年間くらい当て続けていた。大手さんのシステムなんだけどね。 そういう意味で、日本では設計書はやっぱ重要視されなければならないのだと、深く感じた。

言わんとすることはわかるんですが、それは大して責任をとらなくて良いサービスの場合だと思いますよ。 流行り廃りでお金稼げる分野。いらなくなれば捨てれば良いもの。 作ったもので人の生死が決まるようなものでは世界共通で仕様書チェックしてますよ。

今参画してる案件がまさに無駄な仕様書だらけで本当にうんざりする 何が一番イライラするってどんなに詳細な設計書を書いても結局１００％を埋められず、９０％とか９５％しか埋められないから最終的に結局ソースコード読んで理解することになる。まじで無駄な仕事をしているし、請負元の企業の連中はこれがITエンジニアの仕事でございみたいな面で仕事してるつもりでいることがむかつく。

Amazonのwebは仕様書1ページで足りるやろ笑😂

自社サービスなのでシーケンスとかシステムの概要図は今はFigmaで書きますね。 営業とコラボでそこで仕様作っちゃう事もある。 そしてすぐ実装です。 コメントはしますが、コード読んだほうが早い。 なのでアメリカ的なのかな？ｗ お金が法人口座にどんどん入ればそれでサクセス、そういうノリです。 結局、責任なり品質の程度を決めるのが自分や自社にあるからできるんですよ。 西村博之がプログラムはコピペで良いって言ったのは、彼がオーナーだから。 外注なら、以下に責任回避するか、そこにエネルギーのかなりの部分を投じてしまいますよね。 もちろん、発注した人や会社も、その責任回避にただならぬエネルギーを投じられたものを受け取るんだからサクセスするわけないですよね。

非常に共感します。けど郷に入るなら郷に従えで凌いでます。 ツッコむ度にじゃあなんとかしろよって言われて、私は何とか改善しています😅 ですが私の力不足で、詳細設計書の撲滅までいきませんでした。この文化は根強いです😂

日本の設計書は契約書に近いですよね。

外注先に実装を任せるケースでは仕様書が必要なことが多いですね 自社で作るようなところは社内wikiにまとめることが多いです

Excel方眼紙文化…

ほんとね。日本の開発効率が遅いと言われる原因そのままですね。アジャイル開発が入って来ても、設計に要する時間が長すぎる。そして、設計書をこねくり回してレビュー、指摘修正とか。Visioを使ったUMLはさすがに最近の開発では見なくなりましたが、いらんですね。機能一覧からの基本設計では機能の概要、画面のモック、ER図で十分開発はGO出来ると思います。無駄な仕事してますアピールの管理層がはっきり言っていらない人材ですね。問題が起きたら全部コミュニケーション不足で帰結する奴・・いらんでしょ。

確かにコードは書いてる中でやっぱりこっちの方がいいな、とかこれは実現できないなというのが分かってきますから最初からすべて決めてしまおうというところに無理がありそうですよね。。。

設計書はわかるのですが、仕様書も書かないんですね、なるほど。 テックリードをはじめ、プログラマの能力がやはり高いように感じました！

素晴らしい動画ありがとうございます！日本の大学の教育も情報処理試験も仕様書ありきで、困ったもんです😉

引継ぎが発生した場合にどうしているのか気になります。システムフローはあるとして、プログラム内部はコードから読み解く感じでしょうか？

日本はでっかい企業が言われたものを作るだけってビジネス。 自社でサービス作ってる企業とかがあんまりないイメージ。

画面や機能のspecはどのようにチームメンバーで共有するのでしょうか？ 「あれ、ここの画面の動きってどうなんだっけ？」みたいなことは発生しないのでしょうか？

そうすると今その業界にいる人はどうすればいいんだろ？ いずれにしろ、仕様書を作らないと日本の業界では回らない。 かといって優秀なプログラムが書けるとしても日の目を見ない。 というかアジャイルで開発するスキルがそもそも身につかない。 ということは、この業界でキャリアを始めるところから、アメリカ式に開発するエコシステムに所属しないといけないということでしょうか。。 いま業界にいる人たちが目の前の現場をいくら頑張ったとしても、効率の悪い日本式の現場にしか行き場がなくて、悲し過ぎる。。。

仕様書は生成するものであって、書くものじゃないんだろうなって思う。でも、それ言い始めるとコードだって、かいちゃダメ。コードも仕様も半自動的に決まってるはずなので人間が触ればむしろ質が下がるはず。そう思うと全てがバカらしくて、とっとと引退したくなる。

外注するから仕様書が分厚くなる、、、わかる・・・！

アニメ書いたときない人が、アニメ監督なるようなもんなんよなあ…

シリコンバレーのエンジニアは優秀だから仕様書を書く必要性が薄いだけではないか...

日本では何故か、プログラマーよりも、仕様書を書いたり、エンドユーザーとやり取りできるSEの方が単価が高いのは、世界的には異例、という事でしょうか？ 運用設計や、インフラ設計も含めてシステム開発ではないかと思いますが、如何でしょうか？

仕様書は、税務対策ですよー。きちんと対価払ってるってみせるのも、経営者の仕事。アメリカのIRSゆるゆるですが

プログラム以外の分野では当たり前に行われていて、そしてプログラムの分野の人間も大抵は経験していることが、いざ自分たちがその立場になると理解できないというのも滑稽だなという気はしてしまいます。

色々な場面で日本式を好まない方なのは察していましたが、仕様書については一長一短あると思います。 アメリカではないですが海外の会社と取り引きした際に、まさに途中で先方のメインの担当が辞めてしまい別の人が担当になっていました。 引き継ぎも不十分のようで、1から10までまた全てその担当へ伝えたり条件を提示したりする必要が発生して無駄の極みでした。 会社対会社の間で、過去に行ったやり取りと全く同じやりとりが発生する。 酒井さんが嫌う日本は〇〇が無駄だ! に似ていませんかね。

仕様書はプログラムの為ってよりかは、テストの為に書いてる

こうやって日本のITは３０年遅れていったんですね。

だから日本語下手だ外国人エンジニアは不利な立場になりますね。普通の人10倍以上コード書けても評価を貰えない。しかも能力をきちんと発揮できない。

賛成だ

そちらのやり方ではカスタマーサポートはどうやって仕様の共有を受けますか？

プログラムに限らず入出力仕様を決めなければ物を評価(テスト)できないと思います。

一長一短かなぁ。とりあえず、日本の下請けに投げて作らせるピラミッド構造では設計書は必要だし、この商流構造が変わらない限り、真似できない。担当者居なくなったら都度ソースコードからロジック読むのか？という疑問。あと、例外あるものの日本の大手ベンダーは個人的に技術者じゃないと思ってる。スケジュール管理と、お客に概要説明するだけ。設計するのも作るのも、2次受け以下で小さい会社や個人技術者といったよくわからない状態が日本なんだよね。

テスト担当者がテストする時、引継ぎするときなど仕様書必要ですが。。。 仕様書がなくてコードを読み解いていくみたいな不毛な案件をたくさん見ました。さらにそのせいで障害が起こったりしました。 あと大きい案件など設計書納品する場合は必要。 一方的な視点で海外が正で日本が誤のような理論に持っていくのは良くないかと。

ありがたい情報。

日本では、上流工程に係れず言われた仕様だけコーディングしているプログラマさんのほうが多いのでしょうか。 そこに人を使うのは無駄？AI 、ノーコードも実用化されてきて、プログラマも淘汰されるのかなと思いました。

複雑な業務システムの場合は、基本設計レベルのものは最低限必要になるんじゃないでしょうか。 コードだけでは、納品物の検収すらままなりません。

なんのための事務員なんだって話ですよね

仕様書を書ける人が「仕様書は無駄」と言うのは大抵正しい。 仕様書を書けない人が「仕様書は無駄」というのは……。 無駄なのに求められるのは外注文化がやはり原因なのですねぇ。