mediba Advent Calendar 2021 の25日目を担当します、新卒3年目の川北 (@hiromasa-fun)です。
この記事は24日クリスマスイブに書いてます。イブ書き。
今回は、
ScM体験記ベースで、PJ特徴/あるあるなどをまとめてみました。
個人的観点なので鵜呑みにせず一意見として見てもらえればと。
ScM経験
新卒3年目からScMの経験をさせてもらっていて、下記が3年目以降のプロダクトになります。
規模感も結構違いますので、( )でだいたいのスクラムメンバー数を書いてます。
- 4-10末
- 自社開発運営PJ (10)
- 10末-Now!
- 協業開発での受託PJ (30)
この2つは自社開発と受託開発の対極的な環境なので、それぞれでまとめようと思います。
注意事項として言っておきますが、
現在壁にぶち当たっていることもあり現在Joinしている受託PJの方が悪い印象を受けるかもしれません、そこだけご了承下さい。(受託が悪いと言っているわけではない)
自社開発運営PJ
私が、ScMとして初めて経験したプロダクトになります。
このプロジェクトは新卒2年目からバックエンドエンジニアとしてJoinしてたので、仕様や流れもある程度把握してたのもあり、結構入りやすかった印象です。
自由度が高い
PO,PMによるかもですが、自由度が高かったです。自社開発運用なので、ユーザに事前告知等していなければ納期がありません。
スプリントプランニング時点でスプリントバックログを確定させますが、デイリースクラムやリファインメント等でできないものは削ぎ落とせるので精神衛生上は楽なことが多いです。もちろんスプリント内に入れたものはできるだけ完了させることが一番ですっていうのは言っておきます。
また、スクラムメンバー内で何をするか、この時期は何に力を入れるか等を決めていくので、ある程度プロダクトコントロールができます。(ここは人数によるかな？)
スクラムを組みやすい
「自由度が高い」でも言いましたが、納期がないので、納期までの最短スケジュールを引くようなガチガチ計画はやりません。
基本的にスクラムイベントに沿って周期的に開発・改善すること、アジャイル思考の中でPJに合うやり方をしているので、計画→実行ではなく、実行→改善→改善...という手法が納期がないと容易にできます。
なので、スプリント周期を基盤とし、その中でプロダクト価値・メンバー価値を高めることは比較的容易にできると思ってます。(PJ人数やプロダクト規模にもよります)
ScMとしてチャレンジしやすい
自社開発運用であれば、他社の柵もないので、やりたいように改善できますし、動きやすいと思ってます。
このときは、同じPJで1年間バックエンドエンジニアしたこともあり、その時に課題として思っていたことを具現化して提案したり、レトロスペクティブ時に出たものをグルーピングし多い順に議論して改善しようってなったり、初ScMなりにたくさんのチャレンジができたかなと思ってます。メンバー数にもよりますが他社が関わると、全員集まる時間が取れなかったり、他社メンバーの文化/風土に合うかどうかでなかなか決まらないことが多い印象です。
また、開発陣に関しても、新規開発・技術の取り入れが比較的できると思います。受託だと新しい技術を取り入れるためにこのくらいの工数になります。なんて言ったら、それって売上に繋がるんですか。みたいなイチャモン付けてくる場合もあるので、難しかったりしますw
協業開発且つ受託PJ
現在Joinしているプロジェクトになります。
最初からScM/PMOというロールでJoinしたのもあり、プロダクトの理解やメンバー、どういう流れで進行しているのか、どんなPJルールがあるのか、みたいな部分はかなりInputするのに大変だった印象です。
制約が多い
納期という制約があります。受注元はお金を払っているので、あまり時間をかけたくありません。なので、無理な納期を言ってきたりします(全国共通)。なので、納期から逆算してリソースプランニング、スケジュール引いてウォータフォールみたいな形になりがちです。進むにあたってなにかスケジュール上問題があったら。。。と思うことがあるので精神的に強くなれます。
あと、コミュニケーションコストがかなり高くなりやすいです。私の場合は、協業開発且つ受託PJなので、制約上の問題から他社はAツール、受注元はBツール、みたいな事が起きちゃいます。なので、コミュニケーションするときは、AツールでもBツールでも共有・報告しないといけなくなってしまい、結果コミュニケーションコストが高くなってしまいます。報連相強者になれます。
スクラム導入が難しい
納期があるので、スクラムイベントそっちのけでウォータフォールのようにガチガチで進行することがあります。そうなると、スクラムイベントって必要なのか、みたいな話が出てきてPJの仕組みを再整理することになってしまいます。うまいことスプリント周期に合わせてやることはできると思いますが、結構大変です。(受託PJでスクラム導入しているところでうまくいっている企業さんいればお話が聞きたい)
ScMとして改善するするとしても動きづらい
ScMとして、メンバーのベロシティをあげることも1つの主務かと思います。ただ、メンバーの時間や他のタスクをやめて時間を割くのは、成果物が増えても時間を増やしただけで当たり前なので、ベロシティ向上には繋がりません。ですが！！！時間の使い方の見直しも1つの手段です。(もちろん定時内の話です)
じゃあどうするか。無駄な時間、MTGがないか、ルールはこれで良いのか、みたいなところを考えます。
ここで、他社も関わっていると、他社の文化/風土なんかがあって、自社でのセオリーみたいなのが少なからず出てきます。そこを中和して改善するのが難しいポイントだと思ってます。
あと制約上動きづらかったりします。「制約が多い」話でも出ましたが、コミュニケーションツールの統一化をしたくても制約上難しく、要求としての「コミュニケーションコストが少なくなる」手段をもう一度考えたりするので、制約...ってなります。
まとめ
新卒3年目で、2つの対極的なPJにJoinしてみて、いろいろScMとして何ができるか/何をすべきなのかを考えることが多くなりました。
もちろん、最終的な目的としてはScMが不必要になる環境作り (自己組織化) があります。じゃあそのためにこのPJ内はどういうところが課題で、その課題がどこに紐付いていて、どうやって解決するかを考えることを1つずつやっています。
まだScM1年生にも満たないので、たくさんのInputとOutoutをしながら大きな壁を壊して行きたいと思います。
協業先や受注元の関わっているメンバーも一人ひとり自分と同じ人間なので、ジブンゴト化を忘れずに価値を生み出していきたいと思います。
これからもかんばるぞい！