マッチョな人は同じことを考えるのね
マッチョな人間は同じことを考えるのね。わたしはそれほどマッチョじゃないですけどね……。
ドキュメントの内部レビューなんて、まぁ、誤字脱字やページ番号や章番号のチェックだったりすることもあるからね。本当に意味ないし、若い頃よくバックれたな（良い子はマネしちゃダメですよ！）。
ひがさんのおっしゃる「仕様を固める部分」ってのが、わたしのいうところの「外部設計」です。「プログラムファースト開発」か、なるほど言い方の問題ですな。
まぁ、言葉の部分はいずれ学者に補完してもらうとして、小飼さんがやる分野でSQLをどのぐらい使うのか知らないけれど、業務システムに限れば「プログラムファースト開発」のネックになるのはSQLです。SQLができるようになれば、DB設計や業務ロジックの実装など、ユーザーに見えない部分を後回しにすることはぜんぜん怖くない。
分かってないから恐れているだけです。
さらに、「プログラムファースト開発（仮）」はひがさんがおっしゃるおとり、下請けとかオフショアとかやりにくくて、大手でSIerでは採用しにくい。だからこそ良い、とわたしは考えているというのはこれまで書いてきたとおりですけれど、やはり大手SIerではできないでしょう。
むしろ、大手がそんなにマッチョになったら、下々は全滅してしまう。マッチョに変わることができた中小企業はそれなりに生き残るでしょうけれど……。
小飼さんのおっしゃるとおり、わたしは力がないので、今のところ安く取らざるを得ない。「見てたのかよ！」ってぐらいグサッときますな。
それはともかく、ここで言葉汚く罵ってみても、大手SIerの上位には通じない。
ですから、産学協業でこの辺の手法を、なんかカッチョイー名前をつけて確立したいと考えています。
やっぱり、大手SIerなどに採用されるには、どの程度効果がでたのか、定量的、学術的に評価して論文にする必要性があると思う。しかし、それにはよほど大きな会社でないと余分に金を掛けれないし、よほど大きな会社は上に書いたような理由でできないのです。
というわけで、弊社ではなく弊社が所属しているNPO法人のJASIPAを通じて、いろんな大学にアプローチしていけたらと考えています。
「プログラムファースト開発（仮）」だけじゃなく、日本のIT産業は学術的に弱い（お前が言うか！）ので、大学で研究されている理論を、実開発で試すような協業を大学とできたらと考えています。
コメント
インドリ
彼らは働かずに儲ける事しか考えていませんから達の悪いSIerは無視して、お客様にどれだけのお金を溝に捨てているのか教えてあげた方が話しが早いと思います。
oumi
>業務システムに限れば「プログラムファースト開発」のネックになるのはSQLです。
これは、ちがうんじゃないかな？人数じゃないですか？
開発者を増やさざるをえない状況になってきたときに、いかにしてルールを守らせるかとか、EUの認証者の権限を確保する方法とか、コード以外の部分が一番ネックになるでしょう？
情報の伝播速度を確保して、確実に伝播したかを確認する方法とか・・・
コード書く話なんていちばんチョロイ話でしょう・・
しかも、まったく新しく無い気がするのは気のせいだろうか・・
21年くらい前に、Y銀行の情報系システムってまさに、「プログラムファースト開発」だったんだけどな・・定義された名前は無かったけど。若干アジャイル臭もあったかもだけど。
「プログラムファースト開発」という名前は定義されたりしてなかったので、定義付けは重要かもしれないけど。でも内容は、別段、何てこと無い気が・・・
まぁそういった事で、「人数」が問題だと思うわけです。
っていうか、大手SIerでも、アジャイルも、プログラムファースト開発も、プロトタイプ開発の派生も、状況に応じて、工夫してやってると思うんだけどね・・・それぞれが独立して採用されることもあれば、部分的にだったりすることもあるけど。（全部が完全にそうだとは言わないけど）
例として、統合情報基盤的なミドルの上に載せるシステムなんて、はなっからウォ－タフォールで開発できないんだから・・・とかね。
もっとも、ここの経験に基づいて、酷く理想的じゃない事があったのかもしれないですけどね・・
oumi
大手SIerに問題が無いとは言いません。ハイ
oumi
無駄が多いとか、鈍いとかね・・まぁあるでしょう
うわーん飲んだ勢いでＵＰしたけど、消せない orz
インドリさん、oumiさん、どうも。
SQLが分かったら、大手でもアジャイルでできるんですけどね。
人数もたぶん、大手のプロパー＆ほんの少しでできます。
中小企業は困るけど（笑）
もちろん、アジャイルなんて昔からあるプロトタイピングの焼き直しでしかない。
インドリ
>アジャイルなんて昔からあるプロトタイピングの焼き直しでしかない。
これは違います。
プロトタイピングは使い捨て型の従来の設計中心技法ですが、アジャイルではコードを中心とした開発技法であり本質的に異なります。
oumi
インドリさん１を知って２を知らない。
プロタイピングの目的をちゃんと考えてごらん。
>アジャイルなんて昔からあるプロトタイピングの焼き直しでしかない。
の意味がわかるから。
インドリ
余りに大雑把過ぎます。
その違いがソフトウェア工学の進化なのですから知っていないと駄目です。
プロトタイプは捨てますが、アジャイルはコードを捨てません。
さらに、アジャイルはコード中心なのですから開発体制はかなり違います。
組織としての在り方を考えるとその差は大きなものです。
試しにXPでもやってみればその極限と言われている理由が分かります。
プロトタイプなんて生ぬるいものではありません。
oumi
一見あっているようだけど、間違いがある。
>プロトタイプは捨てますが、アジャイルはコードを捨てません。
そもそも、出だしから違う。
「プロトタイプは捨てます」は捨てるタイプのプロトタイピングもあるというだけで、「捨てなければならない」というルールはありません。
「積み上げ型」や「反復型」のプロトタイピングもあります。当然「捨てない」プロトタイピングもあります。また、プロトタイピングの亜種には、イテレーションという考え方を持ち込んだ手法も実際に存在します。
もとの文章の意図や大意を考えずに、
特定の一時期に、だれかが書いた文章をまる暗記して「こうだ」と言いきるのは滑稽にしか見えませんよ。「知っている必要性」と「言うべきタイミングを知っている」ことを履き違えてはいけない。
インドリ
アジャイル開発をプロトタイプと一緒にするということは、スラムダンク方式と一緒にするぐらいおかしなものです。
組織体制を変えなければ実現できない（ここが一番大事）アジャイルと、従来の組織体制を維持したままやるプロトタイプを同じにする事はあまりにも大雑把過ぎます。
組織の変更が大差ないというのであれば、それは実装者が主役になる事を否定する事を意味し、生島さんが言っている改革も大差なしという事になります。
ちなみに、プロトタイプを捨てないで生じる開発のトラブルがある事を考慮しているのでしょうか？
プロタイプの弱点は「捨てるべきものを捨てないでなし崩し的に開発を続ける事」です。
その弱点をよしとするのは如何なものかと思います。
インドリ
組織体制の変更が大差ないというのは大局的ではないと思いますよ。
もしそれが考慮に値しないというのであれば、生島さんが言っていた改革は何なのか疑問です。
開発体制が関係のであれば、今の仕事しない悪質な上流でも何でもいいという事ですよね。
インドリ
失礼しました。
誤：開発体制が関係のであれば、今の仕事しない悪質な上流でも何でもいいという事ですよね。
正：開発体制が関係無いのであれば、今の仕事しない悪質な上流でも何でもいいという事ですよね。
oumi
なんだかこのまま続けるのも心苦しいので、１点だけ、
>アジャイル開発をプロトタイプと一緒にするということは
だれも一緒にしてないことが、判っていない時点で、ほんとうはちゃんと読んでないんじゃないか？って思う。ちゃんと読んだ方が良いですよ。
うむ～。
ちゃんと読んでないというか、敢えて誤読をしているというのか、とにかく何かケチつけたいのか？
「一緒にしている」と読むようでは、顧客や上司の話を間違って聞いてると思うけどな……。
人間の器官で、特定の条件下で通常の6倍の大きさになるモノはなんですか？
セクハラですか？
インドリ
うーんやはりわかっていない・・・
おそらく実践もせずに似ているから一緒だと思っているのでしょうね。
アジャイル開発をちゃんと知っていれば、この記事の内容と関係深いことが分かるのに・・・
よく調べもせずに、似ているだけで何でも一緒だと思わないほうがいいですよ。
生島さんはSQL以外についてはかなりおざなりなんですよね。
その辺が違和感を相手に与えて、ご自身が言っていたようにSQLに拘りすぎる人との誤解を与えるのだと思います。
プログラムファースト開発（仮）はアジャイル開発の簡易版ですよ。
その簡易版に注意を払わないという事は、この記事を自身で否定する結果になるという事を分かっていない。
SQLを上流にさせる方法を考えるのならば、既存の開発プロセス方法をちゃんと調べた方がいいと思います。
それじゃないと説得力がありません。
インドリ
ちなみに、SQLを上流は覚えようだけだと、
「それじゃあスラムダンク方式だ」
「分析段階では実装を考慮してはならない」
「E-R図はSQLを考慮して作るものではない」
・・・・・・
などといわれてアウトです。
ちゃんとソフトウェア工学に基づいて説得しましょう。
もしくは、SQLを覚えただけでは現状は変わりません。
「覚えたけど上流では下流の事を意識しない」
で終わりです。
インドリさん、ちょっと日本語能力が足りなすぎだと思いますよ。
もう少し、国語力がないと……、あなたが騙されたとか、払ってくれなかったとか言ってるのも……。
お客さんがカレーを注文したら、お客さんがバーモンドカレーを求めているのか、本格インドカレーを求めているのか判断して、求めているものを上回るモノを出すのはプロの仕事です。
しかし、これだけ噛み合わないと、インドリさんが言うとおり本当に金を払わない客ばっかりだったとしたら、インドリさんはカレーを注文したのに、ショートケーキを出してるんじゃないかと疑ってしまいます。
それで「こっちの方が絶対においしいのに！」って譲らない。
そんな感じかな……。
インドリ
自分の勉強不足を人のせいにするなんて・・・
自分の書いた文章を見たら如何でしょうか？
「
「プログラムファースト開発（仮）」だけじゃなく、日本のIT産業は学術的に弱い（お前が言うか！）ので、大学で研究されている理論を、実開発で試すような協業を大学とできたらと考えています。
」
考えているのであれば、何故既存の手法について調べていないのでしょうか。
それとも貴方の考えているとは他人任せの事ですか？
信憑性を疑います。
メソポタミア文明
タイトルに引かれて読んでしまいました。
私も大学で色々研究していたのですが、それが会社にいって現場で使えるかといえば・・・そうではないんですよね。
現場でためせるようななってほしいなと最後のとこは思いました。
あ～り～
個人を特定できないＨＮはやめてほしい。
そんなことが以前かかれていたので、意味がわからず私は大丈夫か？と心配な感じですが・・・
>ドキュメントの内部レビューなんて、まぁ、誤字脱字やページ番号や章番号のチェックだったりすることもあるからね
いや、内容検査、検証が一番大事と思ってやればこの辺は対処可能かと。
まぁ、だったりすること「も」ある
ってなっているので問題ないのでしょう。
では、本題の部分「プログラムファースト開発」に。
プチ大手なところで、似たことをやった経験が。
正確には、、、要望を聞いても意味不明度ＭＡＸだったので
「こんな感じ？」と動くものを作ってみたら高評価だったからそのままプログラムファースト開発と同様の状態に・・・
でも、これは、、、見積りとかどうなるんでしょう。
・・・と勉強が必要と感じたコラムでした。
ありがとうございました。
P.S. コメントにあるXPをWindowsXPと脳内変換してしまった。残念だ。。。
メソポタミア文明さん、どうも。
この業界っていろんな手法が研究されている割に泥臭いのよね。
で、大学などの研究機関って、実際の現場で測っているかというと、机上でソースの割合で追いかけたりしているのよね。
それじゃあ、現場に対して訴求力はない。
私は一番泥臭い現場にいながら、研究の重要性は感じていて、研究者が降りてくるべきと思っています。
メソポタミア文明
>それじゃあ、現場に対して訴求力はない。
>私は一番泥臭い現場にいながら、研究の重要性は感じていて、研究者が降りてくるべきと思っています。
現場で研究できるのが1番なんでしょうね。
だが現場は研究者の意見を取り入れたり、逆に研究者にフィードバックできたりできるように今はなってないんですよね。
お互いが相互に補え合える現場が理想なんでしょうね。
そういう職場にしていきたいものです。
あ～り～さん、どうも。
ハンドルは、「通りすがり」とか、ブランクじゃなければよいのですけれど、「通りすがり」って言い捨てるためのハンドルじゃないですか。
見積りについてはね……。
正直に言うと、「プログラムファーストじゃない見積 × 0.8」ぐらいで出します。
もともと、プログラムファーストは一括で取らないとできないし、上流が実装に詳しくないとできない。
大手ではできない。
（大手でできても2千万ぐらいのサブシステムかな）
問題はあるけれど、じゃあ今より劣っているかというと、そうじゃないと思う。
今起きている問題が少しでも解決の方向に進むのであればやればいいと思っています。
この考え方がすでに変わっているのかもしれませんが……。
メソポタミア文明さん、どうも。
しかし、現場の立場から見れば、慣れてない上に、研究のエビデンスを残すための作業や比較実験の作業コストを誰が負担するのか？という問題が起きます。
現場で研究しようとすれば、研究費はどこかから調達しなければならないわけです。
日本では大手でも、費用を現場（プロジェクト）で負担して、研究成果は研究者のモノ的な考え方になりがちですから、日本では研究者を遠ざけようとするのでしょう。
結局、費用をどこかから持って来れたら解決するわけで、IPAとか狙ってます（笑）
oumi
いい感じに、盛りあがってきましたねっ！
燃え上がってかな・・・
>私は一番泥臭い現場にいながら、研究の重要性は感じていて、研究者が降りてくるべきと思っています。
これは良い感覚ですね。旧来からある大手メーカーでも、それこそ「ソフトウェア開発工学」に関連する研究部門あるんですけど、なかなか現場までは・・・ねっ。
>お互いが相互に補え合える現場が理想なんでしょうね。
>そういう職場にしていきたいものです。
これも良い感覚ですねー。
しかし、研究者が現場に近づいてくると、SQLですら怪訝な顔する人たちは・・・うーん
oumiさん、どうも。
> しかし、研究者が現場に近づいてくると、SQLですら怪訝な顔する人たちは・・・うーん
それもありますね。
自社に研究部門があっても広がらないのは、成果の取り合いをしなければならないからじゃないかと思っています。
金の出所が同じじゃ、失敗したら相手に責任を押し付けるし、成果は自分の方につけようとするじゃないですか。
そうすると、相互に補完というのは中々難しくなるわけです。
同じプロジェクトでミッションが違う人が一緒にするには、金の出所が違えば可能になるかと、お互いにプロジェクトの成功が目標というのは変わらないし、成果を取り合う必要もない。
ですから、研究の費用の部分を、IPAなどから公的資金を入れつつ中小企業の現場でって考えています。
私の体が空いたらIPAに乗り込む！
放牧民
元通りすがりです。
横レス失礼します。
>「通りすがり」って言い捨てるためのハンドルじゃないですか。
単純にハンドルなかっただけなんですよ。
そりゃまあ失礼だと思われたのでしたら、いくらでもお詫びいたしますが、悪意のある文章で無いことくらいは読み取って頂けると思っていたのですが。
ちなみに私2chの技術系で時々レスのやりとりしてるんですが、匿名でも特に「言い捨て」とは思わないんですよ。
なので、特に悪意はありませんでした。
ごめんなさい。
まぁ、ハンドルで書き込むことを望まれるのでしたら「名前書いてね」って一行レス書いてあげれば済む話ですし、酔った勢いでストレスをぶつけるのはカッコワルイですよ。
話ずれちゃいますし、本文の価値が台無し。
放牧民
パラパラと失礼いたします。
本題ですが、ひがさんのコラムはリアルタイムで読んでました。
特に違和感は感じませんでした。
ただ、生島さんの「テーブル設計は実装の後！」という主張がひがさんのと同じとは思っていませんでした。
いや、大意には同意なのですが、それまで全くDBの事は考えない、ということではありませんよね？
データの関連性から逆算したら、明らかにおかしな画面になってるケースもありえますし。
私はどうしてもチラチラと考えちゃいますね。チキンですから。
>大手がそんなにマッチョになったら、下々は全滅してしまう。
ぜい肉があってこその大手なわけでして、マッチョはその時点で大手じゃないような。(いろんな意味で)
なので、ひがさんは(もちろん生島さんも)頑張ってるなーとは思いますし、尊敬もできるのですが、「イノベーションのジレンマ」方式のほうがひっくり返せると思います。
私は規模も価値もミジンコ程度の自営業ですが、少しずつ業界のルールを書き換えてやろうと思ってます。
SIって業界自体は消えてもいいと思ってるくらい。
放牧民
ちなみに相手にもよりますが、
>わたしは力がないので、今のところ安く取らざるを得ない。
早いと安くされるって話ですが「普通列車よりも新幹線のほうが高いですし、タクシーだって深夜は3割り増しですよね？」
という理屈が通せるお客さんも一応。
早く出来るやり方を前提に安く取ったはずが、効率の悪い手法を押しつけられて涙目ってことの方が多いんですけどね(^^;)
放牧民さん、どうも。
ハンドルについてはね。たぶん、何十人が相手になってくるとカチンと来ることもあるのです。ごめんなさい。
私が書いているのも、UIを作っている間中がDBの設計期間です。
一番、他に影響を与えるポイントだから、一番時間を掛けれるようにしてます。
ひがさんがおっしゃっているのも、私が言ってるのも、全部がアジャイルじゃないのです。内部（DB）だけを見れば、実はウォーターフォールになっていたりする。
高く取れるときもないことはないのですけれど、現状ではほとんど難しいですね。