読者です 読者をやめる 読者になる 読者になる

うんこめも

自律分散うんこ製造システムについてのメモ

システム開発の切り札?内製化ってどーよ

「開発・改良の切り札 システム内製を極める (2011/7, 日経コンピュータ編)」というシステム内製化の成功事例集みたいな本を読んだ。

などなど、なかなか興味深い事例が多くて参考になる。

ただ、多少の苦労話もあるとはいえシステム部のトップや経営側による成功談ばかりで内製化の光の面しか見せていないように思える。内製化に失敗したところや、かつてうまく内製できな企業のその後などダークサイドを知りたい。特に、どの事例でもデリバリ(スピード)がよくなったという話がメインで品質やコストにはあまり触れられていない気がする。

いい感じの事例紹介に留まっているところが日経コンピュータっぽい。

開発・改良の切り札 システム内製を極める

開発・改良の切り札 システム内製を極める

ここらへんのシステム開発成功したぜ!みたいな本、特に日本のものは、ぼくの考えたさいきょうの開発手法みたいな汎用性なさそうなものや自社のソリューションの宣伝みたいなものが多い気がする。歴史が浅く変化が早い分、体系的・汎用的なものをつくるのは難しいだろうけれど、せめて本を書く前にソフトウェア工学の知見を調べたほうがいいと思う。


じゃ、内製化ってどーよ?

まず、システム内製とはなにか。ビジネスで用いるITシステムを外部のSIerやベンダーに丸投げするのではなく、自社か子会社で主導権をもって構築・運用すること。なのでベンダーをまったく使わないことではない。

ベンダー丸投げの問題点

情報システム部門がない組織がシステムを導入する場合、企画から実装、運用までベンダーにまかせるのが一般的だけれど、これには欠点がある。

  • ユーザ(顧客)の要望をすぐに理解できない
  • 暗黙知形式知に落とし込めない
  • イニシアチブを握れない

そのため次のような問題がでてくる

  • 要望が出てからリリースまで時間とコストがかかる
  • 仕様を調整できず、要件が肥大化するかつ、本当に必要なものをつくれない。

よく引き合いに出される「顧客が本当に必要だったもの」を引用する。*2

f:id:daaaaaai:20140111143736g:plain
顧客が本当に必要だったものとは (コキャクガホントウニヒツヨウダッタモノとは) [単語記事] - ニコニコ大百科
*3


ユーザ主導でのメリット

ユーザ主導とすることで、これらの欠点が打ち消される。

  • 自分たちが必要なものを構築できる
  • 自分たちでつくれば調整に時間がかからなく機動性がある


もちろんこれには前提がある。

  • システム部門のメンバが業務にも詳しく、技術にもある程度明るいこと。


これはそのままデメリットにもなる。

  • 高技能な人間を育成・確保し続ける必要がある
  • 技術的なノウハウを確保する必要がある


ただ、これは開発会社のエンジニアを準委任契約で入れることで解決可能ではある。
また、上記の本ではウルシステムズなどユーザ側の技術コンサルを雇う例が散見された。

また、ベンダーに委託していた場合はリスクも転嫁できるが内製するとリスクをすべて自分たちでもつことになることも注意。


車輪の再発明をする必要はない

また、ベンダーに丸投げすればユーザの要望をすぐに理解できないという欠点については、システム化の対象により程度が異なる。

システム化の対象にしても自社独自の部分と多くの企業で共通なものがある。
自社独自のものは競争力の源泉である場合が多く、ここを内製化すべき。そして人事系など共通なものは既存のパッケージを使いそれをカスタマイズするなり、それに業務を合わせるなどするのが定石とされる。

当然、自社独自な部分とそうでない部分は綺麗には分けられないがその境目は企業ごとに異なっている。
# ここは暗黙知っぽそう。分類するパターンとかノウハウ知りたい。

ユーザ主導開発をするために

つまり、ユーザ主導開発ではリスクはあっても機動性があるし必要なものとつくれるというメリットがあって競争力の源泉になります。じゃあどうすればそれを進められるのか。


ハードウェアも安くなっているしミドルウェアやOSもOSSのいいのがある。生産性の高い言語もフレームワークもあるし知見やノウハウも集積されている。昔よりははるかに敷居は低くなっている。
そして、そんな簡単ではないと思うのだけれど業務を理解している人が開発手法、プログラミングを勉強した方が効率がいいという成功談もある。

必要な条件としていろんなものが挙げられている。アジャイル・優秀なエンジニア・便利で素敵な開発ツール。などなど・・・

けれど、どれも手段でしかない。上記の本で取り上げられていた成功事例に暗黙的に共通しているのは、トップの理解とリーダーの実行力、そしてリスクを許容できる組織の体力ということ。身も蓋もない・・・。


プロジェクトを成功させるには開発力のある組織が必要で開発力を強化するにはプロジェクトの(成功)経験が必要だと思う。つまり鶏と卵の関係。最初はリスクをとってやっていくしかないしそれを続けるにはトップの理解とリーダーの実行力、そしてそのリスクを許容できる組織の体力が必要なんだろう。


なんだか煮え切らない結論になったけれど問題の立て方が広すぎたかも。
内製化は機動性をもたらすけれど銀の銃弾ではなくリスクもあるので覚悟してすすめていったら良いと思います。

*1:じゅうだん会すごい。 http://coin.nikkeibp.co.jp/coin/itpro-s/seminar/si2011summer/pdf/si2011summerprg_01.pdf

*2:出典は不明らしい・・・

*3:まったく余談なのだけれど、ニコニコ大百科はたまにとても良い記事があるし便利。一方でインターネッツで流行っている言葉の元ネタを調べてpixiv辞典がヒットするとたいてい中身が空っぽで使えない。