このブログでは、中小企業経営者（ＩＴ企業）が、中小企業経営者に向けて、知った気になれるＩＴネタを発信しています。課題解決の気付きに、ここで発信するネタが少しでもお役に立てれば幸いです。ＩＴをどんどん活用して、我々の手で豊かなニッポンを取り戻しましょう！！
さて、７回目となる今回は、「失敗しないシステム導入の方法論」にフォーカスしようと思います。前回、前々回の記事では、システム導入が失敗する要因について語っておりますので、まだお読みでない方は、ぜひ下記をチェックしてみてください。
他人事から自分事へ
多くの場合、人は形にしてみせてもらうまで、自分は何が欲しいのかわからないものだ
スティーブ・ジョブズが言うように、人は出来上がったシステムを使い始めてから沢山の要望に気付きます。その要望が山のように詰みあがっていくうちにそれが不満へと変わり、様々なトラブルを引き起こす事となります。
それだったら、という事で、
動く画面を先に作って、使い手に事前検証して貰おう
という作戦を取った事があります。
見積書を管理・作成・印刷する機能一式を使い手のパソコンにインストールして
「これで問題無いか、１～２週間使ってみてください」
とお願いしてみました。
その後の打ち合わせでも使い手の方々は、
「便利になると思いますよ」
「今の業務を続けるのも問題ないと思いますよ」
とニコやかに報告して下さっていたので、これは順風満帆だと高を括っていました。
そしていざ、システム切り替えの日を迎えると、
「なんで、Excelから明細を全部コピペできないの！？」
「やっぱり、日付の印刷位置はこっちにしたい」
「単価の少数を四捨五入にして欲しい」
・・・結局、何も変わりませんでした。
つまり、人は形にしてみせても、見たものを自分事として捉えてもらわなければ何の意味もない、という事のようです。
事前に動く画面を使ってみた所で、実際にそれで本当の仕事をしてみない限りは、結局、何も見えないという事です。
考えてみれば、
「これで問題無いか、１～２週間使ってみてください」
というお願いは、使い手の仕事を増やす行為です。ただでさえ忙しいのに、新システムの新しい画面を試用しろと言われた所で、所詮、他人事となってしまいますよね。確かに、自分だったらそうなってしまうと思います。どうせ、自分以外の誰かが見てくれているだろう、と。
事前検証作戦を何度も失敗させた私は、部分的な機能検証する際、
『使い手に他人事ではなく、如何に自分事として検証してもらうか』
それが大きなカギになりそうだと、気が付きました。
小さく作って大きく育てる
システム導入に関して、私が経験した数多くの失敗から感じた問題点は下記の通りです。
- システムが完成して使い始めるまで使い手のイメージにフィットするか把握できない
- システムが完成して使い始めるまで全ての要求を把握できない
- 見積時に要求をハッキリさせないと大きな見積誤差が発生する
- 見積時に要求をハッキリさせるためには結構な工数が必要
- 一度完成してしまうと新しい要求を反映できない
この他にも色々な問題はあるかと思いますが、私が特に重要だと感じている部分は上記の通りです。この問題に立ち向かうためには、
- 使い手のイメージにフィットするかを早急に評価できること
- 使い手の要求を早急に炙り出せること
- より少ない工数で見積誤差を最小にできること
- そもそも変更を受け入れる前提で開発を進めること
上記の課題をクリアする必要があります。
実は、これらの問題を一気に解決してくれそうなシステムの開発手順というものが存在します。それが、小さく作って大きく育てる、アジャイル（agile：機敏な）開発と呼ばれるやり方です。クラウド型のサブスク・サービス等では一般的な手法なので、耳にされている方も多いかも知れません。
アジャイル開発は、システム全体を一気に造り上げる従来の手法に比べて、下記のような特徴を持っています。
- 大きな開発範囲を細かく機能分割する
- 細かく分割した機能単位でリリースする
- 何回もリリースを続ける
- リリースの結果発生した要求を受け入れる『変化』を前提とする
リリースとは、実際に業務機能として使ってもらうという事です。ですので、使い手には自分事として受け入れてもらう事ができます。
また、機能範囲を小さくすることで、見積誤差も小さくする事ができ、リリースまでの期間も短くできるため、使い手の要求を早急に炙り出すことができます。
そして、何回もリリースを続けること、変化を受け入れることを前提とする事によって、使ってみて初めて見える要求をネガティブな要素として捉えるのではなく、仕事をより良いものへと進化させるポジティブな要素として捉えられるようになります。
例えば、業務システム導入プロジェクトの場合、従来であれば
- 全体を設計する
- 全体の設計内容に関して合意する
- 全体を作る
- 全体をテストする
というような流れで開発を進めていたものを
- 全体を細かく分割（見積登録，検索・照会など）
- 次のリリース(２週間など比較的短い期間)までに何を実装するかを合意する
- 合意した内容を実装・テストする
- リリースする
- ２へ戻る
という短いサイクルを積み重ねていく事によって、システムを構築していこうという考え方になります。リリースの度に発生する要求も、『2.次のリリース(２週間など比較的短い期間)までに何を実装するかを合意する』の中で取捨選択をして、実装に加えていきます。
つまり、小さく作って大きく育てる、といった手法です。
素早くリリースする事で、使い手の要求を早急に炙り出し、そのイメージにフィットするかを早急に評価できるようになります。また、対象範囲を小さくする事で、見積誤差を最小化する事もできるようにもなります。
これで、使い手と作り手の不満を最小化し、誰もが笑顔になれそうなのですが、この手法にも、下記の様な大きな問題があります。
- 実業務使用に耐えうる実装になるまで時間を要する
- 最初に定めた予算及び期間で、全ての範囲を作り切れる保証ができない
実業務使用に耐えうる実装になるまで時間を要する
新システムを１から作る場合は、この問題が顕著になります。ですので、最初の１ヶ月は見積管理のベータ版を作る、というような仕切りにしておき、ベータ版をスタート地点として改善活動を始めていく、という進め方をする場合もあると思います。
また、基準とするカスタム可能なパッケージをシステムベンダーが持っている場合は、それをスタート地点として改善を進めて行くというやり方もできます。
ですので、この問題については様々な手を打てるため、受注前に方針さえ定めておけば、特に大きな問題に発展する事はないと考えます。
最初に定めた予算及び期間で、全ての機能範囲を作り切れる保証ができない
アジャイル開発の採用をお勧めする上で、決裁者が最も嫌がる部分がここなのですが、そもそも、最初に機能範囲と予算、期間を決めて一気に造る手法を取っても、結局は出来上がらないケースが殆どなので、問題の本質はあまり変わっていません。
ここで、経営者の方々にお願いしたいのが、システム導入の目的が、
『システムを造る事』
ではなく、
『業務を効率化する事、そして、より高次元の価値を提供できるようにする事』
にある事を再認識して頂きたいのです。つまり、
『当初思い描いた通りのシステムの完成を目標にする』
のではなく、
『システム導入の結果、何がどの程度効率化したのか、どんな価値が誕生したのか』
で、達成度を評価して頂きたいのです。
システム導入の最初に、上記のような評価基準が明確になっていれば、
『この要望は果たして、〇〇の向上にどの程度、役に立つのだろうか・・・』
『この機能は果たして、新しい価値の実現に本当に必要だろうか・・・』
と、優先順位を判断するための物差しができます。この物差しがあるからこそ、どの機能をどの程度の完成度で、いつまでにリリースできるのか、コントロールできるようになるわけです。
「システム的に難しくても、どうしてもこの罫線が必要だ！！」
という使い手の方にも、
「その罫線は、〇〇の向上にどの程度、役に立つものでしょうか？それよりはこっちの方が・・・」
というように、客観的な共通の価値観で物事を判断できるようになるので、今までのように、『何いってやがるんだコイツ！！』と、険悪なムードになる事もないと思います。
客観的に評価可能な共通の物差しを作る事こそ、システム導入における肝といえる大切な部分となります。
そして更に、システムは一度造って終わりではなく、是非とも、継続して進化させていくべき資産であると、捉えて頂きたいと思っています。
システム導入は投資である
これまでシステム導入は、
『決まった予算・期間で決まったものを造る』
営みとして捉え、その開発費を単なる費用として捉えるのが一般的でした。
しかし近年、ＩＴ、ＩＣＴ技術の進展に伴い、変化のスピードは益々速くなってきています。
例え、３年前に設計したシステムが今、完成したとしても、３年前の常識が今では通用しなくなっている事も多々あるわけです。それこそ、資源の無駄に過ぎません。
この状況を反映して、最近大手企業では、『ＩＴを内製化する』事が活発になってきています。つまり今までは、
「こういうのを〇〇までに作って！！」
という感じで、ＩＴベンダー等に半ば丸投げしていたシステムの開発を自社で行おうという試みをしている訳です。
なぜ内製化する必要があるのか？
それはつまり、
『システムは一度作って終わり』
ではなく
『内部・外部問わず、激変し続ける環境に合わせて絶えず進化するもの』
と捉え、システムは使いながらも常に進化させていく資産、という考え方に変わってきている、という事が察せます。
今までは、自社業務にとってＩＴスキル等は常に必要なものではないから、専門業者に任せておけばよかったのが、
システムが自社業務にとって必須のものとなり、それを進化させていく営みこそ、会社の競争力に直結する重要な資産であるとの認識が広がっているからこそ、内製化が進んでいる要因の１つと言えるでしょう。
つまり、システム導入は費用ではなく、投資であり、常に進化させていくべきものと認識されている訳です。
それではなぜ、システムが企業に無くてはならない重要資産と認識されるようになったのか、次回は今流行の「ＤＸ化って何？ ＩＴ化と何が違うの？」にフォーカスしていきたいと思います。
ここで、結論。
システムは重要資産であり、
激変する環境に合わせて常に進化させ続けなければならない。
如何でしたでしょうか。
失敗しないシステム導入の考え方について、少しでも分かった気になって頂けたでしょうか。
これからも、このような形でＩＴネタを発信していきますので、ご愛顧のほど、よろしくお願い致します。
