【DX化に失敗しないための本】『システムを作らせる技術』でITプロジェクトを成功へ！

「社内のITプロジェクトが、ことごとく残念な成果で終わる。。」

こんな人にピッタリの本を見つけました。

『システムをつくらせる技術』です。

『システムをつくらせる技術』（画像クリックでAmazonのページにジャンプします）

本書は、システムを「発注する側」に向けた本で、「どんな事に気をつければ、システム化を成功に導けるか？」ということが、とてもしっかりと書かれた本です。

本書の概要と、特に重要な箇所をピックアップしてまとめていきます。

この記事のまとめ

システム化に特に気をつけるべき3点

システムは「Why」を最初に明確にすべし！
納期と予算は必ずバッファを設けるべし！
今後の機能追加を想像し、きちんとITベンダーに伝えておくべし！

【目次】

本書の概要
特に重要な箇所
まとめ

本書の概要

本書の概要は以下のとおりです。

システムを開発する側ではなく、「発注する側」に向けた本
システム化は丸投げでは絶対に失敗する。発注側も一定以上のスキルが必要
その求められるスキルを、著者の実体験を踏まえながらガッツリ解説

何よりも本書の序盤のメッセージが胸に刺さります。

（意訳）

「普通、家を建てる時は丸投げではなくて、建築士と相談できるレベルまで、家のことをよく学んで発注をするだろ？」

「それなのに、システムになった途端、お前らは急に”丸投げ”する。そんなんじゃ絶対に失敗するだろ！」

システムを発注したことがある方ならよくわかると思いますが、システム発注の費用って、めちゃくちゃ高いんですよね。

それなのに、お金を払いさえすれば、DX化が成功すると勘違いしている人が多い。

まずは、発注側もスキルを持って臨まないといけない、ということを肝に命じなければなりません！

特に重要な箇所

本書で特に重要な箇所を簡単にまとめます。

システム化は「Why」から始めて、それをぶらさない

まず重要なポイントが、「システム化は、まずはWhy（＝目的）を明確にする」ということです！

システム化のプロジェクトを始める時、だいたいの目的が、「システム化によって、業務の無駄を削減する」という曖昧なものだと思います。

そうした目的のもと、早速システムの要件を決めていくフェーズに入ってしまう・・・。

これでは絶対にそのプロジェクトは失敗します。

なぜなら、Whyが曖昧だと、システムの要件を決めるときに「あんな機能も必要」「こんな機能があると嬉しい」と、希望機能が好き放題膨れてしまい収集がつかなくなるからですね。

では、Whyが明確だとどうなるか。

機能が膨らみそうなときに、「それは目的に沿ったものかどうか？」という基準で重要度を判定できるようになります。

たとえば、Why（目的）が、「オフィスごとにばらばらだった業務を統一する」という明確なものにきめたとします。

すると、システム要件のフェーズに入ったあと、ユーザーから、「こんな入力機能があると、自分の部門としては嬉しい。」という意見が出たときに、

「それは、業務を統一するという本来の目的とは少し離れてしまうので、一旦保留としましょう。」と、判断ができるようになります。

こうして、重要な機能に着目して「舵取り」が上手にできるようになる。

これが、システム化の最初に「Why」を明確にすることが重要な理由です。

システムの発注者側も、このWhyが最初に明確になっているか、ITベンダーと一緒に議論しないと、終盤で共倒れになってしまいます。。

納期と予算は必ずバッファを設ける

続いては、「納期と予算には、必ずバッファを設ける」です。

つまり、予め余裕をみておく、ということですね。

これは、一度でも大きなプロジェクトを経験したことが有る方なら、大きくうなずくことだと思います。

ITプロジェクトは、半年から～数年と、長期間に及ぶことがほとんどだと思います。

そして、予想外のことは「必ず起こる」と言ってしまえるほど、トラブルに見舞われます。

発注者側は、そのことを予め知っておかなければいけません。

「高い金を払ったんだから、あとは納期通りに、コストの範囲内でやれ」

という思いを持ってしまう人は多いと思いますが、それではITベンダー側も、システムを無理に作り上げることになり、

バグが多いシステムや使いづらい機能をもったシステムができてしまうのがオチです。

よって発注者側は、最初に大きなコストを支払ったとしても、後々のために、納期と予算にはバッファが必須です！

これらのバッファがあることで、大きなトラブルに冷静に対応できるようになります。

ITベンダーは「システム品質」には全く意識しないことに注意

個人的に納得感が非常に強かったのが、こちらの箇所です。

「ITベンダーはシステムの品質は全く意識していない。」このことに要注意。

これを発注者側はよく意識しておくべきなんですね。

「え？品質を高めないと、ITベンダー側も、バグの修正で困ってしまうんじゃないの・・・？」

と思いがちですが、ITベンダーが意識していることは品質ではなく、「精度」なんですね。

精度とは、つまり、「バグがいかに少ないか？」ということです。

一方で、ここでの品質とは「機能修正や追加が、どれだけしやすい作りになっているか？」ということですね。

多くのITベンダーが精度向上に熱心なのは、バグが出ると無償で直す責任があるからだ。バグが判明したら、たいていは責任の所在は明確だ。作った人が悪い。

（中略）

それに比べて、品質は高いか低いかがわかりにくい。システムが稼動して何年か経ってから、品質が低いことがわかるケースもある。だから多少品質に難があっても、納品してお金がもらえてしまう。

（Kindle位置：4,461)

バグが多いとITベンダー側の責任ですが、システムの中身が「今後、機能追加しやすい構造かどうか」は責任の範囲外なんですね。

機能追加の際には、改めて客からお金がもらえるため、工数の比例してお金を受け取れるからです。

よって、ITベンダーは「機能追加を効率よくできるような構造にしておくこと」に、なんのインセンティブも働かないんです。。

そのため、発注者側もそのことを意識しておくべきです。

まず簡単にできることは、システムが今後機能追加を予見できる部分に対し、

「〇〇という機能は、今後機能追加される可能性が高いため、マスタを分けておくなどして対策を打ってもらえませんか？」

と予めお願いをすることです。

ITベンダーの収益構造が「人月商売」と呼ばれるものなので、完全に防ぐことが難しい問題です。

しかし、発注者側としてこの背景をよく理解し、少しでも今後のことを考えたシステムになるよう働きかけをしていくべきなんですね。