【アジャイル開発】透明性をもたせることの重要性｜プロジェクトスタート前にクライアントと信頼関係を築くために行うこと

2021-05-11 2023-10-06

ビジネス

アジャイル開発コミュニケーションチームディレクターモチベーション営業

アプリやWebシステムなどのプロダクト開発ではソフトウェアという目に見えないものを作るため、クライアントと開発チーム双方のコミュニケーションが非常に重要です。

完成したプロダクトはコミュニケーションの賜物と言って良いでしょう。

また弊社ではアジャイル（スクラム）開発をしており、アジャイル開発においてプロジェクトを成功させるにはクライアントとの信頼関係の構築が非常に重要になってきます。

今回はプロダクト開発において、信頼関係を構築するためにプロジェクトが始まる前に準備しておくと良いことについて紹介したいと思います。

クライアントとの信頼関係の重要性

アジャイル開発を進める上で１番気をつけなければならない事は、クライアントに安心感をもってもらいながら開発を進めるということです。

安心感をもってもらうことで開発チームとの一体感を促進させます。この一体感というのは幻想的な話ではなく、具体的にいうと、クライアントと開発チームが同じ意識と認識をもって同じゴールに向かって協力し合って進んでいくことです。

この一体感を生むことはとても重要で、プロダクトはクライアントと開発チームの双方の協力によって生まれるものだと考えるためです。

もし、クライアントがいつも開発チームに対して不安な気持ちだったり、不満を抱えていたら、ビジネスとして必要最低限の関わりにして割り切った関係にはできても、開発チームに協力したいと心から思ってもらえるでしょうか？

そこで「クライアントに安心感を与え、信頼関係を構築する」ということを目的としてその仕組みづくりを考えていきたいと思います。

「透明性をもたせる」とは

まずはクライアントと開発チームの間に「透明性をもたせる」ことを考えます。
では、透明性をもたせる理由は何かを考えてみましょう？

やはり実際に物理的な距離があり、オフショア・ニアショアに限らず開発現場の動きが実際に見えない受託開発においては”不安”を感じる機会が多くあると思います。

私自身もリモートと現場の両方で働く機会がありますが、初めの方は少しでもSlackのメッセージの返信が遅かったりすると、ちゃんと仕事しているかな…と不安になることもありました。

物理的に距離があると把握できる情報量がかなり減ります。その情報量の減少がどんどん不安を煽っていくように感じました。
そんな不安な気持ちは相手に対する不信感に繋がっていき、そうなってくると結果に関係なくクライアントとチームの信頼関係はうまく築けません。

言葉ではこうです、ああですと言われたり、実際に予定どおり進んでいたとしても、ある程度の情報量は必要になります。

計画でも、過程でも何でも良いので、それらがあることによって安心感がうまれ信頼関係を築く重要なステップとなると感じています。

それでは一体何に透明性をもたせることができるかをあげてみましょう。

①開発チームメンバー
②開発スケジュール
③開発のタスク管理
④クライアントと開発チームの担当同士の調子（ビデオ通話でも顔合わせをやることはとても重要！）
⑤開発の成果物

では、それぞれどのように透明性をもたせることができるかを掘り下げてみます。

開発チームメンバー

顔写真、趣味、年齢など各メンバーの人柄や性格が少しでもわかるような簡単な紹介資料などがあればよいでしょう。

開発スケジュール

ざっくりな全体のスケジュールなどは、下記のような感じでGoogle Sheet などを使って作ってしまいます。

プロダクトを完成させる上で必要な作業を荒い粒度で洗い出し、大項目として記載し、そこに大まかなスケジュールを引きます。もし祝日や特別なイベントがあればそそれらもここに記載しておけば良いです。

開発のタスク管理

下記のような感じでかなり詳細に。これもGoogle Sheetなどで問題ないです。

それぞれのタスクに細かなスケジュールが振られてばより良いですが、一つ一つのタスクをもっと細かく正確に管理したければウェブのプロジェクト管理ツールを使うのをオススメします。

よく使われているのはBacklog、JIRA、Redmineなどです。

WBSの使い方、プロジェクト管理ツールなどでネットで調べればたくさんでてきます。

重要な事は、なるべく早い段階でこれらを用意して、クライアントに「こんな感じで進んでいくんだな」と少しでもイメージしてもらえることです。
途中各方面から意見がでてきたら都度微調整をかければ良いので、まずはイメージを共有して認識してもらうことが大切です。

クライアントと開発チームの担当同士の調子

Zoomなどの無料のサービスを使ってビデオ通話が簡単にできますので、毎日１０分でも週１回１時間でも良いので顔を合わせる機会を設けます（仕事の話が３分で終わってしまって他に話すことがなくても、雑談もよいので顔合わせをやることはとても重要！）

開発の成果物

アジャイル開発では、進捗をクライアントに確認頂く成果物は完全に完成したものではなく各スプリント毎の成果物（開発途中段階）で大丈夫です。

テスト環境で動くものを用意し、ビデオ通話の画面共有などでクライアントと一緒にその開発環境で用意されたプロダクトを操作して感想を言ってもらうことが大切です。

透明性をもたせて期待できる効果は何か？

上にあげた方法で透明性をもたせた結果、どういった効果が期待できるかをみていきましょう。

メンバーのプロフィール紹介資料

一緒に働く人の特徴をしっていると、その人とどのように接したら良いか、どのように仕事を進めるとうまくいくか考える上でヒントなりとても助かります。

また、一緒にプロダクトを作るという１つのゴールに向かっていく上で顔も知らずに働くというのはそれほど不安になることはありません。一体感と安心感をクライアントと築いていくために知ってもらう必要があります。

開発側にもメリットがあります。プロジェクトの新メンバーがチームに参加したときに、誰かが一人一人の説明をしなくてもある程度の情報共有は可能になるので、時間の節約にもなります。

開発スケジュール作成

全体スケジュールの情報がこれで把握できます。このスケジュールを作成する際に、大項目の必要作業を洗い出すはずなので、粒度は粗めではありますが、項目の抜け漏れの確認ができ、クライアントも開発チームも安心します。

また、Googleスプレッドシートなどのクラウドサービスを使用して開発スケジュールを作れば、開発チームとクライアントで一緒に編集もできるので、クライアントはリアルタイムで開発チームの進捗や更新が見れるのでとても便利です。

開発のタスク管理

細かなタスクまで洗い出し、それを共通の場所で管理することによって２つの良い点があります。
１つ目は、開発チームとクライアントの双方で確認し合うことができ、２者間での認識の違いを発見できる可能性がグッとあがります。

２つ目は、クリティカルパスの発見に繋がります。

クリティカルパスとは、プロジェクトの終了日を決定する一連の作業の経路のことです。

プロジェクトで行うタスク同士には、前工程が終了しないと進めない、同時平行に進めることができるなど様々な依存関係があります。

１つ１つのタスクを細かな粒度で洗い出し双方で確認することによって、一番重要なクリティカルパスとそれに関わるタスクを発見でき、そのパスに影響するリスクの洗い出しを事前に行うことができます。

定期的なビデオミーティング

テキストでのやりとりだけだと、相手への伝わり方が強くなり過ぎてしまって誤解を招き、人間関係が悪くなってしまうリスクが高くなります。

特にリモートのやりとりになると文字でのやりとりがメインとなるので、コミュニケーションの難易度がとても高いです。

やはり素晴らしいプロダクトを作るためにはクライアント、開発と壁を隔てる事なくワンチームとなる一体感が重要です。そのためには人間関係の構築が肝となります。

定期的にビデオミーティングを行い、顔をみて話をすることによって、距離が縮まり、お互いの性格をより知っていくことで、何か問題が起きそう・何か誤解がうまれそうという時に相手を受け入れる許容範囲が広くなり、エモーショナルな面から生まれるコミュニケーションの問題を軽減させることができます。

もちろん顔を見て話をしたとしても問題が起きるときは起きてしまいますが、人間関係を作っていくファーストステップだと考えています。

これがうまく構築できると、形式的なプロジェクトの仕組みだけでは吸い上げることが難しいエモーショナルな部分も吸い上げることができ、双方にとってより気持ちよく仕事ができるようになっていきます。

開発の成果物

なんだかんだ言って開発途中でも実物に触れられる機会があるのは、クライアントの安心感に絶対的に繋がります。開発チームにとっても、定期的に何かしらのアウトプットを要求される環境となるので、１人１人の業務への責任感を高められます。これはアジャイル＆スクラム開発では重要な手法です。

透明性をもたせる効果【番外編】

上記で挙げた以外に、大きくまとめると以下の３つの良いことがあります。

1. リアルな進捗確認
進捗管理シートやタスク管理ツールではわからない、「実際の完成度はどれくらいなのか」という点がこれで示すことができます。ゴールに対して自分たちの現在地を実際のプロダクトの完成度で明らかにできるのです。

2. 問題や認識齟齬の早期発見
会話やドキュメントでプロダクトの仕様に対してどれだけ共通の認識で進めていたとしても、一番重要なのは「仕様通りちゃんと動くのか」という点です。これを確認するためにデモンストレーションをして実際に動いているところをクライアントに見てもらったり、実際に触ってもらって、その場でフィードバックをもらうことでよりスムーズになり、クライアントと開発チーム双方にとって良いです。

3. 方向転換の機会
クライアントもどれだけしっかり仕様を開発チームに伝えていて、開発チームが仕様どおりに作っていたとしても、そのときのビジネス的要因の変化であったり、イメージと実際の乖離など理由は色々あるとおもいますが、実際に動いているプロダクトをみたときにアイデアが変わるかもしれません。こういう機会があるとその点も確認もできます。
やはり世の中に価値を与えることが重要なので、ユーザーにとって将来価値に繋がるものを作っていきたいですよね。