日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

JavaScriptを有効にし、Cookieを受け入れ、以下のブラウザを使うことで完全なコンテンツが楽しめます。
Mozilla Firefox 3.0(Get Firefox)・Opera 9.6・Safari 3.2・Lunascape 4/5(Gecko)・Lunascape 5(WebKit)
Internet Explorer 7/8とそれを使うIEコンポーネントブラウザ(Lunascape・Sleipnirなど)

後で分かった設計ミス

チームリーダーから頼まれて、モジュールの故障解析手順の調査を依頼された。

サービスマンがこのモジュールは本当に壊れているのか、実はそうでもないのか切り分けをしたいと。

その調査をしていたのだが、設計がおかしくて、解析に難ありということがわかった。


うちの職場で開発している製品では、重故障・軽故障・正常動作 という3モードを持っている。

重故障は一度故障すると交換しない限りは復活しない故障、軽故障は外部要因で発生する異常状態を表している。

ところが、境界領域というのもあって、内部の故障で交換するしかないか、外部要因で発生しているか切り分けできない故障もある。

チームリーダーから依頼されたのは、モジュール交換をするべき故障なのか、まずは外部要因を疑うべき故障なのか切り分けをしたいという話。


モジュールが重故障・軽故障・正常動作であるかはインジケータを見れば容易に判別できる。

ここから具体的に何の故障であるか切り分け、内容によっては外部要因を疑ってもらう必要がある。

ところがアーキテクチャ的な問題でこのモジュールとのデータのやりとりは非常に制限されている。

それでも軽故障であれば、故障情報の確認は可能なのだが、

重故障の場合、通常の方法では故障情報の確認ができないのだ。

その上、外部要因で発生する重故障というのが存在しているという、もっと厄介な事情もある。


すなわち、この問題は以下の3点の問題があったわけだ。

  1. アーキテクチャ的にモジュールとのデータのやりとりがしにくい
  2. それでも軽故障なら故障情報の確認が出来るが、重故障は故障情報の確認が出来ない
  3. 仕様外の環境で使うと、外部要因で重故障を発生させられる

1はアーキテクチャ的な問題で、致し方ない面もある。ただ、それゆえの不都合というのは他にもいくつかある。

その弱点を一部補う機能があったのだが、2に書いたとおり、重故障ではうまく働かないという設計上の欠陥があった。

もともとデバッグ機能だったので、そこまで深く考えて作った機能ではなかった故の問題のようだ。

それでも外部要因で発生しうる故障は軽故障に分類してくれていればよかったのだが、

特定の故障は外部要因で起こせるけど、本当に内部回路が故障していたら怖いから重故障にしてしまったのだという。


僕はこの中では3が一番大きな問題だと思うんだけどね。

そのことでチームリーダーに当時の経緯を聞いてみたのだが、元になったモジュールの設計がそうだったから、それに従ったとのこと。

一方でこのモジュールは重故障と軽故障、どちらにしてもインジケータの表示が変わる以外の差はあまりない。

というのも、重故障の場合に取れる次善の策というのがこのモジュールにはないから。

他のアーキテクチャだと、重故障の場合は次善の策を取る仕組みがあるんだよね。軽故障は外部要因によるものと判断して次善の策には出ないんだけど。

故障の種類によっては次善の策があれば重故障、なければ軽故障という区別をすることがある。

その観点で言えば、このモジュールに重故障という概念は不要な気はするのだが、

一方で絶対に復活しない故障というのも存在していて、そういう場合は潔く交換しなさいという指示になるので、その点では重故障の意味はある。

ところが、なぜか外部要因でも起こしうる故障が重故障に分類されていたので、単純に「重故障の場合は交換しなさい」と言えなくなってしまったと。


それでも2の問題がなければ救いようはあった。

ところが重故障の場合は故障情報が取得できないというバグがあったのだ。

そもそもこの機能は純粋なデバッグ機能で、故障解析に使いたいという要求があって作った機能ではなかったと。

ところが1の問題があって、もジュールとのデータ交換には大きな制約があった。

その点ではデバッグ機能とはいえ、モジュールとやりとりできる貴重な機能の1つではあった。

ところが、しょせんはデバッグ機能、開発者以外が使うことは全く想定しておらず、出来の悪い機能だった。

その結果、重故障の場合は故障情報が取得できないというバグがあるまま、製品化されてしまったのだという。

当初、故障情報を取得して故障要因を切り分けしたいというニーズはほとんどなかったそうだ。

開発者はデバッグのために故障要因を知りたかったが、まさかその機能をサービスマンが使うとは想像もしてなかったのだ。


このモジュールの設計が、僕が今の職場に来る1年前ぐらいに行われたもので、僕は設計に関与していないのだが、

どうして「それ重故障にしちゃうんですか」という問題提起がなかったのかは本当に不思議な話だ。

確かに過去の同種のモジュールの設計に従ったという事情はあるのだが、そもそもそれの設計がおかしかったんだよね。

過去のモジュールの設計に従った結果、サービスマンが苦しむという展開は予想できなかったにしても、

そもそもの設計ポリシーとは矛盾しているので、原点に立ち返って考えるべきだったんじゃないかなぁと。

当時、僕が設計に関わってたら、この問題は回避出来てたんだろうか? どうにも悔しい思いがある。

(もっとも職場に来た直後だと、設計ポリシーを詳しく知らない状態だっただろうから、そういう意見は言えなかったかもしれないけど)


まぁもう世の中に出ているもので、なおかつ通常稼働では発生しない問題なので、どうしても修正しないといけないバグではないのだが、

そうはいっても悔しいというかなんというか。もうちょっとやりようがあったよねぇと。

なんか、バグ修正する機会があれば、上で書いた2の問題を修正したいところだけどね。

3は外部仕様にも絡む問題なので不用意に修正はできないが、2は元々デバッグ機能なので外部仕様とは無関係に修正できる。

修正後はデバッグ機能とはいえサービスマンにとっても役立つ機能になり、結果として新しい外部仕様として盛り込まれるのだろう。

チームリーダーには「他の設計変更するときにしれっと変更しましょ」と意見は述べておいたが、やるかは知らない。


Author : hidemaro
Date : 2017/12/07(Thu) 22:15
電気・数学・物理 | Comment | trackback (0)

Tools