未来のいつか/hyoshiokの日記

hyoshiokの日々思うことをあれやこれや

昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど）続き

先日の話の続き。http://d.hatena.ne.jp/hyoshiok/20140115/p1

実名、所属名付きでお話をするスタイルで議論は進んでいく。しかしこうやってまとめてみると無駄に長い。言葉を定義して少しずつ進む。やり取りがリアルタイムではないので進行がもどかしい。結構めんどうなことをいい歳をした大人がやっているという印象である。

追記(2014/1/19) 昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど）続きの続きを書いた http://d.hatena.ne.jp/hyoshiok/20140119/p1

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/RSlNBEeQ_uUJ

SENOH Yasushi 	
1998/05/28

OOA is prerequisite to OOP? (R e: ソフト工学… )


妹尾です。
Hirotaka Yoshioka wrote in message ...
>>   現実問題としてこの手の人に 「なれの果て」が多いのは想像が
>> つきますが、「(プログラミングもできるけど)設計しかしない」と言う
>> 態度は、あっていいと思います。私自身、そういうの目指してますし。
>
> プログラミングと設計ってそもそも分離可能なもんなんでしょうか？
>分離可能だというのを信じるとウォータフォールになるし，なんか
>どーもよくわからんというスタンスだとちがったスタイルになりそーだし．

  そうですか？

> プログラミングのうらづけのない設計ってゴミみたいなもんだと
>思っているので，なんか分離可能つーのが信じられないんですね．

  「(この設計で)プログラミングが可能である事を示す」のと
「プログラムを書く」のは違うと思うので、これだけから
「分離不可能」とは言えないのではないででしょうか。


    

  • -
    • 

せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/

いきなり、プログラミングのうらづけのない設計ってゴミみたいなもんだという過激な発言から始まります。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/KFRskkbERWIJ

Hirotaka Yoshioka 	
1998/05/28

OOA is prerequisite to OOP? (Re: ソフト工学… )


よしおかです．
Yukihiro Matsumoto  writes:
> まつもと ゆきひろです
> |大瀬戸です。

こんちわ

> |>あつかってい対象が，違うのかな．日本でも商用パッケージ作っているところは，
> |>設計とコーディングが一緒ですかね．
> |あっ、これって、設計＊者＊とコーディング＊者＊が一緒って意味ですよね。
> |設計しながらコーディングしながら設計しながら・・・って意味じゃないですよね。
> 設計とコーディングってそんなに分離すべき工程なんでしょうか．
> 外部仕様決めやテストは明確に分離すべきでしょうが．
よくわからないのですけど，シュリンクラップつくっているところって，外部仕
様きまったら，あとは適当に，モジュールオーナーが設計して，コードも書くつー
スタイルがわりと一般的な感じがしてます．原子力発電所とか飛行機の制御とか
のプログラムの作りとちがって，そこそこの品質のものをタイムリーに出すつー
方がともかく必要ですから．

でもってプログラムをスクラッチから作るというのはありえなくて，前のバージョ
ンからの拡張とか修正とかだから，つねに動くものがあるんですよね．だからな
んか設計しているのだかハックしているのだか，(はたから見たら)よくわからな
いんだけど，ともかく雪ダルマ式に機能が増えていくような感じっすね．

そーゆー開発スタイルでは設計者とプログラマを分離するなんてナンセンスです
よね．あ，そーゆー話じゃない？

> 私はプログラムは究極の仕様書だと思ってますが，それは文化の違
> いなんでしょうか．

日本で，そーゆースタイルの開発ができない理由ってあるんでしょうか？プログ
ラマがいないつーのならなんとなくわかるような気がするけど．でも，そんなこ
とないですよね．

よ

若い人はシュリンクラップといわれてもピンと来ないかもしれないので、ざっくりいうと、昔はソフトウェア製品（特に一般ユーザ向け）は箱に入っている形で売られていることが多くて、その箱がビニールでパッケージされていて、そのビニールを破らないと中のものを取り出せないようになっていた。そのビニールでの包装をシュリンクラップとよんでいた。ここでいうシュリンクラップというのは、それから来ていて、一般向けのソフトウェア製品のことをさす。

ソフトウェアの開発と一概に言っても、発電所の制御システムや飛行機の制御やらいろいろある。日本においては「ソフトウェア製品」開発というのはあまり一般的ではなく、いわゆるSI(システムインテグレーター)という形態でのソフトウェア開発がほとんどである。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/cQapbU2M-HkJ

Yukihiro Matsumoto 	
1998/05/29

OOA is prerequisite to OOP? (Re: ソフト工学… )


まつもと ゆきひろです
"SENOH Yasushi"  writes:



    

    妹尾です。
    

    

    >プログラミングと設計ってそもそも分離可能なもんなんでしょうか？
    

    

    >分離可能だというのを信じるとウォータフォールになるし，なんか
    

    

    >どーもよくわからんというスタンスだとちがったスタイルになりそーだし．
    

    

    

    

      そうですか？
    

    

      「(この設計で)プログラミングが可能である事を示す」のと
    

    

    「プログラムを書く」のは違うと思うので、これだけから
    

    

    「分離不可能」とは言えないのではないででしょうか。
    


原理的には可能ですから，私は分離不可能であるとまでは思わない
んですが，多くの場合で分離することには意味が無いとは思います．
また，日本の企業風土かなにかで分離することに意味が無い場合ま
で，設計とプログラミングを分離して「損して」いることはあるよ
うに思います．

どうやら「ウォーターフォールじゃいかん」ってのは周知の事実に
なったようですが，その場合実装やさまざまな事情によって，プロ
グラミングと設計の間の手戻りがかなり発生するはずですよね．そ
の場合，設計とプログラミングを分離することはたんにコミュニケー
ションコストを増大させるだけだと思います．

分離すべきは，前段階の「外部仕様の決定」「モジュール間のイン
ターフェースの決定」レベルか，後段階の「テスト」などでしょう．
前段階は手戻りが頻繁に発生しちゃいかんはずなんで，分離に問題
ないですし，後段階は分離しないと先入観から問題を見逃しちゃう
恐れがありますよね．

んで，日本で設計とプログラミングを分離したがるのは企業の中に
「設計者(SE)」と「プログラマ(PG)」という一種の身分制度が存在
しているからではないかと憶測しているのです．日本ってプログラ
マの地位が低いですよね．
                                まつもと ゆきひろ /:|)

「ウォーターフォールじゃいかん」ってのは周知の事実ということは実はまだなかったのではないかと思う。

身分制度の存在が、設計とプログラミングを分離している原因なのか結果なのか。プログラマの地位が低いという指摘は昔からされている。

この指摘は日本におけるソフトウェア開発の大半がSIというような構造によるものなかのそうでないかはここではまだ明示的に議論になっていない。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/HGHkslhUkDEJ

Yukihiro Matsumoto 	
1998/05/29

OOA is prerequisite to OOP? (Re: ソフト工学… )


まつもと ゆきひろです
Hirotaka Yoshioka  writes:


    

    こんちわ
    


こんにちは



    

    よくわからないのですけど，シュリンクラップつくっているところって，外部仕
    

    

    様きまったら，あとは適当に，モジュールオーナーが設計して，コードも書くつー
    

    

    スタイルがわりと一般的な感じがしてます．原子力発電所とか飛行機の制御とか
    

    

    のプログラムの作りとちがって，そこそこの品質のものをタイムリーに出すつー
    

    

    方がともかく必要ですから．
    


ええ，そうだとは思いますが，元々の発言された方や日本の多くの
「SE」はそもそもシュリンクラップのプログラムの開発にたずさわっ
たことはほとんどないのではないか，と推測します．



    

    そーゆー開発スタイルでは設計者とプログラマを分離するなんてナンセンスです
    

    

    よね．あ，そーゆー話じゃない？
    


ですから，そーゆー開発スタイルはあんまりないみたいなんですよ
ね．で，得意ワザは「原子力発電所とか飛行機の制御とかのプログ
ラム」なんで，そーゆーのが必要でない(むしろジャマになる)局面
でも，設計者とプログラマを分離しちゃうんじゃないか，と思うの
です．



    

    日本で，そーゆースタイルの開発ができない理由ってあるんでしょうか？プログ
    

    

    ラマがいないつーのならなんとなくわかるような気がするけど．でも，そんなこ
    

    

    とないですよね．
    


企業としての設計者とプログラマ(コーダー)の分化が進んでしまっ
て，取り返しがつかないのじゃないかなあ．憶測ですが．

                                まつもと ゆきひろ /:|)

ソフトウェア製品の開発に携わった経験のない人がSEをやったり評論していたりするのではないかという指摘。

ここでいうSEという職種がソフトウェア製品開発ではなくSIでのソフトウェア開発をやっているのではないかという暗黙の仮定が徐々にあきらかになってくる。

企業として分化が進んで、取り返しがつかないのではないかという指摘。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/QLGgvMtVhh0J

Nobukuni Kino 	
1998/05/29

OOA is prerequisite to OOP? (Re: ソフト工学… )


アイザックの紀です。たびたびお邪魔します。
まつもと ゆきひろさん：
> んで，日本で設計とプログラミングを分離したがるのは企業の中に
> 「設計者(SE)」と「プログラマ(PG)」という一種の身分制度が存在
> しているからではないかと憶測しているのです．日本ってプログラ
> マの地位が低いですよね．
そのとおり。企業の中に身分制度があるだけでなく、企業間にも
上流と下流の身分があります。

私のところでは部分的な工程の受注をほとんどやらなくなりまし
たが、日本の世の中では、受発注関係で上流にある会社が
工程上の上流を、下流にある会社が工程上の下流を分担する、
同時に作業単価も下流の方が安いという商習慣がいまでも
あると思います。
だいたい、分析・設計・プログラミング・テストなんていう
工程別の単価表があって、当社ではプログラミングはｘｘ万円/月
だからその単価で見積もるように、などという神話級のやりかたが
いまでもあるんです。これじゃ、ソフト業界はまともな産業に
育たないですよね。

本当にあった笑い話のような話をひとつ。
顧客「見積りは分析・設計・プログラミング・テストに分けて明細を
　　　つけてください」
某社「当社ではそういう工程では開発していません」
顧客「その形式で無いと購買が通らないんです」
某社「わかりました、形式をあわせましょう」
...見積り提出
顧客「この見積りで結構ですがテストのところはいりません。
　　　うちでやりますから」
...受注確定

開発工程の認識の差はともかく、「某社」の方では「テスト工数」に
見積りの多くの部分を割り当てていたので相当値切られた形です。
「顧客」がテストなんかやらなかったのは言うまでもありません。
（なんでそんな妙な受注があり得たか？　その辺の事情は知りません）

私は、スパイラルならテスト工程の実施を分離できると思います。
一種のコンカレントエンジニアリングの形態でプログラミングと
テストを同時に行えるようになれば良いと考えています。
ウオーターフォールでは分離は現実的に効率が良くないでしょう。
一方、手戻りが少ないはずの上流工程は（どのモデルでも）分離
しやすいのでしょうが、個人の技量に出来が左右されるところが
大きいんでしょうね。次工程での実装が読めていない人の下流には
なりたくないです。

＃　上流とか下流とか、「上下」の字を使うからいけないのかな

    

  • -
    • 

(株)アイザック　プログラマ　紀　信邦

企業間にも上下関係がある。多重下請け構造ですな。いろいろ生々しい経験談が語られている。見積もりを値切るためにテストの工数を削減するって、虚構新聞じゃないのかといようなエピソードである。受発注でのソフトウェア開発がSIでの基本的なビジネス慣行になる。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/IdhmSjibznkJ

Yukihiro Matsumoto 	
1998/05/30

OOA is prerequisite to OOP? (Re: ソフト工学… )


まつもと ゆきひろです
os...@cs.ricoh.co.jp (Oseto Futoshi) writes:



    

    大瀬戸です。
    

    

    だから、（必要な範囲で）各モジュール群＊全体を見渡して＊、
    

    

    何処で何をするかと言う方針の決定はソースコードを書く
    

    

    段階では、（天才か超努力家以外の普通の人では）無理
    

    

    じゃないかなと思います。
    

    

    だから、コーディング以前に設計というステップが必要だと思います。
    


そこまでは否定しません．私も「外部仕様の決定」や「モジュール
分割」は分離できると述べました．が，普通「設計」というとそれ
より踏み込んだプログラミングの一歩手前まで含みませんか？

そのような(詳細)設計は分離すべきではないというのが，私の主張
です．

外部仕様（インターフェースあたりのところ）あたりは分離可能だけど、詳細設計と実装は分離すべきではないという主張。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/3Pzg1hB5MQsJ
SENOH Yasushi 	
1998/05/30

OOA is prerequisite to OOP? (Re: ソフト工学… )


妹尾です。
Yukihiro Matsumoto wrote in message ...
>|  「(この設計で)プログラミングが可能である事を示す」のと
>|「プログラムを書く」のは違うと思うので、これだけから
>|「分離不可能」とは言えないのではないででしょうか。
>
>原理的には可能ですから，私は分離不可能であるとまでは思わない
>んですが，多くの場合で分離することには意味が無いとは思います．

  なんていうか、実感として肌に染み込んでくる意見ですね。

  カタチ(例えば書類)の上で分離する事には、私も意味を感じません。
ただ、実装の都合でいつのまにか設計が変わっている(無視されている)
と言う事はあってはならないので、ココロの持ち方として、この分離は
重要ではないかと。

  一応断っておきますが、実装上問題が出たときに、設計まで振り返って、
設計を変更し、実装するのは否定してません。

  むしろ、カタチの上での分離は、実装→設計へのフィードバックが
しにくくなり、結果として「設計が無視される」と言った事態を起こしやすい
のではないかと思います。ただ、こうした「カタチ」の話は、「設計論」では
なく「プロジェクトマネージメント」の話ではないかとも思います。

>どうやら「ウォーターフォールじゃいかん」ってのは周知の事実に
>なったようですが，その場合実装やさまざまな事情によって，プロ
>グラミングと設計の間の手戻りがかなり発生するはずですよね．そ
>の場合，設計とプログラミングを分離することはたんにコミュニケー
>ションコストを増大させるだけだと思います．

  まさしく。

>んで，日本で設計とプログラミングを分離したがるのは企業の中に
>「設計者(SE)」と「プログラマ(PG)」という一種の身分制度が存在
>しているからではないかと憶測しているのです．日本ってプログラ
>マの地位が低いですよね．

  うーん、微妙なトコロですね。

  とりあえず、正論を吐いておくと、「優れた設計者」と「優れたプロ
グラマ」では、「優れた設計者」の方が優遇されて良いんじゃないで
しょうか。

  ただ、プログラミングは「プログラミング」を知らないと出来ないのに
対して、設計は「設計」をしらなくても「できて」しまいますし、これが
結果として「プログラミングはできないから設計でもする」なんて事態を
招く事もあるかと。

＃ まぁ、「仮定」の話ですから。そういうことで。


    

  • -
    • 

せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/

「設計者」と「プログラマ」を分離する前提の議論になっている。正論ってなんなんだろうか。全然正論というか理想論にもなっていないような気がするけど。どうなんだろう。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/SPByZbCeuqUJ
Oseto Futoshi 	
1998/05/30

OOA is prerequisite to OOP? (Re: ソフト工学… )

大瀬戸です。
In article , ma...@netlab.co.jp says...
>どうやら「ウォーターフォールじゃいかん」ってのは周知の事実に
（中略）
>
>分離すべきは，前段階の「外部仕様の決定」「モジュール間のイン
>ターフェースの決定」レベルか，後段階の「テスト」などでしょう．
>前段階は手戻りが頻繁に発生しちゃいかんはずなんで，分離に問題
>ないですし，後段階は分離しないと先入観から問題を見逃しちゃう
>恐れがありますよね．
そうやって分離するのが「ウォーターフォール」だと思いますが。
そして、「スパイラル開発」がモジュール内でプログラミングと
設計との間の手戻りをすることではないと思っていたのですが。

認識を変えるべきでしょうか。


閑話休題

確認ですが
In article , ma...@netlab.co.jp says...
>なったようですが，その場合実装やさまざまな事情によって，プロ
>グラミングと設計の間の手戻りがかなり発生するはずですよね．そ
でいう、プログラミングと設計は作業のことで

>の場合，設計とプログラミングを分離することはたんにコミュニケー
>ションコストを増大させるだけだと思います．

でいう、設計とプログラミングは担当者のことですよね。
ちょっと混乱してきたもので。

この時代、ウォーターフォールではいかんというのが周知の事実になっていなくて、ウォーターフォール前提の方法論が跋扈していたのではないかと推測する。未だにそーゆーことを信じている組織もあるような気がする。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/jLghwzWuWzcJ
Yukihiro Matsumoto 	
1998/06/01

OOA is prerequisite to OOP? (Re: ソフト工学… )


まつもと ゆきひろです
os...@cs.ricoh.co.jp (Oseto Futoshi) writes:



    

    大瀬戸です。
    

    

    >分離すべきは，前段階の「外部仕様の決定」「モジュール間のイン
    

    

    >ターフェースの決定」レベルか，後段階の「テスト」などでしょう．
    

    

    >前段階は手戻りが頻繁に発生しちゃいかんはずなんで，分離に問題
    

    

    >ないですし，後段階は分離しないと先入観から問題を見逃しちゃう
    

    

    >恐れがありますよね．
    

    

    

    

    そうやって分離するのが「ウォーターフォール」だと思いますが。
    


えーと，ということは，大瀬戸さんは「分離はすべからくウォーター
フォールである，存在してはいかん」と思っていらっしゃるという
ことでしょうか？ しかし，それでは大瀬戸さんの他の発言とは矛
盾するのできっと違うでしょうね．

前の発言で私が述べたのは

  外部仕様やモジュール間のインターフェースは頻繁に変更しては
  いけない(場合が多い)ので，分離による問題が生じにくいし，変
  更の頻度を下げる外部要因とするために分離した方が良い(場合
  が多い)

という意味で「手戻りが発生しない」とか「してはいけない」とか
いうような意図はありませんので，直接にウォーターフォールモデ
ルにつながるという認識はなかったのですが，いかがでしょう？

ついでにいえば，上記の「良い」は主にコストの問題ですので，コ
ストを度外視している場合には，良いも悪いもありません．

そして，私は「このような方法は『スパイラル開発』である」とは
ひとことも申しておりませんので，



    

    そして、「スパイラル開発」がモジュール内でプログラミングと
    

    

    設計との間の手戻りをすることではないと思っていたのですが。
    


については，若干当惑しております．

# 個人的な考えでは「フィードバックが行われれば粒度はともかく
# スパイラル開発である」と思ってますが．



    

    確認ですが
    

    

    In article , ma...@netlab.co.jp says...
    

    

    >なったようですが，その場合実装やさまざまな事情によって，プロ
    

    

    >グラミングと設計の間の手戻りがかなり発生するはずですよね．そ
    

    

    

    

    でいう、プログラミングと設計は作業のことで
    

    

    

    

    >の場合，設計とプログラミングを分離することはたんにコミュニケー
    

    

    >ションコストを増大させるだけだと思います．
    

    

    

    

    でいう、設計とプログラミングは担当者のことですよね。
    


そうであった方が「被害」が大きいですが，どちらも作業と考えて
いただいても議論の本質は変りません．

                                まつもと ゆきひろ /:|)

フィードバックがどのくらいの頻度あるいは粒度で行われるかは別として、それが開発の状態として存在していればスパイラル開発であるという立場をとっている。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/gAHGNS0gbRAJ

Yukihiro Matsumoto 	
1998/06/01

OOA is prerequisite to OOP? (Re: ソフト工学… )


まつもと ゆきひろです
"SENOH Yasushi"  writes:



    

    妹尾です。
    

    

      カタチ(例えば書類)の上で分離する事には、私も意味を感じません。
    

    

    ただ、実装の都合でいつのまにか設計が変わっている(無視されている)
    

    

    と言う事はあってはならないので、ココロの持ち方として、この分離は
    

    

    重要ではないかと。
    


えーと，この場合の前提は

  実装の都合でいつのまにか設計が変わっている(無視されている)
  と言う事はあってはならない

ですよね．この議論では設計という用語がいろいろの領域(粒度)で
使われているので難しいのですが，私の考えは

  この設計変更が閉じたモジュールの範囲内で行われるなら問題なし

と思ってます．ですから，前提を共有してないんですね．もちろん，
他人との関わりのある部分を勝手に変更してはいけないので，大き
なレベルでの設計については同意しますが．

ですから，わたしはこの件に関して妹尾さんの意見を全否定してい
るのではなくて，成立しない場合がありますよ，と述べているまで
です．



    

      とりあえず、正論を吐いておくと、「優れた設計者」と「優れたプロ
    

    

    グラマ」では、「優れた設計者」の方が優遇されて良いんじゃないで
    

    

    しょうか。
    


ふむ，つまり「優れた設計者」であるが「プログラマとしては優秀
でない」人や「優れたプログラマ」であるが「ろくな設計が出来な
い」人が存在すると考えておられるんですね．

企業における「コーダー」という職種の存在を見ているとそういう
人がいそうな気になってもしょうがないと思いますが，私の経験で
はそういう人は見たことないですし，存在しないんじゃないかとも
思っています．

もしかすると「プログラマ」という単語が指しているものが食い違っ
ているのかも知れませんが．

                                まつもと ゆきひろ /:|)

ここまで来て、「プログラマ」という単語が指しているものが違っているというのではないか疑惑が生じた。双方で違うものを指していたんだということが徐々にあきらかになる。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/P_1MGujTImAJ
Oseto Futoshi 	
1998/06/01

OOA is prerequisite to OOP? (Re: ソフト工学… )


大瀬戸です。
In article , ma...@netlab.co.jp says...
>|だから、（必要な範囲で）各モジュール群＊全体を見渡して＊、
（略）
>|だから、コーディング以前に設計というステップが必要だと思います。
>
>そこまでは否定しません．私も「外部仕様の決定」や「モジュール
>分割」は分離できると述べました．が，普通「設計」というとそれ
>より踏み込んだプログラミングの一歩手前まで含みませんか？
ここへの回答をする前に、

>そのような(詳細)設計は分離すべきではないというのが，私の主張
>です．

について確認ですが、ここでおっしゃられている「設計の分離」は
工程の分離のことですよね。担当者の分離のことなんかじゃないですよね。

以後、「工程の分離」だと解釈して話を進めます。

で、僕からの回答をします。
ここでお互いの認識がずれている可能性のあるのが、
「モジュールの大きさ」についての様な感じがします。
僕の認識では、モジュールは、
・手続き型言語の場合は、プロシージャや関数のこと
・オブジェクト指向言語の場合は、クラスのこと
です。
その上で、そのモジュールの構成はコーディング以前に設計というステップで
詰めておく必要があると考えてます。
＃モジュール内部のメカニズムは、場合によりその時にある程度規定する
＃かもしれません（疑似言語という形で。）が、
＃基本的には“好きにして”ってスタンスです。

分析・設計という概念を知る以前は、僕の場合、モジュールの決定は
結構いいかげんでした。
＃その時代はＣ言語でしたから、モジュール＝関数 です。
つまり、最初に“まぁこんなもんだろう”と大まかな決定をして
詳細を詰めていき、大きさが80x25のスクリーンで手に負えなく
なってくると、その都度、意味の上でまとまった単位で
細かい関数に分ける、ということの繰り返しでした。
お陰で、出来上がったソースは、1度しか使われないモジュールや
良く似たモジュールが沢山ありました。

手続き型言語の場合は、そういうことがおきても多少の無駄
（呼び出し時間とスタックの消費量）だけで済み、ちゃんと
動くわけです。
＃しかも、1度しか使われないモジュールであっても
＃「手続きの隠蔽」という見方をすると、
＃全く無駄なわけじゃないですけど。

ところが、オブジェクト指向型言語の場合、オブジェクトに
よって、「手続きの隠蔽」に加え「データ（構造）の隠蔽」が
加わります。その場合、矛盾したオブジェクト構造はそのまま
矛盾したデータを含むことが起きてしまうと思います。
だから、思い付きでオブジェクトを作り出す訳には
いかないと思います。

だから、オブジェクト単位の大きさまで踏み込んだ設計
が必要になるのではないかと思っています。

＃もっとも、Shlaer-Mellor 法から OO に入ったから
＃こんな考えを持つのかもしれませんが。
＃しかも、SM法なんてOOじゃないという人もいるかもしれない。:p

モジュール分割の粒度についての考えを述べている。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/5ZIJuFxBIpwJ
Yukihiro Matsumoto 	
1998/06/01

OOA is prerequisite to OOP? (Re: ソフト工学… )

まつもと ゆきひろです
os...@cs.ricoh.co.jp (Oseto Futoshi) writes:


    

    大瀬戸です。
    

    

    ここへの回答をする前に、
    

    

    

    

    >そのような(詳細)設計は分離すべきではないというのが，私の主張
    

    

    >です．
    

    

    

    

    について確認ですが、ここでおっしゃられている「設計の分離」は
    

    

    工程の分離のことですよね。担当者の分離のことなんかじゃないですよね。
    


実は担当者の分離を念頭において話していたのですが…．工程の分
離でも議論の本質は変らないとは思いますが，「分離」という用語
の使い方によっては違いが出てくるかも知れません．



    

    ここでお互いの認識がずれている可能性のあるのが、
    

    

    「モジュールの大きさ」についての様な感じがします。
    

    

    僕の認識では、モジュールは、
    

    

    ・手続き型言語の場合は、プロシージャや関数のこと
    

    

    ・オブジェクト指向言語の場合は、クラスのこと
    

    

    です。
    


あ，そうなんですか．うーん．

私が(多分よしおかさんも)考えているモジュールはもっと大きな単
位です．そして，そのレベルで



    

    ＃モジュール内部のメカニズムは、場合によりその時にある程度規定する
    

    

    ＃かもしれません（疑似言語という形で。）が、
    

    

    ＃基本的には“好きにして”ってスタンスです。
    


が成立すると考えています．



    

    ところが、オブジェクト指向型言語の場合、オブジェクトに
    

    

    よって、「手続きの隠蔽」に加え「データ（構造）の隠蔽」が
    

    

    加わります。その場合、矛盾したオブジェクト構造はそのまま
    

    

    矛盾したデータを含むことが起きてしまうと思います。
    

    

    だから、思い付きでオブジェクトを作り出す訳には
    

    

    いかないと思います。
    


それについては否定しませんが，なにか私が設計が要らないとか，
思い付きでオブジェクトを定義すれば良いと主張しているかのよう
に読めるのですが，気のせいでしょうか？

私が主張しているのは，ある一定の粒度以下では設計という工程と
プログラミングという工程を分離する必要はない，ということで，
分析や設計が不要だとか，いい加減なプログラムを書けば良いとか
いうようなことは主張してません．

                                まつもと ゆきひろ /:|)

まつもとさんの主張はある一定の粒度以下では設計という工程とプログラミングという工程を分離する必要はないというところにつきる。

設計とプログラミングは不可分でいったりきたりしながら進むのではないか。まだアジャイルソフトウェア開発という言葉が出てくる以前での発言だ。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/esD8sMDaZkcJ

SENOH Yasushi 	
1998/06/01

OOA is prerequisite to OOP? (Re: ソフト工学… )


妹尾です。

Yukihiro Matsumoto wrote in message ...
>  実装の都合でいつのまにか設計が変わっている(無視されている)
>  と言う事はあってはならない
>
>ですよね．この議論では設計という用語がいろいろの領域(粒度)で
>使われているので難しいのですが，私の考えは
>
>  この設計変更が閉じたモジュールの範囲内で行われるなら問題なし

  これは実装レベルの話だから問題ないと思います。
  逆に言えば、こういうレベルの事は設計で話すようなコトではないと
思ってます。良い設計とはシステムなりを実現するにあたって必要な
ことがすべて記述されていて、なおかつ実装の自由があるものだと
思います。実装の自由の範囲内では何をしようとも、それは設計を
かえる必要はありません。

>と思ってます．ですから，前提を共有してないんですね．もちろん，
>他人との関わりのある部分を勝手に変更してはいけないので，大き
>なレベルでの設計については同意しますが．

  という事で、良いんじゃないでしょうか。どのレベルまでを設計と
呼ぶかという差はあれど、実態は変わらないと思います。

>ふむ，つまり「優れた設計者」であるが「プログラマとしては優秀
>でない」人や「優れたプログラマ」であるが「ろくな設計が出来な
>い」人が存在すると考えておられるんですね．

  少なくとも、そういう意味ではありません。

  このあたりは単に言葉の問題で、「プログラマ」ってのは「プログ
ラムを書く人」であり、「設計者」は「設計をする人」だという事です。
「プログラムも書けるけど、設計している人」は設計者です。

＃ こういう表現ってへんですか？

>企業における「コーダー」という職種の存在を見ているとそういう
>人がいそうな気になってもしょうがないと思いますが，私の経験で
>はそういう人は見たことないですし，存在しないんじゃないかとも
>思っています．

  私も見た事無いです。でも、存在しないと主張する気もありません。
もっとも、存在するにせよ、しないにせよ、私の書いた事には関係
ありません。


    

  • -
    • 

せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/

「プログラムも書けるけど、設計している人」は設計者ですという主張には個人的には違和感を感じる。ある人は設計もするしプログラミングもする。まあ、言葉のあやかもしれないけれど。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/girS3mWM1_kJ
Oseto Futoshi 	
1998/06/02

OOA is prerequisite to OOP? (Re: ソフト工学… )


大瀬戸です。
＃沢山あってフォローが大変です。(^^;)ゞ
In article , ma...@netlab.co.jp says...
>|ここでお互いの認識がずれている可能性のあるのが、
>|「モジュールの大きさ」についての様な感じがします。
>|僕の認識では、モジュールは、
>|・手続き型言語の場合は、プロシージャや関数のこと
>|・オブジェクト指向言語の場合は、クラスのこと
>|です。
>
>あ，そうなんですか．うーん．
>
>私が(多分よしおかさんも)考えているモジュールはもっと大きな単
>位です．
私が(多分妹尾さんも)考えているモジュールはもっと小さな単
位です．:-)

＃モジュールという言葉をつかったのが駄目だったのですね。
＃済みません。

In article , ma...@netlab.co.jp says...
>実は担当者の分離を念頭において話していたのですが…．工程の分
>離でも議論の本質は変らないとは思いますが，「分離」という用語
>の使い方によっては違いが出てくるかも知れません．
担当者間のコミュニケーションコストと、
一人の担当者の頭の中でのコミュニケーションコストとを、
比較すると、議論の本質はかわらないといえないのでは
ないでしょうか。

つまり、モジュール一つの捉え方（たとえば大きさ）から
異なってくると思うわけです。

>|＃モジュール内部のメカニズムは、場合によりその時にある程度規定する
>|＃かもしれません（疑似言語という形で。）が、
>|＃基本的には“好きにして”ってスタンスです。
>
>が成立すると考えています．
もし、ここでのモジュールが関数単位、オブジェクト単位
であるのならば、担当者（あえてそう呼びます）が
エディタに向かって、キーボードを叩きながら考えても
そんなにおかしなことにはならないでしょう。

しかし、ここでのモジュールがもっと大きな単位
＃たぶん、担当者に任せられる仕事の大きさの単位
であるのならば、担当者が直接エディタに向かって、
キーボードを叩きながら考えてると、おかしなことに
なるのではないでしょうか。
“好きにして”っていう、スタンスは取れないと思います。

前者は、まつもと さんの
>私が主張しているのは，ある一定の粒度以下では設計という工程と
>プログラミングという工程を分離する必要はない，ということで，
という発言と（粒度の面でも）同じだと思いますが
如何でしょう。

そして、後者において、もし、“好きにして”っていう
スタンスを取るとすると、
>分析や設計が不要だとか，いい加減なプログラムを書けば良いとか
>いうようなことは主張してません．
という発言と矛盾してしまうので、この意見にも同意頂けると
思います。

つまり、モジュールの粒度の面を共通に認識すると
お互い同意見になるのではないかと思いますが、
如何でしょうか。

>|ところが、オブジェクト指向型言語の場合、オブジェクトに
（略）

>それについては否定しませんが，なにか私が設計が要らないとか，
>思い付きでオブジェクトを定義すれば良いと主張しているかのよう
>に読めるのですが，気のせいでしょうか？
決してそのような意図はありません。
しかし、モジュールの大きさの解釈で食い違いがあって
そのため誤解を生じた可能性は否定できないと思います。
申し訳ありません。m(_ _)m

徐々に意見の相違点、同意点があきらかになっていくように感じる。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/TOmFMwkI0x8J
Yukihiro Matsumoto 	
1998/06/02

OOA is prerequisite to OOP? (Re: ソフト工学… )

まつもと ゆきひろです
"SENOH Yasushi"  writes:


    

    妹尾です。
    





    

    >ふむ，つまり「優れた設計者」であるが「プログラマとしては優秀
    

    

    >でない」人や「優れたプログラマ」であるが「ろくな設計が出来な
    

    

    >い」人が存在すると考えておられるんですね．
    

    

    

    

      少なくとも、そういう意味ではありません。
    


そうなんですね．それは曲解のしすぎだったかもしれません．謝罪
します．



    

    ＃ こういう表現ってへんですか？
    


表現は変じゃないです．ただ，元の表現は



    

      とりあえず、正論を吐いておくと、「優れた設計者」と「優れたプロ
    

    

    グラマ」では、「優れた設計者」の方が優遇されて良いんじゃないで
    

    

    しょうか。
    


というものでした．で，この発言のこの文脈での意味をとりかねた
わけです．で，結局はどういう意味だったのでしょうか？
もしかして

               優れた人材は設計に回すべきだ

ということ？ それとも全然違う意味？ いずれにしてもなんとなく
私の賛成していない設計とプログラミングの分離を前提にしている
ような気がするんですが…．

                                まつもと ゆきひろ /:|)

設計とプログラミングの分離を前提としているかいないか。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/HXU6Hf_t_zQJ
Yukihiro Matsumoto 	
1998/06/02

OOA is prerequisite to OOP? (Re: ソフト工学… )


まつもと ゆきひろです
os...@cs.ricoh.co.jp (Oseto Futoshi) writes:


    

    大瀬戸です。
    





    

    >私が(多分よしおかさんも)考えているモジュールはもっと大きな単
    

    

    >位です．
    

    

    

    

    私が(多分妹尾さんも)考えているモジュールはもっと小さな単
    

    

    位です．:-)
    

    

    

    

    ＃モジュールという言葉をつかったのが駄目だったのですね。
    

    

    ＃済みません。
    


じゃあ，私はサブシステムという言葉を使いましょう．



    

    しかし、ここでのモジュールがもっと大きな単位
    

    

    ＃たぶん、担当者に任せられる仕事の大きさの単位
    

    

    であるのならば、担当者が直接エディタに向かって、
    

    

    キーボードを叩きながら考えてると、おかしなことに
    

    

    なるのではないでしょうか。
    


# そもそも私が「分離しない」と言ってることは「キーボードを叩
# きながら考える」こととイコールではないのですが…，まあ，い
# いです．

一般論としてそういう「おかしなこと」が発生することが多いこと
には同意します．が，そこで「だから分離せねばならない」と考え
るか，「分離するかしないかは担当者が『好きにして』」と考える
かの違いでしょう．

私の欲しいものはルールではなく，ちゃんとしたサブシステムだけ
ですから．またルールを設定しないとちゃんと分析もしてくれない
技術者より，優れたサブシステムをアウトプットしてくれる技術者
が欲しいです(そうありたいです)．

で，これはシュリンクラップなソフトフェアプロダクトでは普通の
考えだと思います，多分．が，日本の多くの企業では(おそらくは
程度のあまり高くない技術者を大量に抱えていたため)ルールで縛
る性悪説的なやり方が横行している(いた)と考えています．



    

    つまり、モジュールの粒度の面を共通に認識すると
    

    

    お互い同意見になるのではないかと思いますが、
    

    

    如何でしょうか。
    


そうかもしれません．よくわからないけど．

                                まつもと ゆきひろ /:|)

ルールじゃなくて優れたサブシステムをアウトプットしてくれる技術者が欲しいという意見。
日本の企業の組織論になりそうな予感がしたりして…

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/cVhZ_RzipakJ
Hirotaka Yoshioka 	
1998/06/02

OOA is prerequisite to OOP? (Re: ソ フト工学… )

よしおかです．
なかなか琴線にふれるお話なんでリプライしちゃいます．
誰かを説得しよーとか，なにか新しい知見があるとか，
そーゆーことは一切ない，ただのプログラマのヨタ話です．

でもって，設計(未定義語)とプログラミングをわけるメリットってなんなんでしょ
うね．よくわからないっす．

Yukihiro Matsumoto  writes:
> まつもと ゆきひろです
> |大瀬戸です。
> |しかし、ここでのモジュールがもっと大きな単位
> |＃たぶん、担当者に任せられる仕事の大きさの単位
> |であるのならば、担当者が直接エディタに向かって、
> |キーボードを叩きながら考えてると、おかしなことに
> |なるのではないでしょうか。
> 一般論としてそういう「おかしなこと」が発生することが多いこと
> には同意します．が，そこで「だから分離せねばならない」と考え
> るか，「分離するかしないかは担当者が『好きにして』」と考える
> かの違いでしょう．
素人にプログラミングさせれば，そりゃだめでしょう．どんなことやったって，
とか思っちゃいます．

> 私の欲しいものはルールではなく，ちゃんとしたサブシステムだけ
> ですから．またルールを設定しないとちゃんと分析もしてくれない
> 技術者より，優れたサブシステムをアウトプットしてくれる技術者
> が欲しいです(そうありたいです)．
そーなんです．素人を救済しよーとするから，話がややこしくなるんです．
プロのプログラマにやらせりゃいいんです．でもって，これって鶏と卵なんだけ
ど，大学の教育とか企業の研修がプロのプログラマを育成するのに，どれだけや
くだっているかというと，ほとんど，なんの貢献もしていないのじゃないかと思っ
てます．あ，これは余談か．

> で，これはシュリンクラップなソフトフェアプロダクトでは普通の
> 考えだと思います，多分．が，日本の多くの企業では(おそらくは
> 程度のあまり高くない技術者を大量に抱えていたため)ルールで縛
> る性悪説的なやり方が横行している(いた)と考えています．
シュリンクラップなソフトウェアの開発現場ではプログラマがエディタであれや
これやしながらもの作っていきます．外部仕様書はあります．でも，デザインの
メモ程度のものはあっても，詳細な設計仕様書みたいな，それだけわたせば，素
人でもコードがかけるようなプログラムの一歩手前みたいなものは，少くともう
ちの会社にはありません．シリコンバレーの多くの現場もそうでしょう．コード
が最終的なよりどころです．外部仕様書を書く人と，コードを書く人が違う場合
もありますけど，それも多くの場合一緒だったりします．外部仕様を複数人で書
いて，複数人でコードを書くというパターンもあります．でも，外部仕様だけを
書く人とか設計だけする人とかプログラムを書くだけの人とかの区別はないです．
設計もすればコードも書く．

ある意味でハッカーがコードをハックしながらプロダクトを作っていく．そーゆー
イメージです．カオスといってもいいかもしれません．でも，モノは作られてい
ます．すごいスピードで．

素人にプログラムを書かせない．素人に設計をさせない．素人を何人あつめても
プロには勝てないっすよ．

あー，物議をかもしだすよーな事いっちゃったなあ．

よ

ただのプログラマのヨタ話キターー。
素人にプログラムさせない、プロのプログラマにやらせる。言い切っちゃっている。
ハッカーがハックしながら凄いスピードで製品を作っている。カオスである。
しかしこの人、随分挑発的な発言を続けているよな。ビシビシ物議を醸すような言い方だ。何かイヤなことでもあったのだろうか。日頃の鬱憤をはらしているような感じすらうける（笑）

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/_m2HEa5QpGMJ
Hirotaka Yoshioka 	
1998/06/02

"SENOH Yasushi"  writes:
> 妹尾です。
> >いずれにしてもなんとなく
> >私の賛成していない設計とプログラミングの分離を前提にしている
> >ような気がするんですが…．
>   私は設計とプログラミングの分離を前提にしてます。
>   確かに作業の流れの中では分離しにくいこともありますが、設計で
> すべきこととプログラミングですべきことは、まるで違うと思います。
> 
>   設計は、そのアーキテクチャを示すものであり、具体的に実装の
> 内容を指すものではないと思います。だから分離は可能だし、
> 現実的だと思います。
多分妹尾さんのおっしゃっている「設計」が示すものをわたしが理解できていな
いのだと思いますが．．．

>   逆に言えば、プログラミングから分離されていない「設計」って設計
> じゃなくてプログラミングだと思うんですけど。具体的にどう実装しよう
> かと考える行為は設計ではなく、プログラミングだと思います。

別に言葉は，どーでもいいっちゃいいのですが，プログラミングと分離した，設
計というのは，どーゆーナニなのでしょうか？抽象的は話だと，わたしは多分理
解できないので，たとえば，モジラに縦書きを追加するという要求があったとし
て，外部仕様で，< SPAN DIR=TTB >というタグがあったときに縦書きにする，となっ
ていた場合の「設計」ってなんでしょうか？

よ

双方で言葉の持つイメージが共有できていないために、議論がなかなか進まない。このもどかしい感じがインターネットの掲示板のようなものでのスピード感だった。議論の１往復が一日くらいかかることもあるので、延々時間がかかる。

設計とプログラミングは「分離すべき」か、それともそれは「すべきでない」のか。その論争の原点となる、そもそも「設計とは何か」、それを再確認している。

議論を振り出しに戻しているような発言である。

さすがに飽きて来た感じもするのだけど、もう少しで終わるはず。

まだ続く。