「脱・社内受託」協働するモメンタム創りとその成果
事業会社のアドミンやエンジニアが受託開発のような仕事をしていませんか？
ビジネスサイドの要望をアドミンやエンジニアに伝えて、その通りに実現する。そのような「社内受託」と言われる組織もまだまだあるのではないでしょうか？
・突然締め切り（運用開始日）と要望が伝えられる
・曖昧な要望を整理している段階でやりたいことと違うことが判明する
このようなコミュニケーションが多発すると「要望に答え続けた結果、疲弊する」「価値を生むことよりも締め切りにフォーカスされる」ということが起こってしまいます。
１.協働するにはモチベーションが大切
モチベーションの高さは大きく以下の3つの要素で決まるといわれています。
・「目標の魅力（やりたい）」
自分の行っていること、あるいはその成果として得られるものが魅力的
・「危機感（やらなきゃ）」
ピンチに陥っている、あるいは今のままでよくない結果が待っている
・「達成可能性（やれそう）」
うまくいけば達成できそう、あるいはとるべき行動が明確である
①目標の魅力（やりたい）
やりたいを高めるために「期待値調整」が大事です。依頼者が「いつまでに何をするか」を指示するだけでなく【目的】を共有することで成し遂げたいことや価値を認識することが出来ます。
②危機感（やるべき）
やるべきを高めてやれそうに変えていくには実現可能性を明らかにして「実現のための障壁」を取り除くことです。
経験と勘だけを頼りに行うと属人的で再現性がなく、且つ依頼者への説明にも一貫性が無くなってしまいます。危機感は組織で共有するべきです。
③達成の可能性（やれそう）
達成の可能性を高めるには関係者を巻き込み「障壁を取り除く」ことです。
依頼者および関係者を巻き込むことで業務上の課題を解決するだけでなく、関係者と協力関係を築き同じ目的に向かっていることを明確にすることが大事です。
2.協働するための型化
実際に協働するために取り組んだ実例を紹介します。項目2,3個追加して欲しいという依頼には簡易化することもありますが、開発の流れとしては規模に関わらず同じ方法で行っています。
①要件定義
依頼者に要件定義を作成して貰いレビューする、もしくは要件定義を一緒に作成することで【目的】を共有します。
②運用基準（影響調査）
勘や経験だけに頼らず一貫性や基準を持った影響調査を行うため、運用基準を作成して行っています。
③WBS
開発者だけでなく、誰がいつ何をするかを決めて役割分担します。
3.活用成果
実際にどのような利用をしているのか、我々プロセスデザインユニットの活用シーンと成果について簡単にご紹介します。
①開発案件の業務改善
やるべきことが型化されていることでタスク漏れや課題発生による手戻りなどが大幅に減っています。特に役割設計では、依頼者ではなく関係者として役割やタスクを分担することで運用上の課題など早期に解決することが出来ています。
②人材育成
要件定義や影響調査など経験の浅いメンバーであっても、いつ・何を・誰に確認すれば良いのか適切なタイミングで行うことが出来ます。
上司や先輩も成長ステージによりサポートが必要なポイントを絞ることが出来ますし、要件定義など一定品質のドキュメント化がされていることでマイクロマネジメントせずとも必要な情報量を確認してサポートすることが出来ます。
4.最後に
「目標の魅力（やりたい）」「危機感（やるべき）」「達成の可能性（やれそう）」を高めることで、少しずつビジネスサイドとRevOpsとのモメンタム創りが出来ている実感があります。
組織体制やマネジメントというすぐに「変えられないもの」だけでなく、「変えられるもの」にもフォーカスして取り組んでいくことが大切です。