はい、パーソンリンクアドベントカレンダー20日目です。
本日は、クライアントワークとして請け負っていたプロダクトリリースの裏側を話します！！
と、以前予告したのですが、プロダクトまだ本リリースしておりません...(´・ω・`)
試験的にクローズドで運用を始めているプロダクトで、これといった大問題に遭遇するほどのトラフィックが来ておらず、今回これについて書けることがほとんどありません。リリース直前特有のあの緊張感を書くことができず、とても ホッとした 残念な気持ちです。
と、ネタが早々になくなってしまうという状況でしたが、流石に何もなかったですと終わらせるわけにも行かず、どんなネタを書いていこうか悩んだ末、自社プロダクトとクライアントワークの開発末期の動きの違いについて書こうと思いました。
昔からいろんなところで語られているクライアントワークと自社プロダクトの違い。これまでいろいろな会社で自社プロダクト、クライアントワーク共にリリースを経験してきてはいたのですが、実態は世間的に感じられてきたイメージとは異なっていました。完全に自社だけで開発したもの、外に発注してマネジメントしたもの、などその時に状況によって大きく差があるんですよねー。
直近経験した自社プロダクト開発と、今回のクライアントワーク開発。一体どのような動きの違いがあるんでしょうか？
クライアントワークと自社プロダクトのリリースってなにが違うのさ？
自社プロダクトの特徴としてみなさんが思い浮かぶのは
- 自社なので最悪スケジュールはなんとかなる
- 好きな技術を選定できる
- githubだったりCircleCIだったりのサービス利用に制約がない
- 開発者とプロダクトオーナーが近いので仕様の変更が割と柔軟にできる。
- 開発費は自社もちなので当たり次第で赤にもなる
ですかね。一方、みなさんが思い浮かぶクライアントワークの特徴でいうと、
- スケジュール遵守
- 使用技術が決まっている
- 外部サービスの利用が制限されている
- 開発者とプロダクトオーナーの会社自体が違うので仕様の変更などを行う際のコミュニケーションが辛い
- 開発費は相手持ちだが、契約次第では人件費で赤になる
と、あんまりいいイメージはないですかね....
さて、こんな自社プロダクトとクライアントワークですが、みなさんが思い浮かぶイメージでもろもろの条件を雑に整理するとこんな感じですね。
| クライアントワーク | 自社プロダクト | |
|---|---|---|
| スケジュール | 決まっている | 柔軟性がある |
| 技術 | ある程度固定 | 自由 |
| POとのコミュニケーション | 大変 | 楽 |
| 開発費 | スケジュール伸びると赤 | スケジュール伸びると赤 |
実際どんな感じだったのか
今回の要件を整理したところで、早速実際どうだったのか。私の体験談を紐解きながら解説していきます(｀･ω･´)
おそらくこの記事を読まれている方は、この辺に興味があるかと思います。
- スケジュール
- 仕様調整の仕方・伝え方
- 開発手法
この3点について解説していくことにしましょう。
と、その前にまずは前提条件の説明をした方が良きですね。
直近で経験した自社プロダクト、BtoCのECモールサービスでした。登録している店舗が利用者にものを売るための場を用意し、その利用料と決済手数料で儲ける。そんなプロダクトです。
一方今回のクライアントワーク。詳細は触れられないのですが、BtoBの業務系のSasSで、準委任契約のプロダクト開発となっています。
今回の説明では、前者の自社プロダクトを「ECモール」、後者の今回のクライアントワークを「SasS」という呼び方で解説してきます(｀･ω･´)
なお、すべての会社がそうだと言っている訳ではありません。あくまで私の主観なので、「実際そうじゃないよ」的な意見もあるかと思います。もし、そういう意見がある方は、この記事を読んでいる方のためにも、良ければコメント欄に書いて共有して頂けると嬉しいです。
準委任とは？
説明の前に、今回のSasSで用いている準委任という契約について、リリースに関わる部分の違いを軽く。
一般的にIT分野のクライアントワークでは、請負契約で行われているものが(私の知る中だと)多いです。請負の場合、成果物を納品し終わるまでが契約で、いつまでに何を開発してくれという「締切が明確に決まっているもの」で行われている契約です。この場合作るものが決まっていて期限も決まっているため、開発中の柔軟な変更(仕様、期限等)ができない傾向にあります。
一方準委任の場合、契約時点では開発するものの内容や期限は決まっていません。お互い都度すり合わせながら最終的な成果物とリリース時期を決めていきます。なので開発中の柔軟な変更ができる傾向にあります。
とはいえ、このへんは発注元企業のやり方によって変わってくる話ではあります。今回の準委任の契約でやっているものは、クライアントと毎週の定例ですり合わせて色々と決めていけるタイプのもので、調整が十分できる案件になっています。
それでは前置きはこの辺にして、解説といきましょう。
スケジュール
はい、スケジュールです。この業界の人みんなこれに泣かされてる気がしています...
比較しているECモールとSassでは、ECモールの方がスケジュールが厳しい。
Sassの方は準委任という契約スタイルであることもあって、プレリリース時点では、そこまでキツキツのスケジュールになることはありませんでした、と言えればよかったのですが、私がJoinする前に数回スケジュールが延伸してしまったと聞いてます。そこは要件をミニマムに削り、プレリリースで様子見ながら作っていく形に落ち着くよう、なんとか調整させていただく形になってしまいました。お客様に頭が上がりません。ありがたい限りです...
さて、ECモールの場合ですが、こちらは自社プロダクトではあったものの、いろんな力関係がある関係があり遅延が許されないサービスでした。こちらも結局いろいろあって遅延したんですが、かなり強くスケジュールへのコミットが言われていた前提もあり、スケジュールを調整するために関連各所に謝罪行脚をしつつ担当のPOが詰められるというイベントが発生しました。つらみ。その時の担当は自分じゃなかったのですが、それでもかなりプレッシャーが掛かる開発で、大変だった記憶しか残っていません。
クライアントワークで動かせる契約を結んで居た場合、まだ自社より調整しやすいとは思います。お客様との信頼関係が築けているという条件付きではありますけども。開発を請け負っている我々からしてみれば安堵するタイミングだと思います。
その裏のクライアント側では、リリースの遅延発生により自社内で謝罪行脚をしている人がかならずいます。共通して自社側で詰められるのは変わらないのでしょう(´・ω・`)
自社かクライアントかどちらかが詰められる。その余波が直接くるか、防壁があるか、がスケジュールの決定的な違いではないでしょうか。スケジュールはどちらにせよ守らなれけばならない重要な要素なのです。
仕様調整の仕方・伝え方
これは皆が思うイメージどおりで合っているところですね。
SasSとECモールなら自社プロダクトのECモール開発の、方が圧倒的に話が早かった！
わからない要件を引き出すのも、仕様変更を提案するのもとても楽に素早く実施できました。常に顔を突き合わせているというのもそうですが、同じ会社に所属しているため「同じ空気感」を共有できている点もとても大事だったと思います。
しかし、途中からPOが不在がちになったり、組織構成による問題ががでてきたりと、全体を通してよかったのは僅かな時期だけでした。
- 不在で聞ける人が居なくなり滞りがちに
- 要件引き出しや仕様調整が遅延していくことが多々
- 役職もち兼任POとか大変なんでやめましょう。POの実働は普段チームにいる人に渡した方がうまく機能します
- 縦割り組織
- 営業やデザイン部みたいな部署との連携が必要だったのですが、縦割り組織にありがちで全体の最適な形がまとまるのに時間がかかりました
- いろんな人とミーティングを繰り返し、なんども説明することで最終的には落ち着きましたが、その後も「聞いてないぞ」「考慮が足りないぞ」というお叱りをいろんな方面から投げられるという辛さを味わいました。
さて、一方のクライアントワークのSasSサービス。
こちらは自社プロダクト並のスピードは出せないものの、都度のSlackやり取りや、週1定例で3,4時間腰を据えて会話していたこともあり、そこまで大きな問題には至りませんでした。
ただやはりお互いの話したいことをすべて話すには時間が足りていないように思えてます。自社開発並の連携速度には及びませんが、会社としてやり取りしている以上確実にMTGにいらしてくれるため、自社プロダクトPO不在！時よりは前に進んでいる感じはしています。
最高にうまくいっているチーム、組織なら自社プロダクトが最速です！
しかしそこがうまく機能できてい場合だと、クライアントワークの方が早い可能性が十分にあります。
素早く連携を取れる状況が構築できているかどうか。それによって決まってくるように考えています。
開発手法
さてこの記事の最後ですね。開発手法。
ECモールと、SasSはどちらもアジャイル開発していました。
ECモール側は1週をスプリントにしたスクラムを用いて開発していました。デザインレビューやレトロスペクティブもやってるいわゆるスクラムを全部やってみました、というやり方です。言語はRails+AWS+Vue.jsでしたが、古いシステムとの連携がありそこはJava+オンプレ+Oracle Databaseの環境ですね。
一方SasS側は週1定例で都度開発スコープや要件整理をやるだけで、特に振り返りを行うことはあまりありません。毎日の夕会でその日の作業報告や、困ったことの連絡をするくらいはやっていたのと、なにか問題があったら都度内部で一時間くらいのMTGをするというスタイルです。言語はこちらも同じくRails＋AWS+Vue.js。言語的な違いはなく開発プロセスの違いがあるくらいです。
この観点で見た場合、なぜか今のSasS開発の方がよりスムーズに動いている気がしました。毎回そういう場を用意するのではなく必要な時に必要なだけ会話する。それが対話や変化への対応を謳うスクラム開発よりも効率が良かったと感じています。
さて、なぜそうなってしまったのか。
ECモールの場合、週1をスプリントとして水曜日の1日全部を使ってスプリントレビューとレトロスペクティブ、リファインメント+プランニングをやっていました。リリースまで時間があるうちはうまく回っていました。毎週成果が上がりモノがつくられ、社内でレビューに回して使ってもらい、フィードバックを反映する計画を立てる。理想的な開発の仕方だったと思います。
しかし、リリースが差し迫ってあることに気づきます。
長期でみたリリーススケジュールと実際の進捗率が乖離し始める...
スケジュールのところでも出てきたPO不在がちの時期と同じくして起こりました。
POがいない → 全体を把握している人がいない → でもスプリントはちゃんと回っている → なぜかわからないけどリリースに間に合わないことが確実....
みんながスクラムで自らの役割を遂行することにこだわった結果、足りてない場所を埋める活動ができていなかった。「計画に従うよりも変化への対応を」というアジャイルの考え方を理解しきれていなかった。今振り返るとそういうことだったのだと理解しています。
一方SasSの場合、夕礼と必要になったときのMTGでそれなりに上手く開発はできていたと思います。しかし、こちらは都度の振り返りのタイミングが明確に決まっていないため、定期的なプロセス改善は生まれにくいですね。
後は要件を定期的に整理する場が作りにくいこと。クライアントとの週1の定例を実施してはいましたが、要件整理を全部やるというよりは、これからどうしていくか？の議論になりがちで、話さなければいけない要件が結構漏れることが多めです。この点から見るとやはり定期的に要件を整理してやることを決めるスクラムを用いた方が確実だなぁと感じています。
結論としては、その時最適なコミュニケーションやプロセスへ、流動的にやり方を変えていくことがどちらの開発であっても重要である。といえます。
終わりに
エンジニアがリリース直前でしんどいのは、自社プロダクトだから、受託開発だから、という話ではくくれない部分ではないでしょうか？
やはり最終的には、プロタクト側の責任者と開発者がお互いを信頼しあい、プロダクトのリリースに目線を合わせて進んでいけているか？が重要で、それがない開発ではどこもリリース直前の大炎上を避けられないでしょう。
今回我々はクライアントワークで受託開発です。それでも(まだ)大きく炎上していないのは、クライアントとの信頼関係を構築し、クライアントのビジネス的な成功を後押しする形での関係性をもっているからです。
これからのプロダクト開発、大変な状況に甘んじているだけでは不幸せな結果になってしまいます。そこに甘んじるのではなく、お互いが協力しあい「良いものを一緒に作り上げていく」気持ちや行動へ繋げていけるか。
そこを突き詰めて行けるかどうかで決まっていくのではないでしょうか。
明日の[パーソンリンクアドベントカレンダー](https://qiita.com/advent-calendar/2019/person-link)21日目は、[shg_shg](https://qiita.com/shg_shg)さんです。CircleCIの尖った話がありそうでとても期待しています！！
それでは明日も宜しくおねがいします。