ban

新規開発を終えた3PLシステムについて、機能追加を行うために企画フェーズから参画し、要件定義～開発・テストまで一貫して行った。 開発した機能としては以下がある。 - 大手ECサイトと連携し、注文情報を自動連係、自動出荷する - D2Cサイトと連携し、注文情報を自動連係、自動出荷する - 3PLシステム内の在庫や入出荷等のトランザクション情報から請求金額を自動算出する - 自前で基幹システムを持つ大規模顧客のシステムと連結し、出荷情報の取得やその実績の返却等を行う 開発フェーズにおいて、私はPMOとして参画してプロジェクトの牽引を行いつつも、自身で開発やテストにもかかわった。開発チームの規模は2～10名程度。

ロボットを強みとした物流倉庫でのサービス（フルフィルメントサービス）立ち上げから参画し、その後の保守運用まで行った。 システムは主にユーザーが荷物を預けたり出荷するために使用するユーザー側のWebシステムと倉庫内の物品・作業管理や自動化を制御する倉庫側のバッチシステムに分かれるが、私はユーザー側のWebシステムを担当した。 マネージャーポジションではあるが、自身でもアーキテクチャデザインから開発・構築を主導している。参画当初はシステムの設計不備（主に選定したパッケージによるもの）によりほぼ破綻していたプロジェクトを再設計しなおし、内製開発チームを立ち上げ、リリースまで導くことができた。 担当するWebシステムはクラウドサービス"Microsoft Azure"のAzure Functionsというサーバレスアーキテクチャを採用し、スケールしやすく、システムを疎結合に保っている。これにより、OMS(Order Management Sysytem)やECサイト、ユーザー企業の基幹システム等に柔軟に連携することが可能になっている。小規模ユーザー向けにWebブラウザから利用できるポータルサイトも用意している。加えて、システムを疎結合にしたことでサブシステム単位で開発者に業務割り振りができ、効率の良い開発作業を行うことができた。 主な使用技術はNode.js、MySQLが主で、その他フロントエンドにVue.js、自動テストにkarateを採用した。 サービスローンチ後は私のほかのPMポジションが１人、開発担当者が10～20名程度いた。私は開発プロジェクトのマネジメントのほか、非技術部門とのコミュニケーションも行い、会社のサービスの提案・設計・要件策定を行っている。ここでの要件策定後、自部署に展開し、私がプロジェクト担当になれば開発者のマネジメントをしたり、場合によっては私自身が設計・開発・試験からリリースまでを行う。ただし、私は担当システムの専任アーキテクトであるため、担当外のプロジェクトであっても私が設計のレビューを必ず行う。 サービスの初期リリース後も、自動で請求金額の算出・請求書の送付等を行える請求システムを開発したり、Yahoo!ショッピング・Shopify等のショッピングモールや個別顧客のECサイトとの連携を連携先企業担当者とやりとりしながらAPI連携したりと様々なシステム拡張を主導した。

航空券やホテルなど、複数の旅行関連のサービスを運営している会社（Online Travel Agent : OTA）にエンジニアリングマネージャーとして参加した。 内製による開発を行っているが、私の入社前はドキュメントが全くなかったり、試験が部分的に・場当たり的にしか行われていなかったり、プロジェクト管理を行う者が不在だったりと開発チームの運営がほぼ機能不全に陥っていた。結果として新規案件は全面開発停止するものの、既存バグ改修でさらなる障害が発生したり、新規入場者がシステムを理解不能でパフォーマンスを発揮できずと大きな問題が多発していた。 私はこの立て直しのために入社した。 入社後すぐに各サービスを開発する各開発チーム全体を横串で支援するチームを発足させ、開発部全体の立て直しを図った（人選自体は入社前にお願いしておいた）。主に取り組んだことは以下である。 ・PMOチームの発足 これは一般的な意味でのPMOではなく、実際のプロジェクト管理を直接的に支援するというより、規定・方針・ツール類の整備等を行い間接的にプロジェクト管理を支援するものである。 具体的には以下のことを行った。 ① プロジェクト管理ツールの使用方法について整備した。 プロジェクト管理ツールが導入されていたが、単なる備忘録としか使用されておらず、各人がバラバラな場所でタスクを起票していたので、プロジェクト管理ができていなかった。 まずはタスクを管理するプロジェクトを管理単位（各サービス単位）で統合し、タスク状態が見えるようステータス管理や担当者アサイン状況、見積もり工数の入力の徹底を行った。 これにより、いつだれが何をやっていていつ終わるのか、次に取り組む案件は何でいつから開始できるのか、等の見える化ができた。その結果、依頼元のビジネスサイドに状況の共有ができるようになり、また人員計画の適正化ができるようになった。 ② ドキュメントの標準化を行い、各チームでどのようなドキュメントをどのように作成したらよいかを提示した。 従来はドキュメントの作成がほぼ行われておらず、また退職者からの引継ぎも完全とは言えずに、現行システムの要件・仕様・設計等を知ることはソースコードを読み解くしかなかった。このため、開発スピードに大きな悪影響を与えていたし、新規入場者も開発参加までに非常に時間がかかっていた。 とはいえ、ドキュメント作成には非常にマンパワーが必要であるし、ドキュメント作成後もメンテナンスのコストがかかる。そのため、開発現場にヒアリングして必要性の高いドキュメントを洗い出し、特に優先度が高いドキュメントからテンプレートを準備して配布し、各開発チームの負担を極力少なくドキュメント作成に取り掛かれるようにした。 これによって開発チーム間の技術交流も図れるようになった。 ③ プロジェクト体制の明確化を行い誰がどんな役割を持っているかを容易に確認できるようにした。 これまでは開発組織外も含めて誰がどんな役割を持っているかが不明確で、何かしら問題が起こった際に誰に確認すればよいかが不明確であった。責任も不明確で、要件や仕様があいまいなまま開発が始まり、リリース後に想定と違うために再改修を行うということが多々あった。 組織の歴史的な経緯からビジネス要件を考える部署が二つに分かれてしまっていたのも責任の希薄化の一端があった。 開発部外の役割の定義まで私が行うのは無理があったので、反対にどういった役割が必要か（プロジェクトオーナー、開発PM、UX担当など）から定義してテンプレート化し、プロジェクトあるいはプロダクト毎に役割を埋めてもらうことにすることで、責任の明確化ができ、担当者の確認もスムースにできるようになった。 ・QAチームの発足 システム開発においてこれまで試験は俗人的・場当たり的に行われており、品質が非常に低い状態であった。しかし、システムに関するドキュメントもなく、設計方針もないまま長年保守されてきたのでシステムは読み解く（リバースエンジニアリングする）には複雑すぎて単体試験始め試験をしっかり行うにはかなり難易度が高かった。そこで、最低限エンドユーザーから見える部分だけは正常化しようとまずはエンドユーザー目線で要件通り動作するかの試験を行うQAチームを発足した。 ただし、まずは要件の確認から必要であったり、体系的に試験を行う知見がなかったので外部ベンダーに委託して試験実施を依頼した。現状は一部プロダクトの限定的な範囲での試験実施を行えているのみであるが、リリース前にエンドユーザーから見えてしまう障害を概ね除去できるようになってきているので、リリース後のロールバック回数は減りつつある。 ・インフラの見直し インフラ起因での障害が多発していたものの、専任担当者が不在で対応が後手になりがちであった。インフラ自体、マネージドサービスはほぼ使用せずにLinux仮想マシン上で構築・運用されていたので、インフラ使用のコストは抑えられていたが、運用コストは非常にかかってしまっていた。 まずはクラウドネイティブなシステムにする方針は立てたものの、アプリケーション側の対応だったりと長期的な計画にならざるを得ないので、まずはApacheやMySQLといったミドルウェアのパラメータの見直しと監視システムの閾値の調整を行い、ある程度はパフォーマンスの向上が出来たとともに、障害が起こる前になるべく検知できるようにした。 上記のほか、プロジェクトマネージャーとして５つのサービスの開発チームを管理した。チーム規模としては業務委託を含めて10名程度。ビジネスサイドからはそれまで統制がとられずに場当たり的に依頼がされていた状態であったので、一旦依頼は私が受けて、要件や依頼の優先度等を確認し、開発チームとの橋渡しを行うようにした。また、そもそもの依頼目的が不明瞭であったものが多かったので、ビジネスサイドに依頼のビジネスインパクトの確認をしたり、場合によってはビジネスサイドと一緒にサービスロードマップを検討しなおしたりした。 その結果、真に優先度の高い、会社（エンドユーザーやビジネスパートナー）への貢献度の高い案件に集中できるようになった。