軸を決めろ!

私が携わったプロジェクトはゲーム、ツール、業務系などがあるが、殆どが新規案件だった。

新しい分野への開発やR&Dのプロダクトが多くて非常にリスクが高く、今まで作り直しやソフトとして動作が十分でもプロダクトとして破綻したモノを何度か関わった。

もちろん、携わった中で大ヒットしたプロダクトに関わった事もあるし、そのプロダクトのコア部分に関わった事もある。

 

私の会社はオリジナルのプロダクトを出す事に重きを置いているので、どこかの仕様を真似たりする事がない。

仕様を詰め切れず、混沌な状態で無理やり作り、ゲームとして破綻したモノをリリースした事もある。逆にビジネス上の理由で大々的に世に出る事はなかったがソフトウェアとしては中々の完成度のコミックビューアを開発した事もある。これは大手から何社も引き合いがあった。

 

では、なぜ炎上するのか、逆になぜスムーズに開発できるのか?

 

が決まっているのか?」

 

この一言に尽きる。ここで言う軸とは主に以下の内容を表す。

 

  • なぜ、そのプロダクトを開発するのか
  • いつ、そのプロダクトを世にだすのか
  • 予算、はいくらあるのか
  • だれに、向けたプロダクトなのか
  • 優先順位はどうなっているのか
  • だれが、どの様な役割をになうのか

さらに、ゲーム系では上記の要素に加えて世界観などが入る。

軸と言うのは、一般的な表現にすると要件定義に近いかもしれない。昨今のWeb業界などではウォーターフォールモデルは悪の枢軸の様に扱われるが、私は今まで後先考えず、プロダクトを作りながら仕様を考えるやり方に巻き込まれたり、自分でやらかして、何度も痛い目を見ている。

 

開発プロセスでも色々とあるが、私は仕様決めとプロトタイプ開発を並列で走らせる開発方法が一番だと感じている。

また、上記で箇条書きした。項目を個別にこのエントリに書いていくと、結構な長文になるので後日、リンクを貼るので、興味がある人は読めば良い。

 

話が戻り軸はこんなにも大切なのだろうか?

なぜ、を決めてないと、入れるべき機能をいれない機能が入っていないシステムができあがる。

いつ、を決めてないとダラダラを開発を行い、効率が悪い。

予算、を先に決めてないと、物理的に不可能な仕様を入れようとする。

だれに、を決めてないと、開発者の過去経験による、システムになる。

優先順位、を振らないと、最もクオリティカルな部分が終盤になって発覚する。

だれが、を決めないと責任や手柄が明確にわかり辛く、緊張感がない仕事になる。

 

上記の事柄を中途半端にしたまま開発を行うと、プロジェクトの途中でブレが生じ出し混乱が生じる。混乱が生じると人は間違いなく冷静では無くなり、様々な下らない政治的な牽制が始まり、不整合の塊となったプロダクトが出来上がる。

経験上、プロダクトが当たり満足したプロジェクトは上記の用に軸をしっかりと決めて開発した時が多い。

 

ある非常に大きなプロジェクトのグランドデザインに関わり、コンサル会社で働いた事があるが、計画、立案の進行が中々のモノだった。若輩だった私は彼らの中から非常に得る物が多かった。慣れない仕事で大変だったが。

だからと言ってコンサル達のPMBOOKや仮説ドリブンなどをバンザイと言う訳ではない、彼らはモノを作り出す事はできない。

プログラマーはモノを作り出す。しかし、殆どのプログラマは、余りにも物事を拙速に動こうとする。

安易な取り交わし、ナアナアな責任、半ば個人的な欲求による技術への取り組み、行き当たりバッタリの対応。

そんな事ばかりしているので、不整合の塊となったプロダクトになる。

 

軸を決め、文章に残し、プロジェクトに入る前にメンバーに徹底的に意識させろ。

全員が同じ目標、イメージを共有する事から仕事を始めるのだ。

メンバーの目的を明確に、何をどの様にすればいいのか、のヒントを示せば、後は自ずと自発的に動き易いなるはずだ。

プロジェクトが混乱に陥りそうになった時に、その軸を見なおせ、改めて己が冷静では無い事に気づき、反省し、昔が示した軸によってプロジェクトを進めようとするはずだ。

 

軸はプロジェクトの柱