受託開発と自社サービス開発

業務と考え方の違い

ブライシス株式会社・華房誠

2023 年 10 月 27 日

自己紹介

前職

現職

• SIerでシステム構築と受託開発に携わる
• 大手都市銀行の業務システム
• プライムの場合と二次請けの場合あり
• 業務内容は上流工程から納品保守まで
• 職種経験としては営業支援・SE・開発

• SIerを20年務めたあとにブライシス株式会社に転職
• 自社のクラウドCTIサービス・BIZTEL開発に携わるhttps://biztel.jp/
• ひとりチームで新バージョンをスクラッチ開発
• 現在は部長職としてBIZTEL開発を統括

今日お話すること

• 受託と自社サービスで感じた違い
• ①エンジニアリング
• ②プロジェクト
• ③メンタルモデル
• 違いがなかったもの
• 経験が活かせたもの

あくまで自分の

経験での話です

①エンジニアリング

• 課題観点の違い
• 技術基盤の違い

①エンジニアリング

課題観点の違い

• 課題観点の違いが生まれる背景
• 【受託】業務上の困難な要件がある
• 【自社】システム上の困難な要件がある

①エンジニアリング

課題観点の違い

【受託】の業務上の困難な要件とは

• 複雑で特殊な業務フローや状態管理が求められる
• 『一度承認された申請を、指定の状態まで指し戻せるようにしてもらえる？２４時間以内であれば。申請自体なかったことにするオプションも欲しいです。でももうお客様に提出していたら管理者の差し戻し承認が必要かな、そこはもうちょっと考えさせて。あとね・・・』
• 『はい。。』

①エンジニアリング

課題観点の違い

つまり【受託】では業務自体が複雑なため

⇒ 受託は業務の複雑性を起因とした開発の難しさが課題

• その複雑な業務の背景を把握する難しさがある
• なぜそのような運用を行いたいのか、行っているのか
• 把握した複雑な業務を、システムとしてデザインする難しさがある
• 複雑な要件背景が適切に把握された設計
• 複雑な状態遷移が適切にデザインされた実装

①エンジニアリング

課題観点の違い

一方【自社】の場合

• 自社では複雑な業務フローや状態管理は行わない
• そもそも避ける方向でデザインする
• 特定ユーザの特定要件に対応するわけではない
• 永遠に機能拡張し続けるので難しくしたくない

①エンジニアリング

課題観点の違い

では【自社】の困難な要件とは

⇒ 自社はシステムの継続性を起因とした難しさが課題（後述）

• システムが永続的に拡大し続けることを起因とした難しさ
• 永続的に拡大しても破綻しないアーキテクチャデザイン
• リリース・デプロイなど本体システムを支える基盤整備
• トラフィックやデータ増大を捌くための仕組みや知見

①エンジニアリング

課題観点の違い

まとめ

⇒ キャリアパスは困難な要件をエレガントに解決するドメインプログラマ！

• 受託では業務観点での設計力・実装力が鍛えられる
• 業務の複雑性要件は、要件把握力・設計力が鍛えられる
• その設計を適切に実現するためのコーディング力も鍛えられる
• 複雑な要件を読み解いてエレガントな設計や実装で解決できたときの気持ちよさ

①エンジニアリング

• 課題観点の違い
• 技術基盤の違い

①エンジニアリング

技術基盤の違い

• 技術基盤の違いが生まれる背景
• 【受託】リリースは一度きり
• 【自社】リリースを何度も行う

①エンジニアリング

技術基盤の違い

【受託】ではリリースは一度きり

⇒ 良いとか悪いという話ではなく必要性がない

• リリース自体は一大イベントだが頻度は低い
• そのため手順書ベースでの作業となりがち
• リリースのための技術基盤や仕組みを作る必要性がない

①エンジニアリング

技術基盤の違い

一方【自社】ではリリースを何度も行う

• リリースを何度も行うのでリリースに手間をかけられない
• 長くて月次、短くて日次のリリース頻度
• リリースに手間をかけられない
• オペミスのような人為的エラーを避けたい
• 自動でリリースできる仕組みが必要となる

①エンジニアリング

技術基盤の違い

【自社】はリリースを何度も行うために

⇒ アプリケーションを支える周りのシステムが必要になってくる

• リリースを自動化するためのデプロイ基盤が必要
• デプロイ基盤の整備には更に別の基盤や運用が必要
• ブランチ管理とリリース管理とその運用、デイリービルド基盤とデイリーデプロイ運用、デイリーリグレッション運用など
• デプロイのためのインフラ自動化、運用体制や組織など

①エンジニアリング

技術基盤の違い

まとめ

⇒ キャリアパスは基盤全体を知悉するフルスタックエンジニア！

• 自社ではシステム観点での設計力・実装力が鍛えられる
• アプリケーション本体だけではなく、インフラ面、環境面、運用面でのエンジニアリング力も求められる
• 幅広い分野の技術課題に携わることができる

②プロジェクト

• プロジェクト永続性の違い

②プロジェクト

プロジェクト永続性の違い

• プロジェクトの違いが生まれる背景
• 【受託】案件毎にシステムやドメインが変わる
• 【自社】１つのシステムやドメインに取り組み続ける

②プロジェクト

プロジェクト永続性の違い

【受託】では案件毎にシステムやドメインが変わる

⇒ 失敗の反省を次のプロジェクトに活かすことができる

• ゼロイチプロジェクトに携われる
• 新たな技術に携われるチャンス
• 新たな設計で携われるチャンス
• 誰も最初から素晴らしいシステムを作り上げることはできない

②プロジェクト

プロジェクト永続性の違い

一方【自社】では１つのシステムやドメインに取り組み続ける

⇒ 設計に失敗しても次はなく自分の足元を改善し続ける必要がある

• よく言えば１つのシステムにしっかり腰を据えて携われる
• 悪く言えば技術的負債満載でも向き合い続けなれば行けない
• 実は地味な開発活動・整地活動が多い
• 最初の設計の考慮不足を機能拡張の度に気づく
• その度に正しい設計・正しい実装か何かを再検討して改善する

②プロジェクト

プロジェクト永続性の違い

まとめ

⇒ 自社の開発活動は地味、受託の方が技術的・設計的にはモダン？

• Prj永続性の違いは、反省をどのように活かすかという違い
• 次のPrjに活かすか、いまのPrjを改善していくのか
• 受託の場合、次のPrjの技術選定や設計方針に反映ができる
• 自社の場合、地道な改善の積み重ねが必要
• 負債返済も新しい技術の取り組みも

③メンタルモデル

• 課題への取り組み方の違い
• 優先される開発観点の違い

③メンタルモデル

課題への取り組み方の違い

• 課題への取り組み方の違いが生まれる背景
• 【受託】お客様の課題を把握することに注力する
• 【自社】お客様の課題を想像することに注力する

③メンタルモデル

課題への取り組み方の違い

【受託】ではお客様の課題を把握することに注力する

⇒ 一番怖いのは実際提供したら認識が合っていなかったというケース

​

​

​

• 顧客が本当に欲しいものを把握する
• 要件定義を通して、ウオンツ・ニーズを掘り下げ、要望の裏に隠されているものを把握する
• お客様自身が自分たちが本当に欲しいものを知る

③メンタルモデル

課題への取り組み方の違い

一方【自社】ではお客様の課題を想像することに注力する

⇒ 一番怖いのはその機能を誰も求めていなかったというケース

​

​

​

• 顧客がお金を出してでも欲しいものを想像する
• 課題を提示してくれるお客様はいない
• 自分たちで課題であろう事を想像するところから始まる
• 誰も答えを持っていないので喧々諤々で議論する

③メンタルモデル

課題への取り組み方の違い

まとめ

⇒ 自社は開発者であってもお客様の業務像や世の中の動向を意識し、　 顧客満足度を向上させるPdM的な機能提供目線が求められる

• 課題を深掘りできる能力か、課題を発掘できる能力か
• 乱暴に言えば、受託はどう創るか、自社は何を創るか
• 何をには時間軸も含まれる
• １年後のにはこういう機能が求められるだろう、とか
• １年前とはビジネス状況が変わっているな、とか

③メンタルモデル

• 課題への取り組み方の違い
• 優先される開発観点の違い

③メンタルモデル

優先される開発観点の違い

• 優先される開発観点の違いが生まれる背景
• 【受託】予算重視
• 【自社】継続性重視

③メンタルモデル

優先される開発観点の違い

【受託】では予算重視とならざるを得ない

⇒ 予算重視のため、開発観点が納期優先となりやすい

• 予算は受託側・お客様側の双方にとっての最重要視項目
• お客様も予算とスケジュールを組んで社内稟議を回しているので、納期が変わると改めて社内調整が必要
• 納期リスクが上がった場合には、双方で落とし所を探すという方向に流れやすい構造

③メンタルモデル

優先される開発観点の違い

一方【自社】ではサービス継続性が重要

⇒ サービス継続性重視のため、開発観点が品質優先となりやすい

• １つのシステムで長く戦っていくためには
• ジェンガなシステムは絶対に避けたい
• 永遠に機能拡張し続けることを意識したら、
• QCDS：品質・コスト・納期・スコープでどれを選択するかと言えば品質

③メンタルモデル

優先される開発観点の違い

まとめ

⇒ 品質重視するための意識付けや改善活動を日々の業務として行う

• 自社の開発者全員が品質優先の意識を持っているかどうかは別
• サービス継続のために品質維持の意識付けと活動が必要
• ボーイスカウトルール・フェイルファースト
• 品質の維持・改善方法を勉強会や輪読会で学び合う
• 整地活動主体のチームを整備しリファクタ続ける意思表示を示す

今日お話すること

• 受託と自社サービスで感じた違い
• ①エンジニアリング
• ②プロジェクト
• ③メンタルモデル
• 違いがなかったもの
• 経験が活かせたもの

違いがなかったもの

• 経験が活かせたものこと
• やっていて良かったこと

違いがなかったもの

経験が活かせたものこと

⇒ 言語や環境に依存しない普遍的な技術やその技術への理解度

• お客様の言葉の裏に隠された要件を明らかにする能力とまとめあげる能力
• ウォンツとニーズ、顕在ニーズと潜在ニーズ、ドメインを把握する
• 業務モデリング、例外設計・運用設計、ドキュメンテーション
• 設計を可読性・堅牢性・拡張性をもってシステムに創り上げる能力
• リーダブルコード記載の可読性の高いコーディング、オブジェクト指向の理解やデザインパターン・SOLID原則、ドメイン駆動設計のプラクティス

違いがなかったもの

経験が活かせたものこと

• パラダイムの同じ言語や環境
• オブジェクト指向言語とWebフレームワーク
• 何の問題もない
• パラダイムの異なる言語や環境はどうか？
• Flux/Redux 単方向データフロー
• TypeScript、Rust、Scala など関数言語型フレーバーを伴ったモダン言語
• クリーンアーキテクチャなどの機能性のあるアーキテクチャデザイン
• これは新たな学びが必要

違いがなかったもの

経験が活かせたものこと

⇒ モダンな技術の背景を自分の得意な言語の深掘りで理解する

• パラダイムの異なる言語や環境、の技術背景は手持ちの技術でも学べる
• オブザーバーパターンによるイベント駆動型実装の理解
• Java8 StreamAPI/Optional による関数型処理や参照透過、モナドの学び
• イミュータブル強制やNullセーフなどモダン言語アプローチの取り込み
• クリーンアーキテクチャの目的とその実現方法の理解

違いがなかったもの

• 経験が活かせたものこと
• やっていて良かったこと

違いがなかったもの

思い返してみてやっていてよかったこと

• 技術の幅を広げる
• いけてると思うエンジニアをフォローする
• WebDBPressの記事はよく分からなくても全部読む
• 業務の中で少しずつ使ってみて学ぶ、viviやcygwin

違いがなかったもの

思い返してみてやっていてよかったこと

• 技術を深掘る
• 携わっている技術に関連するStackOverFlowの投稿に目を通す
• 携わっている技術に関連する先駆者の書籍を読む
• いけてるエンジニアのgithubソースを写経する
• 社内勉強会で講師役を引き受ける

違いがなかったもの

まとめ

⇒ 学ぶことは無限だが１日１ミリでも技術の幅と深さを広げていく

• どんな現場でも学ぶことはできるし、学ぶことは常に存在する
• どの分野でも先駆者がいて深い洞察を学ぶことができる
• どの業務、どの開発でもこれ以上学ぶ事はないとは言えない
• 自分が携わっている技術の普遍的・本質的な点を意識する
• 自分が携わっている技術の幅と深さを少しずつ広げる意識をする

本日のまとめ

​

• 日々の研鑽の積み重ねが、揺るぎない自信と実力となる
• まずは自分に自信を持つためにコツコツと技術を積み上げる
• そうやって積み上げた点と点が繋がり、大きな成果が生まれる
• それがお客さまと自分自身を幸せにする
• 受託でもSESでも自社サービスでも変わらないエンジニアの責務