IT人材不足の深刻化により、プロダクトオーナー（PO）やスクラムマスター（SM）がプロジェクトマネージャー（PM）の兼務が通常化しています。ですが、それぞれ役割が大きく異なることにより実質PM不在の状態になってしまい、システムの不具合やリリース遅延が多発するというケースが増えています。そんな中、テックリードがプロジェクトマネジメントを兼務することで、プロジェクト状況を劇的に改善することに成功した事例をご紹介します。
T.O氏 プロフィール：
2012年 情報戦略テクノロジーに入社。WEBアプリ開発のリーダー、ITアーキテクトとしてFX証券企業のシステム開発を経験。現在は人材業界のシステム開発現場でテックリードの役割を超えて、顧客と強固なパートナーシップを築きながらプロジェクトの成功に邁進している。
必要だったのはハイスペック人材の確保ではなく、プロジェクトマネジメントの確立
ー 現在のプロジェクトに参画した当初、どのような課題がありましたか？
当時のプロジェクトの状況としては、不具合が多く要件を満たさないため、リリース判定で承認を得られない状態が続いていました。リリース遅延を何度も繰り返し、私が参画した時点で1年半近く遅延していて、最終的には当初スケジュールから約1年越の遅延リリースとなりました。
品質が伴わない原因として、システム評価基準や品質を担保する仕組みが確立されていないことに課題を感じていました。バグチケットを消化しても別の不具合が頻発し、新たなバグチケットが起票されるという手戻りを繰り返す状態。
スケジュールが遅延することで追加要件や変更要望の発生に付随して開発コストも膨れ上がっていました。
その品質の低さの問題への対策案で「ハイスペックなエンジニアを参画させる」、「人を増やして対応する」など単純に人でカバーしていこうとしていて、もっと根本的な品質を上げるための仕組みを整える必要があると感じました。
ー 根本的な仕組みとは、具体的にどのようなことだったのでしょうか。
プロジェクトに参画して遅延や障害が多発していたので、今のままの進め方では不安がありました。まずはなぜこのような状態になっているのか把握するために、現場のマネージャーが参加するミーティングに私もぜひ参加させてください、とお客様にお願いして参加させてもらいました。
実際にミーティングに参加してみると、プロダクトオーナーがプロジェクトマネージャーを兼務していて、プロジェクトマネージャー専任がいなかったのです。プロダクトオーナーは他のサービスも統括して見ているので管轄が広すぎて、プロジェクトマネージャーとしての役割を果たすにはどうしてもリソースが足りていないなと感じました。
実際にプロジェクトとして成果物の品質を担保する仕組みが不十分で、システム規模に対してレビュー体制が整っておらず、評価視点の精度が低いことが障害やスケジュール遅延に繋がっていました。
品質を担保する仕組み創りのためには、プロジェクトマネージャーのマネジメント部分とエンジニアのスキル部分の両面がそろって実現できることなので、これまで通り一辺倒であったプロジェクトマネジメントの部分を改善することと、エンジニアのスキルを向上させることでお客様をアシストすることが私の役割だと考え、様々なアプローチをしていきました。
劇的ビフォアアフター！シン・テックリード流プロジェクトマネジメント
ー 課題に対してどのようなアプローチをしましたか？
お客様側のプロダクトオーナーが想い描いているプランについて、役割分担やスケジュールをメンバーが認識出来ていませんでした。そのため、まず初めにプロジェクトのロードマップを作成していつまでに何がどうなってるかを明確にしました。アプリケーション側だけではなくインフラの構築状況や関連チームの進捗状況も踏まえてスケジュールの可視化を行いました。
また、今では何かが起きてから対応を考えるような、場当たり的な対処で対応しておりリスクマネジメントが出来ていなかったので、事前にリスクを洗い出して、それが起きた場合にどう対応するかということについて、お客様と一緒に対策案を出すことを行いました。例えば、機能毎の優先度を明確化してMUST、NEED、WANTに切り分け、急な要件要望が出た場合は、WANTレベルのものは後ろにずらすなどのスケジュール調整を行うなど、です。他には、急に要員が減った場合にどう対応するのか、バグが予想以上に多く発生した場合にどう対処するのかなどですね。開発する中であり得る色んなトラブルや問題を想定して、対処方法をお客様と一緒に決めていきました。
次に、開発運用を見直し、品質を担当するためにレビュー体制を強化し、テスト計画を策定しました。当初はテストケースを作っていましたが、基準が甘く機能要件を評価しきれない内容でした。また、テストスケジュール遅延とともにテストケース作成まで手が回らなくなり、動くものを作ることを優先して開発担当者に動作確認を任せる形になっていました。結果として複雑な業務であるにも関わらず、テストケースの作成が開発プロセスから外れてしまっていました。
お客様は、テストケースを作っていると時間がかかるので実装を優先したい、という考えでしたが、リリースしても不具合報告が500件超発生している状況だったのでテストの実施は必須だと思いました。フェーズ別の評価観点を明確化して、テストケースを作成。計画的・戦略的なテストを実施しました。
– 当時現場ではすぐに様々な提案を受け入れられたのでしょうか？
いきなり課題提起と提案をするのではなく、下地作りとして日々の一つずつの仕事のクオリティを意識していました。チケットの起票の仕方、コーディングやレビューとかテストのやり方も、みんなより品質の高いものを意識して挙げて自分自身の仕事の品質が高いものを提供しつつ、この場合こうした方がいいよであったり、工夫している点などといったプラス情報などの提案は、どんどんチーム内で積み重ねてやっていました。
また余談ですが、現場に出社するときは必ず元気に挨拶することを心がけています。外部企業のイチ開発要員、ではなく、顧客の社員さんたちと同じ立場で働いているエンジニアとして認識いただきたいので、同じフロアの人にはきちんと挨拶を徹底しています。また、開発プロジェクト以外の、一緒に働いていない他の部門の方にも安心感と相談しやすい心象を与えられるように心掛けています。
実際に過去の現場のお客様が、元気に挨拶するエンジニアとして今でも私のことを覚えて頂いてくださっていると弊社の営業から聞きました。元気に挨拶することでコミュニケーションが円滑になるのであれば、やらない理由がないですね。そうすることで今までよりもややハードルの高い提案だったとしても、やってみましょうか？と皆さんが協力してくれるようになり、提案も通りやすくなっていきました。
上記のアプローチを通して、以前のプロジェクトの反省点を活かし、それ以降のプロジェクトの品質は遅延することなく当初スケジュール通りリリースを達成しました。ローンチ後もクリティカルな不具合はなく、不具合報告も使用方法に関する問い合わせを含めて50件までに減らすことが出来ました。
また、エンジニアのスキルにばらつきがあることで成果物のクオリティもバラついていたので、レビュー工数などの負荷を下げるためにも、同時にスキルアップ目的でエンジニア向けに勉強会を定期的に開催しました。勉強会は多かった時期で月に2，3回行っていて、内容は主にプロジェクトで足りてない技術面が主です。参加者はISTのエンジニアだけではなく他ベンダーのエンジニアや社員の方も参加していましたね。勉強会を続けることで、参画しているBPが今ではハイパフォーマーに成長しました。
一般的なハイパフォーマーというと「スピーディーにタスクを消化してくる人」をイメージすると思いますが、それだと以前の課題を抱えていたプロジェクト状態でもハイパフォーマー揃いだったことになります。そうではなく、私が言うハイパフォーマーは、同じ開発期間で他の人たちよりも品質が高く（機能要件を満たしたうえで保守性にも優れている）、他の人が残した課題まで解消した上で仕上げるという水準の仕事ぶりです。
こういう方が開発した後はコードからも複雑さが解消されて、他の開発者が作業する際にもコーディングがし易いので、チームにもたらす貢献が極めて高いです。そこまで成長しているので、最初はバラつきのあったスキルレベルが今では優秀なエンジニアが多い現場になっていると思います。
QCDの改善のカギはエンジニアチームビルディング
ープロジェクトを成功させるためにプロジェクト管理の部分が大きく影響してくると思いますか？
プロジェクト成功の定義は、お客様の求めるレベル、もしくはそれ以上で「品質・コスト・リリース期限」基準をクリアすることだと思います。
世の中の市場は待ってくれないので、最初に市場にローンチすると決めたサービスのリリース期限に遅延してしまった場合、それは失敗だと思います。ちゃんとリリース期限を守ったうえで品質基準をきちんと満たしていて、予算も当初の予定通りにプロジェクトを遂行してこそ、プロジェクトの成功だと思って日々取り組んでいます。
ー提案を続けてお客様にどのように貢献できたと思いますか？
品質面でも大幅に改善することができましたし、何より今後のプロジェクトマネジメントの成功事例を示せたことが成果だと思います。
私の経験値を伝え続けたことで、お客様の同じチームの人たちはどんどん開発力が向上しています。具体的には、オブジェクト指向での設計視点、クリーンアーキテクチャに則ったレイヤー構成、複雑な業務知識をドメインレイヤーに集約する、などの開発方針を打ち立て疎結合で保守性の高い成果物になっています。
エンジニアの開発力が向上することで保守性があがり、サービスローンチ後の重大なバグを減らすことができます。たとえ障害が起きてもすぐにリカバリーすることができます。プロジェクトのゴールを達成するエンジニアチームをつくることで、事業目標の達成に寄与することができると考えています。
自分が出来ることに合わせるのではなく、お客様に合わせて貢献できることを探しだす。
ーお客様自身も気づいていない課題点を見つけて解決していくスタイルの思考になったきっかけは何ですか？
弊社は「顧客の社員と同じ目線で上流から下流まで伴走するエンジニアリング」をミッションと掲げる会社なので、私も常に意識してお客様の目線で、お客様のビジネスに貢献できるエンジニアとして求められていることを提供できることは何かを考えるようになりました。
初めは手探り状態でしたが、お客さんが抱えていた課題に対して、理想とする状態（ToBe）と現状（AsIs）を可視化してギャップ分析によるアプローチから、課題の原因を調査・分析し解決に向けた進め方や体制などを提案するなど、コンサル寄りの動きをするようになっていきました。端的に言うと、ただコーディングしてリリースするのではなく、付加価値を付けて提供するということですね。
その後、ほかの現場に異動になったのですが、お客様から戻ってきて欲しいとご指名頂き戻ったことがあります。その時、お客様から信頼いただけたことを実感しました。
ーT.O氏の考える「これから求められるエンジニア像」とはなんですか？
私の考えは「顧客満足度を最大化するために、お客様の特性にあわせて自分に出来ることを探し出せるエンジニア」ですね。自分が出来ることに仕事をあわせるのではなく、顧客満足のために貢献できることを探し出すことが重要なのではないかと。
プロジェクト内でどういうことが出来るのかはお客様次第です。例えば現在のお客様は業務知識が深く、事業目標へのコミット力がとても高いです。ただ、そういう気持ちが強いからこそ、大量の要件や要望を受け付けてしまいプロジェクトが遅延してしまうことが起きていました。この場合は私としては、エンジニアリング面でもプロジェクトマネジメント面でも両方をサポートしようと考えます。
逆に、プロジェクトマネジメントがしっかりしているお客様であれば、私は業務理解に注力してエンジニアリング部分で貢献したりとあらゆるものを探っていくことですね。お客様のパターンにあわせて自分自身の貢献できる場所を探して、そこで最大限の貢献をすることを意識しています。
ーこれからの目標はありますか？
自分自身で褒めているようになってしまいますが（笑）現在のお客様とは信頼関係が気づけていて、エンジニアリング以外のところもいろいろ相談を受けるなと思っていて、組織戦略みたいなところも本当は話したいとおっしゃってくれていています。
そうした要望に応えていくために、顧客と外部という垣根を超え、新しいサービスを一緒に作っていけるようなエンジニアになりたいです。
