TEZUKA

グループ企業が使う訪問販売向けの営業支援ツールのリーダーを担当していました。 会社の予算や方針から、チームメンバーは多少の出入りがあるものの常に私を含めて2人または3人と少人数のチームでしたが、この人数で約1000人の営業マンが毎日利用するツールの開発・運営を行っていました。

このシステムは訪問販売向けの支援ツールとなっており、従来は紙の住宅地図を用いて現地で戸別訪問を行って営業活動をしていたものを、It化したもので、このツールに置き換えたことでシステムが稼働しなければ1000人の営業マンの営業活動が一切停止してしまうというものでした。 したがって、私の最も大きな責務としては安定稼働が至上命題でした。 その次の責務としては、現場からの要望を吸い上げ、少しでもより効率的な営業活動につながるツールとして改良を重ねていき、現場の営業機会を1件でも増やすというのが目標でした。

まず、最も重要であると考えたのはシステムの冗長性です。 当時、弊社内ではまだAWSのインフラを活用したシステム開発は誰も手を付けたことがなく、発注先の会社から環境を引き継いだ際には様々なことを手探りで学びながら進まなければいけない状況でした。 そうした中、引き継いだ環境を調査したところ、当時の環境はセキュリティに配慮したシステム構成になっているものの、冗長性が担保されておらず、システム上になにか問題が発生するとすぐに全体が止まってしまう構成となっていることがわかりました。 そこで私が真っ先に手を付けたのは、システムの多重化でした。 AWSを活用すること自体が初めてだったことからすべての項目について学びながらではありましたが、書籍やネットに公開されている情報を頼りに、フロントのWebサーバとバックのAPIサーバについて多重化する構成へと移行。またコストを抑えながらもさらなる冗長性を担保するため、複数のサーバについては予備機を用意し、普段は停止状態でありながら監視システムが異常を検知すると自動的に予備機を起動するコールドスタンバイの構成を実現しました。 この過程で、当初はEC2＋RDSのみを利用していたシンプルな構成だったシステムは、ELBやLmbda、CloudWatchといった各機能を活用する複雑なものへと進化させていきました。 コールドスタンバイの仕組みを導入する過程で実装したEC2の自動起動機能は、後日、システムそのものの自動停止・起動にも活用できる（グループ内の営業マンが利用するシステムのため、夜間は停止することが可能）ことがわかり、営業時間外はシステムを停止することで、システムの運用コスト削減にも大きくつなげることができました。 また、そのほかの問題点としては開発にあたっての人的リソースの少なさがありました。 継続的な機能改善が求められていたものの、当時の社内の他のチームが大きなプロジェクトを抱えていたことから、本プロジェクトにかかわれるメンバーは2，3人と非常に少なく、十分なタスクを並行させることができませんでした。 そのため、チームリーダーとして現場の営業担当者らと密な調整を行い、上がっている機能改善、要望の中でどれがよりコアなドメイン機能に近く、どの項目を改善すれば最小工数で最大効率を上げることができるのかを調べ上げて、タスクの優先度を決めていきました。 少人数で運営している中、AWSシステムそのものに障害が発生したケースがあり、時には、数時間完全にシステムが停止してしまう状態に陥るようなこともありました。 そのような時には、何とか利用可能なリソースでシステムを1分1秒でも早く再稼働できるように対応策を調査・検討し、迅速な障害復旧へと勤めました。 障害発生後は、自社内では知見が不足していたことから代理店のエンジニアにも積極的に問い合わせを行って原因の調査と対策を追求。 蓄積した知見を積極的に活用し、少しずつ堅牢なシステムへと発展させることができました。

前述の営業支援ツールの、リニューアルプロジェクトのプロジェクトマネージャーを務めています。 チームメンバーの募集から担当し、現在は9人のチームを纏めて、グループ企業の各部署と調整を行いながらプロジェクトの進行をしています。

リニューアルするシステムは、グループの基本業務となる訪問販売の営業支援に利用されるツールで、この **システムを既存システムの安定稼働を維持しつつ、新規リニューアルを行うこと** が求められています。 またリニューアルに当たっては、既存のシステムで生じている問題（システムの技術的負債の精算、現場要望への対応の遅れ、システムの担当者以外への理解不足による属人化の解消など）の解決が必要とされ、そのための計画立案から行う必要がありました。

このチームは、プロジェクト発足に当たり新たに募集して集められたチームメンバーで構成されており、チームメンバーが互いに知らないだけでなく、どのメンバーも当然ながら訪問販売営業という業務への理解が不足していました。 このことから、まずはチームメンバーが業務に対して理解を深めるための時間が必要と判断しました。 元々求められていたことが、既存システムの安定稼働を維持することもあったため、チームメンバーにはまず、時間をかけて既存システムの調査を行ってもらい、既存システムを解析するところから業務への理解を深めてもらう時間を取りました。 当然ながら、システムの解析だけでは「なぜこのような形になっているのか」の理解には及ばないことも多いため、その点については私の方から細かく説明を行うことでクリアをしていきました。 また私自身も、既存システムを担当してはいたものの、訪問販売営業の実務経験はなく、当初は停止して終了する予定となっていたことから、約1年程度システムが放置状態となっており、その間に現場の業務が変化した内容については把握できていませんでした。 チームメンバー全員が「なにをつくればよいのか」がわからない状況にあったことから、リニューアルプロジェクトではDDDの手法を用いた開発を行っていくという決断を行い、既存システムの解析が概ね完了し、メンバーに基本業務知識が身についたところで、グループ内の営業部門に声をかけて、毎週2回の定例ミーティングの場を設定。 ドメインエキスパートからドメイン知識の移譲を行うため、約半年間にわたり、このミーティング内で業務のヒアリング、ドメインモデリングを進めました。 ミーティングの席上では、自ら会議の進行を務め、営業部門の人たちとエンジニアが認識の齟齬なく意思疎通ができるようにするため、できるだけ平易な言葉で解説を尽くすことを意識していました。 ドメインモデル図を作成して業務をモデル化し、ユビキタス言語の統一。 この過程を、エンジニア全体で参加して徹底的に議論することで、チームメンバー全員がドメインに対して正しく理解を深められる機会となるよう、時間をかけてきました。 結果として、営業部門の担当者も気づけていなかったドメインの認識に対する転換を数度行うことができ、2024年2月からはいよいよ実装に着手するというフェーズに入っています。 営業部門の担当者が他のミーティングに参加する必要性から会議に不参加となった際にはあまり議論が進められないなどの問題があり、当初想定のスケジュールよりも若干遅れが出ている状況ではありますが、ここでエンジニアメンバーの認識がズレてしまっている場合には、今後の作業工程で大きなズレとして問題になる可能性が高いと判断したことから、多少の時間をかけてでも徹底して議論を尽くすべきと考え、またDDDおよびアジャイル開発の精神に基づいて、描いてきたドメインが途中で変更されることをいとわず取り組んできたことで、システムのリニューアルにふさわしい設計に着々と近づけているという実感を日々感じています。