ガチガチなルールは機能しない　社外の組織を巻き込むため、大事にしたのは文化とコンセンサス

2025年03月14日 12時00分更新

文● 大谷イビサ　編集●ASCII　写真●曽根田元

提供: ヌーラボ

ツイートする
一覧
お気に入り

　多くのSaaSに共通なユーザーへの浸透や定着の課題。プロジェクト管理ツールのBacklogではどのような知見があるのだろうか？　BacklogのユーザーグループであるJBUGにも登壇するヘビーユーザーであるピー・アール・オーの河野千里氏とフィラディスの高木俊輔氏に導入・定着ノウハウを聞く取材の後編。前編は導入がテーマだったが、後編はBacklogの効率的な運用や社外の取引先との連携について聞く。

「課題の粒度」「課題が終わらない」「使い方ばらつく問題」をどうする？

大谷：前半ではおもにBacklogの導入や浸透についてお話しを聞いてきましたが、後半では運用と社外との連携についてお聞きします。運用の困りごとやハードルはどのように解消していきましたか？

高木：Backlogでよく言われる「課題の粒度」に関しては、部署によっては細かくしすぎたり、大きくしすぎたりして、その塩梅にみなさん共通して苦労していました。これも適切な大きさにできるよう、アドバイスしていきました。

大谷：具体的にはどうしたのですか？

高木：たとえば、今までは同じ業務の中で5つのToDoがあると、粒度が細かすぎて追いにくいところがあります。でも、Backlogは課題の中にチェックボックスが作れるので、1つの課題の中で管理できるようになりました。

あとは、「課題が終わらないと」いう問題です。コメントのラリーが続いて、結局このタスクが着地したのかわからない。確認するにしてもコメントを全部スクロールしないと状況がわからないという問題もありました。そういう場合は、やはり課題の本文のところに完了の条件を書き込んでおきます。しかも本文の一番上、ファーストビューで見えるところに置くようにアドバイスしました。

フィラディス情報システム部高木俊輔氏

大谷：放任主義じゃなくて、割と使い方を細かくアドバイスするんですね。

高木：アドバイスしないで、「どうぞ、自由に使ってください」でもいいんですけど、個人的には「全社でやり方を統一する」という裏ミッションがあって、自分のやり方をとにかく真似してもらうことにしました。みんなが僕のやり方を踏襲してくれると、ばらつきがなくなります。

社内でいくつかプロジェクトをこなしてくと、部署によってBacklogの使い方が違っていて、なるほどなあと思いました。でも、部署だけの使い方に慣れてしまうと、部署をまたいだプロジェクトやコミュニケーションが生まれたときに、四苦八苦するんですよ。その点、全社で使い方やマインドセットを同じにしておくと、Backlogを使い倒すことができます。

大谷：なるほど高木メソッドがあって、それを真似しろという感じですね。

高木：そこまでおこがましくは言わないですけど（笑）、ある程度メソッドを持っておいて、それを各部署にインストールしておく。そうすると各部署で「それ、高木さんから聞いた」という話になります。

こうして会社の中で同じ動きをとれるようにするのは、ボール回しをうまくやってタスク管理を効率的に進めるこつだと思いますね。繰り返しになるのですが、異なる部署間で異なるやり方のまま仕事を進めようとすると、やはりギスギスしてしまいます。でも、Backlogの使い方が揃っていれば、最初の部分でつまずかないで済むと思っています。

大谷：けっこうBacklogの導入や定着に覚悟を持ってやっているんですね。

高木：うまくいったらそれでやってくれ、うまくいかなかったら、好きにしてくれみたいな感じです（笑）。

アドバイスする内容はもちろん自分が学んで来たことでもあるし、JBUGも含めて、いろいろな会社の成功体験を社内にどんどんインプットしています。社内でうまくいったことをコミュニティでアウトプットしたら、それは他の会社でも参考になるかもしれません。

「プロマネが見切れない」はメンバーに起票を任せて解決

大谷：河野さんは運用に入って大変だったところ、問題はありましたか？

河野：先ほど話したとおり、多いときには6つとか、7つとかプロジェクトを抱えると、もはやプロマネの私がボトルネックになります。簡単に言うと、起票できなくなります。

でも、開発の仕事ってある程度タスクが決まっています。要件定義に対して、こういう作業が発生するというある種ひな形があるんです。だから、テンプレートを作って、それを元にまずは起票してし、それを細かく区切っていきます。

大谷：ある程度テンプレ化できるので、それを利用するんですね。

河野：もちろん突発的に議論しなければならないとか、決めなければいけないときには、メンバーと話をして、担当ごとにタスクを決めます。ただ、そのときは、私ではなく、メンバーに起票してもらいます。タスクの内容がきちんと伝わっているかどうかの確認を含めて、メンバーに起票してもらうんです。

結局、メンバーも自分で起票すると、これは自分がしっかり完成させなければという意識が芽生えます。

あと、プロジェクトの過程をBacklogに書き込んでおくと、あとから振り返ることができます。たとえばシステム障害のときに、開発や運用の過程を調べなければならないとき、書き込まれた内容が役立ちます。そして障害対応の履歴を残しておき、原因や対応などをまとめてくれると、さらにそれが資産になります。似たような現象が起こったときにまた役立つんです。

ピー・アール・オー. SI事業本部 SI営業部セールスサポートグループ河野千里氏

大谷：ちなみに起票や進捗を管理するバックログスイーパーにあたる人はいるのですか？

河野：うちであれば、プロマネがその役割だと思います。全体の遅れをチェックし、タスクを組み替えたり、増員したり、サポート体制を組んだりします。複数プロジェクトを担当しているときは、予定や優先順位を組み替えた際に、その影響を最小限に抑えるように差配する。これはBacklogのガントチャートを見ながらやっていました。

大谷：高木さんのところは？

高木：うちは各部署でバックログスイーパーにあたる人がわりといますね。プロジェクトを作った本人とか、課題意識がある方が、自発的に進捗を促したりしてくれています。今までExcelやらメールやらでタスク管理に苦戦していたのに、Backlogで解決したという経験をした方が、やってくれている感じがします。

バックログスイーパーにあたる役割が必要というのは僕も理解していて、誰もいないような部署には「担当を置いた方がプロジェクトもうまく進みますよ」というお膳立てはしていこうと思います。

河野：みなさんご自身が困ったことや解決したいという気持ちはあるんだと思うんです。だから、高木さんのようなリーダーのやり方に倣ってくれる方が出てくる。素晴らしいと思います。

前へ 1 2 次へ

ツイートする

Backlog トップへ