エンジニアがビジネスサイドを味方につける技術

 ビジネスサイドとは

* システムの要件を出す人
* ビジネスオーナ
* 管理画面なら、システムを使っている社員
* toCなら、企画担当、マーケティング担当

味方につけると何かいいことあるんだっけ？

* 仕事がやりやすくなる
* レポーティングを適度な質と量にできる
* ガチガチに納期を設定されたりとか、時間かかりすぎじゃないかみたいな
* 細かいWBSでの管理を要求されたら最悪で。マネジメント担当はそのメンテナンスだけで、日々を過ごすことに、、

* リファクタリングのようなビジネスサイドはメリットを感じにくいことに対しても、たがみつさんが言うのであればとその工数を認めてくれる

* ビジネスサイドに逆にお願いをしやすくなる
* 　納期の延期、スコープの縮小や、エンジニアの運用を一部ビジネスサイドにやってもらうとか
* 方向が揃って、結果を出しやすくなる

* 仕事が楽しくなる
* 社内に敵を作ってもね・・・

味方につけるために

味方につけるためには、基本的に、信頼関係を築く事が大事。

 まずは、そもそもちゃんと会って話をしよう

* きちんと話を聞く
* 要望の背景にある何に困っているのかを聞く
* ビジネスサイドが今までどんなキャリアを積んできたのかを聞くと、ITリテラシーとか、システムに対するスタンスが、わかってくる
* そうすれば、IT用語をどの程度噛み砕いて、背景から説明してと考えて、対策することができる
* これが安心感を生む

課題対私達（ビジネスサイド、エンジニア）の関係に持っていく

* けっこうビジネスサイドとエンジニアで対立している現場を見ることがある。例えば、業務が回らなくて困っているのですぐにでもシステム化したいという要望があって、エンジニアのリソース的に対応が難しいときに、「なんでできないんですか。こんなに、困っているんです！」みたいな感じで、ビジネスサイド対エンジニアみたいな構図になることがある
* それを、きちんと現状を説明した上で、開発を着手できないという課題に対し、ビジネスサイドと一緒に、どうやったら着手できるかということを検討する。そうすると、エンジニアは私のお願いを聞いてくれいない！という関係から、いつの間にか、一緒の課題を解決する仲間になっている。そして、この時に絶対やってはいけないのが、安請け合いで、守れなさそうな約束をしてしまうと期待値が上がって、守れなかった時の信頼感の損失が大きいので、辞めるべき。あくまで、現実的な落としどころを見つけるのが大事。

ビジネスサイドの価値観を理解する

* 今、ビジネスサイドが何に困っているのか、重要視しているのかを把握する
* これによって、要件の優先順位、仕様を切っていい箇所、よくない箇所の判断精度が上がる
* さらにここは、どういうレイヤーのビジネスサイドなのかによって、優先順位をつけるのが肝要
* 1番に優先すべきは会社なり、事業の戦略なので、社長、部長、事業責任者の価値観、戦略を把握する。次に現場のスタッフで、現場のスタッフからの課題、要望があって、これ事業の方向性と違うよねとか、これに対応したところで、事業においてのメリット小さいよなぁみたいなことはよくあると思う。ただ、事業的には後回しなのだけど、現場のスタッフの運用回ってなくて、死にそうだなぁみたいなときは、事業責任者たちにエンジニアからもアラートをあげるとよい。しかし、きちんとした優先順位付けの仕組み、会議体が無いと、どちらかというと、現場のスタッフの要望をなんとなく受けて、対応してしまうことが多いように思う。なので、1番確実なのは、KPIなり、KSF（キーサクセスファクター）を事業責任者と明確にして、KPIが上がるのか、KSFを強化できるのかを判断しやすくするのがよい。事業責任者でも、KPIとか関係ない要望を出すこともあるので、そんな要望を不満を与えずに断ることができる

定期的に見えるアウトプットを出す

* 難しい機能開発をしていると着手からリリースまで1ヶ月くらいかかることもある
* 複数メンバーで開発をしているのなら、他のメンバーが小さい機能でもよいので、1週間に1つはリリースするようにする
* 自分は、普段はあまり重い開発タスクを持たないようにしているが、2週間くらいリリース無いなと思ったら、数時間程度で可能な開発をやって、リリースすることがある
* ビジネスサイドは、見えやすいアウトプットが無いと不安。エンジニア、最近、リリース無いけど、何やっているのだろう？みたいな感じに思うこともあるので、定期的にリリースするのは大事
* リリースまでに時間がかかる機能開発については、
* 根本的に、スコープを小さく、リリースを分割できないか検討する
* それによって、アウトプットの早さ、頻度を高められる
* それでもどうしても規模が大きくなってしまったら、画面イメージを作成したタイミング、プロトタイプが動くようになったタイミング等で、ビジネスサイドに見てもらう
* それによって、ビジネスサイドが進んでいるなと安心感を持つことができる

とは言っても、難しいよねと

既存の関係性が悪かったり、エンジニアになりたてで力不足だったり。そういう時は、エンジニアマネージャかシニアなエンジニアに入ってもらって、課題、コミュニケーションの交通整理をしてもらって、関係性を改善するのがよい。頑張ってもできないものはできない。関係性が改善して、コミュニケーションの型ができれば、ジュニアなエンジニアでも安定を維持することはしやすい（簡単ではないが）。大事なのは、助けが必要なときにきちんとアラートをあげること。