ロジック読んでますか？

質問

ベンダー⇒ユーザー系と転職したものです。

ユーザー系SEの方、ロジック読んでますか？
開発はベンダーに任せることも多いと思われますが、
その後の保守はユーザー系SE会社で実施し、
ベンダー会社は離任することも多々あると思います。

ベンダー会社の人が作成したプログラムのロジックや、
契約社員の人が作成したプログラムのロジックなど、
(1)ちゃんと読んでいますか？
(2)それとも仕様書のレビュー・理解どまりですか？
(3)どちらも、あまりしていないですか？

理由も教えてください。

また、ベンダーの方、お客さんであるユーザー系の方は
ロジックまで読まれていますか？

回答No.3

iriyak · ベストアンサー

>ソースを知らないので、親会社（ユーザー）から、若干の
>機能改定を依頼されても、仕様レベルではわかるけど
>実際にその機能改定を行う箇所の特定や工数は、ベンダーまかせであり
>工数の妥当性についても厳密には手が出せない状況であると見ています。

質問者の主張は、『妥当性の検査を質問者の所属するユーザ系ＳＥ会社が行うべきではないか？（ベンダにまかせるものではなく）』でしょうか？？

もしそうであれば、回答者も Yes と考えます。理由はユーザ会社（親会社）への品質責任を負っているのはユーザ系ＳＥ会社であってベンダではないからです。

回答者は、そういう風潮が広がる背景として『それでも実際回っていて取り立てて問題が起きていない』⇒『いいじゃん』という判断をどこかの誰かがしているからではないかと推測します。このあたりの判断基準は（ベンダ）依存度と依存による品質リスクをどう見極めて腹を括るかということなので、一概にその判断そのものがダメーというつもりはありません。腹を括るのなら依存（隠語で丸投げともいいますね）して問題ないと思います。

でも・・・『自分達は上流工程を実施する会社だ。下流は誰でもできる』といった表現は、受け入れ側の品質リスクに留意した発言にはほど遠く感じます。実装を軽んじているニュアンスも感じます。

なんだかたいへんそうですね・・・。

お礼

もうなんだか１対１でのやり取りになっていてすみません。

妥当性の検査というと、仕様のレビュー・テストのレビューを
思いつきますが、それに関しては特に問題はないです。

例えば、１年を過ぎたプログラムのバグが見つかった場合や、
プログラム１，２本の仕様変更などは、小規模の仕様変更となります。

あまりベンダーの方にはわからないかもしれませんが、
毎度、大、中規模の案件は発生しないので、小規模の仕様変更や
機能追加が業務の大半を占めます。

その小規模の改定が実際に可能なのか、どのロジックに影響を与える
のかなど、ユーザー会社（弊社）の人間は、ロジックレベルで理解
できておらず、結局ベンダーや契約社員の担当者に、
「これってできるよね？」といったあまりに不甲斐ない質問を
投げている現場をよく見かけます。

外資はわかりませんが、国内の特に金融系の会社は、昨今経費削減は
命題であり、安く済ませたいはずです。当然小規模改定でも仕様変更に
なるので、ベンダーは工数を要求します。

ユーザー子会社は、そのあたりの融通が効くのですが、なんせロジックを
しらないから、結局ベンダー任せになる。つまり、あまり子会社の役割が
ないと思うのです。ベンダーよりも自社システムの知識を蓄えやすいのに
それをしていないと思うのです。

回答者様の会社の方（または、今まで出会ったユーザー系子会社の方）は
どうでしたか？ロジックレベルでの話ができましたか？

回答No.4

iriyak

＞回答者様の会社の方（または、今まで出会ったユーザー系子会社の方）は
＞どうでしたか？ロジックレベルでの話ができましたか？

＞他社のユーザー系の皆様も、同じようなものなのか、
＞それとも下流といわれる部分も、しっかりと自分の知識として
＞有しているのかが疑問になり質問させていただきました。

回答者の携わった範囲だと話をしていたと思います。しっかりと自分の知識として有するための稼働をいとわなかったという印象が残っています。

お礼

数人の人から話を聞きたかったけど答えにくい質問だったかもしれません。
そんな中、何度も回答を頂きありがとうございました。

回答No.2

iriyak

> さて、NoまたはYesのとき、それぞれどういった理由で、
> ロジックを読むか読まないかを判断されていますか？

非常にシンプルです。ソフトウェアのサポート主管組織はどこか? ソースコードにアクセスできるのはどこか? (版権の保持者はどこか?) などによって自ずと決まっています。

ソースコードの版権が自社にあるが、ソースコードの改修など維持管理に必要な役務を他社に委託しているケースでは、改修の品質責任は受け入れ側の自社にあるので Yes です。

継続開発があり、ある一定の品質水準を維持できる体制を保持できる費用がある間は、必要でない限りそこまで見なくてもよいと判断している場合もあります。他社に依存するモデルです。でも、昨今のソフトウェアシステムのライフサイクルの短さから開発/維持管理体制の縮小がすぐ目前に来ることが多い。他社との契約がなくなっても維持管理の実務が滞らないよう、自社で巻き取るための裾野を広げるプランを発動させて未来に備えています。

お礼

度々の回答ありがとうございます。
著作権についてはそのとおりですね。私の記載漏れです。

ベンダーで仕事をしていると（というか、SEであるなら）
ロジックを軽視することはありません。下手な仕様書よりも
ロジックを信頼するように心掛けています。

ユーザー系にきて、回答者様が回答されたようなことを
抜きにしても、ロジックが軽視されているように思えます。
※自分達は上流工程を実施する会社だ。下流は誰でもできるという風潮です。
※一切のソースを見ないわけではないけど、ソースに慣れていない感が見受けらます。

ソースを知らないので、親会社（ユーザー）から、若干の
機能改定を依頼されても、仕様レベルではわかるけど
実際にその機能改定を行う箇所の特定や工数は、ベンダーまかせであり
工数の妥当性についても厳密には手が出せない状況であると見ています。

私もそれなりに経験は積んでいるので、会社としての方針と
自分の方針を融合させ仕事をすることはできるので困ってはいませんが、
他社のユーザー系の皆様も、同じようなものなのか、
それとも下流といわれる部分も、しっかりと自分の知識として
有しているのかが疑問になり質問させていただきました。

回答No.1

iriyak

こんにちは。

仕事によって、Yes/No 両方を経験しました。ですのでロジックは読んでいる、という答えになるんだと思います。

ところで、質問者はロジックを読んでいるか/読んでいないか、が転職後に気になったのか、そのきっかけをこちらのコミュニティーに共有いただくことは可能でしょうか。それによって有識者によってそのきっかけそのものへの助言を期待することができるかもしれません。

補足

回答ありがとうございます。
もちろん、私の意見もございますが、私の意見と真逆の意見が
でるのかどうかも聞いてみたいので、今のところあえて
中立的に質問させて頂いてます。ご容赦のほど。

さて、NoまたはYesのとき、それぞれどういった理由で、
ロジックを読むか読まないかを判断されていますか？
※他の社員が読んでるからといった理由の場合、YESでお願いします。
　（ややこしくてすみません。社員の誰もが読んでなければ"No"です。
⇒つまり、うちの会社はベンダーと保守契約もして一任している
　　　ので、社員がロジックを読むことはあまりありません。
　　　という感じです。）