オルナタブロガーの中さんが上流工程に関わる人にこそプログラミングを経験してほしいというエントリを書いておられました。
私は提案・設計・開発・運用を担当するという立場でして、これはSEとしては少数派になるかと思います。自分で作るので、提案や設計を行うにしても非現実的なものにならないようにブレーキがかかります。
一方で、自分が作りやすいようにですとか、自分の技術レベルに収まる範囲で話をしてしまいがちです。SEはすぐに「無理です」と言うと批判されることがありますが、広げた風呂敷を後から自分で畳む事がわかっているとついつい「無理です」という言葉を発してしまいがちです。
もちろん、そこはお客様の満足が大きくなることを意識しなくてはなりません。できるだけそうなるよう、普段から心がけているつもりです。
中さんのエントリの後段でこんなことが言われていました。
ちなみにこの話は、開発担当と運用担当にそっくり当てはまる内容です。「運用はシステム開発のおまけ」くらいにしか思っていない方、是非とも運用業務を一度経験してみて下さい。
同感です。私はNotesを担当していますが、Notesは運用ツールが大変充実しています。おそらく何年・何バージョンにも渡って多くの会社で使用されてきた実績から運用ツールも育ってきているのだと思います。
それに対し、特殊な機能を提供するソフトウェアは特定のメーカーが独占的に提供する事が多く、利用者も多くありません。そういったソフトウェアでは操作マニュアルや運用ツールがあまり充実しておらず、困る事があります。私自身も運用を念頭においた開発を行いたいものです。
この事を考えているうちに、ひとつの思いがよぎりました。運用を念頭においた設計をするのと同様に、これからの時代は監査がしやすいような設計を行うことの重要性が増してくるのではないでしょうか。
監査がしやすい、もう少し具体的に言うと「会社が定めたルールどおりに情報システムが運用されている事を証拠で示すことができる性質」を備えたシステムが必要とされています。
簡単な例を挙げますと、営業マンがお客様に見積もりを出すにあたって見積もり金額の承認を金額に応じて部長・課長・係長にもらうというルールがあるとします。このルールが遵守されていることを後から確認しようとした場合、システム上に「この見積書は400万円だから課長が決裁した」という証拠が残っていれば可監査性が保たれている事になります。
一方で課長が決裁したかどうかが証拠に残っていなければ、可監査性が保たれていない事になります。その見積もり書がトラブルになった場合に課長が「知りません」と言ったら混乱が起きますので、後から監査可能な証拠を記録しておくことは重要なことになります。
監査しやすいようにする、というのも運用の一部分という事ができると思いますが、昨今の社会情勢からするに監査の重要性というのはますます高まっています。システムの設計に携わる人は一度監査業務に触れておくとよいのではないかな、と思いました。
# そういえば明日(2008年6月4日)はシステム監査技術者の午後問題の解答例の発表でしたっけ。
Special
- PR -| NAKA@情報インフラ24時 | 2008/06/08 16:31 |
|
コメントが遅れました。TBありがとうございます。 運用改善の取り組みをしていると、「どうしてこんな設計になっているのだろう」と首をかしげる場面が多々あります。よくよく話を聞いてみると、運用担当者は蚊帳の外で物事が決められてしまったということが多いのですが、システムライフサイクルの中で最も長い期間を占める「運用フェーズ」を考慮せずして、効率的なシステムを作ることは不可能だと思っています。 監査という観点も、まさに同じですね。システム構築契約時にいい加減なスキームでやってしまうと、後から説明するのに苦労することでしょう。そういう場面、何度か遭遇しています。 | |
| yohei | 2008/06/09 00:16 |
|
中さん、コメントありがとうございます。 | |

富士通元社長の山本卓眞氏が残した次代へのメッセージ
Facebook就活はもう古い?
東北をコットンの生産地としてブランディングしたい──リー・ジャパン・細川取締役
東北から始まるイノベーション
貧困国の雇用を創出する印刷屋、丸吉日新堂印刷の挑戦