83.チェンジ・ザ・ルール！

前作「ザ・ゴール２」とは、まったく別のストーリーです。

今回は私が仕事としている、ソフトウェア開発会社が例として取り上げられています。しかし、対象があまりにも大きな会社のため、参考に出来ない所もありますが、「なるほど」と思える箇所が幾度が出てきます。

新しいシステムを導入しても変化がない

企業では作業の効率化を図る上で、生産ラインや事務処理などにコンピュータを利用します。

しかし、新しいシステムを入れたはいいが

「手間が増えただけでそれほど変わっていない」

この状況を経験したこと、ないでしょうか。

本書では、このような問題について大きく取り扱っています。

問題点としては、システムを作る側と利用する側の双方に問題があります。双方の問題点について考えます。

システムを作る側の目標

システムを作る側としては、目的は「システムを売る事」です。では、どのようなシステムを作ると売れるのでしょうか。

作る側視点で考えると、次の考えとなります

• 安価である

• 短納期

• 沢山の事が行える（機能が沢山ある）

• 処理速度が高速

• 安定性（トラブルが少ない）

• セキュリティー

• 拡張性

• メンテナンス性

作る側としては、上記を満たしたシステムが目標となります。これらをまとめて「テクノロジー」と今後は表現します。

確かに、このような条件を満たしたソフトが作れるのであれば、理想的ですよね。私自身もそう思います。

しかし、これのどこに問題があるのでしょうか？

次は利用する側の要求について考えます。

システムを利用する側の要求

企業がシステムを導入する場合に、何を目的とするかについて考えると、１つの目的しかありません。

「利益を生み出すため」

え？これだけ？と、思う方はよく考えてみてください。単純に考えると、作り手と似た感じになると思いそうですが、結局の所多くが「利益」と結びつきます。

企業としては、利益を生み出さないシステムなどは必要ないのです。

作る側と利用する側の考えの違い

「利益を生み出す」以外で、作り手と使い手で考え方の異なる部分があります。

それは以下です。

沢山の事が行える（機能が沢山ある）

実際には決まった機能しか使われないことが多く、無駄な機能を実装すると「操作性が悪くなる」「納期が遅れる」「システムが複雑になる」弊害を生みます。

拡張性

将来拡張される事が決定している場合はいいのですが、そうでない場合はこだわりすぎると「納期が遅れる」「システムが複雑になる」弊害を生みます。

「システムが複雑になる」についてですが、複雑になると「メンテナンス性」「安定性」を守る事が難しくなります。

また、エンジニアの性質上「機能」を多く詰め込みたくなる衝動に駆られ、「機能が沢山ある事はいい事だ」と、錯覚しやすいです。

作り手はどのように考えるべきか

このように考えると、作り手と使い手の間には違いがある事がわかります。では、作り手は、どのように考えるべきなのでしょうか？

　「テクノロジーを提供するのではなく、利益を提供する」

これこそが、作り手が優先的に考えなければいけないことです。

使い手はどのように考えるべきか

前提として「利益をもたらすシステム」が導入されたとします。その場合に、そのシステムを利用すれば利益が増えるのだと、誰もが考えます。

しかし、実際にはそれだけでは多少は利益をもたらしますが

「所詮この程度か」

ほどの効果しかありません。なぜでしょうか？

新しいシステムを導入する前は、今まで使っていたシステムが既に存在しているはずです。当然、以前のシステムを前提に社内の運用方法も規定されているはずです。

そのことから、まず新しいシステムに沿った運用に変更されるはずなのですが、実際に運用が変更されるのはそのシステムを入れた部門や部署です。部門や部署の事をこれ以降「グループ」と表現します。

しかし、会社というのは１つのグループで成り立っている物ではなく、社内のグループ同士が互いに関連する事で成り立ちます。

新しいシステムを導入したグループでのみ、最適化が行われたとしても効果は薄く、関連するその他のグループでも、今までの運用方法の見直しが必要となります。

つまり、本書ではこの事を一番強く強調するため、タイトルが「チェンジ・ザ・ルール！」となっています。

ルール（運用）を変えることの難しさ

ルールを変更する場合、新しいシステムを導入するグループは問題ないですが、その他のグループが難しい問題となります。

そこで、変更の必要性をどのように伝えるのか、これが重要です。

本書では、新しいシステムを導入したグループの生産効率の上昇により、他の物流部門に問題が移った事を例として挙げています。

そして、どのようにルールを変更するのか、例を交えて紹介しています。

この例で一番興味を引いたのは、物流のコストを表す評価尺度についてです。つまり、この評価尺度が今までと同じルールを適用しているため、問題が発生したということですね。

ここでは、その評価尺度を次の２つで考える事により、改善を図ります。

• 出荷が遅れたオーダーの金額　×　日数　→　０を目指す事を目標

• 在庫の金額　×　日数　　　　　　　　　→　限りなく０を目指す事を目標

つまり、この２つの評価尺度に基づいて生産を調整し、在庫の量を管理します。

このように具体的な形を作った上でルールの変更を提案すべきということですね。

ソフトウェア開発会社では、混沌としたプロジェクトが多いですが

「利益を与える」

ここに注目することで、使い手にも喜んでいただける製品が作れるのではないでしょうか。

まとめ

自身の経験と照らし合わして、書かれている内容でうなづける所が多くありました。

本書でも書かれていますが、エンジニアの特性として、作るのが楽しくなってくると、目的が

「自己の欲求を満たすため」

に変ってしまう場合があります。余分な機能を付けたり、変に凝ったりするのはそのような思考が働くためだと感じます。

私自身も２０代の頃はそうでした。でも、経験を重ねるにつれ

「シンプルさの重要性」

これに気づきました。それ以降は、極力シンプルな設計やUIとし、常に使う側視点で設計することを心掛けるように変わっていきました。

特に重要な視点として

• 運用でカバーすべきか

• 設計でカバーすべきか

これがあります。何でもかんでも設計でカバーしてしまうと、複雑化するため、運用とのバランスを取りながら「落としどころ」を見つける必要があります。

特に、イレギュラー処理やエラー処理等は実運用を見据えながら、設計しなければいけません。

ソフトウェアやUIの設計をされる方は、是非この「落としどころ」について、十分に検討されることをお勧めします。なぜなら、これが

「ENDユーザーの利益をもたらす要因」

となるためです。