とある企業の基幹システム、1行の改修に1ヶ月をかける 66
ストーリー by hylom
ブラックボックス化 部門より
ブラックボックス化 部門より
あるAnonymous Coward 曰く、
金属加工機メーカーアマダの基幹システム刷新の話が、日経ITproにて紹介されている。同社のシステムは
「改修がわずか1行でも、影響調査に1カ月、テストに数週間かかることが珍しくなかった」
というほど、長年の保守と改修のつぎはぎで大変なことになっていたそうだ。さすがにこのようなシステムでは先がないということか、同社はシステムの再構築を行い、短期間の開発で収まる規模の開発を段階的に繰り返すことで必要となる機能を実装するという開発スタイルに変更したそうだ。
このような開発スタイルを記事では「カイゼン型開発」と呼ばれているが、アジャイルソフトウェア開発と呼ばれるスタイルにほぼ近い。
このような開発スタイルは技術の進歩が早いWeb業界では取り入れられつつあるが、大企業内のシステムでの導入はまだあまり聞かない気がする。
アジャイルだろうがウォーターフォールだろうが (スコア:5, 参考になる)
影響度の大きいソフトウェア変更は怖い例。
カーソルキーで値を設定しなおした際に生じる、線量設定関連のバグで、
改善させるべくソフト修正かけても、過照射の事故がなくならず
死亡事故が続いた怖い例です。
この一件もＦＤＡ（日本では厚生労働省に相当）が、ソフトウェアの
安全性確保に対してとても厳しくなったものと思います。
セラック25 [archive.org]
Therac-25事故の調査 - パートII(英文) [vt.edu]
Re:アジャイルだろうがウォーターフォールだろうが (スコア:1)
http://www.sozogaku.com/fkd/cf/CA0000496.html [sozogaku.com]
http://en.wikipedia.org/wiki/Therac-25 [wikipedia.org]
wikipediaの内容書き出しただけでも「あー」と思うようなネタばっかりです
・1回の治療で200ラド(=2Gy)程度のところを、100倍の被曝をするようなバグ
・独立したコードレビューなし
・エラーコードの説明がユーザガイドになかったため、オペレーターが無視して何度も操作しようとする
・前のモデルからコードを流用したが、前のモデルはソフトウェア不具合部分をハードウェア側でブロックしていたため顕在しなかった
・セラック25は全部ソフトウェアで制御したため不具合が顕在化した
・フラグ変数をインクリメントで処理していて固定値を代入する処理ではなかったため、オーバーフロー時にフラグが初期化されてチェック処理がスルーされた
・照射位置が適切になっていない場合に照射を防ぐ仕組みが無かった
Re: (スコア:0)
参考になるといいたいところだけど、機械翻訳くっつけるのは、好感度を打ち消してマイナスになるに余りある。
「余計なもの」で沈めてほしいくらい。
Re:アジャイルだろうがウォーターフォールだろうが (スコア:2, 参考になる)
http://it.srad.jp/comments.pl?sid=612387&cid=2466107 [srad.jp]
に説明があるから、翻訳するまでもないな。
# 機械翻訳を載せるようなクズは、こんにゃくの角に頭をぶつけてしねばいい。
なかなか思い通りにはならなさそうな気がする (スコア:2)
つぎはぎ増築された基幹システムをゼロから作り直そう！
と言える前提条件をクリアするのが一番大変そうな……
そして、『カイゼン型』を理解しないアホの指示で場当たり的な更新がなされ、
数年後にはやっぱり大変なことになっちゃったり……
Re:なかなか思い通りにはならなさそうな気がする (スコア:2)
ゼロから作りなおせば良くなると考えるのはシロウト. ゼロから「優れた人が」作りなおせば, 良くなる可能性が高いと言う程度.
実際に, ほぼゼロから作りなおしたプロジェクトをいくつか助けたことがありますが, フローチャートとレコード表しか知らない上流の設計と, 数1000行に渡る関数を量産する(名ばかり)プログラマ, そしてバージョン管理システムも知らない管理という組み合わせでは, 全く変わることはありません.
Re: (スコア:0)
「まどか☆マギカ」、まで読んだ
＃そうではない
Re: (スコア:0)
とある企業の一行改修(とあるきぎょうのプロジェクト)
Re: (スコア:0)
その開発スタイルって米国国防総省給与算出システム更新 [srad.jp]に適用可能なの？
Re: (スコア:0)
できる。そして、問題は開発スタイルが適用出来るか、否かではない。
おしえてください (スコア:2)
アマダの元々のシステムが、部品在庫管理、給与管理、原価計算、納品期日管理、請求書発行、入金期日管理 とかの機能がオールインパックだったとして、たとえば給与管理は別システムに更改しましょうとかの話なのかな。
その時の疑問なのだけれど、システムの粒が大きいものってあると思うのだけれど、そういう場合も上手くいくんでしょうかね。
例えば給与システムで、
新システムの移行期間パートさんの就労管理は当座ＥＸＣＥＬで対応しましょうというのはイメージが沸くのだけれど、
給与システムって、ある程度粒が大きくて分けにくい感じがするのだけど、そういう場合はどう対応するのでしょうかね。
人事システムと給与システムは独立させてる。というのはアリでも税金ロジックと社会保険料ロジックだけこのターンでは対応
というわけにはいかない気がするのだが。
よくある (スコア:0)
> 改修がわずか1行でも、影響調査に1カ月、テストに数週間かかることが珍しくなかった
うん、普通。
修正が1行でも100行でも、かかる期間は大して変わらない。
Re:よくある (スコア:2, 参考になる)
だよな
スポーツ新聞や2ちゃんねるじゃないんだから
なにもこんな表題で煽らなくてもいいのに…
# 元記事自体は普通に良い話でした
Re: (スコア:0)
表題で煽ると聞いて思わず「とある企業の禁書目録」ってのが頭をよぎってしまった・・・orz
Re: (スコア:0)
これワザとじゃなかったのか？
Re:よくある (スコア:1)
以前いたところで、危なそうなシステムを組む人たちが理由も確かめずに適当な(そう見えた)対策をちゃっちゃとするので危ないと思い
出荷にはロングランなどもしないとだめじゃ無いの??
っていったら煙たがられました
そのチーム出すトラブルがあまりに多くて顧客よりクレームが入って
結局はロングランとかも始めたそうです
# もちろん、私が言ったことなんぞ...
# 倍返しは無理でしたね :-)
Re:よくある (スコア:1)
どこにぶら下げようかと思ったのですがとりあえずここに。
世間では悪徳として名高い「コピペによるコード量産」ですが、
テストまで視野に入れると、コピペもそれほど悪くないんじゃないかと思うことがあります。
「10の機能から呼び出される共通の下請け処理」を、「共通のコード一つ」にまとめた場合、そのコードに修正を入れることになったら、たとえその修正の影響が出るはずなのは一つの機能からの呼び出しの時だけ、だったとしても、
呼び出し元のの10の機能全てについて問題がないかテストを行う必要があります。
でも、コピペでコードを10個に分散させている場合には、修正に意味がある一つのコピーのみを改修し、その機能についてのみテストを行えばいい、ということで、テストの手間は1/10に減ります。
コピペはコード保守の手間が増えるかわりにテストの手間が減る、というトレードオフで、意外とコピペした方がトータルコストは減るんじゃないかと思うことがたびたび。
#そんな感じでコード修正の影響が広がるのを避けるため、共通コード部は一度動きだしたらできるかぎり手を入れないようにして、その代わりに呼び出し元の方の修正で逃げることも多いのですが、そうするとコードを共通化したメリットが薄まるぐらい汚いコードになっちゃうんですよね。
Re:よくある (スコア:1)
そういうその場しのぎの繰り返しが限界になったという記事ではないの？
Re:よくある (スコア:1)
もうひとつは、「その修正の影響が出るはずなのは一つの機能からの呼び出しの時だけ」というのは、おそらく、「共通のコードにまとめる」という設計なり手法なりが間違っている可能性がかなり高いと思います。
それ、共通の処理ではないという可能性が高いですから。
逆に、「処理を共通化している」と、「どの機能から呼び出しても、必ず同じバグが出現する」ので、対処はしやすくなると思います。
¶「だますのなら、最後までだまさなきゃね」/ 罵声に包まれて、君はほほえむ。
Re:よくある (スコア:1)
COBOLだと、そもそも、データ量の制約があるので、実用的にできるかどうかは確認必要ですが、考え方としては、毎日パラメータを変えて動かすという、日々のデータと、パラメータの組が保存できて、毎日の動作に相当するものが、スクリプトで実行できるのであれば、「以前のデータを処理したら、そのときと同じデータが出力される」ということで、回帰テストはできると思います。
発想としてはそういうことだと思います。
あと、開発環境とは別に、「バグを見いだすには、どういうパターンのデータとパラメータが必要か」というのが決められれば、それをもとに、テストケースを作るような、ツールや、スクリプトや、そっち方面で、最近の環境を使うというのは、考えられる方策だと思います。
以前組み込みでやったときに、構文的に考えられるコマンドを全部生成して、出てくるはずの出力を別途計算して、それを一晩かけて動かすようなこともやっていました。
¶「だますのなら、最後までだまさなきゃね」/ 罵声に包まれて、君はほほえむ。
Re: (スコア:0)
> 煙たがられました
そりゃそうじゃないですかね。
問題なかった場合：ワシの忠告のお陰で問題が出なかった
問題が出た場合： ほーらワシが言ってたとおりだろ
どっちに転んでも責任とらなくていい立場で、
横からごちゃごちゃ言われても、邪魔なだけじゃないかと。
口出ししてくる人に限って、あんまりスキル高くなかったりするし…
Re:よくある (スコア:1)
技術と心持は違う。一人が両方を十分な量だけ持ち合わせていなくても、どちらも大切。
責任は本来後から取るものではない。特に現場においては先に責任を持つ必要があることが多い。
責任を取る立場の人間と、責任を持とうとする人間はしばしば一致しない。
Re: (スコア:0)
自分の場合日々の仕事に忙殺されて大事なステップを飛ばしてしまうという危険性を第三者の目から指摘してくれるのは歓迎かな。
けどあまりに五月蝿いと煙たがられるのはわかる。
Re: (スコア:0)
まぁ、なんて見事な手抜きする奴が正論を説く人間にいう
テンプレなんでしょう！！！
> どっちに転んでも責任とらなくていい立場で、
> 横からごちゃごちゃ言われても、邪魔なだけじゃないかと。
>
> 口出ししてくる人に限って、あんまりスキル高くなかったりするし…
Re: (スコア:0)
ほら、そういう物言いをするから煙たがられるんだよ。
Re: (スコア:0)
> 出荷にはロングランなどもしないとだめじゃ無いの??
> っていったら煙たがられました
煙たがられる理由って、発言の内容じゃなくて、発言の仕方だよね。
上から目線でご高説を述べて相手の神経を逆撫でする姿が目に浮かぶ。
Re: (スコア:0)
言ってることはわかるんだけど。
「ご高説」は「承る」もんじゃなかろうか？
Re: (スコア:0)
なかなか無難に指摘するのって難しいですよね
火の粉が飛んできそうだったので、問題箇所を相手に気付かせるような
教えて発言をしたら説明する為に調べたんだろうか
その問題箇所に気が付いて得意げになって上から目線で説明してましたよ
※大体、そんなタイミングで自分に直接関係ないことを教えてって聞くわけないだろ気が付けよ
Re:よくある (スコア:2)
3 回読み返してようやく理解できたけど、仕事でもこんなわかりにくい言葉で意思疎通をしているの?
Re: (スコア:0)
影響調査に1ヶ月は長いだろ。
というかストーリーのタイトルおかしくない?
1ヶ月＋数週間じゃん。
Re: (スコア:0)
規模や複雑度を考慮に入れてますか？
実際は、 (スコア:0)
影響調査に1日
影響調査の報告資料作成に3日
影響範囲レビューの手配と実施に1週間
プログラム変更票作成に1日
プログラム変更票レビューの手配と実施に1週間
プログラム修正に1日
プログラムレビューの手配と実施に1週間
テスト仕様書作成に1日
テスト仕様書レビューの手配と実施に1週間
テスト実施に1日
テスト結果レビューの手配と実施に1週間
Re: (スコア:0)
いやそうじゃなくて
月末集計処理結果の照合が済むまでの時間でしょう
元々古いシステムだから仕方ない部分はあるのだろうけれど (スコア:0)
クリティカルセクションを外部のエンジニアに頼りきりで引き継ぎしてないとか、修正箇所を仕様書に反映してないとか、システムも問題だったんだろうけど運用の問題がかなり大きいんじゃ。
Re: (スコア:0)
マルチステートメント (スコア:0)
で、その１行のソースがざっと何百Kbyteぐらいあるんですか？
Re: (スコア:0)
1行は80桁だろ、COBOL的に考えて……
意味が良く分かりません。 (スコア:0)
>>というほど、長年の保守と改修のつぎはぎで大変なことになっていたそうだ。
>>短期間の開発で収まる規模の開発を段階的に繰り返すことで必要となる機能を実装するという開発スタイルに変更した
これどう違うの？
教えてエロイ人。
Re:意味が良く分かりません。 (スコア:2)
前者は後からいろいろ改修する予定で書いていないから、改修のたびに場当たり的に修正してつぎはぎだらけのコードになる。開発者も年々汚くなっていくコードを見ながら「こんなつもりじゃなかったのに…」と落ち込む。
後者は後で改修することを最初から考えて作っているから、改修を繰り返してつぎはぎだらけのコードになっても、「さ、最初から修正を繰り返すつもりだったもんね! アジャイルアジャイル! (呪文)」と言えて精神衛生上良い。
…ではなくて、後者だと部品ごとに完成させて、最初の部品を納品した段階で使い始めるので、システムの利用者からのフィードバックが早く得られるとか、部品間の結合が疎な保守しやすいコードになりやすいとか、そういうことではないかな。
Re: (スコア:0)
「エロい人」ってネタ的にだいぶオッサンくさい部類になってきたなあ。
Re:意味が良く分かりません。 (スコア:1)
なんと、ルーガちゃん(小出由華さん)、もうアラサーですよ
#おしえてえらいひと@ウゴウゴルーガ
Re: (スコア:0)
状況から考えて、
変更後はつまりアジャイルだと思っておけばいいんじゃないですか？
文章からは確かに読み取れませんが。
Re: (スコア:0)
「これどう違うの？」って質問は「アジャイルは「保守と改修のつぎはぎ」とどこが違うの？」って意味ではないかと。
Re: (スコア:0)
そういう人には、まずはアジャイルを勉強してもらうしかないと思う。
全然違うんだけど、そういうものこそ分かってない人に説明するのはとても面倒。
Re:意味が良く分かりません。 (スコア:1)
そう、成功すればアジャイルと呼ばれ、そうでなければ、アジャイルのふりをしたそれ以外のものと呼ばれるのだ。
Re: (スコア:0)
具体的にはいろいろな工夫があります。
工夫の内容についてはアジャイルの本を読むと書いてあります。
本を読まずにここのコメントで理解しようというなら、
それは間違っているとしか言いようがないですね。
もちろんその工夫を導入すればすべてうまくいく、なんてマンガみたいな話ではありません。
仕事を甘く見てはいけませんね。
うまくいった例ならあります。
Re:意味が良く分かりません。 (スコア:1)
本質的には～って行は別に反論ないんだけど、
「勉強した人でも違いをうまく説明できない」、だから○○だ
という論法は大変危険です。
ものごとは「うまく説明できるほど理解」しなくても利用に困らない程度使いこなすことはできますし、
段階を踏んでじっくりと説明しないと誤解が誤解を生むことも多いです。
例えば、「相対性理論は誤りだ論者」の論拠はだいたい「俺が納得するような説明は誰にもできなかった」というところから出発しております。
人月と勘違いしちゃだめ (スコア:0)
改修からリリースまで 1.X 月かかる != 改修の工数が 1.X 人月
どの一行かにもよるんじゃね (スコア:0)
たとえばSQL文とか。
内容のミスだけでなく、夜間に終えなきゃならないバッチが終わらなかったらオオゴトだし。
ここまでくると (スコア:0)
ここまでくると、業務そのものの再定義と再構築、それに併せたコンピュータシステムの再構成が必要な段階のはず。
それだけ組織形態や業務フローが硬直しているという証左とみるべきでは？
まあ、ベースとなるシステムがとんでもないタコシステムだった、という可能性も否定できませんが。
本質的にはコンピュータシステムの話ではなく、組織のマネジメントの問題になっているような予感。