スクラム経験のない私が入社したてで大型案件を任せてもらった話

はじめに

はじめまして。こんにちは。
エス・エム・エスキャリア プロダクト開発部の中嶋と申します。

今回は、去年の4月に入社してすぐに任せて頂いた大型案件をリリースするにあたって、大事だと感じたことをつらつらと申し述べさせて頂こうと思います!
これを読んだ方に少しでも弊社でのシステム開発の雰囲気を感じて頂ければ幸いと思います。
(これより今回着手した大型案件を仮に「提案システム」とさせていただきます。)

ちなみに、これまでの経歴の中でスクラム開発経験もチームマネジメント経験もないわたしです。
大変でした。
ですがその倍以上、自分の身になった経験ができたと思います。

結論から

スクラム開発やチームマネジメントをしたことがないなかで、約1年の経験を経て大事だと感じたことを述べさせていただきます。

まず第一に「チームメンバーとの関係性とチームの雰囲気!!!」これ絶対。
自分とチームの関係が良くなければなにかあったときに仲裁することも助けてもらうこともできません。
さらにチームがやらされてると感じたら、確実にいい成果は上げられないと思いました。
そのため私は、チームメンバーが助け合いのもとに主体的に考え物事を達成できる、ようなチームにしたいと思い、下記のことを意識してチームマネジメントを行いました。

  • メンバーの意見に対して否定的な言葉で返さない。
  • どんなチームにしたいか。を伝え、メンバーの想いを聞く。
  • 自分のタスクやメンバーのタスクの共有を常々行う。
    →これは人のタスクを他人事だと思わないよう意識するためとても大事です。

そうすることで「意見が言いやすい」、「共有することで困ってる人を放っておかない」環境を実現できたと思います。
また、メンバー同士の考え方や意見がわかっている分、自然とチームの雰囲気もよくなりました。

おかげでチームメンバーにも恵まれ、仲良く、怒られながら、わいわいと助け合いながら開発することができました。

第二に「ゴール設定とその伝え方」です。
ゴールはなにか。なにを解決したいのか。
それがわかってないと自分達で考え、よりよい成果物を出すのは無理だと思います。
そして物事を伝えるときはあやふやな言葉では伝わりません。
わからないことをなんとなくで答えてしまう、伝えてしまうと人は混乱します。

そのため、

  • インセプションデッキ
  • エレベータピッチ

を意識して伝えことで、問題と原因を理解して頂けるよう努めました。
上記を認識できることで、ゴールと解決策を意識してタスクに向き合うことができるようになると思いました。

上記2点さえ守っておけば力を合わせればなんとかなると思っています。
大丈夫!できる!!

1.大型案件を持つことになるまで

それはそれは古い昔(2~3年くらい前)、とある企画部の方が新規案件を思いついたそうです。
ですが、工数もかかれば割ける人員も限られていました。
そのため我らがプロダクト開発部の方々も着手に踏み切れずにいたようです。

そのような日々が続いていた中、段々と開発部の人数も増えてきて、「そろそろ着手できんじゃね?」というタイミングでわたしは入社致しました。

入社後一月は、チームに社員がわたし一人しかいなかったこともあり、Gr長の手厚いフォローを受けながらチームマネジメントを行っておりました。(業務委託さんは5人ほど)
運用タスクとのバランスを見て、「着手待ちとなっている案件を進めていいよ」とのことだったので、調子に乗って「提案システム」をやりたいと声を挙げさせて頂きました。

なぜか2つ返事で承諾を得ることができました。
「あれ?不安なのは自分だけかな…?? ちゃんとできるかな….???」

2.開発要件を定めるにあたって

最初に述べておくと、私の力及ばずスケジュールを当初の予定より遅延させてしまいました。

「提案システム」を着手すると決めてから、企画部の方と期限や開発要件を決めるためにMTGを行いました。
まだ業務知識もなく理解できないところもたくさんありましたが、Gr長がフォローに回ってくれることで開発要件は思うよりすんなり決まったと思います。

ですがここで問題が発生しました。

「スクラム開発とはなんぞや??」

急いで参考書やセミナーに頼りました。。。
ですがこの点に関しては、必要があれば業務時間中にセミナーに行くことも許可して頂けたおかげで効率よく学ぶことができました。

スクラム開発に関する記事はこちら

当初はマネジメント経験がなく、ウォーターフォールでの開発しか行ったことがなかったため、小規模開発やPDCAを回すと言った考えがありませんでした。
そのため、
「決められた期日にどれだけのことができて、最低限なにが必要なのか、そして目指したいゴールはなんなのか」
また、「なぜこの課題が生まれたのか、なぜそれを解決したいのか」
を全く考えず、相談もせずチームにタスクを下ろしてしまいました。

チームに対してはこれらを連携することでより理解を深めてもらえることを実感しました。

(タスクはホワイトボードを使って管理していました。)

3.開発を進める中で

開発に着手できる段階になり、次の問題に行き当たりました。
スクラム開発を行ううえで

  • スプリントバックログ
  • スプリントレビュー
  • リファインメント
  • 振り返り

等のやり方が確立されていませんでした。

幸いチームメンバーにスクラム開発の知識に明るい方がいらっしゃったため、みんなでスクラム開発の基本的な形を学ぶことから始めました。
そこから徐々に振り返りで問題点を挙げ、次のスプリントの改善を行っていきました。
ここでチームの雰囲気や発言の自由性の重要性を実感しました。
一人の発言力が強かったり、誰も発言しないチームでは改善はありえないとまで思います。

チームでの討論が暗礁に乗り上げたら、私が決定権を持てばよいと思っていて、それまでは自由討論のもと決定を行えばいいと思っています。
ファシリテーターなんて誰でもいいし、決まった人が行わなくてもよいのです。きっと。

(この回の振り返りのファシリテーターを絵しりとりで決めていました。)

そしてチームとしてスクラム開発を学んでいくうえで、開発者に「提案システム」のエレベーターピッチやインセプションデッキを理解して頂けていたことが大きく役立ちました。

ベストな形でのスプリント期間や叶えたい目標に少しでも近づくようなチーム体制を、都度チーム全体で考えることができたと思います。

幾度も壁に阻まれましたが、都度他チームの仲間やGr長が相談に乗ってくれたり、1on1を行いアドバイスをくれたことにより、なんとかリリースすることができました。

最後に

開発手法に「これでないといけない」という形はないと思います。
特に弊社では上から押さえつけられることはありません。

事業的な目線でタスクを考える必要はありますが、
「やりたい!」をできる限り叶えてもらえます。
そして「やりたいこと」に対するフォローや責任も一緒に請け負ってくれます。

どうかこれをもとに弊社を身近に感じて頂けたら幸いと思います。
長くなってしまいましたが、ありがとうございました!!

Pocket
LINEで送る