インタビュー

内製開発の成否をにぎる盲点!!システム障害につながる芽をつぶす「PMO」とは

内製でシステムを開発していくということは、ビジネスの状況に応じ永続的に開発し続けていくということです。ですが、多くのシステムは、開発を重ねるたび「負の遺産」が増大し、ゆくゆく使えなくなってしまうという運命・状況に陥っています。そこで必要になってくるのが「PMO」という存在。「プロジェクトマネジメントを横断的に支援し、システム障害につながる芽を細かくつぶしていく存在」ですが、その重要性についてより具体的にご理解いただけるよう、弊社PMO 兼 リーダーエンジニアの取り組みを紹介します。

H.O氏プロフィール:会津大学のコンピュータ理工学部を卒業後、システム開発会社を2度転職。PGからPLやPMまで幅広く経験。下請けのオペ―レーションタスクから逃れるため、顧客直の情報戦略テクノロジーに入社。医療・自動車・人材業界など様々なエンドユーザー企業での現場を経験。PMOとして、プロジェクトリーダーへの細やかなフォローや、他社から参画しているエンジニアの育成などを担当している。

SEでの参画から「全体像の理解力」を評価いただきPMOに

ー どのような経緯でPMOの役割を任されるに至ったのですか?

1年半前に現在の現場に参画した当時は、私と他社のエンジニア2名、お客様側のプロパーの6名のチームのなかで、主にSEとして開発を担当していました。参画当初、自分のタスクが終わり手が空き始めたら、誰も手を付けられていないタスクを巻き取って対応したり、チームで困っている人がいれば声をかけて一緒に解決していくという行動を積極的に取ることを心がけて動いていました。

参画してまだ時期が浅い時は、システムの仕様や中身がわからないことが多いので、システムの中身を把握することを重視しています。そのため、初めはシステムの理解を深めるためにどんどんタスクを取りに行き、自分で対応して中身を理解するということを積極的にやっていました。

システムの全体像を理解する過程で、とある仕様と実装をレビューした際に違和感を感じ、現場の古参者に確認したところ、その内容が間違いだということが発見できました。その時に自分の疑問点を放置して進めていたら、後から使えないシステムになっていた可能性もありますよね。そういった経験から自分が参画したところのシステムは必ず全体を把握したいと思っており、その為に常にフットワーク軽く行動しています。

また、自ら手を上げてタスクをこなしていくと、システムの中身の把握だけではなくタスクに関連するお客様側の関係者と関わる機会も自然と増えてきました。困った時はこの人に聞けばいい、というお客様との関係性を作ることができましたし、そのお客様側との繋がりが現在のスムースなチーム運営に役立っています。そんな取り組みもあって、参画してから3か月程経過した時に、お客様からPMOの役割をお任せ頂くことになりました。

システムの永続開発に必要な、PMOという存在

ー PMOとして具体的にどんな業務を担当されましたか?

お客様側でシステムの仕様を統括している方のフォローを担当しながら、チームの開発リーダーとしても進捗管理やメンバーへの技術指導を行っていました。チーム内のメンバー育成にも注力していましたね。

仕様を統括している方のフォロー業務としては、仕様や技術調査の他、MTGでの意見集約、資料作成などを主に行っていました。その方はコードレビューも担当しており多忙を極めていましたが、フォローにはいれるようになったことで、時間にすると月に40時間程の業務を代替できたと思います。

またお客様と開発チームメンバーの間にいる役割として心がけていたことは、①レスポンス、②自分でボールを止めないことですね。

レスポンスを早くすることは、一緒にチームで開発する上で相手に安心してもらえることで信頼関係の構築に繋がると思います。そのため、Slackを小まめに見て、誰かが困っている様子があればヘルプになるべく早めに入ったり、質問や情報も積極的に拾って、私で解決できるところは教えてあげたり、わからないところは早めに上の人に質問をすることを心がけていました。

また、自分でボールを止めないコツは、不明点があって調べてもわからない時はあまり時間をかけても意味がないのですぐに質問したり、小まめに方向性を確認してすり合わせを行うことです。すり合わせをせずに方向性がずれたままで進めてしまうと、結果的にやり直しになって工数も無駄になります。私自身も過去に頻繁に駄目出しされてきて、何度もやり直しの経験があるので、その時の経験をもとに普段からなるべく早めに方針を確認することを心がけています。

– PMOとして苦労した点はありますか?

担当していた案件でポータルサイトの刷新案件がありました。元々このシステムは外注で作っていたので、運用している方に質問をしてもシステムのことがわからないといった状況でした。実際に、使っていないと言われていたサーバーを止めた時に障害が発生するということもありましたね。資料や設計書などもアップデートされておらず昔のままの状態、そして作った人はもういなくなっていたということが苦労した点ですね。

それから私のほうで一から整備、整理していきました。この体験もあって、私がメンバーへよく伝えているのは、作っていないエンジニアが見てもわかるようなシンプルなコードを書きましょうということや、ナレッジ化をしっかりやることですね。

– シンプルなコードにすることやナレッジ化をすることのメリットは何ですか?

私は、ドキュメントを残すなどナレッジ化することだけでは意味がないと考えています。継続してアップデートしていかないと陳腐化してしまって全く意味がなくなってしまいますよね。そうなると誰も見なくなりますし、見たとしても過去のナレッジのまま間違った対応をしてしまい、障害に繋がります。障害によってサービス停止にでもなれば、使っているユーザーも離れてしまって売り上げの低下にもつながる可能性もあります。このようなことを回避するために、継続して情報をアップデートしていく必要があると思いますので、普段からメンバーへ特に意識して伝えています。

また、シンプルなコードというのは、例えばそのメソッドというその機能が何をするか一目でわかる名前がついていたり、それを表す変数名がわかりやすいなどですね。綺麗なソースを書いておけば、ドキュメントに書いてたものが陳腐化した場合でもソースそのものがドキュメントとして機能します。ドキュメントが古いと、結局ソースを読まないといけなくなるので、その時に汚いソースになっていると調査に工数がかかりますし、読み間違いからの間違った対応が発生する可能性もありますよね。結果的に保守コストの削減にも繋がると思います。

ナレッジ化することも、シンプルなコードにすることも、先にやっておけば後々運用や保守の場面で楽になるので、先にやっておくべきことはしっかりとやるようにしています。

ー 先回りして対応することを心がけるのはなぜでしょうか?

先にラクして手を抜いてしまうと、結局は後で苦労することになるから、ですね。先に少ない工数をかけて対応しておけば起きなかった問題が、それをしないことで、後から大きな問題になって返ってきます。

そんなことわかっているよと思われるかもしれませんが、最初のうちに出来ることを徹底的に突き詰めることが大事なことだと思っています。次の改修作業や新機能の追加などのアクションを効率的に行えたり、もしも私自身が今の現場から抜けて他の人がシステムを担当しても、障害が起きにくいシステムを残すことができ顧客満足の最大化につながると考えています。

そのために、仕様書で少しでも気になる点があれば、小まめにお客さんと擦り合わせたり、実装の時にはシンプルなコードを書くこと、そして同時にナレッジをアップデートしていくことをやっています。

– PMOの役割を経て、お客さんからの評価の声があれば教えて下さい。

新しいプロジェクトのお話も頂き、そこのリーダーも任せて頂けているので、そういったことも含めて信頼して頂けているのかなと感じますね。

一つ一つの背景理解が未来への投資につながる

–お客様にどのような価値を提供できたと思いますか?

お客様側のプロパーのフォロー役として、先にも記載したとおり月に40時間程度軽減することに貢献できたことだと思います。

また、他社のエンジニアは実装スピードは早いが品質が悪いため、コードレビューのコストが高かったことがありました。こうしたコストは貴重なお客様の時間を奪うことにもなると考えています。そうしたコストを最小限に抑えられていると思います。

–H.O氏が考える理想的な開発チームとは?

お客様と同じ目線で考えて業務を遂行することです。そのために、普段からなるべく背景を確認するようにしています。一つの案件においても、何故この案件に着手するのかということと、この案件を完了することで何を得たいのかということを、しっかりとすり合わせるようにしています。

お客様やシステムユーザーと同じ環境で開発を進める上では、様々なリクエストが出てきます。もちろん、お客様のすべての要望に応えたい気持ちはあります。一方でお客様のエンジニア部門のエンジニアの立場として、全体最適の視点で優先順位をつけて対応していますね。お客様のリクエストをすべて対応しているといつまでもシステムが完成しないので、結果、お客様の期待に応えられなくなるのではと思います。

また、優先順位を決めて必要なことに工数を投下するために、一つ一つの作業の背景を理解し、取捨選択をしながら作業を遂行していくのが大事なことだと思いますね。システム開発で大事なことは、日々の積み重ねです。いかに後の障害や問題を起こす可能性を下げられるかということだと思うのでこれからも丁寧な開発を意識してお客様に貢献していきたいと思います。

執筆者
リビルダーズ編集部

-インタビュー
-,