この記事はGoodpatch Advent Calendar 2024 4日目の記事です。
テクニカルディレクター/ソフトウェアエンジニアの池澤です。
最近はテクニカルディレクター（テックディレクター、TDとも言う）として仕事をすることが多くなりました。
Goodpatchはデザインを得意とする会社なので、テクニカルディレクターの役割にもUIデザインやユーザ体験の考えが大きく含まれます。このデザインとテクニカルディレクターを組み合わせた仕事はとても楽しいものです。その楽しさと私が心がけている習慣についてご紹介したいと思います。
テクニカルディレクターとは
Webプロダクト開発においてテクニカルディレクターの主な役割は「技術面での全体的な戦略と方向性を決定しプロダクトを技術的な面で成功に導くこと」です。
また、チームのコミュニケーション面で各部署・役割毎の要求を技術的に翻訳して認識を合わせたり、ビジネスとデザインと開発をバランスよく連携させるなど、技術翻訳と橋渡しの役割も重要です。
一般的にテクニカルディレクターの主なやることは以下の通りです。
技術設計・戦略： 実現可能性確認（フィジビリティスタディ）、技術選定、アーキテクチャ設計
開発チームリーダーシップ： 技術指導、開発プロセス改善、コード品質向上
プロダクト管理： 開発プロセス改善、要件定義
UI/UX連携： デザイナーとエンジニアの接続、UIレビュー・フィードバック、UX向上サポート
コミュニケーション・調整： 技術要件共有、他部署連携、ビジネス要件調整
技術トレンドの把握： 最新技術調査と導入、開発チーム教育
クオリティコントロール： コードレビュー、セキュリティや性能最適化
テクニカルディレクターについては「Tech Direction Handbook」サイトが詳しく説明されているのでご参照ください。
テクニカルディレクターの楽しさ
切れる手札を駆使したビジネス・デザイン・開発の総合戦
テクニカルディレクターの仕事は、まさに異なる領域が混合となった総合戦のようです。
ビジネス要求や提供価値をユースケースに落とし込み、デザインのクリエイティブなUIと体験を機能仕様として創造し、エンジニアの技術的な制約と可能性の中で具体化します。
チームが切れる手札と現在位置、状況、スキルを駆使しながら、アイデアやワンチーム力でプロダクトのゴールに向かって進む力を生み出す楽しさがあります。
ワンチーム力の向上と不安の解消
私は結構不安や恐怖を感じやすいタイプです。ですがそんな特徴も強みにすることができます。
プロジェクトの成功にはチームの不安を取り除き、メンバー全員のモチベーションと潜在能力を引き出すことが欠かせません。デザイナーが「これ、本当に実現できるの？」と感じたり、エンジニアが「この機能の目的は何か、仕様が曖昧で分からない」と思ったりする時があります。
テクニカルディレクターはそうしたメンバーの不安を敏感にキャッチすることが大切です。そして具体的な解決策を示したり、自走できる仕組みを作ることで理解できない不安や孤立を防止します。
またフォロワーシップの発揮も重要です。フォロワーシップとはリーダーシップを支援して建設的な意見を述べながら、チームの成功に積極的に貢献することです。
メンバーの発言を促したり、心理的安全性を維持するようファーストペンギンとして切り口を作ることで、場の雰囲気や発言発散を促します。そしてワンチーム力を強くしてこの仲間とこのプロジェクトができて楽しい、心地よいと思われる環境ができると温かく柔軟で強いチームになって行きます。
こうしたワンチームと心理的安全性作りは、自分の不安を感じやすいという弱みをチーム作りのアンテナ感度に活かせる楽しさがあります。
RPGゲームに例えた要件定義手法
私はサービス仕様や要件定義を、ドラゴンクエストのようなRPGゲームに例えて楽しく捉えています。
プロダクト開発はRPGゲームでの壮大な冒険の構成に分解できます。
ゲームシナリオ：
プロダクト目的やビジョンは「ゲームシナリオ」に相当します。ゲームシナリオを進行しゴールを達成することがプロダクトの目的です。
クエスト：
各ビジネス要求やユーザ体験、ビジネスユースケースの実現は、ゲームの各エリアで依頼される「クエスト」に相当します。個別のクエストがすべて達成されるとエリアの目的が完了し、メインシナリオが進行します。
ダンジョン：
ビジネス要求を達成するための具体的な対象や機能ユースケースは、「ダンジョン」として捉えます。
各機能を使い、UI画面での操作やAPI処理でユーザがアクションを完了することを、ダンジョンをクリアすることになぞらえています。
例えば、RPGの「村を救う」というクエストには、「原因となるダンジョンを探し出す」「ダンジョンのボスを倒す」「討伐報酬のアイテムを獲得」といったダンジョンクリア結果があるように、機能ユースケースでの具体的な機能やUIでの画面や処理内容に対応します。
テクニカルディレクターは、このRPGゲームのクエストやダンジョン設計者のような存在と考えています。プロダクトの目的達成へ進行させ、ビジネスやユーザ体験を実現させ、各機能やアクションを具体化させることはRPGゲームも要件定義も同じだと思います。
要件定義は複雑で難しく苦手でしたが、このRPGライクな考え方だととても楽しくて、もっと盛り上がってかつ分かりやすいものを作ろうとモチベーションが高まります。
RPGライクな要件定義の詳細については以下をご参照ください。
心がけている習慣について
開発やビジネス知識の収集と読書
テクニカルディレクターにとって、継続的な学習は生命線です。
最新技術のトレンド、ライブラリのアップデート、人気フレームワークランキング、サイバー攻撃ニュースの他、ビジネスや一般教養、趣味、雑学など、幅広い領域の本を日々読む習慣を大切にしています。
私のおすすめの読書法は、開発系ウィークリーメールマガジンです。興味のあるテーマや開発言語のメールマガジンを毎週読むことで、技術の最前線の動向を定期的に吸収できます。
メールマガジンは大抵英語なことと、複数登録した場合メール内記事リンクが100記事以上にもなるので、Google翻訳で日本語変換して読んでいます。
また、紙の本と電子書籍も有効です。
特に電子書籍にはKindle Unlimited のような読み放題サブスクリプションサービスもあるので、気になる知識や仕事上知らなかった分野について、即席で本をダウンロードしてざっと斜め読みすることで、月額固定料金内で本を調べ放題なので気軽かつ効果大です。
重要で有料の知識は紙の本、即時読み切りとコストパフォーマンスでは電子書籍サブスクリプションと使い分けることで、知識の深さとスピードが両立しやすいと思います。
開発系メールマガジンの例
- JavaScript Weekly： https://javascriptweekly.com/
- React Status： https://react.statuscode.com/
- Frontend Focus： https://frontendfoc.us/
- Programmer Weekly： https://www.programmerweekly.com/
- PyCoder's Weekly： https://pycoders.com/issues/655
- Node Weekly： https://nodeweekly.com/
- TLDR： https://tldr.tech/
不安に気づける感性とフォロワーシップを磨く
チーム内の不安や課題にいち早く気づき、適切なフォローを行うことは、テクニカルディレクターにとって重要な資質です。そのため潜在的な不安やモチベーションの変化を読み取るアンテナ感度を磨くことが大切です。私の場合は自分が不安を感じやすいので、それをメンバーや環境などに当てはめることで掴んだりします。
フォロワーシップも重要です。
話し合いの場やオンライン会議の中で、リーダーや発言者に反応を示して孤立させないようにしたり、発言量の少ないメンバーに意見を促してみます。最初の発言は誰しもしづらいものなので、ファーストペンギンとして最初の発言を切り出すなど、チームや非言語の場の雰囲気を整えたりします。
また、Goodpatchには社内チャットツールで、「times_名前」のような個人つぶやき発信をする文化が普及しています。私はこのtimesを多数登録して、日々情報と各自の発信にたくさん触れたりクイックにスタンプや返信で反応をするようにしています。これで情報・感情への反応力や敏感さを磨いたりしています。
こうして心理的安全性を守り、一体感のある「ワンチーム」を作り協力しやすい環境を心がけています。
議事録書きを積極的に行う
テクニカルディレクターはプロジェクトの初期段階から柔軟に関与して、様々な役割で貢献できます。初期フェーズでは情報のキャッチアップを兼ねて、議事録作成などを通じて、チームの理解と連携を深めることも有効です。
議事録は単に会議の記録に留まらず、開発以外のビジネス状況やユーザ課題を理解したり、プロジェクトの全体像と背景を包括的に把握する良い機会となります。キーマンの考えやメンバーの不安、プロダクトにかける思いなど、言語化されにくいプロジェクトの状況や空気を捉える機会にもすることができます。
さらに、異なる職能のメンバーとの対話を通じてワンチーム感を醸成したり、要件定義用のドキュメントツールの選定や置き場所、効果的なツール導入提案にもつながったりします。
要件定義手法への慣れ
私は主にRDRA（ラドラ）と呼ばれる要件定義手法を学びましたが、その他の要件定義も学ぶように心がけています。またコンサルファームなどの作成した優れた要件定義資料を見る機会があればできるだけ読むようにしています。
要件定義手法は様々で、クライアントや業界、開発体制、オフショア開発の有無などによっても変わってきます。そうした中でどういったドキュメントや一覧、図があればシステム設計や開発ができるのかを把握しておくと、スムーズな実装準備や手戻り防止を行いやすくなります。
締め切りをサッカーの試合やパスワークでイメージする
開発において締め切りやリリースは重要ですが、スケジュール計画は悩ましいものです。特にプロジェクトゴールから逆算する際のマイルストーンの設定や成果物のフェーズ分け、スケジュール達成に不安を感じがちです。私はこの課題をサッカーの試合やパスワークに例えてイメージするようにしています。
▼ ゴール前へのパス
締め切り時に「何もない」状態を避けるため以下を意識します
- ボール（成果物）をゴール前（キーマン）に必ず渡す
- パスの質よりもまず確実に渡すことを優先
- パスが確実に出せた上で、メンバーの求めているパスの質とタイミングを合わせに行く
▼ 試合の規模に応じたスケジュール管理
締め切りの重要度を、サッカーの大会グレードに例えます
- 親善試合：スプリントレビュー、社内プロトタイプ
- シーズン大会：機能更新、メンテナンス
- ワールドカップ：本番リリース、サイトリニューアル
こうしたアウトプットや連携の結果、各回の「試合に勝つ」ことが重要です。
試合に勝つためには何としても提出を間に合わせる（パスを出す）ようにし、逆に試合の勝敗に影響が少なければ、今は焦らなくても良いとスケジュールや心理的負担を減らしたりするようにしています。
以下の記事で詳しく説明しているのでご参照ください。 goodpatch-tech.hatenablog.com
まとめ
テクニカルディレクターの楽しさと日々心がけている習慣についてご紹介してみました。
テクニカルディレクターの役割は連携することが大きなウェイトを占めており、単独での実装や作業というよりメンバーやチームがいてこそ意義を発揮できます。
これまで様々なプロジェクトで社内外問わず多くの仲間に支えられ、よいプロダクトを目指して頑張ってこられました。そんな仲間の方たちには大変感謝しております。
これからも「楽しい開発」ができることを目指し、よりよいプロダクトからアウトカムへ繋げられるよう努めて行きたいと思います。
Goodpatchではデザイン好きなエンジニアの仲間を募集しています。 少しでもご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！
