Backlogに限らないが、エンジニアにとって使い慣れたツールとクライアントが使い慣れたツールには違いがある。開発会社内の連絡はslack、顧客とはChatWorkなんてのもよく聞く話だ。こうしたギャップを埋めるために顧客にも同じツールを使ってもらいたいというのがエンジニアの本音だが、それはそう簡単ではない。しかしうまくアプローチすれば顧客とのコミュニケーションもエンジニア同士のコミュニケーションもBacklogで一元化できる。1月に開催されたBacklog World 2019において、その手法を紹介したのはH2O spaceの谷口 允さんだ。
社員、開発パートナーを含め完全リモートワークの体制を確立
H2O spaceは、「ちゃんとWebなkintone/Web制作会社」と自社Webサイトに掲げている。技術にちゃんと向き合い、ちゃんとしたクリエイターを育てたいという同社の思いがそこにはある。では、技術にちゃんと向き合うとはどういうことだろうか。その一端が垣間見えるのが、同社の業務体制だ。
「H2Oはオフィスを持っていません。東京や千葉、大阪に住む社員が全員リモートワークで仕事をしています。社員だけではなく外部の開発パートナーさんももちろんリモートワーク。子育てをしている社員もいるので、この体制を堅持しています」（谷口さん）
エイチツーオー・スペースの谷口 允さん
リモートワーク「にも」対応しているのではない。完全にリモートワーク。だからこそ、コミュニケーションツールへのこだわりが強い。
「よく使われるコミュニケーションツールに、電話、メール、チャットなどがあると思います。しかし電話やメールはリモートワークには適していないと感じています」（谷口さん）
特に電話が嫌いだという谷口さん。「電話爆発しろ」と大書きしたスライドに、同じく電話嫌いの筆者は首がもげんばかりにうなずいてしまった。
電話、メールはリモートワークには適さない
H2O spaceではチャットとBacklogを中心にコミュニケーションを取っているが、それらも万能という訳ではない。チャットはスマートフォンに通知が届くので、心理的な負担になりがち。特に全員がリモートワークの同社では、それぞれの労働時間がばらばら。オフタイムにスマートフォンにチャットの新着通知が届くことも当たり前に起こるので、オフィスワーカーに比べてより負担は大きくなる。またチャットはその特性上、既読が着くと返信が来ることを期待してしまうという側面もある。これがお互いの心理的負担をさらに大きくする。また、記録には残るが会話形式なので情報を整理しにくいというのも、業務の中心にするにはハードルとなる。
ということでBacklogの出番なのだが、こちらはこちらでやはり課題がある。それを谷口さんは、Backlogの「3ない」と表現した。「タスクを整理してくれない」「見てくれない」「使ってくれない」という3つの課題だ。残念なプロジェクト管理の例として挙げられたBacklogの画面には、確かに投稿者が適当に件名をつけたせいで内容が分かりにくい課題が並んでいた。担当者が変わっても、ちゃんと担当者名を変えずに放置され、誰が本当の担当者なのかわからなくなることもしばしばだという。システムに担当者を記入する欄があっても、最新情報が反映されていなければ意味がないのだ。同じように、優先度もちゃんと使われない傾向にあると谷口氏は言う。
「優先度の項目を使ってちゃんと課題を整理せず、件名に【至急】などと書かれることもあります。これではシステムとして優先度を整理できません。期限日も、ちゃんと使ってもらえない項目のひとつです」（谷口さん）
これを解消するためには、ディレクターが課題を整理してあげるべきだと谷口さんは提案。タスクの粒度や締め切りの見直しと再設定、関係ない話題は別タスクに分けるなど、Backlogの機能をちゃんと使ってあげることで、タスク管理のツールとしての力を最大限に引き出せる。
ディレクターがちゃんと整理してあげればBacklogは本来の力を発揮する
特に締め切り設定については、あまり細かいタスクごとに締め切り設定をすると、毎日多くの締め切りメールが届くことになり、かえって軽視されることになるという。谷口さんが提案するのは、小さなタスクにはあえて締め切り日を設定せず、それらをまとめた親課題にだけ締め切りを設定することだ。
ディレクターがちゃんとがんばれば、クライアントにもBacklogを使ってもらえる
Backlogを活かすためにディレクターが担うべき役割は、社内コミュニケーションに留まらない。クライアントとのコミュニケーションをBacklogに一元化する際にもディレクターがちゃんと対応すべきことがいくつかある。そのひとつが、顧客と開発者との間に立って通訳、クッションになること。
クッションなしに同じプロジェクトに招いてしまうと内部のゴタゴタも伝わってしまう
「やってしまいがちなのが、Backlogで顧客と開発者とを同じプロジェクトで結んでしまうこと。これをやってしまうと、開発側のトラブルや内輪の状況がそのままクライアントにも見えてしまい、お互いに気まずくなります。プロジェクトごとに対クライアント、対開発パートナーの2つのプロジェクトを立て、ディレクターがその間に立つことをお勧めします」（谷口さん）
対クライアント、対パートナーでプロジェクトを分け、ディレクターが間に立ってタスクを整理する
間に立つディレクターは顧客の要望を開発者に通訳して伝えたり、開発パートナーの事情を斟酌してクライアントとの間のクッションになったりする。そのためにスケジュールも内部向けと外部向けとで使い分けるべきだという。
「リモートワークなので休日に作業する人もいます。しかしクライアントへの提案や納品は平日にすべきです。このとき、成果物の提出を金曜日に設定してしまうと、その日のうちにフィードバックが来たら休日作業が発生してしまうので、月曜日を提出日にするなど、ディレクターはここでもクッションになります」（谷口さん）
それだけディレクターががんばっても、クライアントがBacklogを使ってくれなければまったく意味をなさない。そもそも開発者向けのコミュニケーションツールであり、システム開発になじんでいないクライアントの場合は利用ハードルがどうしても高くなる。そういった場合にH2O spaceが取っている手法が、「連絡板」というプロジェクトを立てることだという。
なんでも放り込んでいい「連絡板」を作って先方担当者にBacklogに慣れてもらうことから始めよう
「なんでも放り込んでいい場所を作って、クライアントに気軽に要望を書いてもらいます。ディレクターがそれを見て、適切なタスクに振り分けて処理していきます。二度手間に見えますが、これを続けているうちに先方担当者がBacklogの使い方を理解してくれて、次第に自分で適切なタスクに投稿してくれるようになります」（谷口さん）
利用ハードルを下げて、まずBacklogに書き込むことになじんでもらう。その上で適切な使い方を見て学んでもらう。そのためのステップが「連絡板」というわけだ。この手法、Backlogに限らずエンジニア向けツールにクライアントを巻き込みたい場合に広く応用が利くと思われるので、ぜひあちこちで活かしてもらいたいアイデアだ。
週刊アスキーの最新情報を購読しよう
