システムを考える

スキル | ワークスタイル | 技術動向 | 業界動向 | 職場

» 2024/11/12

情報システム業界で仕事をしているわけだから、システムを考えることは当たり前だと思う。しかし同じ業界に生息していても、システムについて考えている人は意外と少ないのかもしれない。そんな気がしてきていて。情報システムではなく情報技術を考える人はいたとして。

先日、経理の担当者から受注情報をシステムに登録したら経理に一報くれ、とアナウンスがあり、システム登録するれば自動的に通達メールが飛ぶ仕組みなのになぜわざわざ、と思っていたら多くの通達メールが届くので埋もれて気づかないとのこと。
疑問は３つ。経理側がメールに埋もれて気づかないからと言って、何故こちらが一報する、という手間を増やさないといけないのか。自分達が失念するくらいだから、こちらも失念する可能性は考えられないのか。そもそも何故、経理が受注情報を把握しないといけないのか。

また別件で、別部署がメンテナンス作業時に障害を起こした、という事で、その情報共有のためと称して招集がかかる。障害の経緯や内容は良く分からなかったが、二人体制の作業にも関わらず二重チェックが形骸化しておりミスが発見できなかったとのこと。二度とミスを起こさないためになぜなぜ分析を行い、結果、手順書の見直しと、チェックシートを作業実施者と監督者が両方記載する方式に変更、ルールの徹底と水平展開。
疑問は、これら対策は本当に抜本対策なのか。

なぜなぜ分析はトヨタ生産方式を構成する方法の一つであるが、一方で自働化という考え方もある。豊田佐吉が発明した自動織機に、稼働中に糸が切れた事を検知して自動で止まる装置が組み込まれていたことに由来する。異常が起こった場合に機械がそれを検知して止まるので、人を機械の番人にする必要がない。

また、アマゾンのモットーには、「善意は役に立たない。仕組みだけが役に立つ」というものがある。人ががんばる善意の行動よりも、仕組みを作る方が大切だ、と言っている。逆もまたしかりで、悪意のある行動もヒューマンエラーも、仕組みを作れば防ぐことができる。

イーロン・マスクはテスラをフルオートメーションの工場で作りたいらしい。どうしても人の作業の方が効率がよい工程があり、この工程のオートメーション化に拘った失敗を反省したりもしているが。理想はフルオートメーションで24時間テスラを作り続けることができる工場だそうな。

どの事例も、人ではなく仕組で問題を解決しようとしている。この仕組、アマゾンではmechanismといっているが、テスラの工場のようにどうしても全て機械化できないと考えると、人の役割が残ること踏まえて本稿ではシステムと言いたい。

システムとは複数の複雑な要素がひとつの統一体を構成する組織のことである。自然もそうだし、人工物もある。人工物のシステムは、何か実現したいことに向けて、複雑な要素を組み合わせて誰が行っても継続的な結果でる仕組みである。そのためシステムを考えるとは、この仕組み自体を考えることであり、要素のひとつだけを考えることではない。

こと、情報システムで言えば、構成する要素として、アプリケーションがあり、サーバがあり、ネットワークがあり、ＰＣがある。それだけではなく、利用者いて、適用する業務があり、運用保守も必要だ。また、連係しなければならない他のシステムがあり、様々なデバイスや機器もある。いずれもが、それぞれ複雑で異なるシステムである。これらを有機的に関係させて目的の動作をさせないといけない。

大切なことは人工物であるかぎり、このシステムが達成すべき目的があるということ。そして各要素は各々の理に従ってでしか動かないということ。仕事柄多くのシステムやシステム開発を見てきたが、意外と何を実現しようとしているのか分からないシステムに遭遇する。最初からそういうシステムを開発してる場合もあるが、長い間継ぎはぎを続けてきた結果、そうなってしまったシステムもある。

また、各要素の理を無視してシステムを構築しようとしている場面にも遭遇する。無から有は作り出せないのが理だが、無から有を作り出そうとするようなシステムを求めるような場面。これを無理という。例えば統制を目的としたにシステムに対して、便利さや効率性を求めたり。

こうしてみると、システムを考えるうえで大切なことが二つあることがわかる。ひとつは、そのシステムが何を実現しようとしているかという、目的。もうひとつが各要素を支配している、理。理を知って、目的を達成する仕組みを作ることがシステム開発だ。仕様書や設計書に書かれてあることをプログラミングすることは一緒懸命考えているけれど、プログラミングの仕様書や設計書のもととなるシステムについては、意外と考えていないのではないか、というのが冒頭の問題提議。

これがもし本当であれば、考えてみると怖いことで。まずシステム設計があって、それを実現する方法としてプログラミング設計やインフラ設計があるはずなのに、そのシステム設計がなされていないとなると何を根拠にプログラミングの仕様書や設計書が作られているのか。

Do the right things right.という言葉がある。「正しいものを正しく作る」位の意味だ。シンプルで当たり前の言葉であるが、その実現は意外と難しい。そもそも作らなければならない「正しいもの」が何であるか自体が分かっていない可能性がある。加えて「正しく作る」という部分に関しては、（それが正しいかどうかは別として）これまでのやり方を踏襲して、ということになるのではないだろうか。

システム業界に従事している技術者がシステムを考えていない。これは「正しいもの」が何であるかを考えていないということでもあり、作り方は過去のやり方の踏襲で「正しい」方法が何であるかも分からない。一般的に当たり前のことが、実はこの業界では当たり前ではないかもしれない。これが本稿のテーマである。いや、そんなことはない、という反論があって欲しいところではあるが、改めてそういう目で自分の周囲を見てみるのも大切なのかもしれない。