内製化のコツとワナ

Transcript

1. © rector,inc
   ソフトウェア内製化のコツとワナ
   株式会社レクター 広木 大地 @hiroki_daichi
   

   View Slide

2. 自己紹介
   「内製化」は何故、効率がいいか。
   「内製化」の効率の良さを台無しするワナ
   「内製化」を失敗しないコツ
   「内製化」時代のベンダーとの付き合い方
   

   View Slide

3. © rector,inc
   自己紹介
   2008年度に新卒第1期としてミクシィに入社。
   メディア統括部部長、開発部部長、サービス本部長執行役
   員。組織改革の戦略・実行を行う。2015年同社を退社。
   2016年「CTOのノウハウを広く世の中に還元する」ことを
   目指し、レクターを創業。
   2018年2月エンジニアリング組織論への招待上梓。
   第6回ブクログ大賞ビジネス書部門大賞受賞。
   ITエンジニアに読んでもらいたい技術書2019大賞。
   日本CTO協会理事。DX推進法人会員募集中。
   広木 大地(ひろき だいち)
   

   View Slide

4. ビジネス書大賞と技術書大賞の２つを
   受賞した初めての書籍
   

   View Slide

5. 本日のテーマは「内製化」
   

   View Slide

6. © rector,inc
   内製化のメリット
   内製化の成功事例として、観測できる範囲では1/3のコストにな
   り、3倍のスピードになることは現実であるし、なにか特殊な事
   例ではない。また、ソフトウェア品質が向上すること多い。
   つまり、経営的には「安い」「早い」「うまい」を実現しているよう
   に見える。
   しかし、このような成功事例と裏腹に影には失敗事例も多く存
   在する。
   この両者を分けるものは何なのだろうか。
   1/3のコスト、3倍のスピードは可能
   

   View Slide

7. でも、何故「内製化」は
   効率が良くなるのか説明できますか？
   

   View Slide

8. © rector,inc
   1
   ２
   ３
   内製化が効率良くなる代表的な理由
   変動費プレミアムがなくなるから。
   取引コストが減少するから。
   ソフトウェア開発のナレッジが蓄積するから。
   

   View Slide

9. フリーランチは存在しない。
   

   View Slide

10. © rector,inc
    ① 変動費プレミアム - いつでも削減できる権利の料金
    外部ベンダー・SES等に発注する費用は、人件費などに比べ
    て、不況時に削減しやすい。
    ソフトウェア開発が競争力の原資ではないバックオフィス機能
    だと考えている企業にとっては、こういった管理コストは削減し
    やすい変動費にしておきたいと考える。
    そのため、平時は「多少割高でも」外部に発注しておくほうが効
    率が良いと考える。
    クラウドサービスを導入するときの理屈と同じ理屈で、システム
    開発は外注化されていった。
    売上が低いときに
    削減するという選択権の料金
    売上
    変動費(IT予算等)
    固定費(人件費等）
    

    View Slide

11. © rector,inc
    ② 取引コスト - 外とやり取りするコストの料金が上乗せ
    取引コスト理論
    　取引コスト理論は、アメリカの経済学者であるロナ
    ルドコース(1910-2013)によって、提唱された経済学
    の理論です。

    取引相手を見つけるために支払うコスト 

    探索のコスト

    取引相手と交渉を行うために発生するコスト 

    交渉コスト

    取引相手が契約した取引を履行するように監督と矯
    正を行うコスト

    監督コスト

    

    View Slide

12. © rector,inc
    取引コストによって、会社・組織の境界線が決まる
    ある経営上のリソースを市場から手に入れるのか(取引コスト)、
    それとも企業内部に構築するのか(内部化コスト)を取引コスト理
    論の観点で見てみると、会社組織の境界線を決めるラインが見
    えてきます。

    

    　内部化コストが高く、取引コストが安いものについては、企業
    外部から調達し、取引コストが高く、内部化コストが低いもの
    は、企業内部に構築することが望ましいということがわかりま
    す。

    

    　この構図は、エンジニアリング機能を必要とする組織にとって
    は、「何を外注し、何を内製するのか」を決定づける構図である
    と理解することができます。

    　

    内部化コスト > 取引コスト
    取引コスト > 内部化コスト
    市場取引
    長期取引
    戦略連携
    組織取引
    企
    業
    外
    部
    企
    業
    内
    部
    

    View Slide

13. © rector,inc
    ③ ソフトウェア開発のノウハウの行方がどうなるか
    

    View Slide

14. © rector,inc
    ソフトウェア開発はコミュニケーションそのもの
    プログラミングは理科系的な数理的なという側面を受け取られ
    がちだが、実際には
    ● 複数人の認識を揃えながら
    ● 機械が理解できるほどブレのない明晰な文章を
    ● 将来の不確実な要求に耐えられるように構成し、
    ● 共同で継続的に管理する
    というプロセス。人文的な側面で言えば、立法行為に近いもの
    だと考えると理解しやすい。コミュニケーションが大事どころか、
    「コミュニケーションそのもの」
    機械が理解できるほど明晰な言語化
    

    View Slide

15. © rector,inc
    「時間の値段」は想像以上に高い。
    ソフトウェアのよく知られた関係性
    として、工数と工期の関係がある。
    10%時間を買うためには、1.5倍のコ
    ストがかかり、50%の時間を買うた
    めには16倍のコストがかかる。
    ソフトウェア以外のプロジェクトの
    感覚と大きく違い、直感に反するた
    めしばしばまちがった意思決定を促
    してしまう。
    

    View Slide

16. © rector,inc
    Putnam SLIM Modelについての解説
    工期
    工
    数
    チーム生産性の幅
    パトナム・モデル
    パトナムモデルは、経験的なソフトウェア工数
    /工期推定のためのモデル。
    1978年に発表
    されたLawrence H. Putnamによる最初の論文は、ソフトウェアプロセスモデリングの分野
    における先駆的な研究と見なされている。
    経験的モデルは、ソフトウェアプロジェクトデータ（たとえば、工数・工期とコードサイズ）を収
    集し、データを数理モデルに適用することで推定。
    それらに得られた知見としては、工期を短くするためには予想されるよりも多くの工数が必
    要になり、どこかで不可能ななゾーンに突入する。
    これは、「妊婦が10名いてもこどもを1ヶ月で産めない」という有名メタファーの証拠でもあ
    る。
    不
    可
    能
    ゾ
    ー
    ン
    https://en.wikipedia.org/wiki/Putnam_model
    

    View Slide

17. © rector,inc
    「完了」と同時にノウハウが喪失してしまう開発スタイル
    変動費プレミアムを最大化したいユーザー企業と、異なる案件
    に優秀なプレーヤーを投入して売上を伸ばしたいITベンダー企
    業の短期的な利害の一致により、多くのシステム開発では急速
    に人員を縮小させてしまう。
    この瞬間に、新規開発で培われたシステムやドメインの知識は
    どこかに消失する。次の機能開発を行いたいタイミングでは、技
    術的負債化していく可能性が高くなる。
    「開発の完了」という幻想、
    「作ったらあとは減価償却」という幻想がシステム開発を割高に
    する。
    保守になる瞬間にノウハウが消滅
    開発完了と共に
    ノウハウの喪失
    

    View Slide

18. つまり、「内製化」しても
    そのメリットが台無しになると
    失敗してしまう。
    

    View Slide

19. © rector,inc
    1
    ２
    ３
    内製化のアンチパターン
    何もかも内製化しようとしてしまう。
    発注者マインドのコミュニケーションのまま進める。
    継続的開発をせず、ストップ&ゴーを繰り返す
    

    View Slide

20. アンチパターン①：
    何もかも内製化しようとする。
    

    View Slide

21. © rector,inc
    何もかも内製しようとする。
    どんなに内製化がすばらしいメリットを持っていたとしても、今か
    らlinuxに相当するようなOS開発をした上でWebサービスを提供
    するようなことはしない。
    これは自社のコアになる部分については内製化し、コモディティ
    となっている部分については、内製化しないという判断を行って
    いるから。
    この判断を自社としてすべてのシステム領域に対して行えてい
    るだろうか。これは、PaaSやSaaSに当たる領域でもそうだ。何
    を内製化したらメリットが大きいかを見極める必要がある。
    今から、OSを作ろうとはしない。
    SaaS
    PaaS/IaaS
    OS
    

    View Slide

22. © rector,inc
    メリハリのあるIT投資
    社会課題としてすでに解決策があるもの
    XaaS利用および外部ベンダーとの協調
    守りのIT投資
    コモディティ領域
    コスト削減や管理を目的としたもの
    自社事業の競争優位につながるもの
    内製化またはラボ型開発の推進
    攻めのIT投資
    競争領域
    売上や利益の増大を生み出すもの
    

    View Slide

23. © rector,inc
    攻めと守りのアセスメントを行い、メリハリをつける。
    自社の強みとして、 

    改善する価値がある 

    他社/社会と同じ課題を
    解決するもの

    攻めのIT投資
    競争領域
    守りのIT投資
    コモディティ
    内製化チーム
    内部プロジェクト
    ラボ型開発
    外注型開発・共同開発
    XaaS/パッケージ利用
    特定のKPIや事業目標に向かって、内部チー
    ムで継続的に開発をすすめるスタイル。事業
    理解とシステムノウハウが蓄積する。
    内製エンジニアや一部フリーランサーなどと
    協力しながら、一時的なプロジェクトとして
    システム開発を行う。
    テックリードとプロダクトデザイナーを外部
    の協力を仰ぎながら、開発と同時にノウハウ
    も伝承できるようにした開発スタイル。
    XaaSと業務のつなぎ込み部分を交換しやすい
    形で外注したり、業界コンソーシアムで共通
    化して、開発を行って効率化を図る。
    最新の動向をチェックした上でうまく選定し
    ていく。メンテナンスや追加開発をしつづけ
    る費用よりも専門SaaS事業者のほうがリーズ
    ナブルなことが多い。
    

    View Slide

24. © rector,inc
    コア・ノンコアアセスメント例
    

    View Slide

25. © rector,inc
    ノンコアシステム
    アセスメント簡易フローチャート
    業務に独自性はある？
    環境変化は激しい？
    競合優位につながる？
    YES YES YES
    NO
    コアシステム
    内製・準内製化していく
    削除・廃止
    ノンコアシステム
    環境変化は激しい？ 競合優位につながる？
    NO NO NO
    競合優位につながる？
    NO NO
    YES
    YES
    YES
    

    View Slide

26. アンチパターン②：
    発注者マインドのまま
    システム開発を進める。
    

    View Slide

27. © rector,inc
    受発注構造を組織内に持ち込むと発生すること
    要求
    納品
    実装
    ⑴ 発注者に文句を言われないように、保守的に納
    期を見積もる。
    ⑵ 発注者に文句を言われないように機能的要件ば
    かり重視する。
    ⑶ 発注者に完璧な仕様書を求める。
    仕事がどんどんつまらなくなる
    ⑷ 犯人探しや徒党を組む、責任回避
    ⑸ 退職する。
    ⑴ システムのことはわからないのでシステム部門の
    言う通りにする。
    ⑵ 完成品の品質が上がらないのでさみだれ的な依
    頼が増える
    ⑶ システムから完璧な仕様書を求められるのでそれ
    を作れる人を探す
    ⑷ 改修にやたらと時間がかかるようになる。
    ⑸ システム部門の能力が低いなどと他社に言いふら
    す。
    すべての不合理の集積地が
    最下流であるシステムの「負債」となって現
    れる。
    ＝　システムは組織の鏡
    発注者 受注者 システム
    

    View Slide

28. © rector,inc
    ソフトウェアエンジニアリングの文化資本
    様々な「当たり前」を獲得するまでに、説明・説得に費やされるコストの差
    当たり前にテストを書く会社 いちいち説明コストがかかる会社
    CI
    ＞
    

    View Slide

29. © rector,inc
    ソフトウェアエンジニアリングの文化資本
    どちらに説明責任が求められるか
    しな
    い理
    由
    は
    ？
    する
    理
    由
    は
    ？
    たとえば、PCのスペックであれば
    ・「採用競合に比べて、悪くする理由」の説明を求めるか
    ・「去年に比べて、高くする理由」の説明を求めるか
    によって無意識な選好の違いが、上長が求める説明責任の方
    針に反映させてしまう。しばしば、合理的に説明を求めることに
    何の認知の歪みがないと錯覚している人がいるが、何に対し合
    理性を求めるかに権力構造が内包されている。
    このようなまなざし(gaze)の違いが、文化資本の形成を促進し
    たり、妨げたりする。
    

    View Slide

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

    View Slide

31. © rector,inc
    幹部の強いコミットのもと、育成としての内製文化の導入
    内製化の成功事例では、多くの場合それを進めたい幹部の強
    いコミットが鍵になる。これは、単なる一部業務の内製化だけで
    はなくて、組織文化の輸入を伴う事が多いからだ。
    そのために、できるかぎり限られた場所での成功体験を積み上
    げていくと組織的なハレーションを少なく導入することができる。
    これは早い段階では「教育育成」の一環として費用を捉えたほ
    うがいいかもしれないということを意味している。
    内製開発は文化資本の輸入・教育
    ● 小さく成功体験を積みやすいプロジェクトにフォーカスす
    る。
    ● プロダクトの意思決定者を明確にする。
    ● 周囲の批判者にも敬意を持つ。
    ● 意思決定者をプロダクトオーナーにし、優先順位付けを行
    う。
    ● 開発者、デザイナー、品質エンジニア、プロダクトオー
    ナーを含んだチームを創る。
    ● 外部パートナーと準委任のスタイルで契約し、チームビル
    ディングを含む会議等にも参加してもらう。
    ● スクラム・カンバンなどの確立されたプロセスを意思決定
    者を含むチーム全体で理解し、共有する。
    ● 相互理解・チームミッションの理解を重視する。
    ● かならず定期的な振り返りを実施する。
    

    View Slide

32. アンチパターン③：
    新規開発にばかり人をあてがう。
    

    View Slide

33. © rector,inc
    スループットをマネジメントしていく能力
    内製の自社事業サービスを継続的に開発する場合におけるプロ
    ジェクト管理は、発注受注を繰り返すタイプのマネジメントとは異な
    るスキルセットが必要になる。
    たとえば、要望が生まれてから実装されるまでのサイクルタイムや、
    リソースがすべて使われているかよりも、フロー効率性が良いかな
    ど、異なる基準でモニタリングする。
    業務システム型のマネジメントでは、この種のリードタイムのモニタ
    リングを行うことは少ない。むしろ、発注側としての契約リスクやコス
    トコントロール、要件定義ずれの補正などの業務が多い。実務的に
    は異なる経験とスキルセットになる。
    発注者PM能力からの転換
    サイクルタイムの計測
    フロー効率性の計測
    

    View Slide

34. © rector,inc
    たとえば、サービスデプロイメントの数
    コード修正の心理的安全性
    開発者数が増えるごとに、生産性の高い組織群はデプロイ頻
    度が増加する。
    それに対して、低いパフォーマンスの組織は、開発者数が増え
    るごとにデプロイ数が低下していく。
    そして、開発者数もスケールしなくなる。
    そのため、マイクロサービスのようにシステムを疎結合に分解し
    て、デプロイしやすい構造にしたり、自動テストの効率を上げて
    いく。また、組織文化もミスに対して他罰的・権威的にならず、修
    正しやすい環境を用意している。
    ※ Lean と DevOpsの科学(p.78)
    

    View Slide

35. © rector,inc
    たとえば、サービスデプロイメントの数
    おおよその目安としてのスコア
    たとえば、60人のエンジニアがいて、1ヶ月（20営業日）あたり
    150回のデプロイ回数の会社を考えてみる。
    150 / 60 / 20 = 0.125 > 0.1
    と計算できる。およそ、一人のエンジニアが１０営業日でつくった
    差分が、一度デプロイされる計算になる。
    結合度の高いサービスやトランクベース開発のできていないシ
    ステムだとすぐにこのスコアが悪化する。
    DevOpsスコア
    デプロイ数 (Deploys）
    開発者数 (Developers)
    営業日数 (Days)
    =
    > 0.1
    

    View Slide

36. © rector,inc
    開発の安定性測定するツール：gilotの紹介
    

    View Slide

37. © rector,inc
    補足：ジニ係数について
    格差を数値化する指標：
    すべての富のうち
    ６人が５９％をもっていて
    みんなアメリカ合衆国の人です
    ７４人が３９％を
    ２０人が、たったの２％を分けあっています
    「世界がもし１００人の村だったら」より引用
    

    View Slide

38. © rector,inc
    1
    ２
    ３
    内製化を失敗しないコツ
    どこを内製化すべきか戦略的にアセスメントする。
    プロダクト開発の文化資本を輸入する。
    継続的に安定したデリバリーに投資する。
    

    View Slide

39. このような「内製化」時代に
    どのようにベンダーに向き合うか。
    

    View Slide

40. © rector,inc
    外部ベンダーとうまく付き合う。
    内製化を成功させるポイントに資するような外部企業との付き合い方がある。
    ノンコアの請負開発・カスタマイズ
    コア機能のラボ型開発・リベニューシェア
    アジャイル教育、開発コーチング、
    チーム年間契約など
    DevOps/SRE/データ基盤などの共同開発
    自動テスト支援
    どこを内製化すべきか戦略的にアセスメントする。
    プロダクト開発の文化資本を輸入する。
    継続的に安定したデリバリーに投資する。
    1
    ２
    ３
    

    View Slide

41. © rector,inc
    ご静聴ありがとうございました
    広木 大地 @hiroki_daichi
    

    View Slide