システム内製化度テスト
おっと、やっと日本でも情報システム内製化への動きが強まってきたようだ。
不況による予算削減の影響か？
いやいや、本気で内製化による予算削減を信じているなら、とんだ甘ちゃんだぜ。
そもそも、システムの外製化が流行ったのは、システム開発のための人材（オタク）を社内で確保することが負担になり、ベンダーに丸投げしていたんじゃなかったっけ？
さすがに、ベンダーの「ぼったくり」や「対応の遅さ」や「業務の不理解」に気づいたのかな？
そもそも、「SIerと呼ばれる企業がこれだけ多く存在しているのは、日本だけ」なのである。
他国では、「内製化または、パッケージソフトの使用がスタンダード」なのである。
確かに、内製化によって得られるメリットもあるけれど、そこには、大きな落とし穴がある。
例えば、システム開発を家作りに例えると、内製化とは、建築家や大工さんにたのまずに素人連中が自分達の住処を作るようなものだ。自分好みの住まいができるかも知れないけれど、きっと、欠陥住宅ができるだろう。
そこで、その落とし穴を確認するために簡単なテストを作ってみた。
いいかげんなテストなので、この結果を妄信するのは、危険だけど、内製化の方針付けぐらいにはなると思う。
５分ぐらいあれば、できるテストだ。
国際線の飛行機に置いてあるビジネス雑誌を読んで、貴重な睡眠時間を削り重要な経営判断を決めるよりは、きっと有意義な時間となるだろう。
◇システム内製化度テスト
貴方の企業の内製化度を測定します。以下の質問にYes, Noで答えてください。
１．情報システムの修正頻度は月に数回以上ありますか？ ２．情報システムは、ECサイトのように外部に公開していますか？ ３．システム障害が発生した場合の対応時間は、２時間以内が望ましいですか？ ４．競合企業との差別化のために、システム構築を行う必要性がありますか？ ５．業務改善による生産性向上に興味がありますか？ ６．貴社に専任の情報システム部員が少なくとも１名以上おりますか？ ７．貴社の業務を全て把握している人材がおりますか？ ８．オープンソースは好きですか？ ９．現在、お付き合いしているベンダーがいますか？ いるとしたら満足していますか？ （この質問はNoなら１点） １０．過去に外注したシステムの成功率は５割以下ですか？ １１．システム構築の失敗リスクを負う勇気がありますか？ １２．貴社の情報システム部門にハッカーがいますか？ もしくは、パートナー企業にハッカーがいますか？ （この質問がYesなら５点!!）
一つの質問につき、Yesの場合、１点で数える（８と１０は例外）。
満点を取る企業は、日本には殆ど存在しないだろう。
８点以上なら、文句なく内製化に向いている企業と言えるだろう。
５点以上なら、内製化に向いている企業だが、外部の協力が必要であろう。
５点未満の企業は、よい外注先を見つけて、丸投げし、あとは神に祈るだけだ。
１．情報システムの修正頻度は月に数回以上ありますか？
もし、システムを外注していると、システムの修正が発生する度に、外注先に依頼する必要がある。もちろん無償では、対応してくれないし、修正内容の打ち合わせ等で時間もかかることを覚悟する必要がある。もし予算に余裕があるのであれば、外注先と保守契約を結び定期的に修正を依頼できる体制を作ることもできるが、費用対効果の面で現実的ではないであろう。その点、内製化していれば、社内の人材で修正できるので、コストと時間の面で有利である。修正内容の齟齬も発生しにくいであろう。
２．情報システムは、ECサイトのように外部に公開していますか？
ECサイトのように外部公開のサービスを運用しているなら、是非、内製化すべきだ。外部公開サービスは、定期的にメンテナンスし、サービスを成長させる必要がある。また、内製化すれば、必然的にサーバも自己管理となり、サービスの利用頻度やユーザの使用感が直接把握できさらなるサービス向上に繋がるであろう。但し、外部公開のサービスにセキュリティホールがあると信用問題になりかねないので、セキュリティ対策等の技術面が不足している場合は、特定の分野に絞り、外部企業に支援を願った方がよい。
３．システム障害が発生した場合の対応時間は、２時間以内が望ましいですか？
システムによっては、１日程度止まっていても、業務に支障がない場合もある。しかし、業務が止まってしまうようなシステムを構築するのであれば、内製化がよい。内製化することにより、システムのブラックボックス部分が無くなり、原因の特定や影響度がすぐに認識できるようになる。但し、２４時間サービスの場合、運用が大変になるので、システムの監視だけ、外注するのも手である。
４．競合企業との差別化のために、システム構築を行う必要性がありますか？
競合企業との差別化のためには、自社の業務の優位性を知り尽くしている必要がある。外注した場合、自社の業務を正確に伝えることが難しい、ベンダーはあくまでシステム開発会社なので自社の業態や実際の業務について、生の知識と経験が無いためである。やはり、本気で差別化を望むのであれば、内製化すべきだ。但し、その差別化が本当に有効なのか、よく検討する必要がある。必要であれば、アナリストを雇うのも手だ。
５．業務改善による生産性向上に興味がありますか？
日本企業は、サービス残業が当たり前であり、低い生産性を労働時間でカバーする傾向にある。ブラック企業ってやつですな。また、従業員も社畜と揶揄されているように、生産性の向上よりも、長時間労働して残業代を稼ごうとする傾向がある。そんな志が低い輩は、外注していればよいだろう。しかし、日々、無駄を省き業務改善を行い生産性を向上させようと思うのであれば、それに伴い情報システムも改善する必要がある。それには、やはり内製化が有効だ。
６．貴社に専任の情報システム部員が少なくとも１名以上おりますか？
内製化する場合、情報システム部門が行うことになるが、少なくとも専任スタッフがいないとつらい。システムが完成した後、運用と日々の修正も行わないと内製化した意味が薄れるので、是非とも専任スタッフを置くべきだ。但し、専任スタッフにITリテラシーがない場合、使えないシステムが作られる可能性があるので、選出に注意が必要。ベンダー出身の人間をヘッドハンティングするのがよいかも。
７．貴社の業務を全て把握している人材がおりますか？
情報システムを構築するには、貴社の業務の全てを理解している人間が必要である。情報の入力と出力でデータの整合性（辻褄）があっていないといけないからである。業務の部分部分を理解している人間が集まって、打ち合わせを行い仕様を作るのでも構わないが、設計作業になれが必要である。業務の流れを理解している人間がいないのであれば、コンサルタントを雇い業務の整理をお願いするのも手だ。
８．オープンソースは好きですか？
オープンソースとは、ソフトウェアのソースコード（設計図）が公開されているソフトウェアのことを指す。オープンソースは、基本的に無償で手に入るが、原則、保障が無い。何か問題が発生した場合は、自力で解決するというのが、オープンソースの精神だ。しかし、有名なオープンソースの場合、「コミュニティー」・「ドキュメント」・「事例」が豊富なため、下手な有償ソフトよりもトラブルが発生した場合の対処が楽な場合もある。また、有償となるが、オープンソースの保障やサポートを行う企業もあるので安心だ。内製化する場合、オープンソースを検討することを薦める。「無償」というのも大きな魅力だが、オープンソースの精神である自由でオープンな風土が、内製化と相性が良い。オープンソースは、沢山の人達に開発され、使用されているため、もしセキュリティホール等の問題が見つかった場合でも一企業が開発している有償ソフトに比べて、対応が早い。また、有償ソフトは、その性格上、システムを囲い込む形になりやすい。つまり、その企業の製品郡でシステムを構築した方が、安定しやすい形となりやすい。
Windowsを代表とするMicrosoft社製品を例に挙げると
「OS：Windows、DB：SQL Server、Webサーバ：IIS、開発ツール：Visual Studio、オフィスツール：Office」 等だ。
もちろん、他社の有償ソフトや有償ソフトとオープンソースの組み合わせで構築することも可能だが、有償ソフトの開発時の試験を考えるとどうしても、自社製品の組み合わせ試験にベンダーも比重をおくのは、容易に想像できる。その点、オープンソースは、オープンな精神の元、自由に組み合わせることが前提としたソフトが多い。無償で手に入るため、トライ＆エラーもやりやすい。非常にお勧めだ。ちなみに私は、オープンソースが好きだ。いや、愛してる。
けど、Microsoft社製品も大好きだ。。
９．現在、お付き合いしているベンダーがいますか？いるとしたら満足していますか？（この質問はNoなら１点）
もし、優秀なベンダーとお付き合いしているのなら、そのベンダーと運命を供にするのも悪くないかも知れない。しかし、世の中には、いろいろなベンダーがいるし、そもそもそのベンダーが最高のパートナーかどうかわからない。自分のことは、自分が一番知っているのではだろうか。
１０．過去に外注したシステムの成功率は５割以下ですか？
システム開発の成功を「予算」、「品質」、「納期」の３つが全て満たしていると定義すると、ほとんどの開発が失敗していることになるだろう。ここでは、「品質」と残りのどちらか一方を満たしたものを成功と定義し、その成功率が５割以下だとすると貴社のシステム開発のあり方にも問題がある場合が多い。失敗原因として、多いのが上流工程（業務分析・システム設計）での失敗である。上流工程では、ベンダーと綿密に打ち合わせを行い作業を進める必要があるが、そこで齟齬が発生し、問題となることがよくある。貴社とベンダーとでは、生業としている業態が違うため、些細な言葉等で、すれ違うことがままある。貴社が、ベンダーの外注管理をしっかりできる自身があるのであれば、今後ともベンダーを使い外注でシステムを構築すればよいだろう。失敗が多いのであれば、一度、自分達で作りあげるのを試してみてはどうだろうか？ベンダーには、その際に技術的に支援してもらえばよいのではないだろうか。
１１．システム構築の失敗リスクを負う勇気がありますか？
システム構築を外注し、ベンダーと請負契約する場合、構築の失敗リスクは、ベンダー側が持つこととなる。（その分、リスク代をぼったくられることとなるのだが。失敗原因で争い、裁判になることもあるけれど。）システムを小さく生み、大きく育てることで、失敗リスクを軽減することが可能である。外注した場合、初期のリスクは減らせるが、運用コストやシステム修正のコストとリスクを取り続ける必要がでてくる。
１２．貴社の情報システム部門にハッカーがいますか？もしくは、パートナー企業にハッカーがいますか？（この質問がYesなら５点!!）
良くある間違いで、ハッカーとクラッカーを混同し、ハッカーが不正行為を行う悪い人と思っている人がいるが、そういう人は、このドキュメント（「管理職のためのハッカー FAQ」）を読んで、悔い改めて欲しい。内製化する際にハッカーがいると非常にこころ強い。ハッカーという名称ではなくて、「プログラマー」、「アーキテクト」と呼ばれている場合もある。恐らく自社にはいないだろうから、パートナー企業にそんな人がいたら、是非、派遣契約を結ぶことをお勧めする。ハッカーにシステムの土台を構築してもらい、模範となるシステムを作ってもらい、他の人達がそれを模倣すればよいシステムが作れるであろう。
参考：
・ジョエルテスト
http://japanese.joelonsoftware.com/Articles/TheJoelTest.html
・「管理職のためのハッカー FAQ」
http://www.yamdas.org/column/technique/hackerj.html
