またひっくり返るのかな
お仕事
業務のワークフローというか、何から始まって、途中で何が起きて、過去の積み重ねの上に結果が伴って、どうやって終わらせるかといったコンテキストを理解できない人は、そういう教育を受けてないのか、そういう業務に携わってこなかったからなのかなぁ。
一言で言えば「空気を読めよ」ってことだ。
開発プロジェクト
先日の一件は、開発リーダーから、先ずはモック (プロトタイプ) を開発して、トライ&エラーで進めましょうということでメール上では決着がついた。私も同意した。要は普通の開発プロジェクトとして進めましょうということだ。それが悪いわけでもないし、間違っているわけでもない。
オーナー曰く「基本設計がほぼ完了」とは、社内に分かりやすく伝えるための言葉の綾だったそうだ。そういうことで良いし、それで決着したと思ってた。
そしたら、翌日、開発リーダーから開発方法論やビジネスの話しの前に、プロジェクトの運営がぐだぐだ過ぎるから、メンバー間の不信状態を招いているとプロジェクトオーナーにメールを送ってしまった。オーナーは開発者じゃないから、開発というのものが本当に全く分かってない。
そんなメールが届くから、オーナーも気にして、話しをしましょうとかになった。
ビジネス担当、マーケティング担当、開発担当の3者がいて、それぞれにプロジェクトの進め方の提案はあるものの、どれが正しいとも間違っているとも言えない。プロジェクトを運営する以上、全メンバーが合意するのは難しくても認識は一致させておかなければならない。論理的に説明できれば、合意できなくても納得はできる。論理的に説明できなくても Executive Decision (昔、そんな映画があったね) でも構わない。現状は、そのオーナーの責務を果たしていないから、それぞれの担当が思い思いの提案をして議論が発散してしまっている。
そして、輪をかけて「基本設計がほぼ完了」とか言い出すから、さらに不信感を高めてしまったという説明をした。
オーナーの考えは、
- モックを開発
- モックを公開してマーケティング
- ユーザーのフィードバックを得る
- フィードバックからコンセプトやビジネス要件を詰める
の流れが決まった (本当はきちんと決議してないけど、、、) ことを「基本設計のほぼ完了」と定義したようだ。一般の開発プロジェクトでは、コンセプトから要件を作り、そこから設計を行うので、コンセプトや要件が定まっていない状態で設計が完了することはあり得ないし、この作業は単なるプロトタイピングや調査の過程でしかない。そして、従来からの普通の開発プロジェクトのやり方でしかない。
私は、普通の開発プロジェクトがダメだと言っているわけではなくて、リーンスタートアップの問題解決型アプローチで行くと決めたはずなのに、また普通の開発プロジェクトのやり方に戻ってしまっていることを認識しているかどうかが大事だと主張した。もちろん方針転換することそのものは構わないが、それを全メンバーが認識していることが重要だと説明した。
じゃあ、また開発リーダーと話しますということになった。何を話すのか、どうしたいのか。唯1つ残念なことは、取り組むプロジェクトの本質とは全く関係ないところで、メンバーのモチベーションを下げてしまったことだ。
マネージャーがメンバーのモチベーションを上げるのはとても難しい、一種のカリスマがいる。けれど、モチベーションを下げないことはできる。マネージャーが判断できないなら権限を委譲すれば良いし、それが嫌なら詳細が分からなくても良いから判断だけしてその責任を全うしていれば良いと思う。
