初めに
KDDI Engineer & Designer Advent Calendar 2023の23日目の記事を担当します@Hemmy7です。
SIer（作る側）から事業会社（作ってもらう側）に転職し、それぞれの立場でシステム開発に携わった経験から得られたノウハウや感じたことを共有します。今回は技術よりマネジメント要素が強い内容となっています。少しでも参考にしていただけたら幸いです。
システム開発の分類
中～大規模なウォーターフォール型のエンタープライズ向け「業務系システム」の経験が中心でした。よって、一般コンシューマー向けの「Web系システム」や「アジャイル開発」とは文化が異なるかもしれません。
経歴（概略）
１社目 商社系SIer：Java開発やプロジェクトマネージャー（PM）など
- オープン系Webアプリケーションの開発に始まり、基幹システム構築のPMなどの実践を積みました。
- オフショア開発案件ではトラブル火消しのためインドへ渡り、片言英語でインド人と一緒にコーディングに明け暮れた経験が一番の思い出です（何とか火消しには成功）。
※主な経験技術：Seasar2、Java、Weblogic、Oracle 11g、Groovy、ZK Frameworkなど。
インドの雰囲気とインド拠点のオフィス
２社目 通信キャリア情シス：PMや要件定義/方式設計など上流中心
- 大規模基幹システム更改のPMO/標準化担当や仮想化共通基盤（プライベートクラウド）更改のPMを経験。
- 直近ではコールセンターシステム更改（オンプレ⇒AWS化）にて標準化/方式設計/共通部品チームリーダーを担当。
システム開発で大事だと感じた3つのポイント
①やっぱり一番大事なのは「要件定義」
＜①-1. 事業会社視点＞
-
要件をすべて要件定義書に書けていれば、基本設計工程以降は寝ていてもいい
⇒とても大げさな表現ですが、そのくらい要件定義は重要だと感じています。実際には基本設計以降も進捗管理や設計書レビュー、工程切替判定を実施する必要はあります。しかし、要件定義書を修正するほどの手戻り（要件漏れ等）が無ければそこまで大きな問題（納期遅延やコスト超過）にはならないと思います。 - いわゆる 「異常系」の要件 は見落としがち
⇒どうしても「正常系」の業務フローをベースに要件を洗い出すことが多いので、情シス担当だけではなくシステム利用部門との連携を密にして 「異常系」も意識してレビュー してもらうと良いと思います。ここで頑張るとV字開発の終盤（システムテストなど）がとても平和になるはずです。
失敗経験：1社目での要件定義
利用部門の責任者（現場経験もある経理部長）に何度も確認して要件定義を擦り合わせた上で開発を進め、リリースが近くなり現場担当に操作確認してもらった段階で 「この仕様では業務が回らない」 と要件漏れを指摘されたことがありました。利用部門の責任者がOKを出したとしても、実際に業務を行う現場担当にも要件定義工程から細かく仕様確認してもらう重要性を痛感しました。
＜①-2. SIer視点＞
- 想定外事象が発生するたびに「要件定義書に記載されているか？」を確認
⇒要件定義に明記されているのならばやるしかないし、記載されていなければ要件追加/変更（追加費用）となります。ただし、要件定義は抽象的な記載も多いのでどちらにも解釈できそうな場合は両社で都度相談して落としどころを擦り合わせます。 - 「要件定義に書いておいてもらえる」に越したことは無い
⇒（要件追加/変更により）追加費用を貰えたとしても、SIer側としてはその分の工数（人件費）がかかっていますしスケジュールのバッファも食いつぶしていくので要件定義に書いておくことが両社にとってベストだと思います。
②事業会社担当と開発パートナー（SIer）担当の関係性
＜②-1. 事業会社視点＞
- ルールを提示し、適切にジャッジし、得点を認める（レフェリーのイメージ）
⇒まず「要件」や「進捗報告の形式」といったルールを示し、それらを定例進捗会などで日々確認して不備があれば指摘（ジャッジ）することが重要だと思います。ここで指摘しないと（手を抜いても指摘してこないな）と思われてしまい、暗黙のうちに基準が変わってき品質が低下してしまいます。また、日々の報告や成果物に良いところ（得点）があったら、やってもらえて当たり前と思わずに感謝を伝えることが大切です。そうすることで（いいものを作ればちゃんと分かってもらえるので次も良いモノを作ろう！と）意欲が高まり品質も上がっていくでしょう。 - 発注側が「偉い」という考えは一切無くす
⇒システム化する目的をや要件を提示する側、システムを作る側という役割が違うだけであり、互いにプロフェッショナルとして対等に認め合える関係が理想だと思います。
※パートナーとの関係性については弊社インフラスペシャリストの@KAJITAKAさんも記事を書かれているのでぜひ併せて読んでみてください ↓ ↓ ↓
＜②-2. SIer視点＞
- お客様のために より良いモノを作りたいと思っている
⇒「事業会社側はお客様でありお金を頂く以上はより良いモノを作るべし」と教えられましたし、実際にそう考えているメンバーが大半だったように思います。
この経験から事業会社側の立場になってからは、SIer側が「良いモノを作る」ことを後押しできるように意識することができました。
- （事業会社側に）技術に詳しい人がいてくれたら嬉しい、分からないなら聞いてほしい
⇒某銀行案件では事業会社側に元SIerの方がいて、技術的な相談にも難なく乗っていただけてとても仕事がし易かった経験があります。一方、別案件ではあまり技術に詳しくない事業会社担当と対面レビューをしたことがあったのですが、 知ったかぶりをせずに、分からない点はいつも真摯に質問いただけた ことがありました。この時のお客様の立ち振る舞いにはとても感銘を受け、 まさに事業会社情シス担当の理想の姿 だと感じました。
③「人と体制」が成功のカギを握る
＜③-1. 事業会社視点＞
- メンバーの入れ替えは比較的難しいので 最初の配置が重要
⇒プロジェクト体制と所属部署が連動していることも多く、簡単には人の入れ替え（≒人事異動）ができない印象なので、最初の体制決めは重要だと思います。また、要件定義やレビューの品質はリーダーの理念に依存するところも大きいと感じます。 - PM/PMOやリーダーは「チームを横断する課題」の管理/調整をする
⇒「この課題はアプリ担当だ、いやこれはインフラ担当だ」というのを各担当同士でやり取りするとチーム間の雰囲気/連携が悪くなってしまう場合があるので、上のレイヤで上手く調整できると良いプロジェクト運営ができると思います。
＜③-2. SIer視点＞
- SIer側の「体制」は（事業会社側以上に）システム品質に直結する
⇒SIer側のリーダーが 「絶対にいいシステムを作る」 という強い思いと能力がある場合、適切に配下メンバーを増員・入れ替えなどして成功に導いていくと思います。（実際に目の当たりにしたことも何度かあります。） - 割と人の増員や入れ替えが可能
⇒SIerではプロジェクト体制と所属部署が依存していないことが多いので、（事業会社と比較すると）体制変更は割とし易いと思います。後に大きな問題になるくらいなら早期に増員や入れ替えをしたほうがSIerにとってもメリットが大きいと判断されるケースもあると思います。（事業会社担当としてもこの点を意識してSIer側に体制強化を上手く要求できると良いのではないでしょうか。）
【番外編：マルチパートナー開発】パートナー同士が仲良くなる方法
思った以上にここまでが長くなってしまったので、番外編の内容は別途書こうと思います。
さいごに
あまり纏まりが無く長々と書いてしまったのですが最後まで読んでいただきありがとうございます。少しでも参考にしていただけたら嬉しいです！！