オブジェクト指向で隠蔽されると、逆に困る例

　オブジェクト指向の場合、隠蔽化され、変更が局所化されるというのがメリットになっています。
　でも、このことは、必ずしもすべて、局所的に直せばいいって言うことではないんです。なんで、逆に、局所的に直せない場合に、どのプログラムを直したらいいのか見えにくくなることがあります。

　その例として、「倉庫が１個から２個に増えた場合の例」を説明します
　（つまり、前のブログで、「引数自体ないしは、引数のデータ構造、さらに入出力テーブルの構造がずれると、思わぬところで、派生効果が現れてしまうのに、メソッドが隠蔽されていて、それに気づかず。。。」と書いた例です）

---

　倉庫が１箇所から２箇所に増えたとします。
　そうすると、在庫には、どこの倉庫に何個あるかという、倉庫の情報が必要になります。
　さて、オブジェクト指向の場合、在庫というクラスが切ってあれば、ここに倉庫情報（倉庫番号）を追加すればよい。簡単でしょ！
　。。。って言うわけないですよね。

　たしかに、倉庫情報を追加するだけで、プログラムは動いちゃいます
（だから問題なんですけど）。
　でも、倉庫が追加されるということは、入庫のときに、どこの倉庫に入れるか、出庫のときに、どこの倉庫から出すかという入出庫に加え、

　２つの倉庫を足したら、受注を受けられるけど、１個の倉庫だけではだめ

というケースをどうするかという問題が起こります。

　この場合、
１．一方にある倉庫の在庫を、もう一方の倉庫へ送る（倉庫間移動っていうと思います）
２．送られたほうの倉庫から出庫する

という手法をとると思います。つまり、倉庫間移動というメソッドも作る必要があります。

---

　さてこのとき、ＤＦＤが書かれていれば、在庫テーブルというデータストアにアクセスしている「プロセスが」図からわかるので、そのプロセスを担当しているＳＥ，プログラマに確認をとれば、ＯＫです。
　さらに、倉庫間移動というメソッドを追加すればＯＫです。

　しかし、オブジェクト指向だと、どのメソッドがどのテーブルのどのデータをアクセスしているのかのドキュメントは、ないことが多いです（JavaDocに、どのテーブルをアクセスしてるよー！まで、書いてないっつーか、JavaDocのコメントの内容説明って、人によってさまざま、つーか、ちゃんと書こう！）

　なんで、クラスの担当者に、在庫の修正内容を説明して、理解してもらって、その上で、自分がクラスのどこを直すか、判断してもらわないといけないです。
　さらに、「倉庫間移動」っていうのは、どこのクラスに入れるべき？というので、悩んでしまうんです。

---

　なんていうことで、ＤＦＤの場合、使っているデータとプロセスが直接結びつくので、影響するプロセスが見えやすいんだけど、オブジェクト指向の場合、本気で隠されちゃうと、関連するクラス程度しかわからず、そのクラス担当者に説明しても、自分が、その変更で、どれだけ影響するか？ということが見えないと、修正漏れになったりします。

　さらに、メソッドを追加する場合、どのクラスに入れるべきかというのを、テキトーにやられちゃうと、あとで、困ったりします。

　つまり、オブジェクト指向の場合、クラスというものが、ワンクッション入るので、本気で隠されてしまうと、そのクラスのどこまで影響が及ぶのかわかんなかったり、下手にクラスを切られてしまうと、かえって、保守に大変だったり、理解に苦しんだり、話を複雑にしちゃったりすることがあります。

　まあ、大きいプログラムでなければ、問題ないんだけどね。

オブジェクト指向だけでも、構造化分析だけでも、ある程度以上のシステムで問題が起こる。で、どうするか

　前に書いたブログ、「上司の「空気を読む」ことは重要、でも、言われたとおりにやるとプロジェクトが失敗する。そこが問題」は、システム開発論についてもいえる。
　システム開発論は、たいてい、「構造化分析」か「オブジェクト指向」かの二者択一の議論になっている。で、いま優勢なのは、「オブジェクト指向」。もちろん。

　だけど、オブジェクト指向の場合、むかし、いがぴょんさんも指摘していたように、ある程度の規模であれば、ぜんぜん問題ないんだけど、ある一定以上の規模になると、問題が起こる。

　これは、データ部分で問題が起こるんだけど、オブジェクト指向の場合、データを公開して、それを共用して参照するというかんじではない（逆に、情報を隠蔽して、カプセル化する）。だから、データ部分を決めずに（先送りして）どんどん、オブジェクトやメソッドがきまってしまう。

　そこで、普通、インターフェースだけを切っていくことになるんだけど、（ここで言うインターフェースは、javaのインターフェースの話でなく、引数とか返り値とかのインターフェースの話）このインターフェースとして定義される、引数自体ないしは、引数のデータ構造、さらに入出力テーブルの構造がずれると、思わぬところで、派生効果が現れてしまうのに、メソッドが隠蔽されていて、それに気づかず。。。ということがおこり得やすい（って、抽象的に書いてもわかりにくいので、倉庫が１個から２個に増えた場合の問題を例に、いつか、この辺の話題は、書こうと思う）。

　さらに、ＥＲ図とは直接結びつかないので、データの正規化部分が行われず、矛盾を起こしたりとかのリスクもある。で、なんだーかんだーで、オブジェクト指向は、データまでも、隠蔽されてしまうから、やりにくかったりする。

　じゃあ、逆に、構造化分析がやりやすいかっていうと、ある程度以上、大きくなると、こまったちゃんなことがおきる。

　構造化分析の場合、とくにＤＯＡの場合、データが中心なので、データ構造を明らかにしないといけない。しかし、「手順はわかるんだけど、データ構造ははっきりしない」ということも、結構ある。

　簡単な話、インスタントラーメンの作り方。
　材料＆利用する器具をすべて書きなさい。。。。
　結構見落とすよ。。ガスコンロまたは、電気ポットって、気がついた？

　でも、インスタントラーメンの作り方なら、簡単だよね！

　実務では、インスタントラーメンより、もっともっと難しいことをやるので、データ構造が見えないっていうことは結構ある。

---

　なので、どうするか。。。

　ウィリアムのいたずらは、ユースケース図から、ＤＦＤに変換し、ＤＦＤからＥＲにいって、ＥＲからクラス図をつくって、ユースケースと一致させる。こうすると、半自動化できる。

　このやりかたは、前のブログに書いたよね。

　この場合、クラス内のメソッドとＤＦＤのプロセスが対応し、プロセスへの入出力となるデータストアが、ＥＲ図のエンティティと一致し、ＥＲ図がＲＤＢのテーブルと一致する（となるように書く）。

　はじめと最後を抽出すると、
　　　　　クラス内のメソッドとＲＤＢのテーブルとの関係がわかる
　わけ。これにより、Ｏ－Ｒマッピングの、業務的な意味でのマッピングがとれる。
　Ｏ－Ｒマッピングツールは、技術的にＲＤＢとオブジェクトのマッピングをサポートしてるけど、じゃあ、あるメソッドがどのタイミングで、どのテーブルと結びつくべきかの業務的な流れを導き出してくれるわけではない（と、思う）。

　なんで、こういうふうにやるわけ。

---

　ところが、こんなやり方を提案したら、「顔面グーで殴られる」わけよ！

　世の中は、オブジェクト指向か、構造化分析かなわけ！
　で、さらに、構造化分析のかたをもつと、さっき紹介したいがぴょんさんのブログが、そのあと、いろんなところから攻撃を受けたように、現場でも、全員を敵に回す形になる。

　しかし、実際、オブジェクト指向だけで分析すると、それこそ、今まで書いてきたように、データが合わない！そのため莫大な意識あわせの時間と仕様変更になるのよ！

　なんでね、現場では、「こっそりと」オブジェクト指向と、構造化分析の両方を使って、やっちゃうわけ。

　最後に、構造化分析したＤＦＤをシュレッターにかければ出来上がり！
（なんで、簡単なのだと、頭の中でつくったり、電子的につくって、ゴミ箱に入れたり）

　ＥＲ図は、提出させられるので（オブジェクト指向なのに）、オブジェクト指向のユースケースとクラス図を提出して、「オブジェクト指向まんせー」って言ってれば、ＯＫなわけよ（みんな、おかしいと思わないのかなあ？なんで、ＥＲ図とクラス図が、バチンと合うのよ。途中に、なんか、使ってるはずじゃん）。

---

　で、ここからが、今日の書きたかった本題。

　そんなわけで、ＳＥさんの中には、オブジェクト指向なのに、こっそりＤＦＤを使ってみたりする人もいる。
　で、この前のうちあわせ。

　資料から、明らかに、情報関連図を使っている！とわかる人がいたわけ！！

　情報関連図というのは、その昔、ＤＦＤが出る前に、あるプロセスに対する入力と出力を書いていく手法。ＤＦＤが出てから廃れた。理由は、情報関連図だと、全体のデータの関連が見えないから。
　逆に言うと、データの全体像と、それを利用するプロセスが見えない状態でも、情報関連図は、部分的にかける。ちょうど、全体像がまだ見えないプロジェクトなので、彼は情報関連図を利用したんだと思う。

　しかし。。。だ！世の中も会社もドコモかしこもオブジェクト指向。
　まさか、「情報関連図をこっそり、使ってますね。さすがですね！」とは、いえない。

　それは、まるで、会社、残業中とかにしておいて、キャバクラにいったら、やっぱり残業しているはずの上司とあって、「お、このキャバクラ、こっそり通ってるんですね。さすが上司、お目が高い！」というようなもんだ。お互い残業中になっているので、そんなこと、いえないだろう。

　つーことで、「お、さすがですね」と思ったけど、その場でいえなかったので、ここで書いたわけ。

　全体像が見えないときに、それでも、部分的な入出力の意識あわせをしようとして、情報関連図という古典を持ってきたのは、さすがだと思った。

上司の「空気を読む」ことは重要、でも、言われたとおりにやるとプロジェクトが失敗する。そこが問題

　以前書いたブログ「サラリーマンって、実際、「責任」はあるけど、「権限」は無いよねえ、だから「空気読む」のが大事！」っていうのを書いたけど、たぶん、今、現場の問題は、

・会社の空気を読んで、上司の思ったとおりにやると、どー考えてもプロジェクトが失敗する。
　つーか、そんなとおりにやったら、「自分は、仕事に殺される！」
　　→たぶん、上司にとって、部下の１人や２人が死のうと、病院に行こうと、大勢に影響は無い
　　　（変わりの人間を求人すればいいだけ）にすぎないが、自分にとって、死ぬのは大変。

・若手は提案してくるが、そのとおりやっても、うまくいくとは思えない。
　→その提案が受け入れられることが少ない。
　　なので、受け入れられたら、どーなるのかのシュミレーションが若手の中で
　　出来ていないように見える。
　　どーかんがえても、受け入れられたら、今より大変！混乱する

・転職しようにも、業界全体が、こういう状態に見える。
　→ほかの業種にいくには、年齢が行き過ぎている

・でも、仕事が出来ている会社はあるのよねー
　→なぜ！？

だと思います。で、この種明かし。

---

　上司が思っていることが、若手の人たちからみると、変な場合があります。
　例でいいましょう。テストが分かりやすいかな。。。

　誰かのブログでみたけど、上司から、こう言われたことはありませんか？

　「テストは、プログラムが終わってから、まとめてしろ！」

　で、若手がこれに反発し、テストファーストで主張するが聞き入れられない。若手はなぜだか分からない。という状況。これ、結構ありえます。
　で、そのブログで気になったのが、上司がいう、理由がわからないってこと（クリーンルームではない。明確な理由が在る）。あれ、この話題、取り上げたっけ？

---

　この「プログラムが終わってからテストする」というのは、第三次オン当時から、９０年代初めに行われた方法で、ＳＥがテストケースを作成する場合に行われます。
　で、なぜ、この方法が取られるかというと、

・一人で抱え込ませない（一通り書いて、レビューできるようにする）
・全体最適と部分最適は違う

という理由からです。詳しい話にかんしては、別のブログで書きますね。

　で、ただ、この方法だと、９０年代中盤からのオープンシステムの場合、動くかどうかわかりません。
　９０年代前半で、システムをビジネスパターンに分けることによって、枯れたプログラムをつなぎ合わせる手法が、ＳＥという存在が業界から省略される（この状況に関しては、稚北大学の宣伝の例をあげて、別のブログで、「じっくりと！！！」話をさせていただきます！！）ことによって、なくなってきた（２０００年代に入って、デザインパターンというまったく違うものが、世の中の支持を得られるようになった。デザインパターンを枯らしても、業務プログラムは枯れない）ので、この手法では、問題が起こりました。

　そこで、２つの方法があります。
　１つが、テストファーストの手法です。これは、エラーいひとがいった手法なので、こっちは支持されました。ただし、これは、先ほどの、一人で抱え込まないという問題を解決していません。
　そのために、大きな問題を生み出すことになっています。
　（この辺の事情は、さきほどの詳しい話にかんしてとあわせて、別の機会に書きます）

　もう一つの方法が、要素に分けてしまい、リスクのありそうなプログラムを先にプロトタイプ段階で作ってしまい、開発部隊を投入する段階では、つなぎ合わせればいいようにする方法です。この考えの変形は、リスクドリブンになります。情報処理試験のプロジェクトマネージャーの重要キーワードとして、「リスクドリブン」が出てたと思いますが、そいうったわけです。
（以降、「リスクドリブンっぽい法」と書く）

---

　しかし、会社で、「リスクドリブンっぽい法」を提案しても、上司がＯＫを出すわけはありません。上司としては、できれば方法は変えないほうがいいと思っています。なぜなら、昔やった方法では、システム開発が成功しているわけです。むしろ、最近のシステム開発（オブジェクト指向が流行りだした２０００年代）のほうが、失敗しているケースがおおいように感じていると思います。なので、成功確率の高い、昔の方法のほうが、いいわけです。

　もし、１００歩ゆずったとしても、テストファーストです。テストファーストなら、そういう本も出ているし、えらーい人がいっているから、なんか安心です。

　ということで、若手の意見が出てきたとしてもテストファーストなので、こっちが採用されてＪＵＮＩＴでのテストとかもやられたりします。

　でも、さっき書いたとおり、大きなシステムでは、問題が起こり、失敗するケースがおおいです。

---

　でも、「リスクドリブンっぽい方法」を提案しても、これは、絶対上司に受け入られません。
　嘘だと思ったら、ためしに言ってみるといいです。
　「”リスクドリブンっぽい方法”という新手の方法があるらしい。これを採用したらどうか？」
　　上司はいいます

　「それを提唱している人は」
　「ウィリアムのいたずら」
　「って、だれ？？」
　「フリーのＳＥ、ぷーたろうみたいなもんっすね。。。」

　きっと、あなたは、上司から、顔面グーで殴られます。

　上司自体は、内容から判断できないっていう人が大多数です。どこかの権威ある人が言うことが必要です。ぷーたろうがいっても信じないでしょう。

---

　なんで、うまいこといってる現場のＳＥさんの場合、いろんなことを、こっそりやってるっていう場合が多い気がします。

　よく、言われませんか？（私は、良くこの言葉を使うんですが）

「こういうやり方は堂でしょうか？」と提案すると、

「その提案、聞かなかったことにする。もし、聞いてしまえば、絶対反対せざるを得ないが、聞かないでやる分には、なにもいえない。やっちゃったモン勝ち」っていうやつ。

　テストの場合、上司のいうとおり、

　「テストは、プログラムが終わってから、まとめてしろ！」

　とやった場合は、まず、昔と状況が違いますから、たいてい失敗します（失敗する可能性大）
　でも、こっそりテストファーストでやったり、リスクドリブンっぽい方法でやっても、上司は、文句いえないって言うか、気づかない。なんで、そういう方法でやって、上司には、「はい、まとめてテストしてます」っていうような顔をして、やってる場合って多いんじゃないかなあ。。。

　今回は、てすとだったけど、プログラム作成なんか、そうしないと、ほんと、殺されちゃうよ！上司の言ったとおりにやってたり、本に書いてあるとおりになってたら。。。

---

　ブログのすごいところは、匿名なんで、そういう、テストファーストの問題点や、そのため、こっそり現場でやっているつじつま合わせ（テストドリブンっぽい方法）が、かけることだね！

　あ、ちなみに、そのテストドリブンっぽい方法、っていうのを、どうやるかについても、別の機会に書きますね。

　あたりまえだけど、ウィリアムのいたずらが、実名入りで、こんなの書いたら、たいへんなことになっちゃうよお！！
（もっとも、経歴まで書いてしまうと、結構信じてもらえるかもしんない。
　今は、ぷうたろうというだけで、過去を書くとじつは。。。

　おしえないぴょ！だって、そうしないと、匿名になんないじゃん！）