マイページ
「何が欲しいか」を解釈や疑問の余地がないほど具体的に伝える
「新しいアプリが欲しい。」「いまの基幹システムを少し改修したい。」みなさんはこう思ったとき、社内の情報システム部にいる知り合いやシステム会社の顔なじみの担当者に、「○○を作ってほしいんだけど……なるはやで！」とばかりに軽い調子でメールやチャットを送っていませんか。
――それ、NGです。システム開発を依頼するときは必ず、提案依頼書を作成します。RFP（Request For Proposal）とも呼ばれるこの書類を、社内の情報システム部や社外の開発会社（ベンダー）に提出し、具体的にどういうシステムを作るのがいいか、専門家の目線で提案してもらうのです。社外からエンジニアを自分のチームに派遣してもらうSES契約（System Engineering Serviceシステムエンジニアリングサービス）を結ぶときも、SES会社への提案依頼書の提出は必要です。
提案依頼書には、「何が欲しいか」を、できるだけ具体的かつ明確に記載します。「美味しいご飯が食べたい」という抽象的な表現ではなく、「オムライスが食べたい。卵はトロトロで。グリーンピースは入れないで。ケチャップは……」というように、欲しい機能を細かく指定します。
提案依頼書には、「なぜそれが欲しいか」も書いてください。どういう理由から課題が生じ、新しいものが欲しいと思うに至ったか、開発依頼の背景を伝えるのです。
そのうえで、「この課題に対して別の解決方法があったら教えてほしい」とお願いするといいと思います。あなたが何が欲しいかを解釈や疑問の余地がないほど具体的に伝えつつも、同時に、エンジニア自身がクリエイティビティと自由を発揮できる余地を与えるのです。
エンジニアの方々は、技術で課題を解決したい人たちです。この前、「週末は何していたんですか」と知り合いのエンジニアに聞いたら、「勤怠管理システムにいちいち打刻するのが面倒なので、自動で打刻されるサービスを作ってみました」と言っていました。時には休みの日にシステムを作ってしまうほど、課題解決に熱心なのです。
あなたが抱えている課題を共有し、エンジニアからの提案にオープンな姿勢を見せれば、「それはどうにかしなきゃいけませんね」と悩みに共感し、喜んで一緒に解決策を考えてくれるでしょう。
非現実的な欲張りは、エンジニアから反感を買う
提案依頼書を提出するときは必ず、「優先順位」も伝えましょう。ここでお話しする優先順位には、2つの種類があります。
まずは、ほかの開発プロジェクトに対する優先順位です。すでに別の開発をお願いしている場合、新規プロジェクトと既存プロジェクトの兼ね合いを考える必要があります。
管理職の立場からすると、「どっちもやってほしい」というのが本音だと思います。しかし、限られた予算・人員・時間のなかで二兎を追うのは困難な場合が多いです。「別で進めている案件の完了目標は、当初設定していた月末から1カ月延長するので、新しい案件を優先してやってほしい」というように、プロジェクト間の優先順位を指示しましょう。
もうひとつは、新規に依頼するプロジェクト内での優先順位です。「この日までには絶対に完成していないとダメなんです」というように、スケジュールを最優先せざるを得ない場合がありますよね。お金はかかってもいいから品質を良くしたいケースもあれば、機能は最低限にして低コストを追求したいケースもあるでしょう。
機能・予算・時間・品質などの複数の観点から、何を重視しているか、または何を重視していないか、何は譲れないか、何は捨ててもいいか、を開発側と具体的に共有しましょう（これらの複数の観点は、「変数」と呼ばれることもあります）。「何も譲れないから、全部モリモリで」という非現実的な欲張りは、やはり、エンジニアから反感を買うだけです。
システム開発においては、変数間の優先順位を可視化するために、トレードオフスライダーと呼ばれる指標が使われます。是非みなさんも取り入れてみてください。
ゴール設定をクリアにし、開発側と共有せよ
「何が欲しいか」、「なぜそれが欲しいか」、「どれを優先するか」。言うまでもないことですが、これらの要件を行き当たりばったりで決めてはいけません。
「自分たちのゴールは何か、どの指標で達成度を測るか」を日ごろから意識し、この視点を提案依頼書にも反映することが重要です。KGI（重要目標達成指標）やKPI（重要業績評価指標）と同じ考え方ですね。最近のプロダクト開発では、参照すべき指標を、ノーススターメトリック（North Star Metric）とも呼びます。北極星のように自分たちを導く目印は何か、を考えるのです。
自分たちが掲げるゴール設定を開発側と共有すれば、開発依頼の背景や優先順位の決定理由を、「収益にこれぐらいのインパクトを与えるから、新しく機能を追加することが必要だ」「いまユーザー数を伸ばすために一番重要なのは品質だから、品質を最優先にする」というように、説得力を持って説明することができます。依頼側の意思決定を支えている指標を知っているだけで、プロジェクトに対する開発側の理解は大きく深まります。
プロジェクトの不確実性を減らすことが管理職の責務
提案依頼書を受け取った開発会社や自社のエンジニアは、まず、既存システムや業務の現状を知るための調査を行います。提案を依頼した側は、必要な情報を正確に提供して、現状調査に協力します。
システム開発は不確実性が極めて高い世界です。ビジネス環境が急変して開発中のシステムが一夜にして時代遅れになった、要件定義をしたあとに発注側の心変わりで要件が増え続けた、開発側と発注側とのコミュニケーションに齟齬をきたした結果、発注側のイメージとは全く違うものが出来てしまった……。開発過程にさまざまな不確実性が転がるなか、プロジェクト成功の鍵はいかに不確実性をコントロールするかにかかっていると言っても過言ではありません。
管理職からすると「モタモタしていないで早く作ってくれ」と思うかもしれませんが、調査は慎重に行われるべき、というのが私の意見です。なぜなら、調査は不確実性を最小限にする非常に重要な作業だからです。カレーを作ろうといざ調理を始めたら、実はピーラーがなくてジャガイモの皮がむけないことが発覚した……ということのないように、いまある問題を事前に洗い出し、開発段階になって想定外の事態が発生するリスクをできるだけ下げていきます。
もし現状調査を蔑ろにし、調査期間を短縮するよう要求したり、ヒアリングに非協力的だったりすると、プロジェクトは高確率で失敗に終わります。不便で誰も使わないシステムが出来上がる、改修が困難なほど複雑なシステム構造になる、セキュリティに欠陥（セキュリティホール）が生まれる、開発作業が大幅に増えて当初は1人月だった見積もりが6人月になって請求される……。こうしたトラブルは決して珍しくありません。
管理職には、利益の最大化はもちろんのこと、リスクを最小化する責務もあるはずです。そのためには、できるだけ調査が正確に行われるようエンジニアをサポートし、長い調査期間をある程度は容認して、プロジェクトの不確実性をできるだけ減らすことが必要です。
