エンジニアの仕事は「プログラミング」だけではない　DeNA入社後に感じたギャップとそれを克服するためのPM術

エンジニアの働き方イメージのギャップと克服

川原遼馬氏（以下、川原）：それでは「エンジニアが入社後のギャップを克服しProjectをリードするまで」というタイトルで発表します。

私は川原遼馬と申します。大学院で物理の研究をした後に、2020年にDeNAに新卒入社しました。その後、DeNAの子会社である株式会社DeNAライフサイエンスの「MYCODE」というサービスで、サーバーサイドエンジニアをしています。

「MYCODE」というサービスは、唾液を郵送することで簡単にできる遺伝子検査サービスです。遺伝子検査をすることで、病気リスク、体質、祖先の分類を簡単に調べられます。

それでは、このセッションで伝えたいことを話します。私はDeNAに入社後に、エンジニアの働き方に自分のイメージとのギャップを感じました。しかし、そのギャップを克服するために、プロジェクトマネジメントの力を伸ばすことで、要件定義からリリースまでをチームで協力して進行できるエンジニアに近づけたという話を、体験談を交えて話したいと思っています。

それでは、入社後のギャップとはなんだったのかについて話していきます。私がDeNAに入社する前のエンジニアのイメージは、仕事の大半はプログラミングである、というようなイメージを持っていました。

リリースまでのサイクルが、要件定義、実装、検証、リリースといった4つの段階で分かれるとすると、実装の部分だけがエンジニアの仕事であり、他の部分にはそこまで主体的に関わらない、といったイメージを持っていました。

しかし、実際にDeNAに入社してみると、まずリリースまでのフローがたくさんある、ということに気づきました。そして実装が主な部分である、ということは変わらなかったのですが、プロジェクト全体の進行は自分が主体的にやる必要がある、ということに気づきました。

また、関係者のイメージも違いました。入社前の関係者のイメージは、エンジニアとその機能を要件定義する人、だいたい2、3人ぐらいで議論していくような小規模なイメージを持っていました。

しかし実際には、他にもいろいろな方とコミュニケーションを取る必要がある、ということに気づきました。例えば実装以外の部分でいうと、お客さまからの問い合わせにどう対応するか、といったことをCSの方と密にコミュニケーションを取る必要などがありました。

こういったギャップを感じていく中で、私が大きく2つ感じた要件定義とスケジュール管理に関するギャップについて、本セッションでは話したいと思います。そして、これらについて後から考えてみると、プロジェクトマネジメントの問題であった、ということを最後に話していきたいと思います。

「SNSログイン」のプロジェクト

これらのギャップを具体的に話すために、私が実際にやったプロジェクトの1つである、SNSログインについて話します。

「MYCODE」では、パスワードと秘密の質問のログインしか使えなかったために、久しぶりに「MYCODE」にログインしようとすると、パスワードを忘れてしまってログインできない。そしてその結果、CSに定期的にお問合せが発生してしまっている、という課題がありました。

技術的な内容は省略しますが、SNSログインの最終的な構成はこのようになりました。第1認証としてSNSログインをした後に、第2認証としてショートメッセージ認証も導入する、という構成になりました。

「要件定義」のギャップ

それでは、この具体例を使って、入社後に感じたギャップの要件定義とスケジュール管理について話していきます。

まず始めに話すギャップは、リリースまでのイメージでいうと、一番左の要件定義に関するギャップです。私は学生時代、要件定義をするのはビジネス職の方であって、エンジニアが主体的に関わることはない、というようなイメージを持っていました。

しかし実際には、エンジニアが主体的に要件定義をしていく必要があることが、1つ目の大きなギャップとして感じました。

要件定義に関する失敗がこちらになります。それは「SNSログインできたほうが便利」「問い合わせが減りそう」といった、曖昧な要件でプロジェクトを着手し始めてしまった、という失敗です。

これをしたことによって起きた問題が、やることが増えた時に目的とコストが釣り合わなくなった、という問題を起こしてしまいました。というのも、SNSログインの導入を検討し始めた当初は、あまりやることも見えていなかったために、だいたい1ヶ月ぐらいで終わりそう、というようなイメージを持っていました。

しかし実際に着手し始めてみると、既存の認証の実装がどうなっているのか、そしてそれを「この部分を改修しなければいけない」であったり、システム異常時に会員さまからどういった問い合わせが来るのか整理する必要があったり、追加されたやることがドンドン増えていきました。

そうすると、最初は1ヶ月程度で終わりそうと思っていたものが、2、3ヶ月はかかりそうとなっていきました。その時、最初に考えた曖昧な要件定義ではメリットが少ないので、目的とコストが釣り合わなってしまいました。

こちらが、私が実際にWikiに書いた要件定義です。このように、かなり曖昧な要件定義でプロジェクトに着手し始めてしまいました。

そこで、これを解決するために、まず定量的な評価を行いました。定量的な評価とは、CS工数の削減を、具体的な数字を使って計算することです。「CS工数×ログインに関する問い合わせの割合×削減予想割合」を計算しました。

また、この青文字の部分の削減予想割合を根拠のある数字にするために、実際に会員さまが使われている利用メールアドレスの分布を、分析スクリプトを書いて計算したり、実際にユーザーアンケートを取って、SNSログインの利用規模を調べることで、根拠のある数字にしました。

また、削減予想費用とシステムで追加で掛かってくる費用を引き算して、削減予想を立てました。これに伴って定性的なメリットも、今画面に表示しているように考えることで、曖昧な要件定義を解決しました。これによって、メリットと実装コストが釣り合わなくなる問題を解決できました。

SNSログインでは、最終的に50個の実装タスクが必要だったのですが、一方で10個の要件定義も必要になりました。これは私が当初想定していた数よりも、かなり多かったです。

要件定義について、まとめます。話が進むにつれて、曖昧な要件に対する実装コストの釣り合いが取れなくなるという失敗をしました。これを解決するために、CS工数の削減予想を定量的な数字として評価しました。また、同時に定性的なメリットも整理することで、実装コストとメリットが釣り合わなくなる問題を解決できました。

「スケジュール管理」のギャップ

それでは2つ目に感じた、スケジュール管理に関するギャップについて話します。リリースまでのイメージの図でいうと、法務やセキュリティという部分に関係するギャップになります。

特に今回はSNSログインといった認証が関わる部分だったので、法務やセキュリティといった部分で調査する必要があり、そういった部分でスケジュール管理が大変だった、という話をしていきます。

まずこのスケジュール管理ですが、私は学生時代、まったく意識できていませんでした。しかし実際に働いてみると、プロジェクトの初期段階で、セキュリティや法務といった、リスクと関連して慎重に調査する必要があるというギャップを感じました。

スケジュール管理に関する失敗がこちらです。それは、調査に思ったよりも時間がかかってしまって、スケジュールが遅延したという失敗です。

というのも、SNSログインではセキュリティや法務周りに関する調査を行う必要があったのですが、今画面に映っているような調査内容をプロジェクトの初期段階ではあまり認識できていなかったために、プロジェクトに実際に着手し始めてから、こういった調査をする必要があることが発覚しました。

もちろん、こういった調査内容はスケジュールに組み込まれていなかったので、こういった調査を行う中で、スケジュールがどんどん遅延する失敗をしてしまいました。今回はその中でも、改修仕様の検討といった部分について、具体的に見ていきます。

「改修仕様の検討」での失敗

改修仕様の検討で時間がかかってしまった原因としては、まず機能のパターンが多く、そしてその機能一つひとつに対してセキュリティレビューが必要だったのが原因です。

機能が多いというところでいうと、まずログインのパターンが3つありました。そして、第1認証、第2認証の切り替えをする機能も必要だったために、機能のパターンがどんどん増えていきました。

右側に表示してある画像は、私が実際に書いた仕様書の目次になります。このように機能がどんどん追加されていきました。

そしてこの機能一つひとつに、このようにシーケンス図を作成して、セキュリティ的に抜け・漏れが無いかをセキュリティエンジニアの方にレビューしてもらう必要があったために、さらにスケジュールが遅延してしまいました。

なぜこういったことが起きてしまったかというと、実装内容を初期段階で認識できていなかったからです。そのため、仕様検討・調査によってスケジュールが大幅に遅延してしまいました。

例えばショートメッセージ認証の導入は、当初2週間ぐらいで、そんなにロジックも複雑じゃないから終わるかなと考えていました。

しかし、実際にタスクに着手してみると、ショートメッセージが実はランダムで到達しないことがあって、そういう時どうすればいいのかであったり。そもそもショートメッセージを発信するためにクラウドサービスを導入する必要があって、そのクラウドサービス自体のセキュリティもちゃんとチェックする必要がある、といったふうに、やることがどんどん増えていって、スケジュールが遅延してしまいました。

こういった問題を解決するために、私は、あらかじめリスクを洗い出す対策をしています。例えば「SNSが乗っ取られたら」「SNSに障害が発生したらどうするのか」といったリスクを最初の段階で考えておきます。

今回はその中でも「ショートメッセージ認証の実装が思ってたよりも難しかったら」ということについて考えていきます。

ショートメッセージ認証の実装が思ってたよりも難しかったら

このリスクに対して、もう少し必要そうな作業を分解していきます。例えば、会員さまが携帯電話をなくしたら、CSのフローを構築して対処できるのか。それともパスワードリセットをしてもらうことで、会員さまご自身で復帰してもらえるのか、ということを考える必要があります。

こうやって、ある程度分解した段階で、このように、タスク一つひとつに対して工数を見積もっていきます。このようにすることで、最初の「ショートメッセージ認証の導入」といった曖昧なタスクよりは、かなり正確に見積もれるようになっていきました。

それでは、スケジュール管理についてまとめます。実装内容の詳細を認識できずにスケジュールが遅延する、という失敗をしてしまいました。これの対策として、今話したように、リスクを洗い出して分解して、より小さいタスクの単位で見積もることで、防げるようになりました。

また、この「リスクを洗い出す」といった部分に関しては、よくわからない場所から調査することを意識しています。よくわからない場所というのは、例えば外部の協力者が必要で、その協力者が今他のタスクで忙しくて、こちらにあまり時間が割けなかったり、そもそも自分がSNSログインの技術的な仕様をうまく理解できていないところは、後から認識していなかったやることがどんどん出てきやすい場所になるので、こういった場所からなるべく早く調査するようにしています。

プロジェクトマネジメントでの失敗

ここまでで、入社後のギャップの要件定義とスケジュール管理の2つについて見てきたのですが、これらはすべてプログラミング以外の部分ということに気づくかと思います。

リリースまでのイメージの図でいうと、実装に入る前までの青枠の部分で私は失敗をして、プロジェクトがうまく進まない事態に陥ってしまいました。

これらを、プロジェクトマネジメントでの失敗、という観点で振り返ってみたいと思います。要件定義は曖昧なままスタートして、スコープが増えるにつれてコストが大きくなり、釣り合いが取れなくなる、という失敗をしました。

スケジュール管理は、調査や手戻りに時間がかかり、スケジュールが大幅に遅延するようなことをしてしまいました。

こういった悩みを持つ中で、私は1on1でメンターに相談しました。DeNAでは定期的に1on1をする機会があり、自分がつまずいている問題や悩みごとについて、気軽に相談できるような文化があります。

その1on1の中で、プロジェクトマネジメントについて書かれた本である『アジャイルサムライ——達人開発者への道』という書籍について、教えてもらいました。その本を読んでみると、自分がなぜかつまずいていると思っていたポイントは、実はすでによく知られている問題だということに気づきました。

そのため、プロジェクトマネジメントを学べば、自分はもっと効率よく仕事を進められるのではないかと考え始めました。

実際にプロジェクトマネジメントについて学んでみると、「要件定義」「やることの決め方」「プロジェクトでよく起こる問題」といった、私がよくつまずいていた問題について解説されていました。そういった重要な事柄をテンプレートとしてまとめたものが、「インセプションデッキ」という手法になります。

「インセプションデッキ」とは

プロジェクトマネジメントには、インセプションデッキの他にもいろいろなメソッドがありますが、今回はこのインセプションデッキについて話して、終わりにしたいと思います。

インセプションデッキとは、このようにプロジェクトでドキュメント化するべき項目をまとめたものになります。例えば目的は「簡単なログイン機能を提供。プロジェクトのスコープ、Googleログインは今回実装するけど、他のSNSログインは実装しない」といったことをまとめていきます。

今回は、このインセプションデッキを使って、調査に時間がかかりスケジュールが遅延した問題について、考え直していきます。

今画面に映っているような調査内容を、プロジェクトの初期段階で認識できずに、実際に着手し始めてから発覚して、スケジュールが遅延した問題を考えていきます。

インセプションデッキの中で、スケジュールの見積りに関係するものを抜粋しました。まずプロジェクトのスコープについて考えていきたいと思います。

プロジェクトのスコープでは「やること」「やらないこと」「後で決めること」を考えていきます。「後で決めること」というのは、今決める必要はないけど、少し決めるのが大変そうだから、いったんここに放置しておくといった項目になります。

この中で「やること」について考えていきます。今回のプロジェクトでは「やること」はSNSログイン。そしてセキュリティをもっと強化するために導入するショートメッセージ認証の2つになります。

この「やること」をもう少し分解していきます。例えばSNSログインであれば、Googleログインだけを実装する。そしてSNS自体が乗っ取られた時の対策も行う。ショートメッセージ認証は、クラウドサービスを導入してショートメッセージを発信できるようにする。そしてショートメッセージ自体に対する攻撃にも対策を行う。と、いったふうに分解していきます。

ここまで分解した後に、プロジェクトの体制について考えていきます。今回考えた「やること」の中で、エンジニアだけではできないことを考えてみると、乗っ取り対策や攻撃の対策には、セキュリティ部の人や法務部の法的な見解を議論することが必要になってくるかと思います。

このように、やることを考えてプロジェクト体制を考えることで、このプロジェクトにどういった関係者が必要なのか、ということが見えてくると思います。

ここまで考えたうえで、この中で大変そうな部分に注目してみます。今回であれば、外部の協力者が必要な、ちょうど青文字の部分が大変な部分に該当するかと思います。

ここで、プロジェクトのリスクについて考えていきます。例えば、セキュリティ対策で時間がかかりそうであったり、SNSが乗っ取られた場合すべての責任は「MYCODE」にあるのか、そもそも遺伝子情報を扱うサービスがSNSログインを使っても法的に大丈夫なのか、といったリスクを考えていきます。

そしてこのリスク一つひとつに対して、リスクを軽減するためにできることを考えていきます。例えば、セキュリティ対策であれば、社内の他の事業部が何をしているのか聞きにいくといった対策を立てられます。

こういった対策をしていく中で、見落としていたリスクに気づくようになります。例えば、今画面に映っていたような、以前はプロジェクトの初期段階で見えていなかった内容も、インセプションデッキを使うことで、プロジェクトのかなり初期の段階で認識できるようになります。

こういった作業内容をあらかじめ認識しておくことで、スケジュールが遅延する問題を未然に防げるようになりました。このように、プロジェクトマネジメントの手法を使うことで、よくある問題を回避できるようになります。

プロジェクトの各ステップで問題はよくあるのですが、私はその問題一つひとつに対して失敗をしてしまい、問題が発生してしまっていました。

しかし、プロジェクトマネジメントの手法をうまく使うことで、すべてとはいえないまでも、ある程度よくある問題を回避できるようになっていきました。

ギャップ克服のために、プロマネの手法を取り入れる

それでは本セッションについてまとめたいと思います。私は入社後に2つのギャップを感じました。1つ目は、エンジニアが主体的に要件定義をする必要がある。2つ目は、プロジェクト自体のスケジュール管理をすることが大切。というギャップです。

そしてそれらのギャップを克服するために、プロジェクトマネジメントの手法を取り入れることで、うまく解決できるようになりました。

最後に、得られた学びについて話したいと思います。まず、新しいことを始める時、理想とのギャップは必ずあると考えました。そして、そのギャップを私は最初ネガティブなものとして捉えていたのですが、今回のように、プロジェクトマネジメントの手法を学ぶ機会と捉えることで、要件定義からリリースまでを、関係者を巻き込みながらリードできるエンジニアに近づけたのではないか、と考えています。以上で発表を終わります。

「認識の抜けを埋める」には？

司会者：川原さん、ありがとうございました。それではQ＆セッションに移りたいと思いますが、最初の質問はこちらです。「認識の抜けを埋めるのって、認識ができていないから難しそう」と。確かに。

川原：（笑）。

司会者：「頭で想像するだけじゃなくて、文字に起こして切り分けて整理するといいのかな。」というような質問がありましたが、こちらはどうでしょうか。

川原：私は、まさにこういった問題を考えていたので、インセプションデッキとか、プロジェクトマネジメントについての本を読みました。

インセプションデッキを知り始めた当初は、自分で文字に起こしてやっていけば、こういった認識の漏れを防げるのではないかと考えていました。

なのですけど、実際はそれでも、やはり認識の漏れは、ご指摘いただいたように起こりました。なので、今では先ほどのスライドで解説したような、プロジェクト体制までを考えたうえで、その関係者の人に「今こういう感じでやることを考えているんですけど、他にもやることはありますか」というように他の人と議論していくことで、自分だけでは気がつかなかった漏れに気づけるようになったのかな、と思っています。

司会者：他者の視点を入れることによって、1人の脳みそだけではちょっと考えられないところも補完していく。そのためのフォーマットとしてのインセプションデッキっていうかたちなんですかね。

川原：はい。

プロマネ研修とスクラム研修

司会者：ありがとうございます。それでは次の質問にいきたいと思います。「プロジェクトマネジメントの学習については、個人的に学習されていますか。それとも、会社で学ぶ機会などがあれば教えてほしいです。」というような質問ですが、こちらはいかがでしょうか。

川原：はい。最初は自分で、スライドで説明したような『アジャイルサムライ——達人開発者への道』といった本を使って勉強しました。ちょうどその自分が学習したタイミングで、会社の研修としてプロジェクトマネジメント研修とスクラム研修が開催されていたので、それに応募して、会社でも学べました。

司会者：最近だと、年に2回ぐらいのペースで、プロジェクトマネジメント研修が行われているので、任意で誰でも受けられるかたちになっていますね。

はい。それではお時間となりましたので、こちらで質疑応答並びに本セッションを終了いたします。視聴していただいたみなさま、川原さん、ありがとうございました。

川原：ありがとうございました。