ディレクターとして入社して半年以上経ったので振り返ってみた

所属しているチームにてディレクターとしてどんな仕事をしているか、振り返ってみます

はじめに

はじめまして福永です。昨年の7月にギフティにディレクター職で入社し働いています。入社して半年以上経過したので、下記観点で振り返ってみようと思います。

• 私の所属するチームでディレクターとエンジニアがどう関わりどんな仕事をしているか
• 前職と比較し働き方がどう変わったか

この記事の想定読者

• ギフティでディレクターとして働くことに興味のある方
• ギフティでエンジニアとして働くことに興味のある方
• ギフティでの働き方に興味のある方

所属チームの紹介

昨年の記事の執筆者の横川君と同じチームに所属しています。エンジニア視点での記事が読みたい方は昨年の記事も参照ください。チームの紹介については同じ内容になるのため抜粋します。

SaaSを取り扱っている事業部の中で、(最)重要クライアントである大手飲食チェーン向けに開発を行っているチームに所属しています。 メンバーはマネージャー1人、ディレクター2人、エンジニア5人です。 eギフトの生成を担うシステムは、通常SaaSの形態でご利用いただいているのですが、対応しているクライアントがeギフトを用いたマーケティングのパイオニア的存在である事、新規施策に積極的である事、飲食業に止まらず小売業全体でベンチマークとされている事が理由で、専属のチームで対応しています。 定期的にクライアントとギフティでディスカッションして、eギフトを使った新しい施策を実施しています。 良い先行事例を作れたらと思い、良きパートナーとして一緒に事業をしている雰囲気がありますね。 良い施策は行く行くは他のクライアントにも横展開できたらと思っています。

全社的にみても、最もクライアントの意向やクライアントが所有する他システムとの連携を求められるチームのため、弊社の他チームとPJの進め方は異なっています。
取り扱っているシステムは、eギフトの販売や交換を担うtoC向けのシステムと、私のチームのクライアントがeギフトを管理するtoB向けのシステムが存在します。システム改修の比率はtoC向けの方が多いですが、toC,toB向けのシステムどちらも触れる機会がありました。

システム開発におけるディレクターとエンジニアの業務と関わり方

今回の記事のテーマである「ディレクターとエンジニアが業務上どのように関わっているか」について、現在どのように働いているのかを説明します。
PJ毎にシステム開発のプロセスは異なります。基本的にはウォーターフォール的に進めることが多く、一般的にはディレクターが上流を担当し、設計やコーディングをエンジニアが担当するケースが多いと思いますが、私のチームでは上流からエンジニアも参加し、チーム全体で相談しながら進めていく傾向にあります。また、PJによってはアジャイル的に2週間程度のイテレーションを回しています。

工程全体

工程全体でのディレクタの関わり方は以下の通りです。

• 各種日程調整
• スケジュール検討・進捗管理
• 課題管理
• 打ち合わせのファシリテート

クライアントとのコミュニケーション方法

各工程の説明に入る前にクライアントのコミュニケーション方法を説明します。
コミュニケーションはbacklogやslack、ビデオ会議を用います。PJ毎に週1回程度打合せを行っており、打ち合わせには弊社のディレクター・エンジニア、クライアントのビジネスサイドのチーム・ITチームが参加します(企画会社やデザイン会社、他ベンダーが参加することもあります)。ビジネスサイドの方と直接会話し、企画の背景や目的を直接確認できるためとても良い経験になります。
以下、各工程毎にディレクターとエンジニアの働き方について説明します。

PJ計画・見積・要件定義

プロモーション企画等の兼ね合いで開発のスピード感を求められるPJが多く、要件の取捨選択をクライアントと調整しながらスケジュール進行を検討することが多いです。基本的な流れとしては、クライアントから「企画の背景・目的・リリース日・実現方法の想定」を説明いただき、いただいた内容についてヒアリングを実施し要件の整理を行います。多くの場合は既存システムの改修ですが、弊社の別チームや事業提携している会社のサービスを利用したソリューションを提案することもあります。
ディレクターやエンジニアの関わり方は以下の通りです。

ディレクターの関わり方

• クライアントへのヒアリング
• 要件の整理
• 実現困難な要件の代替案提案やスコープアウトをクライアントと調整
• エンジニアの見積をベースにした見積書の作成
• スケジュールの計画

エンジニアの関わり方

• クライアントへのヒアリング(ディレクターのみでなくエンジニアも参加します)
• 要件の整理(ディレクターのみでなくエンジニアも参加します)
• 整理した要件から実装方法の検討
• 実現困難な要件の代替案検討
• 設計・実装・テストの見積もり

設計・開発

クライアントと仕様調整を行いながら設計・開発を行います。案件によりますがデザイン周りについては、弊社で担当することもあれば、他企業からデザイン案をいただいて作成することもあります。他社からデザインを頂く場合も、ギフトという観点で検討に参加するもしくは意見を述べるケースも多いです。 ディレクターやエンジニアの関わり方は以下の通りです。

ディレクターの関わり方

• 仕様調整
• 実装に必要な納品物の納期管理

エンジニアの関わり方

• 仕様調整(ディレクターのみでなくエンジニアが直接クライアントと調整することもあります)
• 設計・開発

テスト

PJごとに実施するテストの粒度は異なります。特に新機能や新規画面などユーザーが混乱する可能性がある場合は、UX観点のテスト実施をクライアントと調整します。
ディレクターやエンジニアの関わり方は以下の通りです。

ディレクターの関わり方

• テストの日程調整・実施管理を、内部やクライアント、他ベンダーと実施
• テストケース作成・テスト実施(ディレクター・エンジニア問わず実施します)
• 指摘事項(バグ)の優先度管理、必要に応じて優先度の棚卸しをクライアントと実施
• 指摘事項の対応可否やリリース前後での修正時期の調整をクライアントと実施

エンジニアの関わり方

• 単体テストレベルのテストコードの実装
• テストケース作成・テスト実施(ディレクター・エンジニア問わず実施します)
• (ディレクターが優先度を整理した)指摘事項の原因調査・修正

リリース

リリースにおけるディレクターやエンジニアの関わり方は以下の通りです

ディレクターの関わり方

• リリース日時をクライアントや他ベンダーと調整
• リリース時のリスク管理・体制の整理
• 障害発生時のクライアントとの調整

エンジニアの関わり方

• リリース手順書の作成
• リリースリハーサル
• リリース作業の実施
• 障害発生時の原因調査・修正

振り返り

リリースをして完了ではありません。リリース後や企画の終了後に、クライアントと関係企業にてKPT法を用いた振り返りを行います。継続すべきことや反省点を話し合い、次回のPJでどうすれば改善できるかを話し合います。 ディレクターのみではなく、エンジニアも参加します(内部で実施後クライアントと実施。クライアントとの実施時にはディレクターのみで参加することもあります)。

前職と比較し個人的に感じている違いについて

まず転職をした動機を説明します。その後、転職後に達成されたのかを前職の環境と比較することで環境の差について説明します。

転職した動機

転職した動機は主に下記4点でした。

• ビジネスに貢献していることを感じたい
  
• ワークライフバランスを考慮したい
  
• 技術力を向上したい
  
• モダンな環境のシステムに関わりたい
  

転職後に前職とどう変わったか

ビジネスに貢献していることを感じたいについて

• 開発しているシステムは提供して終わりではなく、サービスの利用状況に応じたフィーも頂く形になっています。これによりクライアントと同じ方向を向いてビジネスを作っていくことやビジネスに貢献できていることを実感できます。
• toCのサービスを提供しているため実際に利用されているところを目にする機会があり、使われていることを実感することができます。
• PJのリリース後、告知のタイミングでアクセス数が増大することを目の当たりにすると、会員基盤の大きさや社会へインパクトを与えることのできるクライアントと仕事をしていることを実感できます。

ワークライフバランスを考慮したいについて

• 作業が特定の個人に集中しないようにチーム内で調整しています。
• 前職よりも残業時間が減りプライベートな時間を確保できるようになりました。

技術力を向上したいについて

• プライベートな時間を確保できるようになることで、勉強する時間も確保できるようになりました。
• ディレクターもエンジニアも問わず、いかにユーザー体験を向上できるかを考え抜き相談しています。また、クライアントのビジネスサイドの方とも直接会話ができるため、技術的な視点のみでなくビジネス視点での能力向上もできると思っています。

モダンな環境のシステムに関わりたいについて

• 作業環境は、コミュニケーションツールとしてslackやbacklog, Trello等を利用しています。
• 開発環境は、AWSやDocker等を利用しています。
• 作業環境も開発環境も前職と比較するとモダンな環境で仕事ができています。

締め

日々の業務や前職と比較してどう変わったかを振り返ってみました。前職でもPMをしていたため、やることの大枠は変わりませんでしたが下記観点で大きく変わったと感じました。

• 採用している技術が(前職と比較して)新しいこと、コミュニケーションツール等生活環境もモダンな環境であること。
• エンジニアのメンバーも上流から参加し、チーム全体で相談しながら進めていく傾向にあること。
• 良いサービスを作るために、クライアントと一緒にシステム開発の工程や企画の振り返りが行われていること。
• ライフワークバランスが保てること。
• ビジネス貢献を感じられること。

以上で振り返りを終わります。今後もチームメンバーやクライアントと共にユーザーの体験を最大限に向上し、より良いサービスを作っていきたいと思っています。 ギフティで働くことに興味がある方にとって少しでも参考になれば幸いです。