アジャイル経営を始めてスクラムで管理したらいい感じになった話

長年アジャイル開発に携わっているんですが、ここ最近は「スクラム」と呼ばれるフレームワークに沿って進める仕事のやり方に体が慣れてきたんですよね。

スクラムにはスプリントと呼ばれる工程の反復単位があって、自分がいま関わっているプロジェクトでは火曜日開始の月曜終わり1週間が１スプリントとして定義されています。

そこでこの体に慣れた仕事の進め方を、そのまま経営タスクの進め方に流用できないかなとふと思って、「アジャイル経営」について自分なりに定義して実践してみたのです。

アジャイル経営を独自に解釈して実践

アジャイル（agile）とは不確実性な物事に対して、短いサイクルを回して改善し柔軟性を持って対応するために考案された開発手法です。

元々はソフトウェアにおける開発手法で、顧客のニーズにより早く最適化することが目的なんですが、経営においても同じような考え方で物事を捉えることができるはずです。

とはいえ仰々しいことを考える必要もなく、ただ単純にスクラムの流れに沿って仕事を回していくというところからでも良いのかなと思っています。

経営タスクをバックログ化

まずは「第○○期３Q 経営課題」など大きくEpicを作って、実現したい内容を計画していきます。

それぞれのEpicに対して必要な課題をバックログとしてJiraチケットに起票して、まずは見える範囲のところから計画スプリントを回していきます。

他にも細かな事務処理や毎週追いかけたい数字の管理などを「定常タスク」として起票して、それ以外にイレギュラーで発生するタスク用に「割込みタスク」としてバックログ化しておきます。

自分の場合は経営課題や営業/マーケティング課題、総務や経理などのバックオフィス課題など、会社の役割によってEpicを大まかに分けて管理をしています。

人数が増えてきたらEpicを各部門ごとに切り分けて、別プロジェクトとして管理しても良いのかなと。

＼ Jiraでバックログ管理！ ／

ベロシティを決定してポイント見積もり

次にスプリントごとにこなせるベロシティ（スプリントで処理できる作業量）を決めて、おおよその工数を定義していきます。

ストーリーポイントはタスクを完了させるための工数を指標化したものですが、ここではお試しで始めてみるのが前提なので定義はざっくりで良いかと思います。

リサーチ系のタスクは３ポイントとか、単純な事務作業は１ポイントとか目安を決めて、それぞれフィボナッチ数列（1, 2, 3, 5, 8, 13, …）を使ってサクサク入れていきます。

進捗はバーンダウンチャートで確認

バックログの完了とストーリーポイントの消化状況は、バーンダウンチャートで追っていきます。

綺麗な形で徐々にタスクが消化されていくのが理想ではあるのですが、パーキンソンの法則然りバックログがギリギリまで完了できないことが多くて課題感があるんですよね。

完了基準を明確にしたり、サブタスクを細かく切ってタイムボックスでタスクを終わらせるなど、現状の進め方にも改善の余地がありそうだなと感じています。

管理はJiraじゃなくてもいい

スクラムを管理する際にJiraというプロジェクト管理ツールを使うと便利ではあるんですが、使い慣れていない場合はスプレッドシートや別の管理ツールでも代用は可能です。

自分の場合は長年Jiraを使ってきたので使い慣れているのと、10アカウントまでは無料で使うことができるので今のところこれがベストな選択肢になっています。

他プロジェクトではNotionでスクラム管理してたこともありましたが、スタートアップにはむしろNotionの方がおすすめかもしれません。

自社内で開発もやっていて不具合の管理や分析などもやりたい人にはJiraがおすすめですが、あまり使い慣れていない方にはややオーバースペックなので、直感的に使えるNotionの方がやりやすいでしょう。

＼ スタートアップにおすすめ ／

経営スクラムイベントを設定する

1サイクル（スプリント）を1週間でも2週間でも良いのですがまずは設定して、それぞれスクラムイベントを決めていきましょう。

スクラムイベントにはスプリントプランニングやレトロスペクティブなど、目的によって様々な会議体を設定していきます。

基本的にスクラムイベントはチーム単位で実施するのですが、まずはボードメンバーだけとか経営者が１人で小さく始めてみるのも良いのではないかと思っています。

最初は形式にこだわらずにイベントを設定し、「このタイミングで振り返りを行おう」など目的を重視して実施してみるのが良いでしょう。

スクラムイベントの設定と目的

ここでは主要なスクラムイベントについてざっくりと説明していきます。

スプリントプランニング（Sprint Planning）

スプリントの開始時に行われる会議で、チームが次のスプリントで何を達成するかを計画します。スプリント中の作業の優先順位を明確にし、チームが共通のゴールに向けて取り組む準備を整えます。

デイリースクラム（Daily Scrum）

毎日行われる短い会議（通常15分以内）で、進捗や課題を共有します。現在の状況を把握し、問題解決を迅速に行うことで、スプリントゴールに向けた進行をサポートします。

スプリントレビュー（Sprint Review）

スプリントの終了時に行われるイベントで、プロダクトオーナーやステークホルダーにインクリメント（完成した作業の成果物）を見せ、フィードバックを得ます。

スプリントレトロスペクティブ（Sprint Retrospective）

スプリント終了後に行われ、チームがそのスプリントのプロセスや協働方法について振り返ります。プロセスやコミュニケーションを改善するためのアクションプランを策定する場となります。

バックログリファインメント（Backlog Refinement）

バックログのアイテムを洗練し、詳細を追加したり、複雑すぎる項目を分割したりすることで、次のスプリントで扱いやすくします。スプリントプランニングをスムーズに進める準備が整うため、スプリント内での作業がより効率的に行えます。

開発スプリントに合わせると良い

もしも既に開発スプリントが回っているのであれば、基本的には同じサイクルに合わせて経営スプリントを回すのが良いかと思います。

自分が実践していて体が慣れているというのもあるかもしれませんが、スクラムの仕組みに会社のフローを合わせることで効率的に業務を管理することができています。

またスクラムイベントについては実態に合わせて最適化するのが良いかなと思っていて、今の経営スクラムはほぼ自分のみで管理しているのでデイリースクラムなどはやっていません。

複数人でそれぞれのバックログを進行させていく状態になったら、デイリーもやっていきたいですね。

アジャイル経営をやってみた所感

まずは経営課題を中心にEpicを立てて、やっていきたいことをバックログ化して進めています。

１スプリントでできることも限られているので、大きめの課題はStep1やStep2などのようにスライスして、基本的にはベロシティに収まるように計画するのがコツです。

またそれぞれのバックログに対して細かくサブタスクを切っていき、Goalを明確にすることで進捗を進めやすくするなどの工夫をしています。

アジャイル経営の良い点

まず１点目は経営課題など具体的にどう進めて良いか迷いがちな問題に対して、バックログやサブタスクに起こすことで整理されて物事が進めやすくなります。

また１スプリントごとに成果物や完了基準を満たすようにタスクを進めることで、アバウトに進めがちな経営課題や施策に対してケツを決めて動くことができます。

「いつまでにやろうかな」ではなく１スプリントでできることを積み上げていき、それらの途中経過を踏まえた上で方向転換をしたり、そのまま進めていったりと適宜その場で判断することができます。

特に仮説をベースに組み立てていく経営課題などに関しては、バックログの振り返りで間違っていたなと思った際に、バッサリと施策ごと捨てるための判断材料にもなりえます。

アジャイル経営の悪い点

アジャイル経営を回し始めて難しいなと感じたのが、ストーリーポイントの設定です。

開発のように目にみえる具体的なプロダクトがあるわけでもなく、作った資料や方針などを成果物としてみなすことが多く、各バックログのGoalの設定が難しい点が挙げられます。

またベロシティに対しても当初の予定より上振れしやすく、消化しきれないバックログが溜まってしまったり、成果物に対してもこれくらいのもので良いかと妥協してしまうなどの課題が見えてきました。

今後改善していきたい課題について

10スプリントくらい回してみたところで、バックログの課題によってストーリーポイントの目安も掴めてきたので一度仕切り直しをすることにしました。

またバックオフィス業務や会社経営に関わるタスクの全量をバックログ化したことで、定常業務が大きくなってしまいポイントが積めなくなってしまったので、一旦過去に作ったバックログは捨ててプロジェクト単位で作り直しました。

まずは最低限消化できる範囲でベロシティを設定して、スプリントを回しながら改善していきたいと思っています。

アジャイル経営について今後の展開

というわけで思いつきでアジャイル経営を始めてみたものの、思ったよりもワークすることに気づいたので今後の展望も書いていきたいと思います。

今の自分の会社は少人数でやっているのでシンプルにスクラムを回せているのですが、人数が増えてくるとコミュニケーションラインの整備や役割の明確化などが必要になってきます。

経営者としては長くやってきましたが、こういう形で組織をスケールさせていくやり方は初めてなので、手探りでやっていくことにはなりそうです。

管掌範囲ごとにプロジェクトを分ける

今は営業やバックオフィスのタスクなども含めて1つのプロジェクトで管理していますが、それぞれの管掌範囲ごとにプロジェクトを分けるのが適切かなと思っています。

プロジェクトを切り出すタイミングがどこかはまだ見えていませんが、組織化して管理者をおけるようになったら判断して良いのかなと思っています。

その場合はバックオフィススクラムのような形になるかもしれませんし、権限や取り扱う情報もあるので経理や財務などは別にするなどの工夫が必要になるかもしれません。

Scrum@Scaleの考えを取り入れる

組織が大きくなるにつれて今のような単純な管理方法では上手くいかなくなるのが見えているので、スケールするための仕組みを取り入れる必要があります。

その際にScrum@Scaleの考え方を踏襲して、管掌範囲ごとに管理者が集まるスクラムオブスクラム（SoS）を組成して拡大していこうと思っています。

ただし、今の開発プロジェクトでもMetaScrumとか、Executive Meta ScrumやExecutive Action Teamとか色々とあってカオスだったりするので、無理に拡大していくのもなんか違うのかなと思ってたりします。

オンボーディング資料を整備する

アジャイル経営なのでスクラムで仕事を回してますなんて言っても、開発でスクラムを経験したことがない人からするとなんのことやら訳がわからないですよね。

なので新しく入ってくる人用にオンボーディング資料を用意するのは必須だと思っています。

というかバックオフィスなんかは無理にスクラム化する必要性もないと思うので、経営領域や営業領域だけとか限定して最適化していくのが良いのかもしれません。

もしくはスクラムがわかる人だけを採用していくとか、この辺は方向性を考えならが会社文化を作ってきたいですね。

アジャイル経営のまとめ

少人数でスクラム開発を回しているスタートアップなどは、考え方や仕事の進め方をそのまま経営タスクにも流用できるのでハマるんじゃないかなと思っています。

また、この記事はアジャイル開発を既にやっていて、スクラムの流れが一通り分かっている前提で書いてしまっているので、補足説明や実際の運用状態なども適宜図式化していきたいなと。

これからはアジャイル経営だなんて言うつもりも一切なく、今のところ自分にはしっくりきているので、もし自社にアジャイル経営を適用してみたいと思っている人の参考になれば良いかなと思って書いてみました。

一部、アジャイル経営を独自解釈して自社の運用に最適化している面もあるので、その点はご了承ください。