Warning: reset() expects parameter 1 to be array, boolean given in /home/users/2/mods.jp-makoto-tanaka/web/wordpress/wp-content/themes/xeory_base/lib/functions/head.php on line 143
このエントリーをはてなブックマークに追加

読了: 約 5 分

以前書いた組織への帰属意識について考えるという記事がこの技術系のブログで1番PVがある訳ですが
その理由としてとあるビックワードで1位になっている事もありますが、多くの方に見ていただいて60いいねを超える評価もいただいてありがとうございます。

会社・組織という単位で帰属意識を高めるためにはどうすれば良いのかという事を書いてきたので、
今回はサービス開発時における、マネジメント、ディレクション・進行管理・目標設定・工数管理等についてこれまで実践してきた事、またもっとこうしておけば良かった、
事について書いていきたいと思います。

この記事を書く経緯

現在スマホ用のサービスを開発する中で、開発フェーズから運用フェーズに入ったのですが、開発しただけで終わっては全く意味がなく、
自分たちの掲げた目標に大してコミットし、達成していく事が大切だということを再認識するためです。

また、サービスの開発で欠かす事ができない、開発フローや、確認フロー、短・中・長期でのタスク管理等など細かい点は
そのときそのときに応じて異なるとは思いますが、何が一番ベストかという現時点での軸・考えをしっかり覚えておきたいと思ったからです。

これから、開発のマネジメントやディレクションに携わる方、既に携わっている方、デザイナーやエンジニアでも自分の意見をしっかり持ち、自分の意見をまとめて、ディレクターに伝えたいと思っている方に読んでいただけれと思います。

目標設定

これについては会社も関わりますし、それぞれのプロジェクトやチームでも違うので『これ』という一つにまとめるのは難しいですが、
チームでの目標・個人での目標は、数字で日程や客観的な視点から、具体的なものを設定し、日頃から意識しておくべきだと思っています。

例:
× JavaScriptをもっと覚える
○ 2013/3までに何の機能をバグのない状態で何ページ創る等

なぜ上記のような事が必要になってくるかというと、
とるべきスタンスや行動が変わってくるからです。

もしチームで掲げたサービスの数字にコミットしようとするのであれば、アクセス解析などの数値分析をデザイナーやエンジニアでもするべきですし、ディレクターやプロデューサーの言っている事をそのままやるのではなく、コンセプト、開発期間、アサイン状況、工数等を考えた上で機能実装すべきで、自分の意見は持っておく必要があるでしょう。

開発フロー・チームビルディング

これについても、プロジェクトのアサイン状況や会社によってもまちまちかと思いますが、
基本的なことから最近の開発の主流である『アジャイル開発』について考えを述べていきたいと思います。

これまでの開発プロセスで有名だったのが、ウォーターフォール・モデルと呼ばれる、いくつかの工程
要件定義 → 設計 → 実装 → テスト のような形で分けて、行うモデルでした。
私も以前勤めていたWEB制作会社ではこの色が強かったです。

ただ、自社メディア・サービス開発において必ずしもこの方法が正しいとは言えなくなってきました。
β版のリリースなどを持って、ユーザーの反応をみて実装をかえる事が多くなりますね。

アジャイル開発は、短期間で小さい単位の機能を開発を行い、それを反復して行っていくという開発手法の事、
まさに自社メディア開発で行われいる手法です。
ソーシャルゲームなど、イベントでユーザーの反応をみてかえていくといったこともあるでしょう。

アジャイルソフトウェア開発とは

この開発手法で大切だと考えているのは、ディレクター・プロデューサーが上という階層構造に間違ってもしない事です。

なぜかというと、これまでのウォーターフォールモデルでは、ディレクターがクライアントとの間にたって、連絡や仕様の確認をして
デザイナーやエンジニアに伝えるために階層構造が出来がちですが、メディア開発においては、ディレクター・プロデューサーが正しいというのは
ないから並列にすべきなのです。

ディレクターは実は、機能やストーリーはこれで良いのかと思ったりしているため、デザイナ・エンジニアはディレクターが言っている事がすべて正しいとは考えず、意見すべきところは意見すべきだという事。
これがサービス開発においてかなり重要なことだと考えています。

開発チームにおけるディレクターの役割とは

リリース後であれば、数値分析に基き、コンセプトにそった機能追加等の修正点の洗い出し、
その際のリソースの確認や開発期間の設定、エンジニアやデザイナーとの数字の共有と目標を意識してもらう事。

また、開発者のデバック確認というのも大事な役割でしょう。開発したてのプロダクトにおいて、
本番環境でのバグ発見は致命的なので、少人数のチームでのダブルチェックという事で必要です。

JavaScript等で動的にページ生成していても会社によってはそういうプラグインやフレームワークを持っているので
エンジニアに頼んで入れてもらいましょう。

ちなみに自分たちのプロジェクトではBackbone.jsを使用していて、色々な解析を入れているのですが、
動的なコンテンツであっても、Google analyticsで取得出来るプラグインがあるのでこちらのJSを使ってます。

ちなみにディレクターを目指す人、ディレクター必見の書籍

開発期間・機能追加/ 確認フローの決定方法

開発期間・機能追加
ディレクターによっては無理な開発期間に短期的な施策を詰め込みがちですが、それは本当に意味があるのかを
開発者とディスカッションしたほうが良いでしょう。
数値分析はもちろんの事、客観的な材料(ユーザーテスト、お問い合わせ、アンケート等)をもとに、
開発期間から逆算して、優先度をつけてライン引きをする必要があります。

基本ですが、上の人から言われたといって、自分の頭で考えず機能を追加するのは工数の無駄ですし、
そもそもプロダクトによってコンセプトが違うので、他のものから取り入れるというのはやめた方が良いでしょう。

確認フローについて
リリース前後にもよると思いますが、開発したものをいつ、何を、どこまで、誰が本番に反映するのか、
ステージングに上げて確認するのは逆算して何時か、また1日何回Deployするのか等最初に根拠をもって決めておくべきですね。
なぜなら、開発中にデプロイの回数を減らしたり、開発人員が変動するとは思いますが、あらかじめ決めておくと、
それをもとにもっとこうした方が良いというアイデアが出たり、PDCAが回せるからです。

まとめ

つらつらと書いてしまいましたが、少人数のチームで自社サービスを拡大させていくためには
個人個人のスキルはもちろんの事、サービスを成功させたいという気持ちも大切です。
気持ちがなければ知恵が出ないと思っていて、質の高い意見をぶつからせて必要な機能を割り出し、数値を分析しながら
PDCAをまわしていくというのが重要だと考えています。

・エンジニア、デザイナーはコンセプトに理解してもらい、どういう機能が良いか聞く。
・システムが分からなくても理解しようとする。分からなければエンジニアやデザイナに聞く。
・目標・前日数値は毎日朝会などで共有して、数字にコミット・意識してもらう。

おすすめ書籍

SNSでもご購読できます。

運営メディア

男性向けお役立ちメディア Coolhomme
就職・転職、エンジニア転職向け求人サイト Rplay
'