このまえ書いたのの続き
この前の→ 開発するときに考えていること。信頼関係 マネージャ編。 - Mitsuyuki.Shiiba
今日はビジネス側の人の信頼を得るために僕が考えていること。
例によって、相手の立場で考えるところから始めよう。
ビジネスな人なので、ビジネスゴールがあって、それを追いかけてるんね。そのビジネスゴールは絶えず変化し続ける。最初に決めた場所に、ずっと向かい続けてもしょうがなくて。常に状況をみてどこに向かうべきかを判断し続けないといけない。という状況。
開発チームに求めるもの
ここで、ちょっとタクシーに乗ることにしよう。
「京都の醒ケ井高辻ちょっと下がったところまでお願いします。」
こういうタクシーだったらいいなーってのは。
- 目的地までの最善の道を知っていること。「最短の道」でなくてよくて。渋滞や工事を考慮して「最善の道」を選んで欲しいなーと。
- 「この道を通ってここまで行きたいんですけど」といった時に、「そこに行くならこっちを通った方が早いけど、そっち通ります？」と聞いてくれるとか。
- 僕は目的地がコロコロ変わるんだけど、その都度一緒になって最善の道を考えてくれること。
・・・あー。そっか。タクシーの運転手というより。僕は車の免許を持っていないんだけど目的地を知ってるから、一緒に車に乗って一緒に考えながら運転してくれる人。がいいんかな。
てことで、開発チームに求めるものはこんな感じ？
- 一緒の目的地を目指してくれる
- 一緒にビジネスゴールを考える
- そこまでの最善の道を知っている
- 開発スキルがある
- 運転のプロとして提案をしてくれる
- コミュニケーションスキルがある
んで、ゴールからの逆引きね。
一緒にビジネスを考える
開発してそれで終わりじゃなくて。開発したものを使ってビジネスゴールを達成するところまでが僕らの仕事。これを意識してるかどうかで全然作り方が変わってくるもんだから面白い。
ビジネス側の人に限らず、誰か他の人と一緒に仕事をするときには人じゃなくてゴール(ビジネス)と向き合う。人と向き合うと「あの人はこの前ああ言った」とか「あの人の言い方が気に入らない」とか「これ、僕の仕事ですか？」とか。そういうくだらない摩擦に力を使ってしまって残念。そうじゃなくて、一緒にビジネスゴールを見る。そしたら「この前ああ言ってたけど、今はこっちの方が良いね！」って言えそう。
んで、ビジネスゴールを見れるようになったら自然とそうなると思うんだけど。「この前こう言ったじゃないですか！」「そうだね。でももう状況が変わったんだよ？」てことで。良い物を作るために、変化を受け入れる。
自分がこの前関わったプロジェクトでもやっぱり、途中でビジネスの人が新しい道を発見したり。なので、最後の最後まで要件変更を受け入れられるようにしてました。もちろん、むやみに変更を受け入れると開発は回らなくなってしまうから、それをうまくさばけるような仕組みを用意する。結構ころころ言うことが変わったりするんだけど、彼らは常にビジネスの価値について考えてて。それと同じ目線で見てみたら一貫性があったりする。
※ちなみにここで言う「変化」は、コミュニケーションロスによる「この前と言ってることが違う！」ことを意味してはいません。
それと、割り込みを受け入れる。基本的には割り込みはしないほうが開発がスムーズに進むんだよ。ってのを伝えた上で。それでも入ってくる割り込みは、ビジネス価値が高いってことだろうということで、喜んで受け入れる。そしてそういった割り込みを受け入れられる仕組みをチームが作っておく。
開発スキル
まぁ、運転手が道を知らなかったら、信用できないよね。開発のプロとして仕事をしている以上ある程度の開発スキルは必要。あればあるだけ良い。そゆことね。
ビジネス要件があったとして、僕らはそれを実現するための、交渉できる選択肢をビジネス側に与えたいと思っている。「これをやるには2週間かかります。今やってる機能を実装するのを2週間遅らせてもよければ実装できます。どうしますか？」とか。
そして、どうするかを決めるのはビジネス側。
今、別の機能を実装してるから、その開発はできません。とかはあんまり言いたくないし。そもそも「〜だからできません」と言うのは「〜すればできます」と言い換えることができるので。後者を選ぶ方がイイ。
最終決断はビジネス側の人がするとはいっても、丸投げするわけではなくて、色々と開発側の視点からのレコメンドなどをしておいて、決断自体には自分も納得する必要がある。
大きな失敗は、運転してたら事故を起こしたようなもので、一発で色んな信頼をなくすのでダメゼッタイ。
逆に小さな失敗は、リスクとして飲み込んで、さっさと前に進むために必要だったりする。
コミュニケーションスキル
正直、あんまり考えたことなかったんだけど。最近、もしか、これってスキルなのか？と感じたので。
ビジネス側の人は結構開発側に気を遣ってくれたりする。また過去の経験を元に話を持ってきたりする。なので。本当の要件の上に何重かの膜がかかってて、しかも本人もそれに気づいていないことが多い。なので。ディスカッションの中で膜を剥がして、真の要件を一緒に発見する。
相手の言葉に違和感を感じたときは、納得するまで話をするようにしている。その結果、最初の話と180度話が変わったりする。
開発状況を見えるようにしておくのはすごく大切。そしてそれを見える状態にするだけじゃなくて、見せておく。交渉できる選択肢の部分にも関係するのだけど。短く切ったスケジュールで実現する機能をキューとして積んでおいて。そのキューを並び替え可能にしておくことで。ビジネスの人が開発チームに交渉できるようになる。今、新たにこういうことをやりたいと思っているので。この機能を遅らせてもいいから、やってほしいとか。
また、同じことを説明する場合でも、見せ方ひとつで印象が全然変わるもので。特にチームの状況を伝えるときなんてチーム全体の印象を自分の言い方ひとつでよくできるんだし。
- 「1の機能を明日出して、2の機能を一週間後に出します。」
と単純に結果だけを説明するより、その裏側の意図も含めて
- 「2の機能を出すのに1週間かかりそうなのですが、1の機能だけでもあるとビジネスにとって価値があると思うので明日なんとかしてリリースしますね。」
と言うだけで全然違う。
それと。新しい技術を取り入れてそれをビジネス側の人に押し付けてしまうのは好きくない。開発側とは違ってそういうのが苦手な人が多かったりするので、ビジネス側が慣れたインターフェイスで、最大限負担なくやりとりをするようにしたい。それがExcel方眼紙ならそれでやりとりする。(※エンジニアが仕様書書くのに使ってたらグーで殴る)
じゃあ開発チームもExcel使うの？ってなるかもだけど。そこにBizLeadを置くことでインターフェイスのミスマッチを吸収してもらうのです。
まとめ
まただらだらと書いてしまったが。まとめると。
- 人ではなく、ビジネスゴールを見て、変化や割り込みを受け入れる
- 開発スキルを常に磨き、交渉可能な選択肢を与え、合意可能な決断をしてもらう
- 大きな失敗はしない。小さな失敗は積み重ねて前進する
- 真の要望を引き出し、チームのがんばりを見せて、その見せ方にも気を配る
- 相手の慣れたインターフェイスでやりとりをする
「ビジネス側の人無茶なこととかイミフなことばっかり言うわー」ってのは。相手の立場になって同じビジネスゴールを見ることで、だいぶと理解できるのではないかと思う。
また、それはビジネス側の人が開発を見るときも同じだけどね。
※ ただし、1ヶ月の研修だけで「Java経験十分です！」というような営業の言うことは理解したくない。
