7割が失敗するDX。その根本要因と言われている「経営層と現場の思いのズレ」を解消するチームビルディングについて、情報戦略テクノロジーテックリードエンジニアがエピソードを交えお話いたします。
Y.K氏プロフィール：新卒で通信基盤構築などを手がけている会社へ入社。主にITインフラ構築を中心にソフトウェア開発やPMなど、マルチに経験を積む。その一方で、請負エンジニアの立ち位置では本当の意味で顧客の役に立てないと感じ、情報戦略テクノロジーに入社。入社後はHRサービスを提供するエンドユーザー企業に常駐し、インフラチームの質の向上を担当。
【課題】人員不足で、許容量の10倍タスクが発生していた現場
ー プロジェクト参画当初、インフラにどのような課題がありましたか？
私が参画した当初、インフラ担当のエンジニアはプロパー社員2名、フリーランスが1名の3名で社内向け、社外向けの20～30あるシステムのインフラを担当していました。参画先の現場がエンジニアに求めていることが「技術ではなく、ビジネスに貢献できるかを考えられるエンジニア」ということもあり、採用が上手くいっておらずインフラエンジニアの人数が十分に足りておりませんでした。
そんな少ない人数で個々の力に頼ったインフラの構築を行っていたため、構築や運用の手順が煩雑になっていました。例えば、コード化されている箇所とされていない箇所が散見されたり、コード化されているものを反映するための手順が揃っていないという状態ですね。
人数が足りていない上に運用の手順が整っていないので、他のチームから来る修正対応や変更依頼もそれぞれのメンバーが各々のベストと考える方法で対応した結果、全体として統一性がなく、非効率になってしまいました。改善は続けていたものの効果の高い改善ができておらず、後の改善により１人で１か月あれば対応できる内容を、当時は２人がかりで半年かけて作業するという状況でした。
その一方で、お客さまの理想は、サービスを1年に3つ、4つリリースしながら、今あるサービスの改善のためのリリースも対応して欲しいというものでした。現状から考えると1年に2つサービスをリリースするのがやっとの状況だったのでハードルは大分高いなと感じました。
【解決①】「使って見せる」ことで、インフラの作業をDX化
ー どのように運用環境の改善を進めたのでしょうか？
運用環境によるミスが多発している状況を変えるために、お客さまからもインフラの設定作業などを自動化することができるツールを導入したいという要望がありました。
ですが、当初は理想的なインフラ環境を実現するため、自社のシステムや運用に100％フィットするツールを使用した方が良いという意見があり、数多くある自動化のツールを検討しましたが要件に100%あうツールをなかなか決められないという状況が続いていました。
このままでは何も進まないと思い、100％フィットするツールではないかもしれないが現状のミスを少しでも減らすことができる見込みのあるツールを導入し、現状を改善していきましょうと説得していました。一歩目を始めてみませんか、というような提案をしていましたね。
しかし、口頭で伝えるだけではなかなか同意を得られず壁にぶつかりました。そうした状況を打破するために、まずは実際に私がツールを使って見せ説得するしかないと考えましたね。お客様に現在よりもこのぐらい楽になりますよ、ということをリアリティをもって伝えていきました。
Terraformというツールを使用することになったのですが、実際、インフラの設定変更も楽になり、今ではツールの力で同じインフラの環境を構築する工数を削減することができました。このTerraformは、手作業で実施していたインフラの設定変更作業を自動化するIaCという技術に基づいており、インフラ作業のDXといえるものです。
DXの導入には大きな抵抗感を感じる方も多いですが、まず小さく実施してみて効果を見せることで、意外とスムーズに受け入れてもらえることが分かりました。そのおかげで2人がかりで半年かけていた開発を1人で1か月で開発できるまで効率化できるようになり、これはいける！とチームの説得に成功しましたね。
繰り返し少しづつでも運用を改善していくことで効率化を実現し、同時にミスも減ったため、月に1、２回の頻度で起きていた障害が年に1、2回まで改善することができインフラの品質もあがりました。そういったことが評価されてとなり現在のテックリードの役割を任せて頂けるまでにご評価いただけたのだと思います。
【解決②】コミュニケーションもDX化
ー どのようにチームをまとめていったのですか？
参画した当初、インフラチームのメンバーが運用方法が統一されていないことを認識しているのにもかかわらず自分の運用方法を他の人に相談や報告もせずに進めていました。その影響で担当した人以外誰もわからないシステムが至るところに出てきていたことなどから、適切なコミュニケーションがとれていないと感じました。
また、リモートワークが始まり、インフラチーム全員でコミュニケーションが取れなくなっていた状況が発生していました。チームでコミュニケーションを取れていないと、自分以外の人の知見を知る機会が少なくなり、ベストな運用方法を見つけることができなくなります。人はそれぞれ得意不得意があるので、不得意な部分はチーム内で補う必要があり、コミュニケーションがその土台になると、私は考えています。
コミュニケーション不足の現状を改善するため、まずは毎朝決まった時間にみんなで集まって話をしましょうと提案しました。積極的に他愛もない雑談をするように働きかけましたね。雑談することで、チーム内で気軽に発言してもよいんだという雰囲気をチームにつくり、だんだんコミュニケーションが活発になってきました。
さらに、足かせになると思っていたリモートワークが功を奏し、会議が変わりました。Google Docsでドキュメントを共有し、修正しながら話し合うというスタイルが確立し、ただの会議からアウトプットを完成させるための会議に昇華できました。この作業しながら話すというスタイルはオフラインの会議では受け入れられなかったことです。リモートワークという特殊な状況により、受け入れられたDXではないかと思います。
【解決③】DX推進による盲点「当たり前」の徹底
ー その他、どのようなことに取り組みましたか？
DXというとITツールを使うことに焦点がいってしまい、盲点になってしまう「当たり前のこと」が実はたくさんあります。
たとえば、インフラチームで担当しているシステムの状況が一覧で見れる画面を作り、毎朝システムの負荷状況を見ながら、負荷の増減の状況や原因をみんなで話しました。これを通じてお客さんのシステムに対しての理解を上げていく取り組みをしています。以前はインフラエンジニア4名が個々で動いていたところがチームで動けるようになったと思います。
必要最低限のドキュメント作りましょうという啓蒙活動も続けて行い、みんながお互いの知識を共有できる状態を作りました。手順書の作成もそのうちの一つとして取り組みましたね。これまで何か作業するときに師匠と弟子のように口伝だけで伝わってた作業内容が、手順書という形に残すことで自分以外の他のメンバーでもできるようになります。それに次の人が参画して現場を理解するスピードも上がり、活躍できる場を作ることができると思います。また、ドキュメントの量を必要最低限に絞れるように取捨選択し、最低限の労力で大きな効果が生まれるように工夫しました。
こういった、考えてみれば当たり前の地道な活動を続けたことで、初めは運用の改善する余力もない状態でしたが、少しずつチームとして効率的に動けるようになり、自分たちの余力が出てきました。クライアント企業として実現したいことに、エンジニアとして答えることができる状態に近づいたと思っています。
ー 最後に、Y.K氏の考える理想的なシステム開発とは何でしょうか？
DXを推進していくことで、経営陣の判断に対して迅速に行動できるインフラ、およびインフラチームを構築して行くことが私の目標です。ここまでご紹介してきたことはほんの一部に過ぎず、またインフラチームでは社内のDX推進の土台を担っているという側面もあります。これからも、DXという手段を最大限に活用することで、会社の事業に真に貢献できるインフラとインフラチームを構築していきたいとおもいます。
執筆者
リビルダーズ編集部
