6人のエンジニアを束ねるディレクターが考える「Webディレクターとして大事な5つのこと」
はじめまして、もちせいです。
現在私は、赤坂にある某美容系IT企業の技術部でWebとアプリのディレクター兼プロダクトマネージャーとして働いています。
ディレクター歴は4年です。
技術部にはエンジニアが6名とデザイナーが1名在籍しており、開発タスクの管理をメインでディレクションをおこなっております。
日々のディレクション業務を行う上で、意識していることがありましたので今回それをまとめようと思います。
その前にまず私の略歴です。
【ざっくり経歴】
・親の転勤で中高はシンガポールで生活
・デザイナー系の専門学校で3DCG専攻し卒業
・Webデザイナー3年→漫画家📕を目指しながらカラオケ歌広場でバイト1年→フロントエンドエンジニア3年→DeNAにて品質管理4年→ベンチャー2社でWebディレクター4年☕
細かな経歴はまた別途まとめようかなと思います。
1. ディレクターの仕事は「開発以外すべて」
まず、なんと言ってもディレクターは、責任感と行動力がないと話になりません。どんなプロジェクトもすべて自分の仕事、すべて自分の依頼と責任のもと動くという考えを持って仕事をするべきです。
その上で、アクションとしては
自らタスクを探し、自らタスクを消費すること
が大事だと思っています。
自らタスクを探す
ディレクターはプロジェクトの総指揮官であり、全体の指示を出しやすくするため、まずプロジェクト内にどんなタスクがあるか、全体のタスクを洗い出す必要があります。
それは「今あるタスク」だけじゃなく「今後発生するタスク」も含めです。
タスクを洗い出し、各タスクの優先順位や割り振り先を決め指示出しの準備をすることで、その後のプロジェクトの進みが格段によくなります。
【自らタスクを探す主な理由】
・プロジェクト内容を咀嚼し、課題や目的やゴールを再認識する
・メンバーアサインや関係者の想定がつく
・早期に正確なスケジュールが組める
他にもいくつか理由がありますが、挙げ出すとキリがないのでこのへんで。
プロジェクト概要書を作る際にもタスクをきちんと洗い出しておかないとゴールのズレ・計画のズレ・メンバー認識のズレが発生し失敗の原因になるので注意が必要です。
自らタスクを消費する
タスクを消費するというのは「自分でやる」と「メンバーに依頼してやってもらう」の両方を指します。自分でできることとできないことがありますが、基本的に開発以外全て自分でやろうとしてください。
【自らタスクを消費する主な理由】
・そのタスクのつまづきポイントが早めにわかる
・依頼精度が上がり結果的に全体の工数削減につながる
・ディレクター自ら動くことでメンバーの牽引力が増す
過去、ディレクションがうまく行っていないディレクターのプロジェクトは、以下のような事象が起きていました。
【ダメディレクターのプロジェクト】
・プロジェクトのゴールがメンバーに伝わっていない
・仕様が詰まっていない
・ドキュメントが足りない
・タスクの要件がわからない
・関係者がだれかわからない
・情報がどこで止まっているかわからない
・チェック観点がわからない
・変更が多く入るがその理由がわからない
・責任の所在がわからない
これにより「無駄な工数（費用）発生」や「メンバーのやる気の低下」に繋がり、誰も幸せになりません。
そういったダメディレクターの共通点は「自らタスクを探し、自らタスクを消費すること」ができていないことが多いです。メンバーから依頼されてから後手後手でドキュメント作成をしたり不透明な依頼内容で低品質のプロダクトが出来上がったり、開発開始が遅れエンジニアへの責任圧迫が起きたりと、プロジェクトが失敗確度が高まります。
逆にディレクターがこのマインドを意識して業務を行うとメンバーは、より「自分の仕事に集中」できます。デザイナーならデザイン制作、エンジニアなら開発です。ディレクターはメンバーが自分の担当以外の作業が発生したり手が止まらないよう、常に業務のしやすい環境の用意が必要です。
そのためには、すべてディレクターの仕事と思い、率先してタスクを整理し、自分のできるところまでやってみて、できないことを「自分はここまでしかできないからお願いします」という気持ちでメンバーに依頼するように心がけるべきです。
2. 常に疑う
私は基本、人の言うことをあまり鵜呑みにしないよう心がけています。
（日常生活では「すぐ信じてしまうので危険」と言われていますが😅）
業務で言うと提案、不具合報告、開発完了宣言、テスト完了宣言などです。
提案であれば「それ本当に必要なことなこと？」「どれくらいのニーズがあるの？」と聞いて提案してきた人に対し、要件の深堀りをします。
他にもエンジニアが開発終了し、単体テストで不具合がなかったと伝えられても、基本自分の端末と自分の目しか信じないようにしています。
提案や開発依頼を疑う
技術部は、他部署から日々多くの依頼が寄せられます。
私の席で「こんな機能を作ることできないか」「この機能をこう変更できないか」「これは不具合じゃないんですかね」と、相談ベースで様々な依頼が来ます。
そこで私は問います。
・具体的にどんなユーザーが使うことを想定しているの？
・ニーズは確定しているの？（何人中何人が喜ぶの？）
・その不具合に出会う人はどのくらいいてどのくらいの緊急度なの？
依頼者は盲目的に「自分」や「自分の目の前の人」が幸せになることばかり考えてしまいます。ビジネスでやっている以上、自分やその周りだけ幸せになる考えでは視野が狭く、「ユーザー全体」「会社全体」「社会全体」がよくなることを念頭に会社は組織として動く必要があります。
ゴールは自分の依頼が叶うことと思ってしまう人が多いので、ディレクターはその依頼の必要性を一度整理する必要があります。整理するときに5W3H技法が役立つときがあります。
【5W3Hとは】
・What：なにを
・Why：なぜ
・Who：だれがだれに
・When：いつからいつまで
・Where：どこで
・How mach：いくらで
・How：どのように
・How many：どのくらい
この条件で依頼内容を当てはめると、本来必要のない（もしくは優先度の低い）依頼が見えてくるので、依頼者には持ち帰って考え直してもらうケースが多いです。
結果的に少数派の意見でニーズが確定していないものだったり、ニーズはあってもやり方が複数ありどれにするか検討が必要だったり（これはまだいいんですけどね）、長期的に見ても費用対効果が見込めずやる意味あるっけ？となったり様々です。
また忘れがちですが、
「その機能があることで困ることない？」
という視点が抜けていたりします。
機能が増えることでコンバージョンへの操作数（Step数）が増え、逆にユーザーにとってデメリットになることもあります。
ソフトウェアテストの7原則：原則7「バグゼロ」の落とし穴にあるように不具合を修正したことによる影響範囲や、新たな不具合がないか確認をしないと、できていたことができなくなったり、修正したことで使いづらくなったりする可能性があるということです。
これらの問いに対して、きちんとロジカルに必要性を説く答えが返せた依頼に対しては技術部として責任持ってリリースまで対応します。
何でも言われた通りに依頼内容を受け入れてしまうと、本来必要な開発や修正に手が回せなくなり（回せたとしても元々行っていた開発が遅延することで影響も出る）、会社にとってもマイナスになるためディレクターはその見極めが大事な業務となってきます。
「不具合がなかった」を疑う
ソフトウェア・テストの技法のテスト原則
「破壊的な過程」であるテストは、プログラムを建設した人間には心理的に困難でプログラマの仕様に対する誤解に基づくエラーは、自分では見つけ出すのが困難。したがって、不可能ではないが、効果的ではない。
というもあるくらい、まずエンジニアは自分の開発した機能内の不具合を見つけるのが困難です。
そのため開発した機能が依頼通り動くことを確認したらディレクターやQAチームに投げてしまいます。
そのためエンジニアの言う「不具合がなかった」は聞かなかったことにしましょう。（画面を開いたらエラーになりそもそも開発完了すら確認してないエンジニアもいましたが...）
また、非エンジニアである依頼者がテストをした結果も疑います。
技術部ではない部署メンバーは技術的リテラシーが低いこともそうですが、ディレクターに比べ最後の砦意識が足りないことが多いです。
不具合はないだろう。技術部がなんとかしてくれる。という甘い考えです。
【不具合がなかったを疑う理由】
・エンジニアは不具合を見つけられない
・依頼者は依頼内容しか確認しない
・そもそもシステムに不具合はあるもの（ソフトウェアテストの7原則：原則1）
不具合は必ずある。ここで見逃したら障害が起きる。という危機感を持ってテストに取り組むことが大事です。
3. 問題意識と改善提案
どんなプロダクトや組織にも問題はありそのレベルは様々ですが、
問題に気付けること
がまず大事だと思っています。
問題に気付けるということは、プロダクトや組織に対して不満を持っているということです。不満を持つということは、不満を感じるセンサーが敏感でよりイノベーションを起こせる「きっかけ」をつかめる人間だと思っています。
ただやっかいなのは
「問題意識」と「改善提案」はペアで持っていないといけない
ということです。両方持っていないと評価されません。
問題意識ばかり高い人は「単なる愚痴を言う人」「いつも口だけの人」という評価になり煙たがられて距離を置かれてしまいます。
なので、その問題をどう改善するか「課題」に落とし込み、それをチームに改善提案できるようになると価値は高いです。
誰のためにやっているのか
問題を意識するとき、そもそも自分のコンテンツ（サービスや製品）は誰のためにやっているのかを認識しておくことが大事です。
エンドユーザーを意識することが大事で、「購入する人」と「利用する人」は必ずしも一致しません。
例えば「赤ちゃんの洋服」は購入するのは保護者だとしたら、実際に洋服を着るのは赤ちゃんです。この場合、最終的に洋服を消費した赤ちゃんをエンドユーザーと呼びます。また家電製品のように、購入した人が家族などと共有して使う場合は家族がエンドユーザーになります。
このように「誰にとってのコンテンツ」かを整理し問題を出すことが重要になってきます。
これはディレクターに限られたことではなく、どんな職種の人でも養うべき能力です。その課題に対する改善提案ができるということは、課題への危機感と改善意欲の表れなので、それができるとチームへの貢献度も自然と高くなり強いては会社が強くなると考えています。
ディレクター自身が提案できることも大事ですし、メンバーからの提案も大事にしたいと思っています。
4. 先回り力
先回り力とは危機管理能力の1つで、以下の意味を持ちます。
この先何が起きるかを予想し、問題が起きないよう先んじて行動する力
自分はまだまだですが、できるディレクターはこの力がかなり高いと思っています。
開発には問題がつきもので、いかにその問題を先回りして防ぐ動きが取れるかができるディレクターの要素となってきます。
先んじて行動するというと前述した自らタスクを探し、自らタスクを消費するに近いんですが、以下の違いがあります。
・自らタスクを探し、自らタスクを消費する = 準備力
・先回り力 = 予見力 + 行動力
先回り力は、予見し行動するという意味なのでその予見力をどうやって向上されることができるか自分なりに解説します。
予見力の磨き方
まず「自らタスクを探し、自らタスクを消費すること」でディレクターとしてトライアンドエラーを重ね失敗と成功の経験をたくさん積みましょう。その経験から行動と結果の法則が見えてくるので、それが予見力のベースになってきます。
その「失敗と成功の経験」は、できるだけ広範囲で積み重ねられるとよいです。それはサービスの領域・プロダクトの特徴・自身が属する立場上のものなど様々で、広範囲で得た経験は「実績」以上に「経験から導き出す予見力」として発揮できるようになるので、常に新しいことにチャレンジし、成功と失敗は振り返ってまとめておくと効果的です。
また、経験を積むと業務中にふと気になることが増えてきます。
関係者との会話中に情報足りているか気になったり、ドキュメントの書き方で認識合っているか気になったり、テスト中やけに処理速度が遅かったりです。
実際確認してみると開発漏れを防げたり、余計な処理の負荷に気付けたりと早めにわかってよいことが多いです。それは予見力が高まっている証拠で、どんな小さな違和感も「念のため確認しておこう」と動くことで、大きな失敗を未然に防ぐことができます。（たとえ単なる勘違いでも、違和感に気付いて動けるディレクターの価値は高いです。）
ハインリッヒの法則にもありますが、大きな障害には必ず気付ける出来事が事前にちりばめられています。
【ハインリッヒの法則】
1つの重大事故の背後には29の小さな事故があり、その背景には300の異常な潜在的失敗が存在する。
常に危機アンテナを貼って予見力が磨かれることを意識し業務する（行動を起こす）ことで、先回り力が向上します。
予見力が発揮される場面
この予見力が一番発揮されるのは、思考の瞬発力が求められる場面です。
例えばディレクターは、経営陣と今後の開発計画に関わる重要な会議で技術的な見解を求められる場面がありこんなことを聞かれたとします。
「こんな機能がライバル社のサービスであったよ。
これって技術的に難しいの？うちでも作れない？」
その機能が簡単に実装できそうに思えたからと言って、経営陣から言われたとおりにディレクターが「できる（YES）」と答えてしまうと危険です。
自社に落とし込んで考えた際の仕様的な疑問点・ユーザーに与える印象・実際に開発するエンジニアの開発工数・それに伴う費用感・現タスクとの優先順位など、どういったことが想定されるか未来予測し「リスク」や「選択肢」を一緒に伝えることが大事です。
ディレクターは時として即座に「技術目線」＋「経営目線」の予見力を試される場面があり、常に先回り力向上を意識しておく必要があります。先回り力で自分やチームそして会社を守りましょう。
5. QCDの中でもお金と時間を意識
QCDとは、生産管理において重要な3つの要素の頭文字をとった用語です。
【QCDとは】
・Q：品質（Quality）
・C：コスト（Cost）
・D：納期（Delivery）
品質は高ければ高いほど良く、コストは低く抑えられるほど良く、納期は守るに越したことはありません。
しかし、QCDには相互作用があり例えば品質を高めるためには相応のコストや時間が掛かったり、コスト抑えたり納期を早めようとするとその分品質に影響が出たりします。
トレードオフの関係にあるため、ディレクターは3要素のバランスをいかに保っていくかが重要なポイントになります。
常に意識するのはコスト（お金）と納期（時間）
QCDの議論の中に「品質ファースト」という考え方があります。
私からすると品質に重きを置くのは当然で、求められた要件・不具合改修を叶えつつ
どのくらい時間がかかるか、どのくらい費用がかかるか
を常に意識すべきだと思っています。
（普段の生活の中でもこの2つは常に意識するべきことです）
品質というのはゴールがあってからこその基準です。品質を意識するのは「プロジェクトのゴールを決める要件定義」と「リリース前に大きな不具合（リリースブロッカー）が出てリリース日を見直す影響が出たとき」くらいです。
そのため初期に開発スケジュールを引いて各モジュールの設計ができていれば、その開発コストと納期は見えてくるので、あとは追加コストを掛けたり納期が遅れないかマイルストーンを設けて管理すればよいです。
その手前で品質に影響ある割り込み要件が発生するような状況は、そもそも計画段階でその想定（準備）不足であるので会社として何か別の問題があるはずです。品質がどうこうの前に、その改善が必要だと感じます。
品質で落としてはいけないのは、当たり前品質
ちなみに品質にも種類があります。狩野（かのう）モデルによると以下の5種類です。
【狩野モデル】
1. 当たり前品質
2. 一元的品質
3. 魅力品質
4. 無関心品質
5. 逆品質
個々の説明は省きますが、その中で一番大事なのは「当たり前品質」です。
【当たり前品質】
充足されていても当たり前と受け取られるが、不充足であれば不満を引き起こす品質要素である。自動車でたとえるならば、「エンジンがかかる」という品質がこれに該当する。エンジンがかかったとしても当たり前と受け取られるが、エンジンがかからなければ不満を引き起こす。
プロジェクトの中で品質を意識する状況となった場合、ディレクターはその品質が「当たり前品質」か「そうじゃない」かの判断するべきです。
例えばリリース前に不具合が発見され改修に時間がかかる。
その不具合を落とした状態で他機能に影響がないことが確認できた場合、考えるのは
・リリースを伸ばしてその不具合を直す
・その機能を落としてリリースを守る
のどちらかになります。（きれいに落とせない場合もありますが）
リリースを伸ばすということは自然に開発コストもかかります。
そこでその落とす機能の品質が「当たり前品質」か「そうじゃない」かでジャッジし、「当たり前品質」ならリリースを伸ばすべきで、「そうじゃない」なら落としてリリース日を伸ばさない判断をすべきです。
リリース日を守ることはとても大事で、よっぽどメインの機能じゃない限り、落としてリリースし第2フェイズという形で落とした機能を復活させれば良いのです。
結論としては、「当たり前品質」を落とすことなく「低コスト」と「納期」を守ることがディレクターとして求められるということです。
まとめ
こうやってまとめるとディレクターは本当に責任感と行動力が求められる仕事だな、と感じます。
1. ディレクターの仕事は「開発以外すべて」
2. 常に疑う
3. 問題意識と改善提案
4. 先回り力
5. QCDの中でもお金と時間を意識
今回の「大事なこと」以外にも、透明性 / ITスキル / 探究心 / リーダーシップ / コミュニケーション能力 / 段取り力 / ドキュメント作成能力 / フラットな第三者目線なども基本として大事なことはたくさんありますし、現場によってはもっと高レベルなことを求められるかと思います。
ただディレクターは裁量が大きいほど楽しい職業です。
「自分のクオリティー」でプロジェクトの良し悪しが決まりますし、成功した時に感じる達成感も大きいです。
今後も社内の優秀なエンジニアやデザイナーが楽しく快適に仕事ができるよう、日々ディレクション能力の向上を励もうと思います！
この記事が気に入ったらサポートをしてみませんか？