こんにちは。モバイルディレクターのカワムこと川村です。早いもので、『livedoor デイレクター Blog』に3回目の登場となります。
ディレクターが自社のポータルサイトでどのような仕事をしているかが綴られてきたこのブログですが、今回はモバイルディレクターがやっている受託案件についてお話したいと思います。
案件の数が多かった時期は受託チームと広告チームのふたつに分かれ、それぞれ受託案件と広告案件を運営していましたが、いまはチーム制ではなく担当者単位で案件を担当しています。そんな私も現在ふたつの受託案件を担当していますが、担当当初は自社案件とはまったく異なったディレクションスキルが求められ、戸惑う日々が続きました。このブログの記事「受託開発事業から自社媒体事業へシフトするための意識改革のポイントとは?」にも記載されていますが、自社案件と受託案件とでは、意識するポイントが異なると考えています。
では、通常業務の流れのなかで実際にどんなところを意識しながら仕事を進めていけばよいのか、ポータルサイトと比べながら解説していきたいと思います。
■仕様検討と開発
受託案件の場合、基本的にクライアントがサイト遷移を提案してきます。この場合、ディレクターには、その遷移を基にいかに工数を抑えてシステムを開発するかなどのロジック面での思考が求められます。システム的に遷移が難しい場合は、こちらでシステム対応可能な案をいくつか出して、クライアントと協議して決めます。
基本、クライアントの要望が第一ではありますが、それらすべてを丸のみにするのではなく、ユーザビリティやシステム負荷などを考慮しながら折衝していくことも必要なのではないかと考えています。自社案件の場合は、いちから自分たちで遷移を作成しますので、システムのことを考慮しながら作成できるというメリットがありますね。
■スケジュール
たいていはクライアントからリリース日の提示があるので、そこから逆算して工数を出し、開発に着手していきます(ケースによっては協議して決めることもあります)。
ただし、一度決めたリリース日はよほどの理由がない限り変更することは難しいと思われます。ですので、ディレクターは、さまざまな可能性を考慮して慎重に開発工数を算出していかなければなりません。
自社案件の場合は、クライアントがいるわけではないので、受託案件よりはスケジュールの縛りは緩いですが、その分ディレクター自身がきっちり管理していかなければなりません。また、デザイナーやブログラマーへの負担がかかり過ぎないように、各々のタスクを把握しておくことも大切と思っています。
■デバッグ
開発が終わったあとに動作確認を行うのは受託・自社ともに共通ですが、受託の場合は、自社での動作確認が終わったあとにクライアントへの確認が必要となります。先方とデバック内容を共有し、最終的な調整後に晴れてサービスリリースとなります。
最後に、どの案件でもリスクヘッジを行っていくと思いますが、受託の場合は、たとえばサイトの表示エラーやメール配信システムの障害などがあったときに、ユーザーからのクレーム先がクライアントになってしまいます。ですので、上記のようなトラブルが起こらないよう事前にどのような対策を行っていくかなどをクライアントと共有することが重要と思っています。
以上が、実際に受託案件に携わっている私の受託案件に対する印象です。ポータルの自社案件とは違い、スケジュールやシステム的に厳しい対応を求められることもあります。
しかし、その分やりがいも大きいと感じています。たとえば、クライアントに説明するうえで、まずは自分がシステム知識をしっかり押さえていなければいけません。すると自然にシステムへの勉強意識が湧きます。また、比較的ではありますが受託のほうが「自分が制作したものの対価を感じやすい」ので、やった分の結果が見えやすいと思います。
私も受託・自社を両立できるよう日々奮闘してるところですが、このように異なった形態の案件を一度に経験できる環境を存分に生かしてキャリアアップしていきたいと思っています。
ディレクターが自社のポータルサイトでどのような仕事をしているかが綴られてきたこのブログですが、今回はモバイルディレクターがやっている受託案件についてお話したいと思います。
案件の数が多かった時期は受託チームと広告チームのふたつに分かれ、それぞれ受託案件と広告案件を運営していましたが、いまはチーム制ではなく担当者単位で案件を担当しています。そんな私も現在ふたつの受託案件を担当していますが、担当当初は自社案件とはまったく異なったディレクションスキルが求められ、戸惑う日々が続きました。このブログの記事「受託開発事業から自社媒体事業へシフトするための意識改革のポイントとは?」にも記載されていますが、自社案件と受託案件とでは、意識するポイントが異なると考えています。
では、通常業務の流れのなかで実際にどんなところを意識しながら仕事を進めていけばよいのか、ポータルサイトと比べながら解説していきたいと思います。
■仕様検討と開発
受託案件の場合、基本的にクライアントがサイト遷移を提案してきます。この場合、ディレクターには、その遷移を基にいかに工数を抑えてシステムを開発するかなどのロジック面での思考が求められます。システム的に遷移が難しい場合は、こちらでシステム対応可能な案をいくつか出して、クライアントと協議して決めます。
基本、クライアントの要望が第一ではありますが、それらすべてを丸のみにするのではなく、ユーザビリティやシステム負荷などを考慮しながら折衝していくことも必要なのではないかと考えています。自社案件の場合は、いちから自分たちで遷移を作成しますので、システムのことを考慮しながら作成できるというメリットがありますね。
■スケジュール
たいていはクライアントからリリース日の提示があるので、そこから逆算して工数を出し、開発に着手していきます(ケースによっては協議して決めることもあります)。
ただし、一度決めたリリース日はよほどの理由がない限り変更することは難しいと思われます。ですので、ディレクターは、さまざまな可能性を考慮して慎重に開発工数を算出していかなければなりません。
自社案件の場合は、クライアントがいるわけではないので、受託案件よりはスケジュールの縛りは緩いですが、その分ディレクター自身がきっちり管理していかなければなりません。また、デザイナーやブログラマーへの負担がかかり過ぎないように、各々のタスクを把握しておくことも大切と思っています。
■デバッグ
開発が終わったあとに動作確認を行うのは受託・自社ともに共通ですが、受託の場合は、自社での動作確認が終わったあとにクライアントへの確認が必要となります。先方とデバック内容を共有し、最終的な調整後に晴れてサービスリリースとなります。
最後に、どの案件でもリスクヘッジを行っていくと思いますが、受託の場合は、たとえばサイトの表示エラーやメール配信システムの障害などがあったときに、ユーザーからのクレーム先がクライアントになってしまいます。ですので、上記のようなトラブルが起こらないよう事前にどのような対策を行っていくかなどをクライアントと共有することが重要と思っています。
以上が、実際に受託案件に携わっている私の受託案件に対する印象です。ポータルの自社案件とは違い、スケジュールやシステム的に厳しい対応を求められることもあります。
しかし、その分やりがいも大きいと感じています。たとえば、クライアントに説明するうえで、まずは自分がシステム知識をしっかり押さえていなければいけません。すると自然にシステムへの勉強意識が湧きます。また、比較的ではありますが受託のほうが「自分が制作したものの対価を感じやすい」ので、やった分の結果が見えやすいと思います。
私も受託・自社を両立できるよう日々奮闘してるところですが、このように異なった形態の案件を一度に経験できる環境を存分に生かしてキャリアアップしていきたいと思っています。
コメント