日頃の愚痴みたいなものを書いていたら長くなった。この記事がきっかけ↓
アイデアを出すことが企画だと思ってる奴は100万回死んでいい
個人開発者でもない限り、企画と開発は別職種として分業体制になっている会社は多いと思う。企画専門の会社や、開発専門の会社もあるぐらいだから、両職種に求められる技能は大きく違い、どちらにもそれなりの訓練が必要ということだろう。
オイラもそういう分業体制の組織の中でエンジニアをしている。働いていて一番強く感じるのは、両者の時間感覚の違いだ。
オイラは基本的にソフトウェアのエンジニアで、企画のアイディアを実装して具現化する役回りになることが多い。「これ、できますか？」と質問されると、毎回気になるのは「どれぐらいの開発期間で？」という点。
ソフトウェアで完結するものは理論上「不可能は無い」が、時間制限があるなら話は別だ。だが、どうにも「アイディアの価値と工数を天秤にかける」ことを説明しようとすると「できない言い訳」に聞こえてしまうらしい。
スポンサーリンク
ソフトウェア開発の工数を説明するのは難しい。
企画職上がりの上司は、ことあるごとに「私の若い頃は毎日徹夜だった」と武勇伝を語り始め、エンジニアリングも徹夜でやればなんとかなると思っているようだった。業務負荷を軽減するための方法など、相談するだけ無駄だった。(試しに武勇伝に習って働いたら労働基準法に触れる結果となったのはまた別の話)
こういう話をする時、北斗の拳の1巻に出てくるミスミのじいさんの種籾エピソードをよく思い出す。ミスミのじいさんがエンジニア職で、スペード一味が企画職みたいなイメージ。
種籾を育てて食糧にするにはそれなりの時間がかかるが、スペード一味はそんなこと気にしない。今この場で種籾を食べてしまおうとする。これって、農耕民族と狩猟民族ぐらいの感覚差な気がする。実際、トレンドを追うような企画職は早い者勝ちで獲物を猟る狩猟民族だと思う。
さて、件の記事について↓
アイデアを出すことが企画だと思ってる奴は100万回死んでいい
タチの悪い人はこの「仕事の時間差」を理解できない。
PCに向かって１年かけてコツコツと積み重ねてきた積み木を、思いつき５秒でぶち壊すのだ。なんとなくそれがいいアイデアだと思った。とか、俺のアイデアを入れたいと思ったとか。
そういう、フラッシュアイデアを言う奴は、それが聞き入れられないと不機嫌になったりする。そこまで作ってきた人たちは、ここまで積み木はつまれているので、そのピースを差し込む場所がない、差し込むと大幅な仕様変更が必要である、その結果クソゲーになる、開発期間が延びる、見たいな事が容易に想像がつく。
明らかに考えが浅いから出る発言だから。この素敵な徒労感は普通に現場に悪影響を与える。
(中略)
プロジェクトの成否（売り上げ）で、関係者の給与賞与が決まるとする。企画や運営がクソならば、開発がどれほど頑張っても利益は出ない。もちろんその逆もある。（俺は両方やってたので、両方の嫌なパターンを見たことがある）
アホなアイデアに付き合って、時間も金も失うのは真っ平ごめんというのは、明確には考えていなくても、そういう空気は自然発生する。だから、これはアホなアイデアじゃないんだ。裏打ちがあるんだ。工数比でトクなんだ。って時に必要なのが、ロジックなのだ。
だからロジックはとても重要なんだ。少なくとも、そこまで積み木を積んだ奴がなるほどと思う程度には考えられていないといけない。考えて仕様書を起こすだけなら一人の工数だが、さて作るぞとなったら一体何人何ヶ月か。考えすぎということはない。そのほうが安いんだから、会社的にも考え過ぎて損はない。
スポンサーリンク
この記事はエンジニアの目線で語られていて、エンジニアのオイラはすごく納得できる。この時間差の感覚が企画の人間にもキチンと伝われば、世の中の様々な歪みが解消されるのではないかと本気で思うほどに。実際、考えてない企画も割と多いし、それにつき合わされて徒労に終わることもあった。その割に企画する人間の方が組織では出世しちゃうのがモヤモヤする。
ただし1つ、一般的にエンジニアが陥りがちな大きな誤解があるとも思う。ここから語ることは、オイラの身近で見たことを極度に一般化した話になってしまうことをあらかじめ言っておく。
コミュニケーションスタイルの違い
エンジニアと企画では、その作業工程が大きく違うためか、もともと人を説得するための「コミュニケーション」に重視している要素が違う。指向するコミュニケーションスタイルがそもそも違うのだ。
企画職の人間が「コミュニケーション」と考えているものの多くは「ロジック」ではなく「共感」だ。それは本来、商品の買い手である顧客に向けられるべき要素だが、頭の切替えが悪いのか区別がつかないのか、同じ手段でエンジニアと接してしまう人は多い。
この共感型コミュニケーションは、味方を増やすには効果的で、プロジェクトの立ち上げ時には頼りにもなる。だが、製品に収束させる際のコミュニケーション、つまりエンジニアとのコミュニケーションには向かない。
ロジカルなコミュニケーションを重視しない企画が多い理由を想像すると、企画職の人間にとって、「製品への収束」というフェーズが業務全体のほんの一部でしかないからかもしれない。そもそも、製品への収束フェーズの経験値が企画の他のフェーズに比べて圧倒的に少なくなるのが大きな原因ではないだろうか。企画ってのは没になることも多いですからね。
と、最近はちょっと好意的に解釈している。(直接関わるときは「死ね」と思っていますが)
こういう、ロジカルなコミュニケーションを重視しないタイプは一流にはなれないだろうが、組織の中ではそれなりに発言力のあるポジションになれたりするのでまた厄介。企画職は上流側に位置しやすいってのもある。
知識の違い
そして、指向するコミュニケーションスタイルの違いに加えて、両者の持っている知識の違いがまた壁となる。職種別の分業体制では、専門知識の差というのが当然立ちはだかるのだ。特に、初めて関わる人同士はお互いに伝わる表現を見つけるのにメチャクチャ苦労する。もうホント、色んな例え話を考えるわけよ。手間がかかるからやりたくないけど、軽く作って見せたりもする。早い段階で動くものを見せてしまうと、簡単に作れると誤解されて余計ややこしくなることもある。エンジニアが善意で提示した情報のせいで要求が上がってしまうのだ。
これがコミュニケーションコストというやつ。
以上がオイラの日頃の愚痴となります。
1人の人間が全ての能力を備えるかは別として、プロジェクト内ではどちらのコミュニケーションスタイルも備えていないとカタチにならない。ただ、より上司の共感を得られる人の方が出世しますね。
ところで、就職活動で御馴染みの「コミュニケーション能力のある学生」と言った時に、それを「共感」だと捉えている会社には「共感型のコミュニケーション」を鍛えた人材が、「ロジック」だと捉えている会社には「ロジック型のコミュニケーション」を鍛えた人材が採用されていく。抽象的な表現のおかげで偏りを増していく面白い仕組みだと思う。
※一口に「企画」と言っても、コンセプトデザインやプロジェクトマネジメントなど、フェーズによって役回りは違うけど、時間感覚とコミュニケーションについて語るためにあえて一緒くたにした。
スポンサーリンク
コメント