冷たい方程式（9） 原則と現実
八木社長とムツミさんは、指定の時刻より10分ほど早く現れた。総務部の受付業務は17時30分で終わってしまうので、反対側の警備センターから入ってもらう。
「遅い時間にすみません」八木社長は頭を下げた。
「いいんですよ。私もたまには残業しないと」本当は残業にはならないのだけど。
会議室では渕上マネージャが待ち構えていた。呼んだ覚えはないのに亀井くんも何食わぬ顔で座っている。磯貝課長は、関わり合いになりたくないのか、テクニカルアドバイザーの職務を放棄して、さっさと帰ってしまっていた。まあ、同席してもらっても役には立つわけではないのだけど。
八木社長は挨拶もそこそこに、早速、本題に入った。
「それでは、よろしくお願いします」
あたしたちは、それぞれ持参した仕様書一式を開いた。今回、レビューのモデルケースとして選択したのは、職位マスタメンテナンス画面だ。渕上マネージャは、最初にクラス図を取り上げた。
「これはプロの設計とは言えませんな」渕上マネージャは、冷たい声で指摘した。「ビジネスロジックのクラスとして、MaintenancePositionMasterLogic1つしか定義されていない。その中に、画面の初期化、検索処理、確認処理、登録処理、更新処理、削除処理、印刷処理などのメソッドが詰め込まれている」
「どこがいけないんですか？」あたしは聞いた。自分のため、というより、発言しづらそうな顔のムツミさんのためだった。
「君は、SRP……単一責任原則という言葉を知らないのか」
「……一応、知ってますが」
「では、このクラスがSRPに則っていないことぐらいは分かるだろう」
「どういうことですか？」八木社長は首を傾げた。「SRPとは何でしょう？」
あたしは、単一責任原則の意味を簡単に説明した。
社内SEという職種になってみて分かったことがある。SIerに比べて、プログラミングの機会は圧倒的に少ないが、逆に、体系的な勉強をする時間は意外に多い、ということだ。うちの会社では毎年、期首に当年度の目標を個人ごとに最大6つまで設定し、その達成度を期末に評価される。開発グループはIT関連の資格取得が多いが、「クラウドの実用性についてレポートを作成する」というような研究目標でも可だ。あたしもそのたぐいのレポートを作成するために、デザインパターンやアスペクト指向、DIなどを勉強したことがあり、基本的な用語については頭に入っている。
SODECなどの展示会に足を運ぶことも推奨されていて、ビッグサイトには毎年のように行っている。毎日、終電ぎりぎりまで仕事をしていた、前の会社では考えられないことだ。
プログラミングを日常的に行っているSIerよりも、お気楽な社内SEの方が最新技術の動向に詳しかったり、オブジェクト指向の体系的な知識を身に付けていたりする。まったくこの業界は皮肉に満ちていると思う。
説明を聞き終えた八木社長は、釈然としない表情で訊いた。
「つまり、1クラス1メソッドという構造にすればよろしいんでしょうか？」
「そこまで極端である必要はありません」渕上マネージャは、淡々と告げた。「だが、1つのクラスには1つの責務というのが原則ですな。プロならそれぐらいは理解しておいていただきたい」
ムツミさんの表情が曇った。それが困惑なのか怒りなのか、まだ付き合いの浅いあたしには判別しがたい。
「あの、いいですか？」珍しく亀井くんが発言した。「今のままの方が、後々、保守がしやすいと思うんですけど」
あたしも本心では、その意見に賛成だ。SRPの利点は否定しないが、すべてに適用しようとしても、複雑さを増すだけだと思う。
渕上マネージャは、軽蔑したような視線で、亀井くんをじろりと睨んだ。まるで物理的な攻撃を受けたように、亀井くんの小太りの身体が後ろにずれる。
「君は経験不足で分かっていない。明確な責務に分かれたクラス設計は、後々の保守のために必要不可欠なものだ。もっと勉強したまえ」
亀井くんは何かを訴えかけるようにあたしの顔を見た。あたしは渋々、口を開いた。
「あの、SRPの目的は、そのクラスを変更することによる影響範囲を最小限にとどめることにあると思うんですが」
渕上マネージャが無言で視線を投げつけてきたが、あたしは構わず続けた。
「このロジックに関して言えば、職位マスタのメンテナンス以外で使用されることは、まずないと考えられるので、どのような構造になっていても、他への影響は少ない、というか、ないのではないかと思いますが」
渕上マネージャはゆっくりと頭を横に振った。
「これは原則の問題だ」無機質な声でゆっくりと告げる。「SRPがクラス設計の最も重要な原則の1つであることは明確だ。原則から外れるのであれば、それ相応の理由がなければならない。私の考えでは、君の意見はその理由にはなっていない」
「職位マスタメンテナンスに関するメソッドが、1つのクラスにまとまっていた方が保守しやすい、というのが大きな理由です」
「クラスの責務が明確になっている方が、保守はしやすい」渕上マネージャは断言した。
誰がソースを読むか分からないSIer依存のシステムなら、クラスの責務が明確になっていることは重要かもしれない。だけど、このシステムを保守していくのは、あたしであり、亀井くんだ。あたしとしては、SRPにこだわった美しい構造より、保守しやすい構造になっている方がありがたいのだけど。
渕上マネージャは、デザインパターンは知っているらしいのに、YAGNI――今、必要じゃないものはきっといらない、という言葉を知らないのだろうか。
もっとも、あたしはそんな言葉を持ち出す気は、さらさらなかった。今、一番やりたくないのは、この場で「設計とは何か」みたいな議論を延々と繰り広げることだ。
「分かりました」八木社長も議論で時間を浪費したくない、という考えは同じのようだ。「こちらの勉強不足でございました。おっしゃるとおりに修正させていただきます」
ムツミさんは不服そうだったが、何も言わなかった。話を先に進めてもらいたい気持ちの方が大きいのだろう。時間が一番気になるのは、実際に仕様書を作成する立場のムツミさんだから。
「先に進みましょう」あたしは提案し、全員が賛成した。
あたしたちが解放されたのは、それから2時間後だった。
渕上マネージャの指摘は、仕様書のほぼ全ページに及び、ムツミさんは、それらの指摘事項を必死で書き込んでいた。赤のボールペンでの書き込みで、遠目にはページがピンク色に見えるほどだ。それでも足りなくて、裏にまで追加で記述がある。
渕上マネージャが退席した後、残されたあたしたちはぐったりしていた。疲労度が一番高いのは、もちろんムツミさんだろう。気の毒に、汗で薄い化粧が乱れている。
「おつかれさまでした」あたしは声をかけた。
「ここまで細かく指定されるとは思いませんでした」ムツミさんはつぶやいた。
八木社長も、いつもの温和な笑顔を忘れて苦い顔をしている。この仕事を、あんなに安い見積もりで受注したことを後悔してなきゃいいんだけど。
渕上マネージャと一緒に会議室を出ていった亀井くんが戻ってきた。手にはコーヒーカップが4つ載ったトレイがある。
「どうぞ」亀井くんは、真っ先にムツミさんにカップを渡した。「クリームと砂糖、いりますか？」
ムツミさんは驚いた顔で亀井くんを見たが、すぐににっこり微笑んでカップを受け取った。
「ありがとうございます。じゃあ、クリームだけ。いただきます」
亀井くんは、八木社長とあたしには、トレイごと渡しておいて、自分はいそいそとムツミさんの隣に座った。自分のカップを手にして、何やら話しかけている。ムツミさんも、儀礼的に仕方なく、という態度でもなく、案外楽しそうに受け答えしていた。あたしは、見ているのもアホらしくなって、八木社長にカップを渡すと、小声で訊いた。
「こんなに工数かけてしまって、ぶっちゃけ、赤字にならないですか？」
八木社長は困ったように苦笑した。
「ぶっちゃけ、ぎりぎりです。いつものことですがね」
「大変ですね」
「ええ、まあ。来週から片寄がお世話になりますが、この分だとすぐに実装に入るのは難しいかもしれません」
すでにムツミさんの席とPCは用意してある。
「私たちもできるだけフォローします」そう言って、あたしは亀井くんの方を見た。「まあ、あいつは放っておいても世話を焼くでしょうけど」
「心配なのは、実装面ですね」八木社長も心配そうな顔で部下を見た。「同じように細かく指示されると、スケジュール面でも遅延が出てきそうで……」
その責任をホライゾンシステムに押しつける、というのは、いかにもありそうな話だ。
「磯貝とも相談して、何とか遅れないようにしてみます」
と言ったものの、磯貝課長があまりあてにならないことは、八木社長も知っているので、その表情が晴れることはなかった。
「それはそうとちょっとお訊きしたいのですが……」八木社長は、渕上マネージャが退出したドアをちらりと見た。「渕上さんは、ずいぶんシステム開発の経験がおありなんですか？」
「うーん。それは私も知りたいんですけどね。なぜですか？」
「いえ、何というか……」八木社長の視線が、言葉を探すように天井付近を泳いだ。「日比野さんもお分かりかもしれませんが、この業界にある程度長くいると、話している相手のスキルや経験がだいたい見えてくるものなんですよ。例えば、日比野さんはSIerで経験を積まれてきたんだな、とか」
「ああ、なるほど」あたしは同意した。「確かにそれはありますね」
「へええ」と割り込んできたのは、亀井くんだった。「そうなんですか。ちなみにぼくはどう見えますか？」
いつのまにか、亀井くんとムツミさんが、こっちの話を聞いていたようだ。ムツミさんも、興味の色を浮かべている。
「そうですね……」八木社長はちらりとあたしを見た。
「構わないから言ってやってください」あたしは許可した。「正確なところを」
「えーとですね」八木社長は苦笑した。「まあ、正直なところ、ちょっと経験不足なところがありますね。カンのようなものがないというか。すみません」
ムツミさんが思わずクスクス笑った。
「カンって……当てずっぽうってことでしょう」亀井くんは憮然となった。「そんなものどうやって養えば……」
亀井くんは誤解している。カンは経験とデータの蓄積によって形成される処理機能だ。当てずっぽうとは違う。
「それでですね」八木社長は話を戻した。「渕上さんは、ちょっと読めないんですよ。知識は確かにあります。一夜漬けで詰め込んだ短期記憶というわけでもなさそうです。でも……」
「でも、開発の経験があるようには見えない……」とあたしは言葉をつないだ。「……ですか？」
八木社長はうなずいた。
「ああいう人に会ったのは初めてです」
「私もですよ」
考えてみれば、あたしたちが渕上マネージャについて知っているのは、本社でERPパッケージ導入の責任者だったということぐらいだ。SIerにいたことがあるのか、そもそも転職してうちの会社に来たのか、など、過去についてはまったく分からない。
「あの人が徹夜でコーディングしている姿なんて、ちょっと想像できないですねえ」亀井くんが言い、全員が力なく笑った。
「とにかく無事に終わりたいですね」八木社長は最後に、ポツンとつぶやいた。
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
くくな
亀井くんの意見に賛成。
クラスの数が、おおくなりすぎると、管理が大変だし、
追うのも大変。
BEL
「これはプロの設計とは言えませんな」
これ以降の発言をみればいいたいことはよくわかるが、
これは仕事上のかかわりがある人に対する"プロの発言"ではないｗ
渕上さんのキャラ流行ってほしいわｗ
オブジェクト指向を突き詰めていくと、
確かに柔軟性は上がるだろうけど、可読性は下がっていく。
なので保守性が上がるかどうかはそのシステムによる。
規模によってはカウボーイで行った方が全然いい場合もあるし。
「このシステムを保守していくのは、あたしであり、亀井くんだ」
この考え方は、どうかね。このシステムをいつまで使うとか決まってないんですよね。
管理部署が変わったり、この２人が退職しても大丈夫なようにはしておくべきでしょう。
ところで私には、いまのところ渕上さんが
「開発の経験があるようには見えない」とまでは映らないですけどねえ。
第１話で「ホライゾンシステムに発注することに決めた。
この決定を、その後、あたしは何度も後悔することになる。」
ってあったけど、
どの会社に発注するかは、渕上さん出現とは関係ないわけですよね。
他の高い会社なら、渕上さんの要求にこたえても
想定リスク内におさまってたって理論なのかな。
fgnplo
これは・・staticおじさんならぬ
オブジェクトおじさん・・か？
elseorand
SRPのために一般的には
ビジネスロジックは、機能毎の複数インターフェースを実装し、
各メソッドはStrategyパターンを利用して、
実装を委譲・転送するのが望ましいのですが、
これ文中にあるように「マスタメンテ」ですよね。
クラスの変更理由なんて「DBテーブル構造の変化」以外には、
ほぼ発生し得ないわけで、特に理由もなくそれ以外を想定するのは、
YAGNIに違反ですね。
変更の予見こそが「カン」であり極めて重要なスキルな訳ですが、
やっぱりこの渕上マネージャーは、「バカ完璧主義者」に過ぎないな～
SRPが「変更理由」を観点にしているところまで理解できていないですね。
banana
八木社長の発言で大体わかった気がします。
ホライゾン社はユーザ企業の情シスと交渉した経験がほとんどない。
おそらくこれまでは二次下請け、三次下請けで
元請けがやっている仕事も見えていない。
そりゃ孫受けの単価で見積もれば安くなるよ。
視野の広さというか、システム開発への理解は、
開発の仕事といったら設計書作成とコーディングの亀井くんと同レベル。
正直、あきれました。
banana
YANGIってもあれでしょう。
開発時は必要と思わなかったのでやりませんでしたというやつ。
それで、運用に入ったら想定外で、
あとから追加すると膨大な工数がかかるといわれ、
原因は要件義の漏れとなる。
じゃあ、要件定義漏れをなくすにはと検討すると、
上流工程が、要員育成が、変更管理が、開発プロセスがと
どんどん収拾つかなくなる。
原理原則で押す渕上マネージャー、
現場たたき上げのノウハウで押す三浦マネージャー、
私にはどちらも自分の哲学を持っているひとかどのマネージャーに見えます。
・・・この物語、良くできいる。
現場の人の見方を知ることができて、
勉強にはなるのですが、
年寄りにはこたえますね。
abc
> ・・・この物語、良くできいる。
> 現場の人の見方を知ることができて、
> 勉強にはなるのですが、
> 年寄りにはこたえますね。
某有名画像「the war between developers, designers & project managers」を思い出してしまいました。
このコラム作者さんの描くマネージャは、いつも×能な働き者としての出演なので少し違いますけどね。
nanashi
>>bananaさん
YAGNIはXPというアジャイル開発の一種の用語で、アジャイルが前提です。
XPでは複数回要件定義的なことを行うので、YAGNIでいいんです。
「お客様は使ってみないと欲しい物がわからない」という事実に対応するため
ミニマムで運用を始めて必要要件を洗い出しつつ継ぎ足して開発していくと。
こうなると「トータルの予算は？成果物は？納期は？」という疑問に行くかと思いますが、そこは既に10年以上前の話のため名著を読んでいけば答えは載っています。
とおりすがり
＞YAGNIはXPというアジャイル開発の一種の用語で、アジャイルが前提です。
いやそうでもない。
ウォーターフォールでさえも、その原理原則は生きている。アジャイルではそれがより強くでるだけで、ウォーターフォールだから要らない機能を盛り込めなど誰も言ってない。
むしろ日本のウォーターフォールだと、仕様書には「欲しい機能」は盛り込めるだけ盛り込むけど、「実装方法」については分かってないからできるだけ何も書かないよな。
WhiteBall
どちらかと言えば、渕上マネージャに近い考え方でシステムを作ってきました。
「オブジェクト指向とはこういうものだ」という決めつけですね。
しかし、年数を重ねるにつれ「YAGNI」は大事だなーと考えるようになってきましたね。
そのあたりの「バランス」をとれるかどうかが大事なんだと思いますが。。。
この「バランス」が曲者で、結局、レビュアーの個人裁量になってしまう気がします。
たとえ会社でコーディングルール的なものが決められていたとしても、です。
ハムレット
>考えてみれば、あたしたちが渕上マネージャについて知っているのは、
>本社でERPパッケージ導入の責任者だったということぐらいだ。
良くある話で、ERPパッケージ導入と云っても、会社によっては大量のカスタマイズが断続的に発生して、出来あがったコードがスパゲティの嵐で、性能劣化や改修の度にデグレが発生するって事も良くある話だと思います。
渕上マネージャが原理原則に拘るのも、案外とその時のカオスとの戦いがトラウマになっているってこともあるのかな。・・・とか考えてみる。
まあ、いちいちデザインパターンで設計段階で縛らなくても、コードメトリックスをチェックして、クラスやメソッドサイズに制限を掛けて押さえるとか、コードクローンの割合をチェックするとか、包括的にスパゲティコードの発生を抑え、管理する方法はあると思うのですが。
どうなんでしょうね。
banana
なるほどYAGNIか、YANGIじゃなくて。
勉強になりました。
ありがとうございます。
banana
30にもならないSEもどきや、
開発の一部しか知らないであろう
「この業界にある程度長くいる」人がカンを語る。
フィクションなんだから、
ここまで現実のシュールさをコピーしなくても。。。
読み返して気が滅入った。
悪い夢を見そうだ。
この上は利用部門からスーパーマンが登場して、
全ての問題を解決する展開にして欲しい。
カタルシスがなければ
やってられない。
あら？
今までと同じパターンかと見せて。
ひょっとして、実は逆というパターンですかね。
まあまだわかりませんけれど。
現状で出ている情報を素直にとると、
渕上マネージャが間違っているように見えますけれど。
細部にこだわるのは無駄にコストがかかるパターンが多いですし、
マスタメンテのような単純な機能にオブジェクト指向があまりいらないということは、
マーチン・ファウラーさんですら言っています。
とはいえ。
よくよく考えてみると出ている情報は少なく、一部の人間の主観でしかないわけで。
仕様書の品質が実際にはどれだけ低いのかは読者に示されていませんし。
オブジェクト指向設計も必要ないから使わなくていいと高をくくっていると、
ある日複雑な機能が必要になって、
収拾がつかなくなりデスマーチに叩き落されたりします。
使わなくていいというのが勉強したくないための希望的観測だったりすることも多いですし。
そういう可能性があるかどうかについて、我々は何も情報を与えられていません。
とりあえず八木さんの反論が今一つなのは今回で見て取れたといっていいと思います。
本当にオブジェクト指向知らずに言っているんじゃないかと思わせる。
ムツミさんの発言がなかったのも意味があるのか。
実は今回一人だけ渕上さんについていけるレベルにいるのは彼女だけとかいう話なのか。
それとも単なる深読みのしすぎか。
まあ私の深読みが当たることはあまりないわけですが。
小説というものは作者の掌の上で転がる楽しみがありますね。
BEL
前作は橋本さんを改心(？)させたという結末があったけど
今回はそういうのはあるのだろうか。
今は何かに取りつかれたような渕上さんだけど
今後人間らしさがみられるような展開はあるのだろうか。
ていうか、ここまで首突っ込むなら冗談抜きで自分で実装したほうがいいわ。
こういう人、会ったことないわけでもないなあ。
技術者気質だけど、コンサルにあこがれてるのか、
プログラマの仕事は断固やらない(けど気になっちゃって首突っ込む)。
誰も読みもしないのにUMLで書くことに固執する。
ローカル変数が共有されたら困るから(されねーし)staticメソッド使用禁止。
処理はなるべくストアドに書く(ビルドしないで取り換えられるから)。
通りすがり
＞30にもならないSEもどきや、
＞開発の一部しか知らないであろう
＞「この業界にある程度長くいる」人がカンを語る
こういう書き込みをしちゃうあたり老害が露呈してるよね
恥ずかしく無いのだろうか
年齢が高かったりすれば偉いとでも思ってるのかね
こういうのがいるから社会システムが腐っていくんだ
としろう
しかし酷いなこりゃ
ドキュメントもデザインパターン適用も過剰品質ではないのか？
コストカットとは対極ではないのか？
オープンソースソフトの方のドキュメントや信頼性はいいのかね？
条件の後出しは反則だろう。
もう再見積でいいんじゃね？
YAGNI関連の話だと
使いまわしや汎用性を考えて原則論をかざして作ると必要な物を作るのに
必要な工数に比べ余分にに工数がかかる
よってその必要性が薄いと判断すれば最小限で済ませるべき。
だが、逆に当初になくて、又は念を押して確認したのに
「やっぱり追加機能が要る」と手の平を返される事も少なくない。
そこで「そのようなことは無い」とされたが、
それで低減される工数又は、要りそうになる追加要素が小さければYAGNI違反をする。
どっちの原則論にも傾倒しない所に最適な落とし所があると思っている。
banana
> 通りすがりさんへ
私のコメントを読んで
誰を連想したか知りませんが
私は別人です。
物語に戻って、主人公は渕上マネージャーの原理・原則論に
対応できるだけのITスキルがないようです
（YAGNIの理解も不十分そうだ）。
それでも渕上マネージャーを止めたいというなら
「経験とデータの蓄積によって形成される処理機能」を根拠に、
オーバースペックを主張しても無意味。
役職が上の年長者に通じるわけがない。
幸いのことに、勤怠管理システム再構築なんだから、
過去の実績をしらべて
この箇所では保守作業が発生する可能性が低いと説得したらどうでしょうか。
曲がりなりにも、今システムを見ているのだから、
実績データなら落下傘マネージャーに対抗しうる。
なお、渕上マネージャーに近い立場にいるので肩入れしていますが、
私だって渕上マネージャーに問題がないとは思っていません。
自分の考え、見通しをメンバーに説明する努力をしていないあたり、
大いに問題だと思っています。
・・・ところで、ふと思ったのですが、
現行のシステムに不満があっての再構築なのに、
利用者部門の不満というか、改善要望を聞いていませんね。
要件定義フェーズがすっぽり落ちている気がする。
これも伏線でしょうか。
banana
エースシステムがぼったくった保守案件とやらが
今回問題になった箇所にも影響与えていたら、
主人公には悪いが、ここは渕上マネージャーに譲れというしかない。
んでもって、ホライゾンシステムの状況を
率直かつ頻繁に渕上マネージャーに報告すること。
渕上マネージャーの立場では契約見直しが難しい可能性もあるから、
見ているだけの人と思っていても、課長にも働きかける。
で、なんらかの指示をもらって、
それを一つ一つ片付ける。
八木社長と愚痴っていても前には進めない。
# 作者さまへ。
# 興味深い物語、ありがとうございます。
大手SIer
取りあえず分かったこと。
技術的な知識以前に渕上マネージャ以外は全員、今のご時世でそれなりの規模の
親会社を持つ子会社の勤怠管理システムがどういう隠し要件をもっているか分かっていない。
※渕上マネージャーは書いてないのでよくわからない。
まず、企業経営を考えた時、人事系とは言えども決算に影響するシステムの保守に関する
考えが甘すぎ。
とくに
>このシステムを保守していくのは、あたしであり、亀井くんだ。
>あたしとしては、SRPにこだわった美しい構造より、
>保守しやすい構造になっている方がありがたいのだけど。
の発言はSE失格ですね。
そのシステムの保守が担務の人が保守するだけで、今後も含めて保守は開発メンバーが
保守し続けている保証はない。
また、こういったシステムは自身が不慮の事故などで出社できなくなることも考えるべきだし、
「自分が保守しやすい＝誰もが保守しやすいではない」という観点も持つべきでしょう。
SRPがいいか悪いかを論じる前に思考を変えるべき。
あとは、機能面では言われたものを作ればいいと考えているように見える。
私ならこの規模の企業だと業務系の基幹系システムとの連携や、親会社を含めたシステムの
最適化でよくある統合人事DBが外部システムとしてできたときに困らない程度の設計にする。
他は要件などをきちんと見ないとわからないけ、どこの会社でもあるこの程度の要件なら
マスタを利用するクラスを分ける用途ごとに最適化する程度でほとんど手間にならない。
結局としろうさんの書かれている
>それで低減される工数又は、要りそうになる追加要素が小さければYAGNI違反をする。
>どっちの原則論にも傾倒しない所に最適な落とし所があると思っている。
ていうのが、SEとしての経験とカンの見せ所だと思いますけどね。
「ホライゾンを含め開発メンバーは、コードは書けるかもしれないが
『今や基幹系システムとみなされている企業の人事系システムを開発する』という点において
あまりにも経験が不足している。」というのが私の所見。
としろう
ちょっと渕上氏の言動は色々矛盾に思えるのですよね。
「君たちには、コストという考えはないのか？」
と言って置いて、設計書の作りこみ品質と、過剰にも思えるプログラム設計方針
これは自社で無いので脅せば只同然で出来ると考えているように見えてしまう。
そして金額としてのコストを低くした結果の構成では
大手SIerさんの想定するケース
>私ならこの規模の企業だと業務系の基幹系システムとの連携や、親会社を含めたシステムの
>最適化でよくある統合人事DBが外部システムとしてできたときに困らない程度の設計にする。
ようなケースでは不釣合いであるように思う。
その場合に一体化・同居を考慮すればOracleなどにしておいてもいいはずだ。
よって、渕上氏は目先のコストをカットしているだけの可能性が高い。
上からの立場で高圧的に質問するようでは問題解決の最適解は逃してしまいますね。
発注側、客側、エンドユーザ側、どの立場でもね。
今回は渕上氏の判断が間違っていたら迷走のパターン。
デザインパターンに原則論をかざすならアンチパターン的な所にも目をつけていて欲しかった。
原則論をかざしすぎる所から実装の経験が無いに等しいか視野が狭い人なんでしょう。
※管理面や紙の上での話は見えても、現実と現場は見えていない
banana
コメントの大多数が渕上マネージャーの手法を
行き過ぎた過剰品質を求めるコスト高の手法とみなしていることが、
私には不思議でなりません。
渕上マネージャーが求めるレベルが妥当という可能性はないのでしょうか。
主人公やホライゾンの見通しが甘すぎた可能性は？
コメントの大多数が渕上マネージャーには
経験や現場感覚に乏しく、バランス感覚が悪いと見ていることが
私には不思議でなりません。
YAGNIとSRPどちらに重きをおくか。
現場の人のほうが正しく判断できるという根拠は？
「現場」に運用開始後、数年にわたって保守したことがある人、
あるいは複数のシステムを横断的に分析したことがある人は
どれくらいいるのでしょうか。
渕上マネージャーは何も語りませんが、
そういった「現場」から見えない「現実」を
見ている可能性はないでしょうか？
elseorand
>渕上マネージャーは何も語りませんが、
>そういった「現場」から見えない「現実」を
>見ている可能性はないでしょうか？
渕上マネージャーが深謀遠慮だとしても、
言葉に出して説明していない時点で、
渕上マネージャーが駄目な理由が変わるくらいでしょうね。
>YAGNIとSRPどちらに重きをおくか。
>現場の人のほうが正しく判断できるという根拠は？
そもそも渕上マネージャーのSPRの理由自体が、
半可通そのものです。
業務上・プログラミング上の妥当性のない・妥当性を提示しない
クラスの細分化は、QCDどの面からも害悪です。
としろう
banana氏が自分のコメントにコメントしているようですので。
>渕上マネージャーが求めるレベルが妥当という可能性はないのでしょうか。
当初主人公が言った10人日程度の工数であり、
DBをオープンソースにとかアンバランスな言ってなければ
キッチリ作って欲しいという事なんだという事で妥当ではないだろうか？
成果物としての品質を高く要求するなら応じた対価は必要です。
SRPを持ち出して、工数UP方向で細かい作りにまで口を出すなら尚更。
>YAGNIとSRPどちらに重きをおくか。
>現場の人のほうが正しく判断できるという根拠は？
現場でない人の方が正しく判断できる根拠が不明です。
現場では経験ですね、それにプログラム関連としてYAGNIやSRPを知っているかも。
現場で無い人に有るとすれば空気を読めば「理論」になるかと思う。
しかし、経験も無ければ理論を上手く使えはしないだろう。
勿論、個別で見れば違うケースもあるだろうが。
banana
YAGNI-SRPについて業務上・プログラミング上の妥当性を示していないのは
主人公も、勤怠システムについて十分な情報を持たない読者も同じ。
マネージャーの立場から見てください。
SE・プログラマーは複数いて、それぞれスキルが異なる。
複数の人が自分を物差しにマネージャーの判断を
バランス悪い、○○すぎると言い出したら。。。
そもそも、上位職の判断が優先されるのが組織というものです。
マネージャーが現場のSE・プログラマと同等の理論武装をしないと、
判断を下せないということは、まったくありません。
具体的、客観的な理由を示さないといけない立場に
渕上マネージャーはない。
渕上マネージャーは会社に対しては説明責任がありますが、
プロジェクトメンバーに対しては説明する義務はありません。
説明しない方が良いと思うならそれも十分あり。
私は渕上マネージャーはもっと自分の考えや
見通しを説明するべきと思っていますが、
それはやらないといけないからではありません。
その方がプロジェクトを進めやすいと思うからです。
言葉に出して説明しないのも一つの判断で、
そのことで切るのは乱暴だと思います。
あと、DBにオラクルを取り消し、
オープンソースを採用したことで、
品質重視の姿勢と矛盾するという感想がありますが、
シンプルに渕上マネージャーが重視する品質は、
ソースコードに依存するというだけかもしれません。
また、オラクルを使うことによって増加するイニシャル数十万円、
ランニング数万円も削りにかからないといけないほど、
経営環境が急激に厳しくなっているのかも。
ユーザ企業にすればSIerに対し、
建築士などにも引けを取らない単価で発注しているという意識があります。
ところがシステム開発の成功率といったら俗に3割、
建築や製造業といった世界にいる人からみたらアマチュアレベルです。
物語のように自動車産業の会社であれば、
我々が安いと思う金額でも高すぎ、
大手のエースシステムが作ったものを見てみろ、
リコールレベルだ、
あれがITならこの単価でも高いという
社内の空気があるのかもしれません。
elseorand
いや～正直、論外。
>YAGNI-SRPについて業務上・プログラミング上の妥当性を示していないのは
>主人公も、勤怠システムについて十分な情報を持たない読者も同じ。
十分な情報？？現状の提示されている情報が十分ではないとする根拠は？
他のシステムとの連携があるかもしれないなどと推測を膨らませているのは、
氏の妄想では？
渕上マネージャーを擁護しないといいつつ、
言行不一致で肩入れしすぎですな。
現在、主人公・読者とも提示されている情報は
・アウトプット形式は豊富であるが、マスタメンテであること
・渕上マネージャーがSRPといいつつ、変更理由を根拠としないクラス分割を命令していること
これで「マスタメンテの変更理由で妥当性が高い物は、テーブル構成の変更のみのため、この場合、全メソッド同時の変更となる。故にメソッドをまとめてもSRP違反とならない」と判断することにどういった問題が？？？
banana
たぶん、私bananaと大手SIerさんがごっちゃになっています。
bananaは渕上マネージャーに肩入れしている人。
人事システムの重要性を指摘しているのは大手SIerさん。
技術のわかるマネージャーというのは私のあこがれでもあります。
原理原則論を押すからには、
なにか理由があってのことだと信じたいのですが。。。
やっぱり渕上マネージャーにフォローの余地はないのでしょうか。。。
1SE
みなさん、やはり実際の仕事でもこうやって議論されているのでしょうか?
現実だと各自の書いてらっしゃるようにことが運ぶことはなかなかないように思うのですけど、そうでもないですか?
自分はどちらかというと渕上マネージャーに近い考えなんですけど、どうしても他の人の意見に負けてしまいます。
私は実際の仕事上では渕上マネージャーのようなやり方は反対で、
先週もそれで一戦交えたほどですが。
>やっぱり渕上マネージャーにフォローの余地はないのでしょうか。。。
余地がないってことはないでしょうよ。
現在書かれていることは、主人公の主観でしかありません。
実際に客観的な事実はそんなに出てきていない。
これだけで断言できるなら、それは技術者というより予言者でしょう。
渕上さんに問題がありそうな点は、これまでずっと提示されてきていますが、
今回で主人公側の技術力のない点もかなり出てきています。
どっちに転んでも不思議はありません。
なんだったら、今から作者が気を変えて、正しい側を変えることだって可能でしょう。
まあ現実問題として、世の管理者の方々に言いたいのですが。
技術者として、仕様書をしっかり書くのを拒否したいのは、
別に仕様書をしっかり書くメリットを理解していないのではなく。
理解したうえで、それでもデメリットが大きいと主張したいのだということ。
そのほかにもいろいろ主張するのは、
別に管理者が嫌いなので根拠もなく否定しているわけではなく、
客観的に理由があるから言っているのだ、ということです。
ということを昔上司に行ったら、
自分がわからないことを言うやつは失礼だ、とか返されましたが。
管理者がそういう人ばかりでないことを祈っています。
まあ。
この段階の情報量で渕上さんが間違っているに決まっていると断言するのは、
技術者全体の評判を下げるような気がして、書き込んでみました。
banana
救済の可能性を残してくれて、
渕上マネージャーに代わりお礼申し上げます。
システム開発のときの判断の根拠って、
数字の裏付けがない経験則や一般論って事があります。
他の世界に持っていけば理由になってないってケースも多いと思います
（SE・プログラマ側だけではなく、ユーザ側もそうです）。
ユーザ側はプロに頼んでいるのだから、
うまくSE・プログラマが取り仕切ってくれるだろうと期待する。
ところがそうは問屋が降ろさない。
何しろ、ソフトウェアのメトリクスや品質の定義すら
実用レベルに達していない（と私は思っている）世界です。
混乱に次ぐ混乱で、ユーザ側はSE・プログラマに対する信頼を失います。
ITスキルをもたないマネージャーも同じです。
そんなとこに、アジャイルじゃYAGNIじゃSRPじゃなんて言われても、
正直、ありがたみも説得力もありません。
根拠となる数字は？ってなもんです。
とっぴに聞こえるでしょうが、
私はソフトウェア工学が未熟なのが
諸悪の原因だとおもっています。
年食って横着になると勉強する気も失せる。
俺にわかるように説明しないSE・プログラマが悪いと
開きなおるマネージャーの気分も今はわかる。
システム開発が工業のレベルに達すればQCDも改善し、
良いものを安く提供できるようになるでしょう。
マネージャーもSE・プログラマの判断を
もっと信じることができるようになる。
でも、そんな世の中は俺が現役のうちには来そうもない。
今どきの人たちはケント ベックさんでしょうか。
私のアイドルはフレデリックス ブルックスとエド ヨードンでした。
ソフトウェア工学がカリスマに取って変わる日が
くれば良いのですが。。。
としろう
>自分はどちらかというと渕上マネージャーに近い考えなんですけど、どうしても他の人の意見に負けてしまいます。
負けるからには理由があるし、勝ったとしてそれが正しいとも限らない。
目的はより良いシステム成果を出す事であるので本末転倒ではいけない。
プロジェクト終了後にある程度どうすれば良かったかが判るのでそれを以って学習するしかない。
>今回で主人公側の技術力のない点もかなり出てきています。
その通りかもしれないが、手駒はそれしかいないのです。
下手な背伸びは炎上要因になるだけです。
与えられた戦力で戦うしかないのはどちらの立場も一緒。
マネージャは手駒、SE・PGはマシンや環境に予算納期
リスクを考え対策を取るのも上位の仕事。
渕上氏の言う事が正しくても目的が果たされなければ失敗。
渕上氏はコストを削るなら物事の優先順位を考えて行わなければならない。
仕様書の問題では
.NETなどの高級言語では最早ソースが仕様書ではないだろうか？（問題発言）
ソフトにバグが無くならず実行して判るバグがある
仕様書の作成段階で間違いが無いなんて思考実験でもテストにならず無くなる事は無い。
ソースの方が美しく簡潔に書けるのにドキュメントでは大変な事になる事もある。
DBの正規化問題のようにソースと仕様書の同期というか
同じ事を別形式で別途記述管理する事に無駄は無いのかという疑問がある。
金と時間があるなら良いだろう。
要件定義や仕様作成から、製造中に追加変更が殆ど出ないほど固まっていたらそれでもいいだろう。
でも、実際はそんなことはまずない。
そして、会社を跨ぐなどで審査承認フィードバックにオーバーヘッド・・・・。
この辺の解決にはまだ時間がかかるだろう。
>ソフトウェア工学が未熟なのが諸悪の原因
どんな時もどんな場合も解決してくれるような銀の弾丸は永遠に無いだろう。
今の日本では、もっと別な問題が駄目な現実を作り出している。
どっちかというとそれ以前の問題。
例え公式のような物が出来ても使い方を間違ったり入力が違えば意味が無い。
>システム開発が工業のレベル
定型のようなものは大体そうなるかもしれないが
工業でも、ドリームライナーやF-35他の開発で思うようにいかない
ソフトでの生産は、実際はコンパイルがそれであり、
ソフトの開発はコーディングまで、工業で言えば設計作業であるという意見がある。
工業の設計って、そんなに予定調和で進むのか？失敗しないのか？
大概のソフト開発でカリスマは必要ではなくなるかもしれないが、
誰でも出来るという事にはならないのではないか？
アラファイブ
権限の配分の誤謬のような気がします。
○れるSEなどでは、自分サイドも権威を
持ち出して上手くさばくシーンがありますが
こちらはどうなるのでしょう。
ただ、それだとよっぽどコネが無い限り
実質的下請けになるのはさけられないで
しょうけど。
tiu
渕上さんの問題点は、技術がどうこう以前に、
仕事のやり方に問題があるような気がしますが･･･。
必要な仕様書を現担当に相談せずに製造側に要求する。
レビューの問題点についても、現担当と事前に話もしない。
これでは、マネジメントでは無く、ただの独裁ではないでしょうか？
>銀の弾丸
過剰な人員投資ぐらいでしょうか？
銀の弾丸の中には人間が詰まっていて、運良く変形しなかった弾丸は
次の弾丸として再利用され、使えなくなったものは捨てられていくという。
笑えない･･･。
話が入り乱れて楽しくなってきていますね。
いくつか感想を。
入り乱れているので個人は特定せずに、文に対して書きます。
>システム開発のときの判断の根拠って、
>数字の裏付けがない経験則や一般論って事があります。
>他の世界に持っていけば理由になってないってケースも多いと思います
数字的な裏付けそのものはいろいろ出ているらしいですよ。
ちょっと古めのプログラムの本を読めばいろいろ出ていました。
今でも最新の論文読めば出ているのではないですか？
学者さんはそれが仕事だと思いますし。
で。読んで実践してますか？
たとえば昔から有名なもので、
単価の高いプログラマーを雇うことによって生産性はそれ以上に上がるので、
利益率は高くなるということがあります。
もちろん年功序列で高くなっている人のことではありませんが。
これは別にアジャイルの時代になっても否定される気配はありません。
また、プログラマーは個室を用意することによって、
生産性が大幅に向上するという数字も出ています。
もちろん個室のレンタル料を上回るということです。
これはアジャイル的にはあまりよろしくないといわれていますが。
生産性よりコミュニケーションを大事にするために。
ただし、生産性を維持したまま個室をやめるためにはペアプログラミングの採用が必要です。
たとえばこの二つの有名な法則を、自分で昔から実践しているのでしょうか？
あるいはもっと先端的な工学的法則を勉強して実践しているのでしょうか？
自分で実践していないというなら、
工学的になればいいなあというのは単に愚痴っているだけの話ですね。
あと、プログラミングは進歩が激しく、測定誤差が大きいので、
数字を出すのが追い付けないという傾向もありますので、
工学的な運用が難しい面はあると思います。
アジャイルの人には、そもそも生産性の測定は不可能だ、と言い放っている人すらいますね。
>負けるからには理由があるし、勝ったとしてそれが正しいとも限らない。
見るからに矛盾していますね。
>その通りかもしれないが、手駒はそれしかいないのです。
>下手な背伸びは炎上要因になるだけです。
十分な仕様書も書かなければ、
アジャイルプラクティスを導入するわけでもない、
カウボーイコーディングは。
もっとも手駒の技術力を必要としますよ。
もしくは運ですかね。
まあ適当に組んで動くなら確かにそれはそれでいいんですが。
運が悪くバグが頻発すれば、
デスマーチになり、それは避けようがありません。
仕様書を十分に吟味して開発するウォーターフォールは、
個々の技術力がある程度低くても採用できる、確立した方法論です。
まあ今の世の中に求められるコストで、これが本当に採用できるかという問題もありますが。
もうちょっと技術力があるなら、
アジャイルが採用できて楽しく開発ができますが。
アジャイルプラクティスをいろいろ採用して、
どんな仕様変更にも即対応できるようにもなっていないのに、
YAGNIだけ採用しようとしている時点で、
ちょっと背伸びが過ぎるといわざるを得ないんじゃないでしょうか？
>NETなどの高級言語では最早ソースが仕様書ではないだろうか？（問題発言）
まず、.NETは言語じゃないですよ。
.NET上で動くCOBOLもありますし、有名どころではPowerShellも.NET上で動く言語です。
まあC#のことだとして話を進めましょうか。
C#は高級言語ですが、C#で書かれたプログラムが高級だとは誰も保証しません。
保守性が落ちるからクラスの作成が禁止されるプロジェクトも存在します。
それでは、可読性はCと大して変わりません。
そのプロジェクトで育ってきたプログラマーは、
ほかのプロジェクトでもCレベルのプログラムを量産し、
政治的に多少偉くなってしまったりすると、
保守性などを理由にして、むしろCレベルのプログラムを推進し始めます。
ええもう身近にもたくさんいますよ。
メンバーの教育コストを君は考えないのか、とか言ってますね。
まじめに会社のこと考えていっているらしいですよ。
そこまで極端ではなくても、
C#で仕様書と同じくらい読みやすいプログラムを書くのは簡単なことではありません。
きっちりとオブジェクト指向を勉強して、
さらにRuby on Railsなども見て最近のプログラムに求められる可読性がどれだけ上がっているかも勉強して、
C#でそれをどうやって実行できるか、自作するライブラリでそのレベルの可読性をどうやって達成できるか、
頑張って頑張ってなんとか実現できることです。
まあ頑張る量は才能とかにもよるでしょうし、一概には言えませんが。
少なくとも、C#を採用するだけで仕様書として十分な可読性が達成できると断言しているのを見ると、
ちょっとあまり信じる気にはなれません。
まあそれでもコードがドキュメントだと言い放っておくと、
ドキュメントとコードの乖離を防ぐという利点があることは確かですけれどね。
>渕上さんの問題点は、技術がどうこう以前に、
>仕事のやり方に問題があるような気がしますが･･･。
技術的には渕上さんの弁護をする余地はまだあると思うのですが、
こればっかりはどうにもならないのですよねえ。
特に下請けいじめについてはどう考えてもフォローのしようがない。
やはり実は渕上さんに感謝して終わる流れというのは深読みのしすぎですかね。
素直に悪役と思っておいていいのだろうか。
としろう
勘違いされているようなので
>>負けるからには理由があるし、勝ったとしてそれが正しいとも限らない。
>見るからに矛盾していますね。
矛盾ではない、負けに関しては議論で理由が弱いと判断されたとか、
悪いが感謝関係他の圧力、政治的な理由などがあるでしょう。
その勝負と、本来の目的に対して正しいかは別だと。
だから結果を見て次の機会に正しい事を通す為の材料にという
前向きな方向で行こうと言う事
>>>下手な背伸びは炎上要因になるだけです。
これは技術的な背伸び（初めて使うDBやSRP原則の強い適用）を
やりすぎてはいけないと言う事
高級言語については
.NETが言語のように間違って読める書き方をしたのはすまない。
だが、当然汚い低級言語的書き方をしたソースに先の爆弾発言を適用する気は毛頭ない。
あげあし取り
コメントも含めてキレイなソースを書けることが前提
プログラムのコンパイルに近く、javadocのようにというか
ソースから仕様の逆生成がもっと実用的になるか、
仕様書からプログラムが出来るようにする方向になっていくのではないだろうか？
低予算短納期ばかり求められ、途中変更も多発では、全部奇麗事では済まない。
優先順位つけて妥協していくならどういう順だ？ということ
それと仕様書には余り細かい所まで書くべきではないと思うのだが
渕上氏は高級言語レベルに近い細かい記述を求めそうなので
そこまで行けば殆どソースが仕様書になってしまう事もあるのでね。
プログラムなら関数他同一処理のまとめで綺麗に書けるが
仕様書だと要所要所に※～参照と、別ページへのリンク多用になり読み難い
かといって、各所に内容展開すると、訂正時に大変
banana
なんちゃら工学の成果って、
「よーし、こんどのプロジェクトから導入するぞー」ってノリで
取り入れるもんじゃないと思う。
HowTo本に書いているTipsじゃないんだから。
比較対象実験になっているか、
たとえば問題の因子（たとえば個室うんぬん）以外で、
生産性に影響を与える因子が特定されて、
双方が同じ条件になっているか。
統計的な処理は適切でかつ、有意といえるかなど。
その辺を学会なりで十分検証して定説（せめて有力な仮説）にいたったら
日立、富士通といった大手SIerが検証して、
ユーザ企業に提案して初めて実践フェーズに入る。
そんなもんじゃないでしょうか。
>としろうさん
>矛盾ではない、負けに関しては議論で理由が弱いと判断されたとか、
負けた側がいれば、それに対応して勝った側がいます。
だから同じことは勝った側にも言えます。
だから矛盾です。
>だが、当然汚い低級言語的書き方をしたソースに先の爆弾発言を適用する気は毛頭ない。
>あげあし取り
あなたの「当然汚い低級」がほかの人の「当然汚い低級」と一致する保証はありません。
私の周りにいる人も、自分は汚くも低級でもないプロとして恥ずかしくない、と思っていましたし、
あなたがそういう状況であるかどうかも私にはわかりません。
だから、.NETというくくりで大雑把にくくっているようでは、ちょっと検証が足りないのではないかと思われても仕方ないと思いますよ。
実際のところ、その後の解説を見ていても、
少なくともアジャイルやテスト駆動開発で言っている「ソースがドキュメント」という状況とは、
ちょっと違うレベルの話になっているようです。
同じ言葉が色々な状況を表すことは多いです。
もうちょっと厳密に解釈した方が良いと思います。
>bananaさん
>なんちゃら工学の成果って、
> 「よーし、こんどのプロジェクトから導入するぞー」ってノリで
> 取り入れるもんじゃないと思う。
もちろんそれはそうですが、
最初の一歩は必ずあります。
その最初の一歩を自分が踏み出しているのですか？ということです。
>その辺を学会なりで十分検証して定説（せめて有力な仮説）にいたったら
昔から検証しているんですから、
当然有力な仮説には至っていますよ。
まあ至った時には時代遅れになっていたりすることも多いですが。
にしてもそれより古いよりはましでしょうし。
取り入れているところもあります。
IBMなんかは割と聞きますね。
日立や富士通なんかはなぜか全然聞きません。
本になってないだけかな。
にしても、下っ端企業に成果が降りてきてないのも事実ですが。
いずれにせよ、
自分が絶対できない範囲にのみ有効な手段があると夢見ているのは、
あまり建設的ではありませんね。
自分が動ける範囲にも手段がないということはないでしょう。
banana
そんなにあわてて返事を書かなくても。。。
勇み足ぎみになっていますよ。
のんびり行きましょう。
any
1クラス1メソッドが必要ないならそこまでこまかーく設計する必要も無いんですよ。