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

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

使いやすいからお客さまにも受け入れられてもらえる

大谷：さて、今までは社内での導入や定着の話だったのですが、チームワークマネジメントは社外の取引先や顧客とのコラボレーションも前提にしています。

河野：私たちの場合は、システム開発会社ということもあり、もともとタスク管理の必要性は理解していました。実際、他のプロジェクト管理ツールを使ったこともあったのですが、結局Backlogに戻ってきたという経緯があります。だから社内に関しては、わりと浸透は早かった。でも、ここまで利用するようになったのは、やはり「お客さまとの情報共有に使いやすいから」という理由だと思います。

お客さまは開発者ではないので、タスク管理にも慣れていません。でも、Backlogであれば、チケットを渡して、これをいつまでに戻してくださいとお願いすると、すぐに理解してくれます。もちろん返してもらえない方もいますが、メールやチャットで課題のURLを送ると、きちんと必要な情報を返してくれるようになります。こうしたことが増えてくると、どんどん定着していって、ますますプロジェクトの進行がスムーズになります。

大谷：使い方が簡単だから、いったんやってもらえば、お客さんもすぐに慣れてくれるんですね。

河野：他のプロジェクト管理ツールも機能的にはあまり変わらないと思っているのですが、やはりUI/UXという点なんでしょうね。使い勝手のハードルがどうしても1段上がってしまいます。その点、スターが付けられたり、ゴリラのアイコンが出てくるBacklogはファンシー。

だから、みなさんに受け入れられてもらいやすいと思っています。いったん使ってしまえば、わりと抵抗なく利用してくれるという感覚です。必要な情報をすぐに挙げてくれますし、メンバーとしても組織の垣根なく、必要な情報を得られるので便利です。

あとはお客さまには「お困りになっていることはないですか？」と聞いたり、対面であったときに「こうすればいいですよ」といったフォローは定期的に行ないます。一言添えるだけで、あとは使っていただけます。

大谷：言われると「実はここが困っていて」ということもありそうですね。

河野：はい。メール文化の方々もまだいますので、その場合は先ほど話したとおりに、メールでBacklogの課題のリンクを送ります。普段の使い方やアプリケーションから外れないように使ってもらうためにはどうしたらよいかを考えます。

大谷：ユーザーの行動の導線上にBacklogを置いているわけですね。それは違和感なく使えそうですね。

まずは合意形成　組織や文化によってやり方はさまざま

大谷：とはいえ、新しいツールを導入してもらうとなると、ハードルはありますよね。社内ならともかく、お客さまの場合は特にあるのではないかと。

河野：そうですね。やはりお客さまの中には「手間が増える」という心理的なハードルがあるんですよね。「なんのために書くの？」と言われてしまう。だから、開始時からプロジェクトの関われる場合は、「なぜBacklogを使うのか」といった部分はしっかりお話しさせてもらっていますね。

プロジェクトの初期のタイミングで大事なのは、お客さまとの合意形成です。このプロジェクトを完遂し、成功に導くためには、ゴールの認識合わせが大事。これが要件定義の最初にあたります。このゴールを共有し、ゴールから導かれたいろいろな細かい部分を記録するために、Backlogを使わせてくださいとお願いして、導入させていただくことが多いですね。

大谷：最初にこのゴールに向かって、こういう風に進めますというお客さまとのコンセンサスをとって、あとはそのための作業や議論も普段のBacklogでのやりとりで確認していくわけですね。

河野：お客さまも、弊社のチームも、それぞれ文化があるので、ルールをガチガチに決めてしまうとうまくいかないんです。あるチームではこのやり方はうまくいくんですけど、このチームではうまくいかないといったこともあるので、プロジェクトの立ち上げ時はみんなでやりやすい方法はどれか手探りで探すこともありますね。

その上で、まずは使ってもらう。そして情報を入れていただく。その中でも、ゴールはなんなのか？　成果物はきちんとできあがるのか？　押さえておきたいポイントはなにか？を常に意識し、これらを実現するためにはなにをすべきかを考えながらプロジェクトを回していました。

同じ部署、同じ会社みたいな感覚を心がける

大谷：高木さんは他社とBacklogを利用するのに際してどういう方法をとりましたか？

高木：私たちの場合は、顧客というより、取引先なのですが、Backlogでやっていくことに対して、最終的にはNGという会社ももちろんあります。ただ、その場合はどうしようもない。一方、Backlogでやるとなった場合は、私がいったんタスクを書いてしまい、担当まで割り振ってしまいます。

もちろんBacklogの使い方が全然わからないという方も多いですが、今までメールでやってきたキャッチボールを、これでやっていきましょうとお願いします。今まで1つのメールに対するラリーが多くて、全部追うのがとても大変、あの話題が見当たらない、話題が拡散してしまうみたいなことがなくなりますと説明します。

大谷：取引先さんと課題を共有するんですね。

高木：はい。取引先からしても、メールを探すのは大変だし、1つにまとまっていたら楽。だからいっしょにBacklogに使えば、メリットありますと説明し、その上で私がタスクを全部登録します。その上で「ちょっと一緒にやってみましょう。簡単ですから」と腹割って話をしながら、割とこっちに引きずり込んでいる感はあります。

あと、「かしこまらないでください」というお願いもします。確かに取引先からすると私たちがお客さまという立場になりますが、同じプロジェクトを成功させようという仲間なんですから、同じ方向でいきましょうと説明します。なにかあれば課題に書いてください、タスクを登録すること自体、正しいや間違いや成功、失敗はないので、とにかく書いてくださいとお願いします。

その上で、私もラフに書きますし、相手にもラフに書いてもらいます。ただ、ラフでも正確に書けば、コメントの中でも乱暴な書き方、いい加減なお願いはなくなります。

大谷：「心理的安全性」というワードが正しいのかわかりませんが、取引先さんにも安心して使ってもらう雰囲気作りをするんですね。

高木：他社と一緒に仕事するときは、信頼関係を構築したいですよね。

やはり、いっしょにやってくことに関して役割分担はあるわけですから、そこはお互い気遣いながら、やりとりします。「高木さん、こちらの確認早めにしてくれますか」「これちょっとわかんないんで確認しといてもらっていいですか」みたいな感じで、他社とのやりとりでも、本当に同じ部署、同じ会社みたいな感覚を心がけてます。

大谷：取引先さんも同じように接するんですね。

高木：正直、「Backlogでいっしょに仕事をする」という土俵に乗ってくれただけでも、こちらとしては御の字です。だから、なるべく相手の立場に立って考えているつもりです。本当はルール化しようとか、共通理解を持とうとかした方がよいもかもしれませんが、今のところはそこまでしなくても、ラフにやっていて、プロジェクトは割とスムーズに回せている気がします。