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

完全に内製というキーワードに釣られて買ってしまった。このペライ本に1700円とかいう値段つけるあたりややボられているような気がしないでもないが、それだけまだまだ世間的には本書に書いてあるようなことは主流ではない、という証左でもあるのかな、と穿った見方をしてしまうのである。内容は、薄く広く色々な企業のシステム開発の内製化への取り組みを取材・紹介したもの。個々の事例に深く踏み込んではいないので、もうちょっと詳しく知りたいところは端折られている。しかし、小さなところから大きな企業や事例を取り上げることで、多様性を確保しているところが本書の読むべき点であろう。

ところでシステム開発を内製する、というのの定義であるが、本書を読むところによるとその実態はかなり曖昧で幅広い。俺はプログラマ畑なので、内製というとユーザ企業が開発者を丸抱えしてIT関連の業務に従事させるイメージが強かったのだが、世間的にはどうやらそうでもないらしい。本書でも指摘されていることだが、日本では専門色の強い人材を期間で正規雇用*1する雇用慣行はまだあんまり無いので、やはりシステム開発者を専属で抱え続けるのはちとツライといったとこなんでしょう。とはいえ、規模がそこそこある企業であれば専属要員の予算をあて続けることもできるし、ITが企業の戦略上重要な位置づけにあるとの認識があればこれもまた一定量の予算の確保が開発者の通年確保にも繋がるわけで、要するにITとの付き合いかも企業それぞれで変えればいいじゃない、ということなんでしょう。

てなわけで、本書の内製の事例では、要件定義から実装から運用までゼンブ自分たちでやるところから、要件は自分たちで決めるけどその先の設計や実装は外部に依頼するというものや、都度に派遣やら準委任やらで開発者と契約を結んでユーザ企業の指揮下で開発を行う、というものまで色々です。しかし、これらの事例に共通していることが一つだけ存在する。それは、ITに関する決定は自分たちで下している、という点。要するに「丸投げ」してないってことですな。ITに関するアレコレを、外部の業者に頼めばよろしくやってくれるっしょという他所事ではなく、自分らのビジネスはこれこれこーいうものだから従ってソレの実現にはこれこれこーいうITが必要だ、という姿勢なわけです。

てなわけで、内製ってのは別に自社内に開発者を抱えるかどうかは一つの要因にすぎないわけですな。例えば、要件レベルで整合性が取れてれば良いのであれば、実際のシステム開発を開発者を内部に抱え込むか外部に抱えるかは、極論を言えばどっちでもよいわけで。いやいやウチのビジネスはソースコードレベルで担保しないと成り立たないんでということであれば、内部に開発者を抱え込んで外部に頼むとどーしても発生するコミュニケーションギャップを減らして開発のスピードアップ・一つのシステムに長期的に同一の開発者を当てることで開発の安定性向上を図るのも一手になる、と。

技術史的には、もうハードとソフトをベンダーに一括で頼まざるを得なかった時代は終了した、ということでもあるんでしょう。PCサーバはアキバなりネットで買ってきて、ソフトはテキトーなPCで開発というのは極当たり前であり、クラウドでハードすら持たないことも可能になってきた。これもまた、どこまで外部に頼るのか？　という問題であり、答えは企業それぞれで付き合い方を考えればよい、ということになるんでしょう。技術の進展で選択肢が増えるのは世の常でありますが、本書では「後発有利」という言葉を使ってますがホントその通りだと思います。

技術者のキャリア的にも考えさせられるものがある。例えば、従来、ある開発者を固定の客先に貼り付けるのは「塩漬け」として人を出す側のベンダーやSI側の視点では忌み嫌われている。これは技術者を多様なプロジェクトに参画させ、ずっと同じ現場に居ると技術者のスキルアップが個人の努力に頼らざるを得なくなるのを解消する意味合いがある。しかし、比較的枯れた技術で長期間システム保守に従事するニーズにはユーザ企業固有のビジネスを踏まえた上で動ける人材の方が何かと都合が良い。ことSIer文化圏にいる開発者のキャリアとしては、自社のビジネスを理解した上でコードを書く、という仕事のやり方はそんな悪いもんではないんじゃなかろうか。先進的な技術を使う機会は減るかもしれないが、そこはまぁ、自分らのビジネスを踏まえた上でコードを書くスキルとのバーターであろう。