アジャイル型開発でシステムの請負業務を行っているソニックガーデン社の倉貫義人さんが書かれた「人が増えても速くならない」（技術評論社）から、私たち多能工型のマーケティングプランナーが考えておきたいポイントをまとめてみました。

●遅れているプロジェクトに人を追加してもダメな理由

１）後から入った人の情報や知識のキャッチアップ、教育に時間・コストがかかる

２）関わる人が増えるとメンバー同士のコミュニケーションに時間がかかる

３）タスクを分解するにも限界がある

これは、システム開発に限らず、単純に人を増やせば早くできると思う人に説明するためのポイントです。

●エンジニアは、建築でいうと設計者である

エンジニアは、どんなふうに動くソフトウェアにするか、顧客やビジネスサイドの人たちと相談しながら設計してプログラムという形で表現する人だ。仕様を把握する人とプログラミングすべき人は同一人物であるべきだ。

　この文章をデザイナーに置き換えても良いとは思いますが、どの世界でもできる人は顧客やビジネスサイドの人と相談して進めていけるコミュニケーション能力があり、そんな人が設計（マーケティングのプランニング、デザインのプランニング、システムのプランニング）をするのが効率的であることは言うまでもありません。

　実際のビジネスの場では、あるプロジェクトで有能なマーケターとデザイナーとエンジニアが一緒になった場合、誰がイニシアティブをとっていくのか？ということが問題になることがあります。企業が協業して行うケースはもちろん、同じ会社であっても複数の業種のプランナーが揃うと、目的は同じでもアプローチ方法が異なり、事前にお互い理解したうえで進め方を根回しをしておかないと、「あのエンジニアはよくわかりもしないのにマーケティングの話をしている」とか「あのデザイナーはシステム実装のことを無視してUXありきでまとめている」‥などといった面倒なことが発生するのです。

　あらかじめクライアントがどのアプローチで目的を実現したいのかをくみ取って、関与者間で方法論を合意しておく必要があります。

●ソースコードは、人それぞれで書き方が違う

プログラムは、その人ならではの創意工夫でシンプルに美しく表現するもので、画一的にはならない。エンジニアがお互いに見合うことで、理解と品質の向上が見込める。

　ソースコードは、そう単純にマニュアル化できないようで、これはマーケターの企画方法やデザイナーの制作方法が異なるのと同じでしょう。

●シンプル イズ ベスト

最初からずっとシンプルに作らないとダメ。一度、乱雑・複雑につくってしまうと、シンプルにするのは不可能に近い。

　例えば大手企業のクライアントはリスク分散したいが故、複数の企業に声をかけて複数のシステムやWebサイトをつくったりしますが、増改築が重なり、ぐちゃぐちゃになってしまうことはよくあることです。リスクヘッジしたい、クライアント側の担当者も変わる、請負型の担当者も変わる、そしてテクノロジーや法規も変わる‥という中で、どこまでをルール化できるか？なかなか難しい問題ではあります。

●システムの見積問題

クライアントは、「システム開発は不確実性が高いものなので、確実な見積と約束をとりたがる」ので、エンジニアは、「約束された見積を守ること、依頼されたものを期限内に収めることだけが仕事になる」。だから、エンジニアはクライアントが気づかないアドバイスや方法論の選択肢をいちいち提示したりしない。クライアントがそれに不満なら、機能ありきで期間を見積らせるのではなく、期間ありきで機能を見積もらせるべきだ。

　という論調ですが、ここはクライアント側とエンジニア側が歩み寄り、機能ありきか期間ありきかにおいて、お互いに納得できる話を事前にしておくということが大事ではないかと感じました。ウォーターフォール型で開発するのもアジャイル型で開発するのも、もしくは両方をミックスするのもケースバイケースのように思います。

　それぞれのPros.&Cons.を提示しながら、今回のケースに最適な方法を提示できるのが、私たちのような多能工型のプランナーがやるべきことではないでしょうか。