テクニカルディレクション/開発ディレクション・エンジニアリングの仕事をする上で大切にしていることは何ですか？

「僕は、クライアントが"本当に求めていること"を明確にしてあげることを意識しています。必ずしもクライアント自身が最適な方法をわかっているわけではありませんし、私たちINIがコンサル、PM、デザイン、開発のセクションの垣根を超えて、クライアントと同じ目線を向いて考え、意見を出しあうことが大切だと思っています。」

「クライアントだけではなく、その先にいるエンドユーザーへの体験価値をいかに向上させられるか。それが私たちが大切にしたいことです。そのためにも、各工程をしっかりとつなぐディレクションが大切だと感じています。」

「その通りだと思います。プロジェクトの規模にもよりますが、社内の各領域の担当だけではなく、クライアント、社外のパートナーなど多くの人が関わります。その中で私自身も、"それぞれの関係者の橋渡しとなること"を意識して取り組んでいます。前提にある知識や定義なども異なる場合もありますので、齟齬を生まないよう、わかりやすく、丁寧なコミュニケーションを心がけています。」

「大規模プロジェクトになればなるほど、開発の遅延や予期しないエラー、問題なども発生しやすくなりますもんね。そのようなリスクを早めに察知し、対応策の検討をするためにも、プロジェクトの関係者とは密にコミュニケーションを取り、スムーズに進行できるよう要件定義の策定などを意識しています。」

「プロジェクトのゴール・目的を常に捉えることで、先回りができるんだと思います。実装フェーズになると、作ることが目的化してしまうこともありますからね。作業が分業化されると、そこにコミュニケーションの歪みが生まれてしまい、"何のための機能何だっけ？"と、当初の目的を忘れた成果物が出来上がってしまうことも多いと聞きますが、目的さえ全員で共有し、一本の筋で通しておけばズレは起きにくいはずですから。」

「そうですね。クライアントの目的を重視し、実現のためのコミュニケーションを積極的に取っていくことが大切ですよね。そういったことが当たり前にできることが、INIの強みだと思っています。」

取り組まれているプロジェクトや仕事内容を教えてください。

「私は大手メーカー案件のテクニカルディレクター・開発ディレクターとしてプロジェクトに参画しています。クライアントが実現したいものを叶えるために、機能面の実装だけではなく、情報設計、デザインといった前工程からも仕様のレビューを行い、必要に応じて目的が何かを探り直して、再検討を促すこともあります。

テクニカルディレクターの役割は実装以降のクオリティ担保だけだと思われるかもしれませんが、前工程の成果物がクライアントの目的を果たせるものでなければ、実装そのものも形骸化してしまいますからね。」

「一般的に言われているテクニカルディレクターという職種の範疇を超えているかもしれませんね（笑）。ですが、それがINIの強みでもあると思いますので、私も今後も意識したいです。」

「私が担当しているプロジェクトは、大手消費財メーカーのオウンドメディアのリニューアルプロジェクトですね。もともとフルスクラッチで運用されていたのですが、エンドユーザーにて運用していくにあたり、テクニカルディレクター・開発ディレクターとして要件定義から構築後の公開手順の整備・ドキュメント化などの運用支援まで一貫して携わっています。」

「僕は三菱電機ビルソリューションズ株式会社様のプロジェクトですね。テクニカルディレクター・開発ディレクターとして、要件定義、設計レビュー、CMS設計、テスト設計、開発進行管理、コードレビュー（品質管理）を行いました。

INIの社内では、これまでのプロジェクトで活用した要件定義書、CMS設計書、開発仕様書などのドキュメント類のひな型資料がイントラで共有されています。そして、各プロジェクト後に行っているKPTの振り返りに沿って、随時アップデートを重ね、組織としてのナレッジの積み上げがありますので、効率的に進めることができています。」

参考：三菱電機ビルソリューションズ株式会社様
営業スマート化プロジェクト

https://www.ini.co.jp/portfolio/mebs.html

「私も先ほどお話ししたプロジェクトでは、公開手順をドキュメント化することで公開作業時の事故防止をするとともに、事前にクライアントとも共有することで認識の食い違いを無くすこと、クライアントの要望を明確化し、最適な方針を提示することを心がけていました。そういった一つひとつの取り組みがナレッジとなって、後輩メンバーの成長に繋がったら嬉しいですね。」

「そうですね。属人的な感覚に頼るのではなく、誰がプロジェクトに参画しても早期に一定の品質を提供できることが大切ですし、ドキュメントに落とし込まれていることで、INIの組織としての品質ガイドラインにつながっていますよね。こんな細かいところまでやるの！？と外部のパートナーさんからびっくりされることもありますが（笑）。」

INIらしいな、と感じるところは？

「やはり、クライアントの目的や達成したいことを軸としたコミュニケーションが当たり前にあることですかね。プロジェクトが進行する中で、そういった当初の目的を忘れてしまうことも多分にあると思うのですが、INIでは社内のメンバーはもちろんのこと、社外のパートナーさんにも目的を共有して、特にはプロの視点からアドバイスをもらい、クライアントの成果に共に向き合っていますので、そういったスタンスはこれからも大切にしていきたいです。」

「目的の実現のためには、当初に決めたスケジュールや仕様にこだわりすぎるのではなく、柔軟に対応していくことも大切だと考えています。もちろん、全てが実現できるわけではないですし、優先順位をつけることも必要ですが、そういった背景も含めてしっかりとコミュニケーションを取るところがINIらしいな、と思いますね。」

「そうですね。加えて、先ほどのようにドキュメントを残していくことで、クライアントが実現したい目的・ゴールに対して、"どうしてこうしたのか？"を振り返ることもでき、私たちの学びにもつながると思います。各メンバーがそれぞれのプロジェクトでド様々なキュメントを作っていますが、それを共有し、ベストプラクティスを拾ってINIのスタンダードにしていけば、もっと私たちの標準レベルも引き上がっていくと思います。」

「そうですね。私自身、新卒で入社して初めてプロジェクトを任せてもらえた時も、過去の様々なドキュメントがあったことで"こうやってやれば良いんだ！""こういったポイントをチェックしないといけないんだ！"というガイドにもなり、安心して取り組めた記憶があります。」

「クライアントワークにかかりっきりになると、そういったナレッジの取り組みはおざなりにしがちですけど、ドキュメントを残す文化は意識的に継承していきたいですね。」