-shared-img-thumb-SAYA160312200I9A3531_TP_V

情報システムは、数多くのハードウェアやソフトウェアを組み合わせて構築するものです。システム開発のプロジェクトで、新規にソフトウェアを開発したとしましょう。満を持してソフトウェア開発を完了し、現場の環境にインストールしたところ、そのソフトウェアが期待通りに動かず使い物にならない……このようなことは、実際によく起こります。

システムエンジニア(SE)は、このような状況に遭遇した場合どのように対応していったらよいでしょうか。

ここでは、現場で動かないソフトウェアがあった場合に、どのように問題解決をしていけばよいかについてお話していきます。ここで述べる内容を理解することにより、「ソフトウェアが現場で動かない」といった問題の解決を早めることができるとともに、一般的な現場対応のスキルが身に付きます。

現場でソフトウェアを動かす責任はすべて自分にあると考える

他人の作ったソフトウェアを現場に入れて動かないとき、SEの中には「あの人(会社)の作るソフトウェアは、いつも品質が悪くて困る」「どうしようもないから、開発担当を呼んで現場で直させよう」などとすぐに人(他社)のせいにする人がいます。しかし、SEがこのような態度でいては決して問題を早く解決できるようになりません

このような場面では、「開発担当者は、ソフトウェアを作る人」「ソフトウェアを現場で動かす責任は、SEにある」と考えるべきです。このように書くと、「開発したソフトウェアが動かないのは、開発担当者の責任に決まっているではないか。動かないソフトウェアを作ることに、何の意味があるのか」と思う人がいるかもしれません。

このような考え方は、半分正解で半分間違っています。なぜなら、この時点でソフトウェアが動かないのは「ソフトウェアのバグ」のせいなのか「開発と現場の動作環境の違い」のせいなのかが分かっていないからです。そして、その原因の切り分けは現場のSEが行う仕事になるのです。

原因の切り分けは、どのようにすればよいでしょうか。それには、問題の再現パターンを突き止めることが近道です。問題の再現パターンが分かれば、そのパターンを開発担当者に伝えて開発環境で再現するかどうか確かめてもらえばよいのです。

再現パターンの確認の結果、開発環境でも問題が起きることがわかれば、問題の原因は「ソフトウェアのバグ」です。しかし問題が起きなければ、「開発と現場の環境の違い」があると考えられます。そして、次は「開発と現場の環境の違いを吸収するにはどうしたらよいか」と考えることになります。

稼働まで時間がないときは、「開発担当者を現場に呼んで直させる」というやり方になることもあります。しかし、このやり方は最終手段と考えてください。このやり方の場合、問題の原因はたいてい現場に呼んだ開発担当者しかわからなくなります。

そのため、以後他の場面で同種の問題に遭遇した場合に、いつも開発担当者を呼ぶことになってしまいます。開発担当者は、複数の案件を抱え忙しいのが普通です。開発担当者を現場に呼ぶと、出張経費が多くかかりますし他の開発案件の進捗にも影響が出ます。

一方、ソフトウェアが動かないときの問題解決はSEのスキルであると考えられます。これからは、「動かないソフトウェアを動かす」のはSEの仕事だという認識を持ってください。

SEがソフトウェアの問題の原因を特定する

ソフトウェアが動かないとき、SEはどうしても最初にプログラムのバグを疑ってしまいがちです。しかし、現在のシステムは高度に複雑化しています。実際には、開発担当者の行うプログラムのコーディング作業以外が原因になることも多いです

「開発環境と現場のファイルアクセス権限の違い」「開発に使用するソフトウェアライブラリの問題」「Windows OS(基本ソフト)の同じバージョンであっても、エディション(中小規模ワークグループ用と大規模エンタープライズ向け)における動作の違い」といったものが原因になることも実際にあります。

しかし、これらの原因にたどり着くには開発担当者任せではできないのです。現場のSEが、現場で起きている現象を把握し仮説を組み立てていくしかありません。SEの知識や経験にも左右されます。そして、SEが現場に合わせたソフトウェアの修正案を立案していくという姿勢が求められるのです。

このように、「動かないソフトウェアを何とか動かす」スキルはSEにとって必要なものであると言えます。動かない原因を思い込みで決めつけず、開発担当者の協力を得ながら自分で責任を持ち考える姿勢が重要です。そのような姿勢で仕事を行っていけば、お客さまにも会社にも評価されお互いの信頼関係を深めることができるようになるでしょう。