メールマガジン

お問い合わせ・資料請求

2018年03月07日

株式会社ディーバ

第298回 『スクラム』を始めてみて

CPM事業部 開発統括部 グループ経営システム基盤開発部
マネージャー 小川 崇弘

システム開発におけるスクラムとは

まず、システム開発におけるスクラムですが、以下ウィキペディアの抜粋です。

スクラム (ソフトウェア開発)-序文

スクラム(英: Scrum)は、ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」とされる。~抜粋~

予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくアプローチを採用する。問題を十分に理解することも、定義することもできないので、現れた要求へ素早く対応するためのチームの能力を最大化することに集中する、というアプローチである。』

 

我々のチーム運営

私は、現在の開発チームに1年ほど前に異動し、このスクラムを実践したチーム運営に初めて触れました。

最初に驚いたのは、デイリーミーティングで、全員立ったまま、一人一人、昨日・今日行ったタスクを話すというものでした。当時のチームの人数は、10数人だったかと思います。ミーティングは、30分かけないことを目指し、報告だけなら15分程度で終わるものでした。

現在、「立ったまま」ミーティングするかどうかは、ミーティング主催者に任せていますが、私が参加しているミーティングのほとんどが、「立ったまま」かつ「オープンスペース」で開催となっています。

とにかく、「立って話す」というのが驚きでしたが、報告するだけであれば、かしこまって「座る」より、「立つ」方が身振り・手振りも入って、ミーティングが盛り上がりやすいかなと思います。また、全員の目線が高いのも何かしら要因があるかもしれません。

そして、これと併せて、以下のタスク管理を実践していました。

それは、会社・事業部が目指すべきゴールと、各メンバーが日々実践していくタスクとの関係性を、明示化しようとするものでした。

具体的には、①まず開発部長が、経営陣及び事業部長と、Fixした製品開発ロードマップ(数年単位)を、メンバーが分かるストーリーと優先順位を付けて、最初の階層とします。

②次に製品オーナーが、この「①」を実現するために、四半期程度で実現しなければならない、具体的なストーリーに分解し、優先順位を付けます。

③そして次に「②」をチームリーダーが、1~2週間で実現する具体的なストーリーに落とし込み、メンバーをアサインします。

④最後に各メンバーは、「③」を実現するための、日々行うタスクを書き出します。

これで、経営陣と認識があった事業部・部門のゴールと、日々メンバーが行うタスクがつながります。また、各階層のストーリーに対するオーナーの優先順位も明確です。

このうえで、これが絵に書いた餅とならないよう実現すべく、といっても、時間とリソースは限られていますので、以下のタスク見積もり・調整を実践しています。

まず各メンバーが、例えば1週間のうちで、メインタスクに割り当てられる現実的な時間(例:1日の実稼働6時間×5日=30時間)も宣言し、「④」で、メンバーが自身で作成したタスクに対して、時間単位の概算見積もりを宣言します。そうすると、見積もったタスクがこの1週間で、どこまでできるかが分かります。

ここまでの情報が揃ったうえで、チームで集まって、次の1週間でチームでやるべきタスクを、『全員』でプランニングします。なお、このプラニングも、全員立って実施しています。

この際、大抵見積もりを超えますが、その場合も優先順位が付いているので、優先順が低いものから次回に回して調整します。最優先のものだけになっても見積もりを超える場合は、他チームとリソース調整し、それでも足りないなら、部長にエスカレーションして、上位ストーリーの優先順位の変更となります。その際、各階層のストーリーに対するオーナー、優先順位、タスクとのつながり、が明確なので、話は比較的スムーズです。

この計画のうえでも、日々の突発事項は誰にも予測できません。メンバーの休みなどもそうですし、上位層からストーリーの調整が入ってくることがあります。

ここで話は最初に戻って、デイリーのスクラムミーティングで、チームリーダーは日々のメンバー・チームの状況を把握できますので、そのうえでストーリーと優先順位に沿って、各オーナーと日々調整できます。

 

あらためて気づいたこと

長々と書きましたが、目指していることはとてもシンプルです。

それは、メンバーが、その組織・チームで働くことの意義=お客様へ提供する価値を継続的に実感できる状態の構築です。これにより、お客様により良い価値が提供できると信じています。

それを実現しているポイントは、以下の通りです。

・組織目標=お客様へ提供する価値と、メンバーのタスクとの関係の明示化

・その関係における各階層のゴールのオーナー、ストーリー、優先順位の明示化

・上記を元に、日々(個人ではなく)チームで、「立ちながら」、見積もり、調整を行う環境

言われてみれば、当たり前のことですが、明示化・継続となるとなかなか難しく、私も以前そうでしたが、リーダーが管理作業と並行して開発作業も行っていたことで、上記の1つが欠けて、現実と乖離して、回らなくなる=使わなくなる、という状況だったと思います。(よくあるケースかと思います。)

現在のチームでは、開発リーダーが開発作業に従事せず、上記の管理作業に専念しているので、徐々に良い方向に回りはじめていると思っています。

 

我々が提供すべき価値

我々はお客様に、経営判断に役立つ情報を提供すること、を目指しております。私個人の解釈として、経営判断=組織目標に向かったアクションに直結するもの、と考えています。

そして、我々が提供する情報は、まさにそのアクションに直結し、組織目標への関連が明示化されているべきものだと考えています。

私の部門は、この目標に向かった製品開発を担っておりますが、前述のスクラムを利用したシステム開発にヒントがあるのではないかと考えています。

まだハッキリした答えはでていませんが、真に「経営判断」に貢献するための製品を開発すべく、日々精進して参りたいと考えております。

 

ご精読ありがとうございました。