あなたは「作る」、つまり構築することに決めました。自社のカスタム エンタープライズソフトウェア ソリューションが技術的な課題を解決する最良の手段だと思われたのでしょう。エンジニア部門から、このソフトウェア要件は社内で対応可能だと言われたのかもしれません。あるいは、このシリーズのパート1またはパート2をまだ読んでおられないのかもしれません。
どんな理由で作ることに決めたにせよ、またどのような技術的課題を解決するにせよ、構築では実装、保守、維持、純粋なノウハウにおける課題に直面します。自社ソフトウェア管理のやっかいな問題が明らかになってくると、弊社のサービスを求める電話がよくかかってきます。私は長年、お客様と協力してソフトウェアを構築してきました。この経験により、組織が独自のソリューションを構築する場合に突き当たる課題も、ソリューションを購入した場合のメリットも同じくらい知ることができました。
皆様にとって構築が正しい方向に進んでいるか定かでない場合、または良くない方向に進む兆候を避けたい場合は、このブログが最適です。私たちの経験から、自作がうまくいかなくなる典型的な3つのシナリオを用意しましたので、ぜひお読みください。
いくつかの組織では、計画がソフトウェアソリューション構築にまで進みます。組織のIT部門はツールの開発に意欲的かつ積極的で、組織の幹部も計画に夢中ですが…その後、沈滞します。
おそらく幹部の承認が遅れ、最終的には開発も遅れるかもしれません。または、ITの厳格なプロセスに従って実装に仕様を追加する必要が生じますが、あなたはそれを理解できないか、実装するにはチームと何度もやり取りする必要があります。または、特別な委員会がそれを引き継いで、組織の計画/開発サイクルにタスクを追加するかもしれませんが、委員会はそれをどうやって前に進めるかの検討に時間を費やし、ほとんど動きません。
どの事例でも、組織のメンバーは自分の任務を首尾よく済ませようとしていますが、ソリューションはほとんど進みません。たとえ構築がいつの日か始まるとしても、長い時間がたち、要件とリソースが完全に変化してしまっている可能性があります。
他の組織では、過剰な計画ではなく不完全な計画がソリューション構築の進行を妨げます。たとえば、マーケティング部門が販売データレポートを毎日シームレスに配信できるソフトウェアソリューションを要求し、熱心で俊敏なIT部門がそれを提供します。しかしマーケティング部門は販売数量とタイムスタンプを関連付ける必要に気付き、IT部門は改訂を行います。その後、マーケティング部門は、ユーザーデータを組み込めばわかりやすいと判断し、ITは3回目の改訂をします。結局、ソリューションはマーケティング部門の満足のいくものにならず、10回目の改訂までにはリソースが使い果たされ、責任感が強く柔軟だったIT部門は（おそらくいら立ちながら）プロジェクトから撤退することを余儀なくされます。
最後に、ソフトウェアソリューションがすでに運用中でうまく機能しているシナリオを見てみましょう！でも、それはエンジニアリング部門の常任専門家「ジミー」氏が構築したものです。このソリューションは、1台のローカルデスクトップコンピューターで運用されます。機能しますが、危なっかしいです。ジミー氏は情熱的で、素晴らしい展望を持っており、組織のニーズとも調和しています。まさに必要なものを提供してくれるソフトウェアソリューションがあることは確かに素晴らしいですが、1回の故障、1回のソフトウェア更新、またはジミー氏の1回の休暇で大きな障害が生じかねません。そして、組織全体がプロセスに関与できるようにマルチユーザーシステムを求めようとしても、ジミー氏のお一人様ソリューションは制限だらけです。
さて、上記のシナリオはあなたの現状に当てはまるかもしれませんし、そのうちの1つが迫っている恐れを感じるかもしれません。今こそ選択肢をしっかりと評価するときです。改善が必要ですか、それとも手を引く時ですか？「もうすぐ始まる」と聞き続けている場合は、すでにどれほどの時間が経過したか考えてください。実装を数か月または数四半期待っているだけならいいですが、何年も待っているならば（残念ながら、よくあることです）、もうあきらめて、あなたのソリューションを実現してくれる別の選択肢を考える時かもしれません。
ソリューションがすでに実装済みでも、脆弱である、または期待した成果が得られていないならば、ソリューションの維持に必要なプロセスを再確認してください。現時点での要件を明確に見定め、ソリューションの実現に向けた自分の役割に責任を持ちましょう。計画が不完全だと、IT部門との関係がぎくしゃくし、プロセスが遅くなるか、完全に停止するでしょう。また、変更が必要な場合、エンジニアがどれほど柔軟かつ迅速に対応してくれるかを把握してください。調整が発生すると、いつもあなたが関与できない「ブラックボックス」で行われますか？IT部門のプロジェクト推進者が会社から離職し、それとともに自社開発プラットフォームに関する制度上の知識も失われましたか？もしそうなら、オープンな話し合いの場を持つことを検討し、ソフトウェア購入の選択肢について話し合ってください。あなたとあなたの組織に完全な透明性をもたらし、細かなところにもアクセスできるソフトウェアです。
最後に、構築が破綻していることがわかった場合は、この機会にリセットボタンを押して、ソフトウェアソリューションを購入することを検討してください。賢い選択をしましょう。ソフトウェアソリューションの実装にあなたが積極的に関われるような、強力なサービス指向アーキテクチャのあるベンダーを探してください。あなたの会社の現状を理解し失敗したプロジェクトから学ぼうとするベンダーを見つけられれば、新しいソリューションはきっと改善され、メリットが得られるでしょう。またこうすればチームメンバーのメンツも保たれ、これまでのメンバーの努力が無駄ではなかったと自覚してもらえるでしょう。
Minitabは、お客様のソフトウェア実装において大きな成功を収めています。同時に、とても多くの組織の自作ソフトウェアの苦しみを見てきました。ですからエンタープライズレベルのソフトウェアソリューションを「作る」か「買う」かの決定に役立つ多くのアドバイスをご提供できます。これは単純な二者択一のようですが、この決定は問題の答えの発見、プロセスの改善、ビジネスの成功において大きな違いを生みます。ですから時間をかけてご自分の組織を知り、ニーズを知り、さまざまな選択肢を詳細に知るように努めてください。そうすれば、目標を達成する可能性がきわめて高くなります。