Upgrade to Pro — share decks privately, control downloads, hide ads and more …

内製化のコツとワナ

hirokidaichi
February 26, 2021
1.7k

 内製化のコツとワナ

hirokidaichi

February 26, 2021
Tweet

Transcript

  1. © rector,inc ① 変動費プレミアム - いつでも削減できる権利の料金 外部ベンダー・SES等に発注する費用は、人件費などに比べ て、不況時に削減しやすい。 ソフトウェア開発が競争力の原資ではないバックオフィス機能 だと考えている企業にとっては、こういった管理コストは削減し

    やすい変動費にしておきたいと考える。 そのため、平時は「多少割高でも」外部に発注しておくほうが効 率が良いと考える。 クラウドサービスを導入するときの理屈と同じ理屈で、システム 開発は外注化されていった。 売上が低いときに 削減するという選択権の料金 売上 変動費(IT予算等) 固定費(人件費等)
  2. © rector,inc ② 取引コスト - 外とやり取りするコストの料金が上乗せ 取引コスト理論  取引コスト理論は、アメリカの経済学者であるロナ ルドコース(1910-2013)によって、提唱された経済学 の理論です。


    取引相手を見つけるために支払うコスト 
 探索のコスト
 取引相手と交渉を行うために発生するコスト 
 交渉コスト
 取引相手が契約した取引を履行するように監督と矯 正を行うコスト
 監督コスト

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

    は、企業内部に構築することが望ましいということがわかりま す。
 
  この構図は、エンジニアリング機能を必要とする組織にとって は、「何を外注し、何を内製するのか」を決定づける構図である と理解することができます。
  
 内部化コスト > 取引コスト 取引コスト > 内部化コスト 市場取引 長期取引 戦略連携 組織取引 企 業 外 部 企 業 内 部
  4. © rector,inc ソフトウェア開発はコミュニケーションそのもの プログラミングは理科系的な数理的なという側面を受け取られ がちだが、実際には • 複数人の認識を揃えながら • 機械が理解できるほどブレのない明晰な文章を •

    将来の不確実な要求に耐えられるように構成し、 • 共同で継続的に管理する というプロセス。人文的な側面で言えば、立法行為に近いもの だと考えると理解しやすい。コミュニケーションが大事どころか、 「コミュニケーションそのもの」 機械が理解できるほど明晰な言語化
  5. © rector,inc Putnam SLIM Modelについての解説 工期 工 数 チーム生産性の幅 パトナム・モデル

    パトナムモデルは、経験的なソフトウェア工数 /工期推定のためのモデル。 1978年に発表 されたLawrence H. Putnamによる最初の論文は、ソフトウェアプロセスモデリングの分野 における先駆的な研究と見なされている。 経験的モデルは、ソフトウェアプロジェクトデータ(たとえば、工数・工期とコードサイズ)を収 集し、データを数理モデルに適用することで推定。 それらに得られた知見としては、工期を短くするためには予想されるよりも多くの工数が必 要になり、どこかで不可能ななゾーンに突入する。 これは、「妊婦が10名いてもこどもを1ヶ月で産めない」という有名メタファーの証拠でもあ る。 不 可 能 ゾ ー ン https://en.wikipedia.org/wiki/Putnam_model
  6. © rector,inc 攻めと守りのアセスメントを行い、メリハリをつける。 自社の強みとして、 
 改善する価値がある 
 他社/社会と同じ課題を 解決するもの
 攻めのIT投資

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

    NO コアシステム 内製・準内製化していく 削除・廃止 ノンコアシステム 環境変化は激しい? 競合優位につながる? NO NO NO 競合優位につながる? NO NO YES YES YES
  8. © rector,inc 受発注構造を組織内に持ち込むと発生すること 要求 納品 実装 ⑴ 発注者に文句を言われないように、保守的に納 期を見積もる。 ⑵

    発注者に文句を言われないように機能的要件ば かり重視する。 ⑶ 発注者に完璧な仕様書を求める。 仕事がどんどんつまらなくなる ⑷ 犯人探しや徒党を組む、責任回避 ⑸ 退職する。 ⑴ システムのことはわからないのでシステム部門の 言う通りにする。 ⑵ 完成品の品質が上がらないのでさみだれ的な依 頼が増える ⑶ システムから完璧な仕様書を求められるのでそれ を作れる人を探す ⑷ 改修にやたらと時間がかかるようになる。 ⑸ システム部門の能力が低いなどと他社に言いふら す。 すべての不合理の集積地が 最下流であるシステムの「負債」となって現 れる。 = システムは組織の鏡 発注者 受注者 システム
  9. © rector,inc ソフトウェアエンジニアリングの文化資本 どちらに説明責任が求められるか しな い理 由 は ? する

    理 由 は ? たとえば、PCのスペックであれば ・「採用競合に比べて、悪くする理由」の説明を求めるか ・「去年に比べて、高くする理由」の説明を求めるか によって無意識な選好の違いが、上長が求める説明責任の方 針に反映させてしまう。しばしば、合理的に説明を求めることに 何の認知の歪みがないと錯覚している人がいるが、何に対し合 理性を求めるかに権力構造が内包されている。 このようなまなざし(gaze)の違いが、文化資本の形成を促進し たり、妨げたりする。
  10. © rector,inc 幹部の強いコミットのもと、育成としての内製文化の導入 内製化の成功事例では、多くの場合それを進めたい幹部の強 いコミットが鍵になる。これは、単なる一部業務の内製化だけで はなくて、組織文化の輸入を伴う事が多いからだ。 そのために、できるかぎり限られた場所での成功体験を積み上 げていくと組織的なハレーションを少なく導入することができる。 これは早い段階では「教育育成」の一環として費用を捉えたほ うがいいかもしれないということを意味している。

    内製開発は文化資本の輸入・教育 • 小さく成功体験を積みやすいプロジェクトにフォーカスす る。 • プロダクトの意思決定者を明確にする。 • 周囲の批判者にも敬意を持つ。 • 意思決定者をプロダクトオーナーにし、優先順位付けを行 う。 • 開発者、デザイナー、品質エンジニア、プロダクトオー ナーを含んだチームを創る。 • 外部パートナーと準委任のスタイルで契約し、チームビル ディングを含む会議等にも参加してもらう。 • スクラム・カンバンなどの確立されたプロセスを意思決定 者を含むチーム全体で理解し、共有する。 • 相互理解・チームミッションの理解を重視する。 • かならず定期的な振り返りを実施する。
  11. © rector,inc たとえば、サービスデプロイメントの数 おおよその目安としてのスコア たとえば、60人のエンジニアがいて、1ヶ月(20営業日)あたり 150回のデプロイ回数の会社を考えてみる。 150 / 60 /

    20 = 0.125 > 0.1 と計算できる。およそ、一人のエンジニアが10営業日でつくった 差分が、一度デプロイされる計算になる。 結合度の高いサービスやトランクベース開発のできていないシ ステムだとすぐにこのスコアが悪化する。 DevOpsスコア デプロイ数 (Deploys) 開発者数 (Developers) 営業日数 (Days) = > 0.1