はじめに
こんにちは、CARTA HOLDINGSでエンジニアをしているこんちゃん(@konchanSS)です。
この記事は筆者が新しく発足したプロジェクトのシステムを外部委託で作った経験をチームで振り返った際に得た学びを『システムを作らせる技術』によって補強したものです。
この記事を読んでくれた方は是非『システムを作らせる技術』を一読して欲しいです。
システムを知らないあなたにこそ読んでほしい
この記事はビジネスサイドや、PdMだったりマネージャーといったいわゆるシステムの開発を依頼する側の人たちに向けて書いています。
意図した通りのシステムを作ってもらうための術を知ることはあなたにとって以下のメリットがあります。
- 意図した通りにシステムが動くことで業務の効率的になる
- 貴方がやろうとしているビジネスを促進させる
システムを作ってもらうための術を知ることがなぜそのようなメリットを享受できるようになるかは、以下に書いてある筆者の体験と『システムを作らせる技術』を合わせて読んでもらえるとわかります。
この記事はどういう場面で役に立つの？
『システムを作らせる技術』では、外部委託および内製に左右されない内容が書かれています。今回の記事は特に外部委託というところに重きを置いて書いていきます。
外部の開発会社に業務委託を行う際の”当たり前”から書いていきます。
この記事における事業背景
筆者が今回選択した手段は万人に当てはまるものではないです。
CARTAでは、内製開発を目的としたエンジニアチームがあります。かつ、フルサイクルエンジニアという働き方を実践しており、エンジニアが解決する課題は技術領域に限らないものとなります。
この記事においてエンジニアに相談するということはすなわち、そこに対する課題が本当に課題なのかを確認し、一緒に考えて解決に導いてくれる手伝いをしてくれるという認識で読んでいただけると助かります。
WHYをちゃんと深ぼってゴールをはっきりさせる
外部に委託をする前に今一度、何のためにプロジェクトが始まったのか(WHY)、ゴールはどこなのか明確にすることでやらないことを決めるのが大事です。
これは外部委託あるあるでプロジェクトが始まると
- 「せっかくだから」とやりたいことが色々と出てきて追加で対応をしてもらった結果、費用がとんでもない額に
- 予定してたスケジュールから大きく遅れが出てしまうケースです。
もちろん、今回のプロジェクトにおいてもそうなりそうなフェーズがありました。この失敗から学んだことは以下2つです。
- WHYの明確化: 何のためにプロジェクトが始まったのか
- ゴールの明確化: ゴールを決めてやらないことは何なのか
実際にはどうしてたの？
では、実際にどう決めたのか。当初の目的(WHY)は以下でした。
- ビジネスとして成立するということも確認しつつ、できるだけ最短でビジネスが行えること
- 最終的に自分たちで開発・運用を行うこと
それを元にゴールを設定しました。
「少しでも安くこのビジネスモデルを成立させ、CARTA MARKETING FIRMが売るプロダクトラインナップの1つとすること」
ゴールは関係者同士で話し合い、納得できるまで話し合います。
ゴールが決まれば、あとはやりたいことが出てきたときに「ゴールに沿っているかどうか」というのを照らし合わせて判断するだけです。
開発会社と契約する前にICT部門と法務には相談する
まずは法務やICT部門に契約形態から相談すると良いです。 続いて契約内容についても相談していくと良いでしょう。
これもあるあるなのですが、いざ開発会社と契約してみると品質やセキュリティなどのいわゆる非機能要件に問題があって契約上どうすることもできなくて、泣く泣く追加開発の費用を払ってしまうケースがあります。これらは始まってみるとどうしようもなく、事前に抑えておかなければいけません。
ICT部門には、主にセキュリティ懸念面や非機能要件におけるアドバイザリを担当してもらっていました。
- 外部委託するならば監査的に改ざんできないログ収集・改ざん不可能なアカウントの作成
- AWS基盤における権限委譲範囲の意思決定
- セキュリティ要件においては全社で策定しているポリシーに準拠する
- 非機能要件における対応の責任範囲の明文化と契約書への盛り込みレビュー
上記のようにプロダクト開発においてヌケモレしやすい部分をサポートしてもらっていました。
要件が曖昧な段階で契約しないこと
結論、曖昧な段階で請負契約にすることはやめましょう。「この要件の中でこれやってくれると思ったのに！」と先方との認識のズレが起こり、結果としてハレーションが起きやすいです。
請負なのか、準委任なのかはシステム開発においてもすごく大事です。特に作って欲しいものが曖昧な段階で請負契約すると痛い目を見るので、フェーズやマイルストーンごとの準委任契約にした方が良さそうというのが筆者の見解です。
同じように経理にも相談する
経理にどのようなフォーマットで売上・支払データを提出する必要があるか前もって確認しに行くと良いです。
これは担当したプロジェクトで実際に起きたことですが、用意してもらった締め処理の支払データや売上データの形式が経理が求めるフォーマットと合っておらず自分たちで整形、もしくは追加で開発してもらうことになりました。
もし、既存事業があるのであればそこでどのようなフォーマットで提出しているかを参考にすると良いですし、パッケージのシステムを使う場合は開発会社にサンプルをもらって経理に確認してもらうのも一手です。
機能を考える前に業務を設計する
ゴールが決まったら、次はもう欲しい機能とか一覧出したくなりますよね。それはすごくわかります。今回のプロジェクトでもそうでした。ただ、それだと後々こういう機能が必要だとわかったり、漏れが起きてしまうものなのです。
結局、あなたの普段の業務がどのような流れで行われて、何をどう管理したいのかがはっきりしないとシステムを作っても業務は改善しません。なので、まずはシステムを作る前にまず業務を設計しましょう。
普段の業務フローとそのフロー1つ1つでどのような情報を扱う必要があるのか整理しましょう。
実際にははどうしてたの？
こんな感じで簡易的にフローを作ってそのフローごとに登録したい情報をまとめてみたりしてました。
業務を遂行しない方が業務設計を行う場合は実際に業務を遂行する方を呼んで
- どういう情報を入力しながら業務を行うのか
- どのように業務を行いたいのか
をヒアリングするといいのではないでしょうか？(筆者はそうしました。)
逆に「業務の設計って何すればええねん」って思う方は、事業部のエンジニアに相談してみるのがオススメです。
非機能要件は最も漏れやすいので注意する
わかる人には「RFP(Request for Proposal)をちゃんと書こう」で終わりです。また、身近のエンジニアに非機能要件の確認方法を事前に相談しましょう。
ただ、それでは分からない人向けに書きます。
本記事ではRFPについては詳細を説明しませんが、理解しておくこと、作成できるようになることは非常に大事です。詳しい部分はぜひ、『システムを作らせる技術』を読んでみてください。
非機能要件とは、読んで字の如く機能にはないがシステムに求める要件のことで、6大項目から構成されることが多いです。
- 可用性
- 性能・拡張性
- 運用・保守性
- 移行性
- セキュリティ
- 環境・エコロジー
パッとイメージできない人も多いでしょう。ここでは、『システムを作らせる技術』の一節を借りて非機能要件の説明をします。「快適に過ごせる注文住宅」を例に考えます。
住宅の比喩を使って説明しよう。
・「大きな本棚が欲しい」 => これまで議論してきた機能
・「冬でも快適に過ごせるように高断熱にはこだわりたい」=> 非機能要求
・「耐震や高断熱のためにコンクリート構造がよい」=> システムアーキテクチャ
230ページ
イメージできましたか？非機能要件の設計を完全にお任せしてしまうとどうなるかも想像に苦しくないはず。同じ悲劇がシステムでも起きます。システムの使いやすさや安定性・保守性が大切なのは、住宅における居住性や快適性、安全性といった要素と同様です。
一方、エンジニア以外の方が非機能要件をどのように把握するかは実際のところ難しいところではあります。
『システムを作らせる技術』は、委託元が非機能要件を知っておく必要があるとしており、そのためにいくつかの切り口を用意しています。
ここでは紙面の都合上、詳細なやり方は説明しないので是非本を読んで欲しいのですが...。
とりあえず本記事では身近のエンジニアに非機能要件の確認方法を事前に相談しようとしておきます。
プロジェクトマネージャというかファシリテートする存在はいた方がいい
新しいプロジェクトには当然、色んな立場の人たちが関わることになります。プロダクトのことを考えるPdMや事業責任者、出来上がったプロダクトを売るセールス、受注先の開発会社のエンジニアやマネージャーなどステークホルダーは多岐に渡ります。
また、プロセスにおいて1つの機能が出来上がるまでを見ても、社外に質問をしたり、社内で事業責任者に確認を取ったり色んな人とのやりとりを経て決まります。
つまり、ちゃんと状況を整理できていなければボールの所在を見失いやすく、かつ社外や部署を跨ぐコミュニケーションがあると特にプロジェクトは停滞しやすいです。
チーム体制として決める人は一通り揃っているけど、彼らの決める裁量や権限の範囲は決まっており、決める人同士の連携や決めたことを次に繋ぐ存在がいないという状態も起き得ます。
なので、役割として用意しないにしろ、橋渡しできる存在がいた方がスムーズに進みます。
実際にはどうしてたの？...
今回のプロジェクトでは、初期では筆者がGithub Kanbanを使って状況の把握と決めないといけないことリストを管理しつつ進めていました。常に状況がわかるようにやることリストの中にコメントとして状況を残しつつ、やってました。
別のプロダクトでは非エンジニアもGithub使うことがあるので問題なかったですが、そうじゃない部署はそれぞれのタスク管理ツールを使うと良いと思います。
まとめ
以上がCARTA MARKETING FIRMでプロダクト開発を外注した際に、実際に起きた失敗から学んだことです。
筆者が『システムを作らせる技術』に出会ったのは、これらの失敗を経験した後でした。
『システムを作らせる技術』を読んだとき、自分が実際に経験したことを追体験したような衝撃を受けました。当時、私たちは自社内でプロダクト開発を完結させており、外部委託会社に開発を依頼するという経験に乏しい状態にありました。
また、私たちがそれらの問題に出会ったとき自社内にエンジニアがいるという都合上、エンジニアに相談するという手段を取ることで解決することができました。
CARTAのエンジニアは事業をエンジニアリングするということに価値をおいており、このような相談にも乗ってくれます。
自社内にエンジニアがいない方は是非『システムを作らせる技術』を読んでいただければ解決へのヒントが得られると思います。
この記事が同じような状況の会社の方の参考になれば幸いですし、『システムを作らせる技術』を読むきっかけになることを願っています。
参考にした記事および書籍
高信頼化 ソフトウェアのための 開発手法 高信頼化 ソフトウェアのための 開発手法ガイドブック
合わせて読みたい
