とあるチームの開発サイクル ~ ウォーターフォールからアジャイルなチームへ

とあるチームの開発サイクル ~ ウォーターフォールからアジャイルなチームへ

with コメントはまだありません
ホワイトボード_アジャイル

BS事業部の成田と申します。
Webサービスを運営されているお客様の元で開発のディレクターをやっています。
今回は私が関わっているプロジェクトでここ1年近くで起こった変化についてお話ししたいと思います。

 

ウォーターフォールでのプロジェクト遂行をしていたチームが環境の変化により開発スタイルやプロジェクト管理という仕組みからアジャイル(※)なチームに生まれ変わることが出来ました。
※ここでは開発のプロセスではなく、チームの概念がアジャイル(素早い、機敏な)というスタイルに適用されていることを指しています。
それはなぜか?
以下の4つのポイントが要因となっています。

1. 変化-社内から常駐へロケーション移動

全てはここから始まりました。2015年の1月。
 
アプリ基盤の再構築という大規模開発後、今後の開発サイクルを短縮したい、
コミュニケーションロスを解消したい、障害時のリアルタイムな状況の把握がしたい…
などのお客様の思いからプロジェクトメンバ全員が常駐する契約へ切り替わりました。
エンド直系のプロジェクトのため、そもそもお客様と直接やり取りはしていたがロケーション差異があったため、見えない所や誤魔化しが効く所があったのは正直否めない所でもありました。これはトップシークレットです(笑)
 
このまま常駐して良いものか…一抹の不安を抱えつつ、プロジェクトメンバは常駐での開発を開始することとなりました。
 
しかし、不安は杞憂に終わりました。
お客様側が望んでいた課題の払拭は私達にとっても課題となっていたことでした。
これが、対面でプロジェクトを進めることで今まで以上に円滑に案件遂行が出来るようになりスピード感が増すこととなったからです。
 
結果、お客様が期待していた効果や私達が感じていた今までの溝がみるみる内に埋まっていきました。
関係性もより親密になり、システムだけではなく業務側の関係者も開発に携われる様になったことから開発のスタートダッシュが促進されるようになりました。
 
【環境の変化は人の意識を変える!】

2. 改善/効率化-お客様とメンバの意識から

ロケーションの変化により関係するお客様、プロジェクトメンバの意識にも変化が現れました。
お互いに「より良くプロジェクトを進めるには…」という思いが近くにいることで温度感を増したことが背景にあります。
これを機に、PLが各案件をコントロールしていた所をメンバ自体に権限を委譲し、より柔軟に自由度を持って案件遂行できるように開発の計画を割り振るようにしました。
当初は今までのやり方や発想に固執してしまうこともありましたが案件をこなすことでチームとしての統一性や、自分だけではなく関係者に対し常にギャップが発生しない様に情報共有を徹底することで認識齟齬をなくすことに努める様になりました。
 
これは運用面での改善にも効果がありました。
システムリリース時の手順の不手際などが度々発生していましたがこれが改善される運びとなりました。
私達は手順書を改めて見直し、且つ手順書をもとに2名以上で遂行するように制度を設けることにしたのです。
結果、経験や慣れに依存せず「全員が同じようにリリースをする」という作業が確立されリリース時の無駄な失敗が解消されることになりました。
 
同じ様に、今までは思い立ったタイミングで実施していたチーム内でのソースレビュー会や
見積もりチェック会も定型的に実施するようになり、
品質改善、システムの安定性にも繋がっていくこととなりました。
 
【変化に乗じて改善のアクションや効率化に挑戦しよう!変化に慣れる!】

3. 課題-自由と制約の狭間

順調に見える開発サイクルですが、反面、私達がお客様側に近くなったことでこれまでかかっていなかった部分での負荷がかかるようにもなりました。
それは開発だけではなく、案件のディレクションにかかる負荷です。
 
原因は何か?
これは常駐したことで、直接ヒアリングや課題改善の提案、要望をキャッチアップできるようになりましたがその交通整理を自分達で負担するようになったからです。
お客様側のシステム担当はあくまでも承認者でしかなく、案件の遂行や計画、調整事項などは全て私達プロジェクトメンバに降りかかるようになりました。
 
一見、問題ないようにも聞こえますが、本来見込んでいる作業範囲、言ってしまえば契約の範囲を越えたサービス/サポートをしているとプロジェクトメンバも感じるようになってきたことが背景にあります。
一長一短でもありますが、モチベーションにもかかるだけに軽視は出来ません。
開発の遂行をすることでの事業貢献なのか、
全体をサポートすることでお客様自身の負荷を下げることが事業貢献なのか。
これは私達が一つ上のステージに立った証でもあるのかも知れないと思いました。
同時に、期待する役割や私達が担うサービスが成長した現われなのかも知れません。
(偉そう 笑)
 
【課題があるのが問題ではない!常に発生する課題をどう改善していくかが大事!】

4. 改善-ナレッジ化とサイクル化(文化の形成)

この様な経験、出来事を経て、私達は現在もより良く開発をしていくにはどうするかについてお客様と一緒に取り組んでいます。
システムの保守をしていると、どうしても俗人的な面が出てきます。
このような問題に対しては、手順書の様にナレッジ化しておくことで情報の引き出しを作っておくように努めています。
当たり前のことかも知れませんが、私達はそれが出来ていませんでした。
そして実際に実施したことで結果が得られました。
手間を惜しむのではなく、目的が何か。常に考えるようになりました。
 
そしてこのサイクル自体を止めない様に、適宜朝会やチーム会といったコミュニケーションの場を設け、それぞれの課題や不満、そして挑戦してみたいことなどメンバ間で共有し合うようにしています。
これも一つの習慣、サイクル化してきたことで意見交換が活発になりました。
お客様も同様です。立場などに左右されず、それぞれが言い合える環境が作れました。
サイクル化がゴールではないですが、道筋が見えることで目指すものが共有され、明確に突き進むことが出来るような文化が出来てきたと感じます。
 
【文化が出来ると人が栄える!つまり、システムも一緒に栄えていく!】

まとめ

つらつらと長くなりました。
最後になりますが、今回の話を要約すると以下になります。
(書いてありますが 笑)
 

  • 環境の変化は人の意識を変える!
  • 変化に乗じて改善のアクションや効率化に挑戦しよう!変化に慣れる!
  • 課題があるのが問題ではない!常に発生する課題をどう改善していくかが大事!
  • 文化が出来ると人が栄える!つまり、システムも一緒に栄えていく!


 
これらを踏まえて私達はお客様と一緒に変わっていくことが出来ました。
とはいえ、開発のプロセス自体がアジャイル開発(cf.Scrum)ではなかったりとまだまだプロジェクトを良くするための模索中でもあります。
 
課題解決や改善など全てを同時に実践していくことは難しいですし、何より環境や関わっている人はそれぞれ違うと思いますので一概には言えませんがまずは簡単な事から変えていく。そんなちょっとしたアプローチがきっかけでチームは変わっていくことが出来ると思います。
 

以上、ありがとうございました。

成田
Follow 成田:

株式会社システムサポートに2007年中途入社、千葉県出身。 Web系を中心にシステムの上流~下流工程から ちゃっかり業務運用/ヘルプデスクなども経験し今に至る。