ProjectManagerからScrumMasterになった話

SIerにいた頃の話をいくつか投稿しようと思います。
今回は、SIerの典型PMに疑問を持ち始めSMになった話を書きます。
Scrumとは？とかScrumMasterのタスクの具体的な話には触れてません。導入までの経緯と具体的なissueなどを書きます。

ハイライト

1章　PM編：受注と発注の向き先の違い
2章　SM見習い編：Scrum導入の話に超絶立候補
3章　SM苦労編：受注・発注・マルチベンダのワンチーム
4章　SM超越編：同じ方向

1章　PM編：受注と発注の向き先の違い

SIerとして10年弱経ち、相応の規模のPMも任せてもらえるようにもなりましたが、プロダクトやサービスの進化が目的となる発注側と、プロジェクトのQCD（品質、コスト、納期）が目的となる受注側の向き先の違いに違和感を感じてました。

SIerの仕事は基本的にはシステム構築部分を担当するため、発注する事業側とは会社としての目的も個人個人の評価材料も異なるのは自然でした。
とはいえ、同じGoalへすら向かっていないこの状況に違和感抱きまくりな状態で、自分としては事業サイドのプロダクトやサービスの成功にコミットしたいものの、そこに直結しないプロジェクトのためのタスク（そんなクリティカルな要素じゃない機能の品質担保に工数かけるとか）が死ぬほど無駄に思えてました。

2章　SM見習い編：Scrum導入の話に超絶立候補

そんな中、発注サイドの重鎮も似たようなことを考えていた経緯もあり、Agile手法のひとつScrumをやってみないかという話がきました。Scrumとかって実際導入するときどんな感じで選定するのって話って結構あがると思いますが、自分の現場の場合のリアルはこんな感じ。

課題：思いついてから世に出すまでが遅すぎる
　ステークホルダ、仲介業者的な存在が多く、伝言ゲームが半端ない
　CS向けサービスにおいてスピードがでないことは対競合に対して致命的

課題に対してのアプローチ経緯：受注サイド（SIer）に投げる
　速くしたい、なぜ速くできないのかと詰める
　SIerサイドはそれなりのロジックがあり、謎のDisりあい　NO幸せ

ブレークスルータイミング：課題認識力と対策実行権力を持つ人出現
　事業サイドの役員人事により、システム開発に長けた方が一気に解決（今回の場合は無駄を省くプロセス、一体感を出すチームづくり、という意味でScrumを選択）に向けた方針をGrip

こんなところでしょうか。もともと事業サイドとのゴタゴタと、自分の違和感も含め色々もやもやしてたこともあり、このブレークスルータイミングでこのキーマンにのっかって推進することを決意しました。

ScrumMasterの勉強の仕方

一度、この事業は独自のAgile開発を定義して推進していましたが、独自流すぎて「課題解決事例」や「普通どうする」みたいなものがなく、広めることに苦労したという経緯もあり、ある程度本流であるScrumがチョイスされたという経緯もあり、本流の講師に認定のScrumMaster研修をお願いして皆で受講しました。
※ちなみに研修ではPMです、っていうとめっちゃ怒られいじられます。

後になって思うと、この研修でみんなで学ぶフェーズにおいて、受注サイドも発注サイドも役員レベルまで含めてみんなで一緒に受けたのは結構効果的だったと思ってます。（研修中は役員にマジで緊張するけどw）

3章　SM苦労編：受注・発注・マルチベンダのワンチーム

というフェーズをへて、ついにScrumチームが結成！
PO1名、SM1名（僕）、Dev6名という構成でしたが、最初は上手く成立させるためにPOにはサポートメンバがついたり、運用チームは別で作ったりしました。

ここの立ち上げ編は死ぬほど思い出があるのですが、いくつか発生したissueをピックアップして思い出としてのせます。

１、バックグラウンド違いまくる集合体問題

事業プロパー、事業パートナー、SIerプロパー、SIerパートナー、違うSIerのメンバーといった感じでワンチームで同じ目的へ進め！という状況で始まったので、大事にするもの、スキルレベル、働き方など全然違いましたw
比較的スキルやモチベーションは恵まれたチームだったなあと思いつつもそれでも一つの同じ方向を向くのは辛かったです。

やったことは、ひたすら話す場をつくる。思えば事業も開発も全く同じロケーションで仕事するのって僕も初めてだったので、この利を活かさない手はない！というのもあり、序盤は開発時間削ってでもワークショップしまくりました。ワークショップの内容なんか極論どうでもよくてとにかく思いを言えればいいかなと。レトロスペクティブだけは結構工夫してやってた記憶がはるかかなたに。

２、連携システムはScrumじゃないよ問題

これもあるあるだと思うのですが、それなりな規模のシステムになるとそこをとりまく連携システムがめっちゃあります。このサービスもそうで、しかも自分のチームだけScrum導入してたので（他はウォーターフォール）、開発のサイクル、リズム、考え方があわない。もともと僕はWFサイドの人だったので謎に裏切り者扱いされたりもしてw

これに関して言うとScrumMasterの見せ所だった気がします。結構はじめはマジで喧嘩、というか深いコミュニケーション（いや、喧嘩だなw）をとるところからはじまり、自分たちの進め方も伝えてどこをどう妥協するかを話してました。そもそもが、世に出すスピードを速くしてプロダクトをよくするためのScrum導入実験なので、そこを折れすぎると実験にならない、という謎の使命感で嫌われ役をやってました。ただ、意外とその行為でチームメンバからの信頼は得た気がします。

３、チーム再編成多いよ問題

これはもう事業によると思うんですが、自分がいたところはメンバもよく変わるし、異動も多いし、新入社員も入るしってところで、一度つくりあげたチーム内の空気がどんどん変わっていくケースは多々ありました。

これはむしろポジティブにとらえる、ですね。多様性を尊重して１からまた話す場をつくるってことをトライしていた気がします。スクラムマスターをやったのは結局キャリアで2年半くらいでしたが、こういったスキームにおいて型なんてなくて、いまチームにいるメンバでできる最良のやり方をみつけるのがいいんだろうなって思ってます。

4章　SM超越編：同じ方向

そんなこんなでScrumも慣れてきた頃、トップダウンで納期必達目標達成型のお達しがきます。
この記事を読んでいると言うことはScrumやAgileをある程度勉強されてる前提だと思うんですが、納期にコミットしないのがScrumだったりするので、なかなか葛藤はありました。（僕以外のメンバーも）

Sprint期間を１週間にしたり、他チームもScrumにしていったり（他の記事にする予定）しましたが、残り2日間で後数アクションだけショートしそうな状況になりました。

その時、チームメンバーで会議室集まって、2時間以内に実装からリリースまでできて効果がありそうなItemは生み出せないか、というワークショップをして実際にリリースし、そのうちの１つの施策があたり、最終日に目標達成できた瞬間は結構今もキャリアハイな感覚です。

・自分の疑問だった何のためにシステム開発してるか、がクリア
・それをチーム全体で同じ方向を向いた状態で実現できた
・Scrumなんてただの手段であり、そんなの飛び超えてトライできた
・ひいてはこんなチームに導けたスクラムマスターすげえ！（俺）

ということで、かなり長くなってしまいましたが、自分が経験できたScrumMasterへの進化でした。