アーカイブ動画

3つの事例で語る、大規模案件におけるプロマネの極意とは？

セッション前半は、TIS株式会社で大規模案件を手がけるクレジットプラットフォーム第1部の萩谷健太氏、西潟秋穂氏、河田光将氏の3名が登壇した。

クレジットプラットフォーム第1部は、2008年の大型クレジット業務期間システム更改のリリースから現在まで、年間約2000人月規模のアプリ保守開発を実施。クレジット決済の基幹システム保守開発という、社会の重要なインフラを支えている。

本セッションでは、「品質重視の大規模案件」「納期重視の法令案件」「エンハンスメント案件」という3つの特性が異なる案件をもとに、PMに求められるスキルや組織作りについて語られた。

▲左から、TIS株式会社 金融事業本部 クレジットプラットフォーム第1部 主任 萩谷 健太氏、西潟 秋穂氏、河田 光将氏

【Case１：品質重視の大規模案件】

まず紹介されたのは、信用情報を精査する仲介システムを廃止・統合する案件である。 これまで利用していた他社のデータチェックシステム廃止に伴い、同機能をTIS株式会社の基幹システムに一本化。その上で外部の信用機関に保管管理するというものだ。

信用情報とはそのまま、個人の契約内容や支払情報など、まさに個人情報の塊。万が一間違った情報を外部に送ってしまうと、法令違反となる可能性があった。

そこで品質を第一に考え、開発手法はウォーターフォールにすることを決めた。

本来であれば、本番環境と同様の環境でテストが必要だったが、本番環境と同様のデータがあるわけではなく、同取り組みを行うことは難しかった。また、本番環境でテストする際に、実業務に影響を及ぼすわけにはいかない。そこで、テスト方法の検討を重ねていった。

「テスト環境と本番環境を並行して稼働する、いわゆる並行稼動テストを行うことにしました。本番環境でのテストにおいては実業務への影響を回避するために、機能を新規で作成、既存機能も同じく、意図的にコピーして新規作成するなどの配慮を施しました」（西潟氏）

このような配慮が奏功し、不具合なく全処理において質の高いテストが実行できた。品質の担保を最初に考え、どのような手法があるかを検討する。その上で取捨選択し、実行可能な計画とすることが品質重視案件では重要であり、求められるスキルだと西潟氏は強調した。

【Case２：納期必達、スピード重視案件】

続いてはスピード重視、納期必達案件だ。「割賦販売改正法」公布に伴い、施行日までに絶対、かつ正常に法令体制を構築し、順守体制を整える必要があった。

まずは徹底的なリスクのあぶり出しを行った。納期必達はもちろんだが、品質を落とすことも許されない。そこで、マンパワーを大量投入するオフショア開発が検討された。

ポイントは、さらにリスク分析を行った点だ。具体的には、オフショア人員を大量に投入することのリスクである。具体的には、言葉の壁によるコミュニケーションロス、大量メンバーによる知識のばらつき、仕事ぶりが見えづらいなどのリスクが浮かびあがってきた。

これらのリスクを解消すべく、日本語・中国語両言語が堪能で、プロジェクトの全体像を理解している人材をブリッジSEとして立てることで、リスクを回避することとした。

「実際、プロジェクトは納期に間に合うことができました。納期必達のスピード案件では、最初の計画段階で徹底的にリスク分析を行い、リスクに対して対策を講じるスキルと経験が、PMに求められるでしょう」（西潟氏）

【Case３：障害対応の自動化システムをSIerからクライアントに提案】

3つ目は、障害対応における自動化システムの提案事例だ。登壇者は、河田氏にバトンタッチされた。

「突発的な障害が発生すると、正確かつ最速の対応が求められるため、どうしてもそちらに労力を奪われることが多く、通常業務に影響が生じることがあります。このような状況を改善するために、一部の業務を自動化できないかと考えました」（河田氏）

とはいっても、自動化はクライアントから依頼されていない。そこで自動化することは多くのメリットがあり、長期的にはコスト削減なども含め、クライアントにも寄与することを、ロジカルかつ視覚的にまとめ、クライアントに提案することを決めた。

上記スライドの赤枠で囲った作業は自動化できると判断。先のメリットも合わせて伝え、実際に自動化システムを構築。エンジニアが対応する業務タスクは半分に減った。

「保守開発案件であっても、自分たちから改善策を見つけること。その内容をきちんとまとめ、メリットがあることをクライアントに伝える提案力が、これからのPMには求められます。また、このような案件の場合は既存の開発プロセスとは異なり、技術要素など自分たちで主導し選択できるので、新たな技術の習得など、メンバーのスキルアップにも寄与すると考えています」（河田氏）

金融レガシーシステム開発PMがモダン技術を習得するためにしたこと

後半のセッションでは、クレジットプラットフォーム第2部から石川貴之氏、塩原雅也氏が登壇した。まずは石川氏が、同部署について説明した。

「我々の部署はアジャイル・スクラム開発を採用することで、お客様と一緒に、短いサイクルで開発を繰り返すことで、顧客のDXを推進する役割を担っています。属人性のないシステム開発を目指し、モダンで新しい技術や開発手法を取り入れています」（石川氏）

▲左から、クレジットプラットフォーム第2部 主査 石川 貴之氏、主査　塩原 雅也氏 石川氏は、優れたプロダクトを開発するためには、

顧客やビジネスに関するドメイン知識、技術力が必要だと述べる。そして、DX、アジャイルやクラウド、内製化といった昨今のトレンドやキーワードを踏まえ、新しい技術のキャッチアップなど、必要な要素を挙げた。

●初期フェーズに必要な知識をまとめて関連づけて学ぶ

続いて登壇した塩原氏は、長年金融ドメインでレガシーなシステムの開発に従事してきたところから、新たに取り組んでいるスキルチェンジや成長について語った。

「お客様のご要望で、アジャイル開発やクラウド活用、マイクロサービスなど、モダンなシステムを構築するプロジェクトが立ち上がりました」（塩原氏）

ところが、塩原氏のこれまでの開発手法はほぼウォーターフォール型であり、アジャイル開発は触れた程度。クラウドに関しては触ったこともなく、オンプレがメイン。マイクロサービスに関しても経験はなく、普段はモノリシックなシステム開発ばかりであった。

プロジェクトの開始は3カ月後、「そもそも自分たちに取り組めるのか、スキル面が最大の課題だった」と、塩原氏は振り返る。開始までの期間を考えると、一つ一つ愚直に勉強していては間に合わないと感じたと、当時を振り返る。

そこでプロジェクトの初期に必要であり、他の技術と比べるとスキルレベルが低いと感じた要素から学ぶことにした。また、それぞれ別々に学習するのではなく、一連の技術としてまとめて勉強するようにした。

たとえばDDDでアプリ設計を行い、マイクロサービスアーキテクチャでモダン言語を用いてAPIサービスを作る、といった具合だ。それぞれの技術を同時に関連づけて学ぶことで、次のような学習成果を得たと塩原氏は振り返る。

「最初は点であった学びが次第に線に、そして面に。しかも、それぞれの技術の相関関係まで理解していきましたから、まさにシナジー効果で、学習の幅が広がっていきました。ただ物理的にはかなりの量を勉強することになるので、正直、かなりきつかったですが（苦笑）」（塩原氏）

このような学習方法が奏功し、結果としてプロジェクト開始まで体裁を整えることができ、プロジェクトも1年でファーストローンチを達成する。同時に、いくつかの学びを得た。

まずは、学ぶべき箇所を取捨選択し集中したことだ。一方で、選ばなかった要素も当然、後の段階では学ぶべき必要があると補足した。またモダン技術であってもこれまでのレガシー的な技術と、完全に分断された異次元の技術ではないこと。

レガシー技術がしっかりと身についていれば、モダンな技術もキャッチアップが比較的短期間で可能であることも分かった。新しい技術に限ったことではないだろうが、実際に手を動かすこと。学習成果を評価してくれる人がいると、学習効果が高まることも改めて学んだ。

今回の経験を踏まえ、現在はチームとして以下のような学習方法を行っている。特に、議論とフィードバックのサイクルをチームでまわすことで学習効果がさらに高まり、チーム全体のスキルレベルの底上げにつなげていく狙いだ。

●SIerのPM経験はモダンな開発案件でも必要

改めて、これまでSIerでキャリアを積んできたスキルが、アジャイル開発においても役立つかのか、主に以下3つの点で紹介した。

１．ドメイン知識
２．SoRの開発経験
３．保守運用

ドメイン知識においては、特にアジャイル開発の場合は、内製・アジャイル案件が多く、PO（プロダクトオーナー）はシステムについての勘所が必要となる。また、開発メンバーはドメイン知識が乏しいことが多く、両者の橋渡しになれるという。

SoRの開発経験については、SIerならではの経験が活かせる。DX案件、アジャイル開発により開発されたマイクロサービス由来のSoEであっても、いわゆるSoRである旧来の基幹システムを存続し、連携することがほとんどだからだ。両システムの勘所ならびに、開発においてトラブルを回避するポイントやノウハウを知っているアドバンテージがあると、塩原氏は説明した。

保守運用面においても、SIerであれば当然行う業務。対して、アジャイル開発を始めたばかりの顧客にとっては知識が乏しい分野である。

「昨今は、ローンチ後も開発チームが運用も行うDevOpsが主流です。つまり、いかに保守運用しやすいシステムを開発できるかが重要であり、長年にわたり同業務に取り組んでいた我々だからこそ、貢献できるノウハウがあると考えています」（塩原氏）

長年レガシーシステムの開発に従事してきたベテランエンジニアでも、やる気と環境（実践の場と協働するチーム）が整えば、スキルアップはできると、塩原氏は力強く述べ、本セッションを締めた。

【Q＆A】参加者から寄せられた質問に登壇者が回答

セッション後、登壇者たちが参加者から寄せられた質問に答えた。

●大規模案件PMについて

Q．オフショア人材の活用に苦労や想定外のリスクについて

西潟： 具体的なプランを示せば、お客様も納得するケースが大半です。想定外の事象においては、今回は対象国である中国には日本の休日とは異なる春節があったこと。日本語では「以上・以下」は対象を含むとの理解ですが、中国では含まないそうで、実装してみたら全く違う仕様になっていたことがありました。

Q．ブリッジSEはどのように調達したのか

西潟：オフシェア開発を採用しようと決めた段階で、日本語・中国語に堪能な人材をピックアップ。その上で一緒に働いてもらい、我々の文化やパーパスを理解してもらった上で、セッションで紹介したフレームワークとしました。

Q．Case3の案件における、企画から実運用開始までの期間

萩谷：企画からお客様に提案するまでは2カ月ほど。そこから実際に運用に至るまでには、4～5カ月ほどでした。大規模な開発や改修といった事案ではありませんが、稼働しているシステムに実装するものですから、最後の運用フェーズで時間を要しました。

●アジャイル開発について

  Q．開発スタイルをモダンにしたことで生じた他部署とのギャップや対応は？

塩原：全社に通じる制度など、私たちの改革や力だけでは及ばない範囲はあり、そこは課題と言えます。実際、現在のプロジェクトはお客様と協力しながら進めるスタイルですが、自社のサポート不足を感じています。これから試行錯誤を重ね、改善していくつもりです。

石川：ギャップの違いで苦労することは多々あります。その点においては、マネジメント層を中心に啓蒙活動をしていこうと考えています。啓蒙活動においては我々だけでなく、お客様側もプロダクトオーナーがスクラム研修に参加していただき、資格を取得してもらうなど、新たな開発文化の醸成も含め広げていく必要があると考えています。

Q．学習モチベーションはどこから出てくるのか。低いメンバーへの対応策は？

塩原：個人の意見ですが、新しい技術を学ばないとこの先エンジニアとして居場所がなくなってしまう、このような危機感が一番大きな要因です。若手の技術者も同様だと感じています。実際、我々のチームでモチベーションの低いメンバーはいませんし、嫌々学習しているような人も見かけません。

河田：我々も同様に危機感を感じており、アジャイル開発に関する勉強会に参加したり、スクラムマスターの資格を取得するなど、多くのメンバーが能動的に勉強しています。

TIS株式会社
https://www.tis.co.jp/

TIS株式会社の採用情報
https://www.tis.co.jp/saiyo.html