アジャイル・スクラム開発を標準化し会社に導入する

約7年前から今の会社の前の前の会社のときにアジャイル・スクラムが開発メソッドとして会社に取り入れられました。その当時日本からベトナムに駐在で来ていた方がアジャイルコーチを日本でやっていて、ぜひともオフショアでアジャイル・スクラムが開発を取り入れたいとのお話でした。そこからが僕のアジャイル・スクラムとの出会いです。

それから今に至るまでの7年間、様々な開発プロジェクトを遂行する中で1つの懸念が生まれました。それは、スクラム・アジャイルといってもアサインされるメンバーによってやり方や考え方に違いがあるということです。

それによってプロジェクトの立ち上がりに時間がかかったり、アサインされるメンバーのスキルや経験に属人化する形になってしまったりと、プロジェクトの度に同じような問題が起きていました。

そこでプロセスから実際に使用するツールとそのテンプレートなどスクラムイベントに関わるほとんどの部分を社内で標準化していきました。

実際の社内標準化を以下のように行いました。

1. スクラム・アジャイル開発自体を改めて確認
2. 自分たちの開発スタイルの特徴を改めて確認
3. マニュアル化できるところを洗い出す
4. マニュアル化
5. トライ＆フィードバック

1. スクラム・アジャイル開発自体を改めて確認

長年プロジェクトをやっているとプロセス自体に慣れがでてくるので、改めてプロセスを見直すということはあまりしなくなっていました。なので、まず自分たちがいわゆる世界的に標準化されているスクラム・アジャイル開発にちゃんと沿ったやり方ができているかを見直しました。

2. 自分たちの開発スタイルの特徴を改めて確認

開発はベトナムのオフショアなので、日本のチームやお客様と物理的な距離もあれば言語の違いがあります。また、ベトナム側の体制は日本のSESをアサインするような1名、2名が全ての役割をこなすといったやり方ではないので、人数もそれに比べると多くなります。それらの特徴を踏まえフォーカスしたことは社内と社外両方に対しての透明性でした。

3. マニュアル化できるところを洗い出す

そうなってくると自分たちが「誰が何を考えどれくらいの時間で何をやるのか」の部分に透明性をもたせると共に、それらの部分をマニュアル化してしまえば、誰がプロジェクトにきてもある程度のクオリティは担保できると考えました。

4. マニュアル化

マニュアル化はGoogleのスプレッドシートを使って行いました。

そこは特に凝ったことをせずなるべく記入する手間を省くためにも関数を組み込んでもらいスプリントのイベントに合わせて記入、見直し、更新できるものを作っていきました。

実際にどのように標準化されているかはベトナム時代に僕が書いた記事の「アジャイル開発のチームビルディングは３つのポイントと２つのコツ」の中の、「社内全体でのワークフローの基準をつくる」で詳しく書いているのでぜひそちらを読んでみてください。

5. トライ＆フィードバック

マニュアル化したものを各プロジェクトに導入していきました。ただそれだけでは意味がなく正しく使われているかをモニタリングし、また現場からフィードバックを定期的に吸い上げ、常にマニュアルをアップデートする仕組みを作りました。その仕組みをつくることによって、マニュアル化されたものに問題があれば解決のために動くきっかけになり、改善点があればより良くしていく機会になっています。

実際にどのような仕組みをつくったかはこちらの「PMO組織で会社がプロジェクトを横断的に管理する仕組みをつくった」で書いているので読んでみてください。

柔軟性や変化への対応を求められるスクラム・アジャイル開発をオフショアで進めるというのは簡単ではないので、ある程度社内で標準化させるということが重要だと考え実際に取り組みました。

個々が意味を理解し個々で進めることは難しくはないですが、チームとして動くとなるとある程度の統制が必要となります。それは、概念を理解するだけでなく、標準化を行い、それを導入し、モニター＆コントロールする必要があります。そのあたりは会社のメンバーとうまく協力しながら僕がこれまでやってきたことなので何かお役に立てることなのではと考えています。