2020/08/04 に開催された 【DX無料オンラインセミナー】内製化の勘所と落とし穴 のイベントレポートです。

●イベント概要
昨今のビジネス環境変化の激しさが増す中、情報システム/IT部門には、事業部門のニーズを正しく把握し、高品質な対応が求められるだけでなく、競争力を高める為、ビジネススピードに追随するべく迅速な開発や対応力が求められております。

このような背景からも社内システムやIT部門に対する期待もより高まっており、ユーザー企業が主体となってシステム構築の「内製化」を進める必要に迫られています。 　 しかしながら、いざ取り組むとなると通常の業務やタスクを抱えながら、どこから手を付けて、どのように内製化をリードしていけば良いか見えないといった課題を抱える企業も少なくありません。

そこで本セミナーでは、「内製化」を無理なく実現する為のノウハウを共有させていただきます。

■ソフトウェア内製化のコツとワナ

広木 大地さん [レクター / CTO協会]

●エンジニアリング組織論への招待
・ビジネス書大賞と技術書大賞を同時受賞
　　ビジネスとソフトウェアの関連は強い

●日本CTO協会
・CTO会という草の根活動からはじまった
・DX基準（DX Criteria）の策定、普及
・2つのDXは不可分
　　企業のデジタル化
　　デベロッパーエクスペリエンス
・目的
　　企業の超高速な事業仮説検証能力の獲得
・320の観点を自己診断
・GitHubで公開
・公開後の広まり
　　自己診断結果の公開
　　診断事業の登場
　　公共団体への情報提供

●内製化のメリット
・早い！安い！うまい！
　　コスト 1/3
　　スピード x3
・そうなっている事例はある
・影には失敗事例がたくさん

●なぜ「内製化」は効率が良くなるのか？
・変動費プレミアムがなくなる
・取引コストが減少する
・ソフトウェア開発のナレッジが蓄積する

●内製化にフリーランチは存在しない
・内製化で解決できる問題と解けない問題がある

●変動費プレミアムがなくなる
・変動費プレミアム
　　いつでも削減できる権利の料金
・IT予算では変動費
・ベンダーにとっては固定費（人件費）
　　リスクに対するプレミアムが乗る
・クラウドと同じ理由でシステム開発は外注化されていった
・ソフトウェアをバックオフィスだと捉えていると削減しやすいコストに見える

●取引コストが減少する
・外とやり取りするにはコストが上乗せされる
・取引コスト理論
　　相手を見つけるコスト
　　交渉のコスト
　　取引履行の監督コスト
・取引コストで組織の境界線が決まる
・自分たちが内部に取り込むより
　　外から調達するほうが安いなら外注
・取引が内部になるほどコストは下がる
　　ただし内部化コストは発生する

●ソフトウェア開発のナレッジが蓄積する
・ベンダー企業にITエンジニアの多くが所属している
・ユーザー企業にはノウハウが残りにくい
・つくりなおす、評価するノウハウが残らなかった

●ソフトウェア開発はコミュニケーション
・ソフトウェア開発のプロセス
　　複数人が認識を揃える
　　機会が理解できる、ぶれない明晰な文章
　　不確実な要求に耐えられる構成
　　複数人共同で継続的に管理
・コミュニケーションそのもの

●時間の値段は想像以上に高い
・工数と工期の関係
　　10%の時間を買うには、1.5倍のコスト
　　50%の時間を買うには、16倍のコスト
・少ない人数で長い時間掛けるとコストは少ない
・人数が増えるとべき乗で複雑になる
　　さらに時間を掛けるほど高くなる

●完了と同時にノウハウが喪失してしまう
・たくさんの人員が開発し、終わると少ない保守人数
・ドキュメント化したものは残る
・無形のノウハウは消失してしまう

内製化してもメリットが台無しになると失敗

●内製化のアンチパターン
・何もかも内製化しようとする
・発注者マインドのコミュニケーションのまま
・継続的な開発をせずストップ&ゴーを繰り返す

●何もかも内製化しようとする
・今からOSをつくろうとはしない
・自社のコアは自分たちでつくり、コモデティは買う
　　自然と判断できている
・同様にどこにメリットがあるかを判断することが必要

●メリハリのあるIT投資
・守りのIT投資
　　すでに誰かがつくっている
　　XaaS利用や外部ベンダーとの協調
　　社会課題としてすでに解決策があるなら買った方が安い
・攻めのIT投資
　　競争優位につながるもの
　　内製化か、ラボ的な開発

●ゼロイチではなくグラデーション
↑攻めのIT投資
｜　内製化チーム
｜　内部プロジェクト
｜　ラボ型開発
｜　外注型開発・共同開発
｜　XaaS/パッケージ利用
↓守りのIT投資
・アセスメントで判断

●コア・ノンコアアセスメントの例
・システムカテゴリ
・業務の独自性
・環境変化
・競合優位性
→全てありならコア

●簡易フローチャート
・独自性はある？
・環境変化は激しい？
・競合優位につながる？
→すべてNOなら廃止の判断にも

●受発注構造を組織内に持ち込むと発生すること
・発注者
　　わからないのでシステム部門の言う通り
　　品質が上がらないのでさみだれ依頼
　　仕様書を書ける人を増やす
　　改修に時間がかかるように
　　システム部門の悪い噂を流しはじめたり
・受注者
　　文句を言われないように、保守的な見積もり
　　機能的な要件ばかり重視
　　完璧な仕様を求める
　　犯人探しや責任回避
　　退職へ
→これらはシステムに現れる
　　システムが組織の鏡になっている

●説明・説得に費やされるコストの差
・自動テストを書いたら良いことあるんだっけ？
　　体感として理解している人にとっては
　　なぜ説明しなければならないのか
・なかなか新しいことを始められない文化へ

●ソフトウェアエンジニアリングの文化資本
・どちらに説明責任が求められるか
　　PCのスペック
　　採用競合に比べて悪くする理由
　　去年に比べて高くする理由
・上長が求める方向性に反映される
・何に対して合理性を求めるか
・まなざしの違いが、文化資本の形成に影響

コミュニケーション難易度の差が
内製化成否の鍵を握っている

●幹部の強いコミットのもとで育成としての内製文化
・継続的な開発のための文化資本を輸入するという考え方
　　小さな成功を大切にする
　　プロダクトの意思決定者を明確にする
　　かならず定期的な振り返りを実施
　　など
・短期の成功を求めるとできない
・文化の輸入、育成だと捉えれば間違えない

●新規開発ばかりに人をあてがう
・必要なスキルセットはちょっとずつ違う
　　発注者としてのプロジェクト管理
　　継続的なシステム開発
・継続して開発して行く場合
　　安定、詰まりがないことをモニタリング
　　ベルトコンベアに流れていく中で
　　ボトルネックを探していく
・ウォーターフォール的な
　　人数を増やして、減らしてのやり方では
　　ノウハウが蓄積しない

●サービスデプロイメントの数
・開発者が増えると、デプロイ頻度が上がるか
　　ハイパフォーマー、ミドル、ローで比較
・デプロイしやすい構造になっているか
　　自動テスト、自動デプロイなど

・DevOpsスコアが安定しているか
　　デプロイ数 / 開発者数 / 営業日数
　　150回 / 60人 / 20日 = 0.125
　　→割と安定している

・gilot（ジロー）
　　開発の安定性を測定

●内製化を失敗しないコツ
・どこを内製化すべきかを戦略的にアセスメント
・プロダクト開発の文化資本を輸入
・継続的に安定したデリバリーに投資
　　時間を買うのは高い
　　文化的な資本が減らない
　　見えない品質に投資ができる

●外部ベンダーとうまく付き合う
・全く不要なのではない
　　全外注、従来型を踏襲しても常に良いとは限らない

・どこを内製化すべきかを戦略的にアセスメント
　　ノンコアの請負開発
　　コア機能のラボ型開発・レベニューシェア
　　　　請負ではコストが高い、継続的な利益共有なら共存
　　　　準委任もあり

・プロダクト開発の文化資本を輸入
　　アジャイル教育、開発コーチング、チーム年間契約など
　　お手本を輸入する
　　OnJobトレーニング

・継続的に安定したデリバリーに投資
　　DevOps/SRE/データ基盤などの共同開発
　　自動テスト支援
　　　　マンパワーが必要
　　　　繰り返している企業にノウハウがある
　　効率的に開発できるようにしてから内製化

■感想

コア・ノンコアアセスメント
アセスメントから攻め守りの開発体制を判断する流れは分かりやすいですね！コモディティは買うのイメージはありましたが、判断基準が曖昧だったことに気づきました。業務の独自性、環境変化、競合優位性という観点があることで、基準がぐっと明確になりますね！

ITベンダーからお手本を輸入する
とても共感しました！ITを活用していけるように組織を変革していくためには、自組織内にノウハウを蓄積できていなければ推進していけません。はじめはお手本を輸入し、伴走から徐々に自走できるように流れをつくっていくのが現実的だと感じています。

登壇者の皆さん、運営の皆さん、ありがとうございました！