アカウント名:
パスワード:
これは、みずほ証券が苦しい。
無理筋を通すため屁理屈をこねるしかない立場は判るが、そのためにソフトウェア工学を誤用してまで持ち出すのは見苦しい。一般には「ソフトウェア工学」が何なのか判らない人が多いので、これで要らぬ誤解が広まらないことを願う。
ソフトウェア工学的には「実装と仕様ドキュメントは整合している『べき』だが、現実にはそうではない」という立場。では、どうするか。仕様から実装への自動生成なり、実装から仕様へのリバースエンジニアリングなり、一貫性をできるだけ(100%は不可能)維持するためのソフトウェアプロセスなり、実装と仕様を一致させる文芸的プログラミングなり、『べき』でしかない理想論を、精神論ではなく科学的・工学的に実現するのがソフトウェア工学。
大規模システム構築の経験がある技術者ならだれでも知っていることだが、ドキュメントと実装が乖離するのは現実。アジャイルでもウォーターフォールでも。一方、前記の研究はまだ完成には程遠い(完璧な自動生成w、完璧な仕様書生成w)。ならば、現実に起こっている問題に対し、実践可能な選択肢の中から、コスト・効果の兼ね合いを考えつつ最適の選択をするのが正解。そして、その選択戦略もソフトウェア工学の範疇。記事から判断しても、東証のアプローチは業界では標準的で、ソフトウェア工学の王道を実践している。
で、みずほ証券が持ち出した「ソフトウェア工学の知見」的には、・現実的にはドキュメントとソースは別ものになる。 ソフトウェア工学はその現実を理想状態にするのが目標だが現実はまだ不可能。 「ソースのみが事実を反映している」という立場は実践的で合理的。・コードの重複は良かれ悪しかれ。「コード重複が常に悪」と言い切れるのはかなり狭いドメイン。 例えば、サブルーチン化を抑えることは、変更の影響範囲がシステム全体に渡ることを防ぎ、 リグレッションテストのコストを抑制する効果がある。コスト(予算・工数)は有限というのがヒント。
明らかに正しいことを言っているのは東証の方。みずほ証券もそれは判っているはずで、それでもあんなことを言わざるを得ない立場には同情する。現場の技術者はさぞかし辛く、苦しいだろう。
なお、個々のバグか仕様ミスかの話は(今回の1円誤発注のこと)はこの話のスコープ外とさせていただく。それは、東証の方が悪いのは明らか。ただ、賠償責任については契約と法律の話。それは他のスレッドに譲る。
大規模システム構築の経験がある技術者ならだれでも知っていることだが、ドキュメントと実装が乖離するのは現実。アジャイルでもウォーターフォールでも。一方、前記の研究はまだ完成には程遠い(完璧な自動生成w、完璧な仕様書生成w)。ならば、現実に起こっている問題に対し、実践可能な選択肢の中から、コスト・効果の兼ね合いを考えつつ最適の選
> ドキュメントのメンテは”当然”の事
そもそもここに錯誤があって、元記事の1行まとめやタレコミが恣意的な誘導を行っているとしか思えないんだが、東証がメンテしていないっていうドキュメントはごく一部のみなんだよね。なのに、一読しただけでは、まるですべてのドキュメントをメンテしないように受け取れるように書いている。このストーリーでも案の定、大量に釣られてる。
それもメンテしていないのは、ソースコードと1対1に対応する実装と等価レベルの詳細なやつ。「a++」の代わりに「変数aに1を加える」といった類のもの。ここの読者なら、書くことが馬鹿らしい、無駄って思えるものだろう。でも、勘定系では敢えて書き、人も分けてチェック&レビューのチャンスを一段増やしている。まあ、さすがにテストが終わるとこのドキュメントはメンテしない。
東証でも、上位のドキュメントは、当然、業界標的な工数をかけてメンテしているし、ドキュメントの階層に応じて更新のライフサイクルを定義して管理しているというのは、元記事の中まで読むと、書いてある。
記事も読まずに感情だけで書く人間が多いというも悪いが、それを利用して、さいしょの1行まとめにバイアスを入れた元記事はかなり悪辣。
で、みずほの主張が受け入れられると、今後国内のITコストがかなり跳ね上がることになるため、国内ITベンダは一瞬得をするが、国内企業は総じて国際競争力を失うことになる。アジャイルにも逆風。いいこと無いよね。
そういう話じゃなくてあなたのおっしゃっているような上位のドキュメントでもメンテしておらず、担当者のノウハウという名の業務知識として埋没する事がありかつそういう現場ではシステムの整合性を管理把握している人間がいないので書いたんですが
ドキュメント化しない事の欠点を一つどの現場でも担当者の質は新規開発が最高で保守開発では年々劣化するのが常上記で書いたノウハウ=業務知識が単なる対処療法なのか、基本的な仕様なのかを把握出来ていないこれがドキュメント整備がなされていない業務系システム開発の現場だと思うのですがあなたの携わっていたドキュメント整備がなされていない業務系システムでは状況が異なるのでしょうか?
>一貫性をできるだけ(100%は不可能)維持する
東証はPCLレベルで未反映なだけで、詳細設計は反映してた。みずほの主張はここがキチガイ。
同意。アホかと。
あと、別スレでも槍玉に上がっているけど、「テスト2つでバグ再現」とかいう主張は、「答が分かっているので答えるのは簡単!」と言っているのと同じバカさ加減だし。
・コードの重複は良かれ悪しかれ。「コード重複が常に悪」と言い切れるのはかなり狭いドメイン。 例えば、サブルーチン化を抑えることは、変更の影響範囲がシステム全体に渡ることを防ぎ、 リグレッションテストのコストを抑制する効果がある。コスト(予算・工数)は有限というのがヒント。
何年も保守し続けていく必要があるものなら、コードの重複でしのげるのはその場限り。コストを後世にツケ回しているということを自覚すべき。70件以上もある類似関数の山に呆れながら共通の機能追加を行う羽目に遭ったことがあるが、「いくら何でも多すぎだから今本当に必要なのはどれ?」とメンテしていた人に訊いても何年にも渡って継ぎ足し継ぎ足しできたので誰も全体像を把握している人がおらず未回答。「明日・明後日という短期間で必要」というので、徹夜して全部に適用したけどそのうち注意力も散漫になってきたので、ミスを入れ込んだかもしれない。
> 何年も保守し続けていく必要があるものなら、コードの重複でしのげるのはその場限り。コストを後世にツケ回しているということを自覚すべき。
そんな当たり前の話は現場は皆知っている。今さら書くまでも無い。
問題はコストと工数。コストと工数が無限に出るなら、意識の高い技術者なら誰しも自分の作品を理想的コードに向けて仕上げたいと思うだろう。
感覚でものを言っても意味は無く、実際には感覚値を具体値に代えて様々な限られたリソースのトレードオフが選ばれる。例えば、上の「しのげるのはその場限り」についても、十分枯れたCOBOLのレガシーシステムでは「その場」という変数に10年とか代入される。コピペで10年しのげるならば、他に優先順位の高いチケットにリソースを回す方が正しい戦略だ。
一人の技術者が「リファクタリングしたいから」と自己満足のために主張しても、受け入れられるはずは無い。コピペで10年しのげてきたのは歴然とした事実なのだから、コピペの風習を無くしたいなら、その事実を上回るだけの具体的証拠を揃える必要がある。
なお、先に書いた通り、現場は皆コピペの風習を無くせるものなら無くしたいと願っているので、コピペ絶滅の戦略的に正しいストーリーが構築できたなら、大いに受け入れられることだろう。健闘を祈る。
コピペ部分に関して少なくとも今後10年一切改修せずにしのげる、あるいはしのげると予想されるなら誰も否定はせんよ。
実際にはそんな評価抜きにして単に面倒くさいからでコピペが多用されるのが問題なわけで。現状は現状として、この腐った現状を追認するしかできないものは学問の名に値しないわな。実際のソフトウェア工学はテスト自動化とかで退行テストコスト抑制とかの言い訳潰しの方策は出してるっしょ。
> コピペ部分に関して少なくとも今後10年一切改修せずにしのげる、あるいはしのげると予想されるなら誰も否定はせんよ。
その通り。予想されるから(少なくとも予算の決定権を持つ責任のスコープの広い人間には)否定されないわけ。それが実績に基づく現実的な判断であり、事実。
> 実際のソフトウェア工学はテスト自動化とかで退行テストコスト抑制とかの言い訳潰しの方策は出してるっしょ。
残念ながら、その類の研究はJavaがほとんど(JavascriptとC++が少し)。その技術がCOBOLに降りて来て実績を積むのは10年後かもしれないし、来ないかもしれない。しかし、実践者は今後数年以内に入手可能な技術で、目の前にある課題に取り組む必要がある。それが現実。
予算の決定権を持つ人間がコピペ部分に改修が必要になりそうか評価してるって? 面白い冗談言うね。
まぁ、テスト自動化ツール作るのに数年もかかるようじゃコピペに頼りたくもなるのもわかるけど、技術力無い現状を必死に肯定してみても進歩しないよ?
テスト自動化っていっても、CIなんて簡単な話は既に行われているけど、それはクローン潰しの役に立たんよ。
制約充足器を用いたテスト自動生成なら役に立つと有望視され、実際かなり研究投資されているが、それでもtoy problem用の研究レベルから、実践レベルまで降りてくるのにまだ数年かかる。ましてや、COBOLに降りてくるなんていつの話やら。
> 予算の決定権を持つ人間がコピペ部分に改修が必要になりそうか評価してるって? 面白い冗談言うね。
真っ当なら当然判断する。もちろん統計値のレベルで。10年後に1億円の損害が10%で発生すると見積もったリスクに対し、リファクタリングに年間12人月当てるぐらいなら、「そのリスクは取ってリファクタリングは却下」と判断するわけだ。
リファクタリングに工数を当てたいのなら、その判断に対して有効な統計値を携えたストーリーを描けるかが求められる。「従来は年間12人月かかると見積もっていたが、昨年の技術革新により見積もりが年間0.5人月に減ったからやるべき」とかな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
ソフトウェア工学の誤用甚だしい (スコア:1)
これは、みずほ証券が苦しい。
無理筋を通すため屁理屈をこねるしかない立場は判るが、
そのためにソフトウェア工学を誤用してまで持ち出すのは見苦しい。
一般には「ソフトウェア工学」が何なのか判らない人が多いので、これで要らぬ誤解が広まらないことを願う。
ソフトウェア工学的には「実装と仕様ドキュメントは整合している『べき』だが、現実にはそうではない」という立場。
では、どうするか。仕様から実装への自動生成なり、実装から仕様へのリバースエンジニアリングなり、
一貫性をできるだけ(100%は不可能)維持するためのソフトウェアプロセスなり、
実装と仕様を一致させる文芸的プログラミングなり、
『べき』でしかない理想論を、精神論ではなく科学的・工学的に実現するのがソフトウェア工学。
大規模システム構築の経験がある技術者ならだれでも知っていることだが、
ドキュメントと実装が乖離するのは現実。アジャイルでもウォーターフォールでも。
一方、前記の研究はまだ完成には程遠い(完璧な自動生成w、完璧な仕様書生成w)。
ならば、現実に起こっている問題に対し、実践可能な選択肢の中から、
コスト・効果の兼ね合いを考えつつ最適の選択をするのが正解。
そして、その選択戦略もソフトウェア工学の範疇。
記事から判断しても、東証のアプローチは業界では標準的で、ソフトウェア工学の王道を実践している。
で、みずほ証券が持ち出した「ソフトウェア工学の知見」的には、
・現実的にはドキュメントとソースは別ものになる。
ソフトウェア工学はその現実を理想状態にするのが目標だが現実はまだ不可能。
「ソースのみが事実を反映している」という立場は実践的で合理的。
・コードの重複は良かれ悪しかれ。「コード重複が常に悪」と言い切れるのはかなり狭いドメイン。
例えば、サブルーチン化を抑えることは、変更の影響範囲がシステム全体に渡ることを防ぎ、
リグレッションテストのコストを抑制する効果がある。コスト(予算・工数)は有限というのがヒント。
明らかに正しいことを言っているのは東証の方。
みずほ証券もそれは判っているはずで、それでもあんなことを言わざるを得ない立場には同情する。
現場の技術者はさぞかし辛く、苦しいだろう。
なお、個々のバグか仕様ミスかの話は(今回の1円誤発注のこと)はこの話のスコープ外とさせていただく。
それは、東証の方が悪いのは明らか。ただ、賠償責任については契約と法律の話。それは他のスレッドに譲る。
Re: (スコア:0)
ソフトウェア工学的には「実装と仕様ドキュメントは整合している『べき』だが、現実にはそうではない」という立場。
では、どうするか。仕様から実装への自動生成なり、実装から仕様へのリバースエンジニアリングなり、
一貫性をできるだけ(100%は不可能)維持するためのソフトウェアプロセスなり、
実装と仕様を一致させる文芸的プログラミングなり、
『べき』でしかない理想論を、精神論ではなく科学的・工学的に実現するのがソフトウェア工学。
大規模システム構築の経験がある技術者ならだれでも知っていることだが、
ドキュメントと実装が乖離するのは現実。アジャイルでもウォーターフォールでも。
一方、前記の研究はまだ完成には程遠い(完璧な自動生成w、完璧な仕様書生成w)。
ならば、現実に起こっている問題に対し、実践可能な選択肢の中から、
コスト・効果の兼ね合いを考えつつ最適の選
Re:ソフトウェア工学の誤用甚だしい (スコア:5, 参考になる)
> ドキュメントのメンテは”当然”の事
そもそもここに錯誤があって、元記事の1行まとめやタレコミが恣意的な誘導を行っているとしか思えないんだが、
東証がメンテしていないっていうドキュメントはごく一部のみなんだよね。
なのに、一読しただけでは、まるですべてのドキュメントをメンテしないように受け取れるように書いている。
このストーリーでも案の定、大量に釣られてる。
それもメンテしていないのは、ソースコードと1対1に対応する実装と等価レベルの詳細なやつ。
「a++」の代わりに「変数aに1を加える」といった類のもの。
ここの読者なら、書くことが馬鹿らしい、無駄って思えるものだろう。
でも、勘定系では敢えて書き、人も分けてチェック&レビューのチャンスを一段増やしている。
まあ、さすがにテストが終わるとこのドキュメントはメンテしない。
東証でも、上位のドキュメントは、当然、業界標的な工数をかけてメンテしているし、
ドキュメントの階層に応じて更新のライフサイクルを定義して管理しているというのは、
元記事の中まで読むと、書いてある。
記事も読まずに感情だけで書く人間が多いというも悪いが、
それを利用して、さいしょの1行まとめにバイアスを入れた元記事はかなり悪辣。
で、みずほの主張が受け入れられると、今後国内のITコストがかなり跳ね上がることになるため、
国内ITベンダは一瞬得をするが、国内企業は総じて国際競争力を失うことになる。
アジャイルにも逆風。
いいこと無いよね。
Re: (スコア:0)
そういう話じゃなくて
あなたのおっしゃっているような上位のドキュメントでも
メンテしておらず、担当者のノウハウという名の業務知識として埋没する事があり
かつそういう現場ではシステムの整合性を管理把握している人間がいないので書いたんですが
ドキュメント化しない事の欠点を一つ
どの現場でも担当者の質は新規開発が最高で保守開発では年々劣化するのが常
上記で書いたノウハウ=業務知識が単なる対処療法なのか、基本的な仕様なのかを把握出来ていない
これがドキュメント整備がなされていない業務系システム開発の現場だと思うのですが
あなたの携わっていたドキュメント整備がなされていない業務系システムでは状況が異なるのでしょうか?
Re: (スコア:0)
>一貫性をできるだけ(100%は不可能)維持する
東証はPCLレベルで未反映なだけで、詳細設計は反映してた。
みずほの主張はここがキチガイ。
Re: (スコア:0)
同意。アホかと。
あと、別スレでも槍玉に上がっているけど、
「テスト2つでバグ再現」とかいう主張は、「答が分かっているので答えるのは簡単!」と言っているのと同じバカさ加減だし。
コードの重複がコストを抑制する効果は近視的 (スコア:0)
・コードの重複は良かれ悪しかれ。「コード重複が常に悪」と言い切れるのはかなり狭いドメイン。
例えば、サブルーチン化を抑えることは、変更の影響範囲がシステム全体に渡ることを防ぎ、
リグレッションテストのコストを抑制する効果がある。コスト(予算・工数)は有限というのがヒント。
何年も保守し続けていく必要があるものなら、コードの重複でしのげるのはその場限り。コストを後世にツケ回しているということを自覚すべき。
70件以上もある類似関数の山に呆れながら共通の機能追加を行う羽目に遭ったことがあるが、「いくら何でも多すぎだから今本当に必要なのはどれ?」とメンテしていた人に訊いても何年にも渡って継ぎ足し継ぎ足しできたので誰も全体像を把握している人がおらず未回答。
「明日・明後日という短期間で必要」というので、徹夜して全部に適用したけどそのうち注意力も散漫になってきたので、ミスを入れ込んだかもしれない。
Re:コードの重複がコストを抑制する効果は近視的 (スコア:1)
> 何年も保守し続けていく必要があるものなら、コードの重複でしのげるのはその場限り。コストを後世にツケ回しているということを自覚すべき。
そんな当たり前の話は現場は皆知っている。今さら書くまでも無い。
問題はコストと工数。コストと工数が無限に出るなら、
意識の高い技術者なら誰しも自分の作品を理想的コードに向けて仕上げたいと思うだろう。
感覚でものを言っても意味は無く、実際には感覚値を具体値に代えて様々な限られたリソースのトレードオフが選ばれる。
例えば、上の「しのげるのはその場限り」についても、十分枯れたCOBOLのレガシーシステムでは「その場」という変数に10年とか代入される。
コピペで10年しのげるならば、他に優先順位の高いチケットにリソースを回す方が正しい戦略だ。
一人の技術者が「リファクタリングしたいから」と自己満足のために主張しても、受け入れられるはずは無い。
コピペで10年しのげてきたのは歴然とした事実なのだから、
コピペの風習を無くしたいなら、その事実を上回るだけの具体的証拠を揃える必要がある。
なお、先に書いた通り、現場は皆コピペの風習を無くせるものなら無くしたいと願っているので、
コピペ絶滅の戦略的に正しいストーリーが構築できたなら、大いに受け入れられることだろう。
健闘を祈る。
Re: (スコア:0)
コピペ部分に関して少なくとも今後10年一切改修せずにしのげる、あるいはしのげると予想されるなら誰も否定はせんよ。
実際にはそんな評価抜きにして単に面倒くさいからでコピペが多用されるのが問題なわけで。現状は現状として、この腐った現状を追認するしかできないものは学問の名に値しないわな。実際のソフトウェア工学はテスト自動化とかで退行テストコスト抑制とかの言い訳潰しの方策は出してるっしょ。
Re: (スコア:0)
> コピペ部分に関して少なくとも今後10年一切改修せずにしのげる、あるいはしのげると予想されるなら誰も否定はせんよ。
その通り。予想されるから(少なくとも予算の決定権を持つ責任のスコープの広い人間には)否定されないわけ。
それが実績に基づく現実的な判断であり、事実。
> 実際のソフトウェア工学はテスト自動化とかで退行テストコスト抑制とかの言い訳潰しの方策は出してるっしょ。
残念ながら、その類の研究はJavaがほとんど(JavascriptとC++が少し)。
その技術がCOBOLに降りて来て実績を積むのは10年後かもしれないし、来ないかもしれない。
しかし、実践者は今後数年以内に入手可能な技術で、目の前にある課題に取り組む必要がある。それが現実。
Re: (スコア:0)
予算の決定権を持つ人間がコピペ部分に改修が必要になりそうか評価してるって? 面白い冗談言うね。
まぁ、テスト自動化ツール作るのに数年もかかるようじゃコピペに頼りたくもなるのもわかるけど、技術力無い現状を必死に肯定してみても進歩しないよ?
Re: (スコア:0)
テスト自動化っていっても、CIなんて簡単な話は既に行われているけど、それはクローン潰しの役に立たんよ。
制約充足器を用いたテスト自動生成なら役に立つと有望視され、実際かなり研究投資されているが、
それでもtoy problem用の研究レベルから、実践レベルまで降りてくるのにまだ数年かかる。
ましてや、COBOLに降りてくるなんていつの話やら。
Re: (スコア:0)
> 予算の決定権を持つ人間がコピペ部分に改修が必要になりそうか評価してるって? 面白い冗談言うね。
真っ当なら当然判断する。もちろん統計値のレベルで。
10年後に1億円の損害が10%で発生すると見積もったリスクに対し、リファクタリングに年間12人月当てるぐらいなら、
「そのリスクは取ってリファクタリングは却下」と判断するわけだ。
リファクタリングに工数を当てたいのなら、
その判断に対して有効な統計値を携えたストーリーを描けるかが求められる。
「従来は年間12人月かかると見積もっていたが、昨年の技術革新により見積もりが年間0.5人月に減ったからやるべき」とかな。