パスワードを忘れた? アカウント作成
10023572 story
ソフトウェア

とある企業の基幹システム、1行の改修に1ヶ月をかける 66

ストーリー by hylom
ブラックボックス化 部門より
あるAnonymous Coward 曰く、

金属加工機メーカーアマダの基幹システム刷新の話が、日経ITproにて紹介されている。同社のシステムは

「改修がわずか1行でも、影響調査に1カ月、テストに数週間かかることが珍しくなかった」

というほど、長年の保守と改修のつぎはぎで大変なことになっていたそうだ。さすがにこのようなシステムでは先がないということか、同社はシステムの再構築を行い、短期間の開発で収まる規模の開発を段階的に繰り返すことで必要となる機能を実装するという開発スタイルに変更したそうだ。

このような開発スタイルを記事では「カイゼン型開発」と呼ばれているが、アジャイルソフトウェア開発と呼ばれるスタイルにほぼ近い。

このような開発スタイルは技術の進歩が早いWeb業界では取り入れられつつあるが、大企業内のシステムでの導入はまだあまり聞かない気がする。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 影響度の大きいソフトウェア変更は怖い例。
    カーソルキーで値を設定しなおした際に生じる、線量設定関連のバグで、
    改善させるべくソフト修正かけても、過照射の事故がなくならず
    死亡事故が続いた怖い例です。

    この一件もFDA(日本では厚生労働省に相当)が、ソフトウェアの
    安全性確保に対してとても厳しくなったものと思います。

    セラック25 [archive.org]

    1985〜1987年――セラック25:複数の医療施設で放射線治療装置が誤作動し、過大な放射線を浴びた患者に死傷者が出た。セラック25は2種類の放射線――低エネルギーの電子ビーム(ベータ粒子)とX線――を照射できるよう、既存の設計に「改良」を加えた治療装置だった。セラック25では電子銃と患者の間に置かれた金属製のターゲットに高エネルギーの電子を打ち込み、X線を発生させていた。セラック25のもう1つの「改良」点は、旧モデル『セラック20』の電気機械式の安全保護装置をソフトウェア制御に置き換えたことだった。ソフトウェアの方が信頼性が高いとの考えに基づく判断だった。
     しかし、技術者たちも知らなかった事実があった――セラック20およびセラック25に使われたOSは、正式な訓練も受けていないプログラマーが1人で作成したもので、バグが非常にわかりにくい構成になっていたのだ。「競合状態」と呼ばれる判明しにくいバグが原因で、操作コマンドを素早く打ち込んだ場合、セラック25ではX線用の金属製ターゲットをきちんと配置しないまま高エネルギーの放射線を照射する設定が可能になっていた。これにより少なくとも5人が死亡し、他にも重傷者が出た。

    Therac-25事故の調査 - パートII(英文) [vt.edu]

    速やかに患者の処方データを入力。これは、X線を関与最も治療から一般的な間違いだった、彼女はこれを入力に慣れていた。間違いは修正するのは簡単だった、彼女は単にモードエントリを編集するために上向きのカーソルキーを使用していました。しばらくすると、マシンがシャットダウンし、コンソールにはメッセージ表示された"不具合54(線量設定エラー)"。

    彼女が入っていた他のパラメータは正しかったので、彼女は、リターンキーを数回ヒットし、その値を変更せずに残しました。メッセージがパラメータが "検証"と、端末が "ビーム準備ができて、"期待通りに表示されていたことが示されたところ彼女は、画面の下部に達した。彼女は治療を開始する1-keyコマンド "B"を( "ビームの"ための)ヒット。しばらくすると、マシンがシャットダウンし、コンソールにはメッセージ表示された "不具合54(線量設定エラー)"

    • by Anonymous Coward on 2013年09月26日 0時47分 (#2466107)

      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は全部ソフトウェアで制御したため不具合が顕在化した
      ・フラグ変数をインクリメントで処理していて固定値を代入する処理ではなかったため、オーバーフロー時にフラグが初期化されてチェック処理がスルーされた
      ・照射位置が適切になっていない場合に照射を防ぐ仕組みが無かった

      親コメント
    • by Anonymous Coward

      参考になるといいたいところだけど、機械翻訳くっつけるのは、好感度を打ち消してマイナスになるに余りある。
      「余計なもの」で沈めてほしいくらい。

  • つぎはぎ増築された基幹システムをゼロから作り直そう!
    と言える前提条件をクリアするのが一番大変そうな……

    そして、『カイゼン型』を理解しないアホの指示で場当たり的な更新がなされ、
    数年後にはやっぱり大変なことになっちゃったり……

    • ゼロから作りなおせば良くなると考えるのはシロウト. ゼロから「優れた人が」作りなおせば, 良くなる可能性が高いと言う程度.

      実際に, ほぼゼロから作りなおしたプロジェクトをいくつか助けたことがありますが, フローチャートとレコード表しか知らない上流の設計と, 数1000行に渡る関数を量産する(名ばかり)プログラマ, そしてバージョン管理システムも知らない管理という組み合わせでは, 全く変わることはありません.

      親コメント
      • by Anonymous Coward

        「まどか☆マギカ」、まで読んだ
        #そうではない

        • by Anonymous Coward

          とある企業の一行改修(とあるきぎょうのプロジェクト)

    • by Anonymous Coward

      その開発スタイルって米国国防総省給与算出システム更新 [srad.jp]に適用可能なの?

      • by Anonymous Coward

        できる。そして、問題は開発スタイルが適用出来るか、否かではない。

  • by asap (6830) on 2013年09月25日 23時32分 (#2466073)
    この手の開発は全く分からないのだけれど、全くの妄想で書くと
    アマダの元々のシステムが、部品在庫管理、給与管理、原価計算、納品期日管理、請求書発行、入金期日管理 とかの機能がオールインパックだったとして、たとえば給与管理は別システムに更改しましょうとかの話なのかな。
    その時の疑問なのだけれど、システムの粒が大きいものってあると思うのだけれど、そういう場合も上手くいくんでしょうかね。
    例えば給与システムで、
     新システムの移行期間パートさんの就労管理は当座EXCELで対応しましょうというのはイメージが沸くのだけれど、
    給与システムって、ある程度粒が大きくて分けにくい感じがするのだけど、そういう場合はどう対応するのでしょうかね。
     人事システムと給与システムは独立させてる。というのはアリでも税金ロジックと社会保険料ロジックだけこのターンでは対応
    というわけにはいかない気がするのだが。
  • by Anonymous Coward on 2013年09月25日 19時15分 (#2465934)

    > 改修がわずか1行でも、影響調査に1カ月、テストに数週間かかることが珍しくなかった

    うん、普通。
    修正が1行でも100行でも、かかる期間は大して変わらない。

    • Re:よくある (スコア:2, 参考になる)

      by Anonymous Coward on 2013年09月25日 19時31分 (#2465942)

      だよな

      スポーツ新聞や2ちゃんねるじゃないんだから
      なにもこんな表題で煽らなくてもいいのに…

      # 元記事自体は普通に良い話でした

      親コメント
      • by Anonymous Coward

        表題で煽ると聞いて思わず「とある企業の禁書目録」ってのが頭をよぎってしまった・・・orz

        • by Anonymous Coward

          これワザとじゃなかったのか?

    • by Minno86 (40623) on 2013年09月25日 19時45分 (#2465951)
      ありますよね
      以前いたところで、危なそうなシステムを組む人たちが理由も確かめずに適当な(そう見えた)対策をちゃっちゃとするので危ないと思い
       出荷にはロングランなどもしないとだめじゃ無いの??
      っていったら煙たがられました
      そのチーム出すトラブルがあまりに多くて顧客よりクレームが入って
      結局はロングランとかも始めたそうです
       # もちろん、私が言ったことなんぞ...
       # 倍返しは無理でしたね :-)
      親コメント
      • by Anonymous Coward on 2013年09月26日 0時54分 (#2466110)

        どこにぶら下げようかと思ったのですがとりあえずここに。

        世間では悪徳として名高い「コピペによるコード量産」ですが、
        テストまで視野に入れると、コピペもそれほど悪くないんじゃないかと思うことがあります。

        「10の機能から呼び出される共通の下請け処理」を、「共通のコード一つ」にまとめた場合、そのコードに修正を入れることになったら、たとえその修正の影響が出るはずなのは一つの機能からの呼び出しの時だけ、だったとしても、
        呼び出し元のの10の機能全てについて問題がないかテストを行う必要があります。

        でも、コピペでコードを10個に分散させている場合には、修正に意味がある一つのコピーのみを改修し、その機能についてのみテストを行えばいい、ということで、テストの手間は1/10に減ります。

        コピペはコード保守の手間が増えるかわりにテストの手間が減る、というトレードオフで、意外とコピペした方がトータルコストは減るんじゃないかと思うことがたびたび。

        #そんな感じでコード修正の影響が広がるのを避けるため、共通コード部は一度動きだしたらできるかぎり手を入れないようにして、その代わりに呼び出し元の方の修正で逃げることも多いのですが、そうするとコードを共通化したメリットが薄まるぐらい汚いコードになっちゃうんですよね。

        親コメント
        • by Anonymous Coward on 2013年09月26日 8時33分 (#2466175)

          そういうその場しのぎの繰り返しが限界になったという記事ではないの?

          親コメント
        • ひとつには、テストはサボらずに、でも手を抜きましょうということで、10個のテストでも1個のテストと手間が変わらないような方法を考えましょうと言うことかと思います。
          もうひとつは、「その修正の影響が出るはずなのは一つの機能からの呼び出しの時だけ」というのは、おそらく、「共通のコードにまとめる」という設計なり手法なりが間違っている可能性がかなり高いと思います。
          それ、共通の処理ではないという可能性が高いですから。

          逆に、「処理を共通化している」と、「どの機能から呼び出しても、必ず同じバグが出現する」ので、対処はしやすくなると思います。
          --
          ¶「だますのなら、最後までだまさなきゃね」/ 罵声に包まれて、君はほほえむ。
          親コメント
      • by Anonymous Coward

        > 煙たがられました

        そりゃそうじゃないですかね。

         問題なかった場合:ワシの忠告のお陰で問題が出なかった
         問題が出た場合: ほーらワシが言ってたとおりだろ

        どっちに転んでも責任とらなくていい立場で、
        横からごちゃごちゃ言われても、邪魔なだけじゃないかと。

        口出ししてくる人に限って、あんまりスキル高くなかったりするし…

        • by mondy (27787) on 2013年09月26日 2時21分 (#2466134)

          技術と心持は違う。一人が両方を十分な量だけ持ち合わせていなくても、どちらも大切。
          責任は本来後から取るものではない。特に現場においては先に責任を持つ必要があることが多い。
          責任を取る立場の人間と、責任を持とうとする人間はしばしば一致しない。

          親コメント
        • by Anonymous Coward

          自分の場合日々の仕事に忙殺されて大事なステップを飛ばしてしまうという危険性を第三者の目から指摘してくれるのは歓迎かな。
          けどあまりに五月蝿いと煙たがられるのはわかる。

        • by Anonymous Coward

          まぁ、なんて見事な手抜きする奴が正論を説く人間にいう
          テンプレなんでしょう!!!

          > どっちに転んでも責任とらなくていい立場で、
          > 横からごちゃごちゃ言われても、邪魔なだけじゃないかと。
          >
          > 口出ししてくる人に限って、あんまりスキル高くなかったりするし…

          • by Anonymous Coward

            ほら、そういう物言いをするから煙たがられるんだよ。

      • by Anonymous Coward

        >  出荷にはロングランなどもしないとだめじゃ無いの??
        > っていったら煙たがられました

        煙たがられる理由って、発言の内容じゃなくて、発言の仕方だよね。
        上から目線でご高説を述べて相手の神経を逆撫でする姿が目に浮かぶ。

        • by Anonymous Coward

          言ってることはわかるんだけど。

          「ご高説」は「承る」もんじゃなかろうか?

        • by Anonymous Coward

          なかなか無難に指摘するのって難しいですよね
          火の粉が飛んできそうだったので、問題箇所を相手に気付かせるような
          教えて発言をしたら説明する為に調べたんだろうか
          その問題箇所に気が付いて得意げになって上から目線で説明してましたよ

          ※大体、そんなタイミングで自分に直接関係ないことを教えてって聞くわけないだろ気が付けよ

          • by fcp (32783) on 2013年09月27日 20時36分 (#2467280) ホームページ 日記

            火の粉が飛んできそうだったので、問題箇所を相手に気付かせるような
            教えて発言をしたら説明する為に調べたんだろうか
            その問題箇所に気が付いて得意げになって上から目線で説明してましたよ

            3 回読み返してようやく理解できたけど、仕事でもこんなわかりにくい言葉で意思疎通をしているの?

            親コメント
    • by Anonymous Coward

      影響調査に1ヶ月は長いだろ。
      というかストーリーのタイトルおかしくない?
      1ヶ月+数週間じゃん。

      • by Anonymous Coward

        規模や複雑度を考慮に入れてますか?

    • by Anonymous Coward

      影響調査に1日
      影響調査の報告資料作成に3日
      影響範囲レビューの手配と実施に1週間
      プログラム変更票作成に1日
      プログラム変更票レビューの手配と実施に1週間
      プログラム修正に1日
      プログラムレビューの手配と実施に1週間
      テスト仕様書作成に1日
      テスト仕様書レビューの手配と実施に1週間
      テスト実施に1日
      テスト結果レビューの手配と実施に1週間

      • by Anonymous Coward

        いやそうじゃなくて
        月末集計処理結果の照合が済むまでの時間でしょう

  • クリティカルセクションを外部のエンジニアに頼りきりで引き継ぎしてないとか、修正箇所を仕様書に反映してないとか、システムも問題だったんだろうけど運用の問題がかなり大きいんじゃ。

  • by Anonymous Coward on 2013年09月25日 19時32分 (#2465943)

    で、その1行のソースがざっと何百Kbyteぐらいあるんですか?

    • by Anonymous Coward

      1行は80桁だろ、COBOL的に考えて……

  • by Anonymous Coward on 2013年09月25日 19時34分 (#2465944)

    >>というほど、長年の保守と改修のつぎはぎで大変なことになっていたそうだ。

    >>短期間の開発で収まる規模の開発を段階的に繰り返すことで必要となる機能を実装するという開発スタイルに変更した

    これどう違うの?
    教えてエロイ人。

    • 前者は後からいろいろ改修する予定で書いていないから、改修のたびに場当たり的に修正してつぎはぎだらけのコードになる。開発者も年々汚くなっていくコードを見ながら「こんなつもりじゃなかったのに…」と落ち込む。

      後者は後で改修することを最初から考えて作っているから、改修を繰り返してつぎはぎだらけのコードになっても、「さ、最初から修正を繰り返すつもりだったもんね! アジャイルアジャイル! (呪文)」と言えて精神衛生上良い。

      …ではなくて、後者だと部品ごとに完成させて、最初の部品を納品した段階で使い始めるので、システムの利用者からのフィードバックが早く得られるとか、部品間の結合が疎な保守しやすいコードになりやすいとか、そういうことではないかな。

      親コメント
    • by Anonymous Coward

      「エロい人」ってネタ的にだいぶオッサンくさい部類になってきたなあ。

    • by Anonymous Coward

      状況から考えて、
      変更後はつまりアジャイルだと思っておけばいいんじゃないですか?

      文章からは確かに読み取れませんが。

      • by Anonymous Coward

        「これどう違うの?」って質問は「アジャイルは「保守と改修のつぎはぎ」とどこが違うの?」って意味ではないかと。

        • by Anonymous Coward

          そういう人には、まずはアジャイルを勉強してもらうしかないと思う。

          全然違うんだけど、そういうものこそ分かってない人に説明するのはとても面倒。

        • by Anonymous Coward

          具体的にはいろいろな工夫があります。
          工夫の内容についてはアジャイルの本を読むと書いてあります。

          本を読まずにここのコメントで理解しようというなら、
          それは間違っているとしか言いようがないですね。

          もちろんその工夫を導入すればすべてうまくいく、なんてマンガみたいな話ではありません。
          仕事を甘く見てはいけませんね。

          うまくいった例ならあります。

  • by Anonymous Coward on 2013年09月25日 20時26分 (#2465971)

    改修からリリースまで 1.X 月かかる != 改修の工数が 1.X 人月

  • by Anonymous Coward on 2013年09月25日 23時25分 (#2466071)

    たとえばSQL文とか。
    内容のミスだけでなく、夜間に終えなきゃならないバッチが終わらなかったらオオゴトだし。

  • by Anonymous Coward on 2013年09月26日 1時44分 (#2466125)

    ここまでくると、業務そのものの再定義と再構築、それに併せたコンピュータシステムの再構成が必要な段階のはず。
    それだけ組織形態や業務フローが硬直しているという証左とみるべきでは?
    まあ、ベースとなるシステムがとんでもないタコシステムだった、という可能性も否定できませんが。

    本質的にはコンピュータシステムの話ではなく、組織のマネジメントの問題になっているような予感。

typodupeerror

海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs

読み込み中...