成功の鍵は品質管理と技術のアップデートや浸透にあり！システム情報社に聞くDX時代のSIerの品質管理部門のあり方とは。

役割としては、いわゆる「品質管理部門」が一番近いかと思います。

ただ当社では、「プロジェクトの状況や納品物の品質のチェック」に加え、プロジェクトを遂行するための「開発標準の策定」という役割も担っています。 会社のバックボーンを支えるような組織と言えますね。

当社は中長期経営計画の中で「DXへの対応」を最重要のテーマに据えています。 推進にあたって何がキーワードかを考えると、やはりUXやデザイン志向、アジャイルへの対応などが挙げられます。

この方向性に沿って当社がお客様へ価値を提供していくためには、まず会社や社員への浸透を進めていく必要があります。 その役割のために従来の品質管理部門を拡大させる形で設立したのが技術監理本部なんです。

そうですね。技術監理本部は「品質監理部」「PMO室」「技術統括部」の３つに分かれています。

もともと品質監理部は「品質のチェック」と「開発プロセスの定義と普及」がミッションでした。 そこに「三現主義に基づいた深く入り込むプロジェクトマネジメント」をテーマとするPMO室と、「先進的な技術の標準化や普及」というミッションを担う技術統括部という部門ができたんです。

私の知る限りですが、ここまで品質と技術の部門が完全に一体化しているケースは珍しいかもしれませんね。 ただ、品質向上のためのプロセス策定にあたっては、そのための技術について決めることが必要ですし非常に重要なので、理にかなっていると考えています。

品質監理部はシステム開発系の他社と大きな差は無いかなと思います。 最も重要な業務は、PMR（プロジェクトマネジメントレビュー）と呼ばれるものです。 全プロジェクトに対して四半期に1回、評価・チェックを実施しています。

請負開発では各工程ごとに「工程移行判定」という機会があり、そこでもレビューを実施します。 継続的な案件の場合は請負案件とは異なり、「その案件がどういう状況にあるか」を明確に確認する機会がないので、この四半期に1回のレビューを徹底しています。

もうひとつ重要な役割はSICPという当社の開発標準の刷新です。 「UXへの対応」や「ファシリテーションの強化」などDXに対応するためのいくつかのテーマを選定し、教育カリキュラムに落とし込んで社員に浸透させる取り組みも大きな仕事です。

「三現主義に基づいた現場に深く入りこんでのチェック」がミッションです。

案件の重要度に応じて「重点プロジェクト」を定め、PMO室のメンバーが実際にプロジェクトへ足を運び、成果物のチェックを行うこともあります。 独自のチェックリストに基づいてプロジェクトの状況を点数化し、現場のリーダーに寄り添いながら一定の水準になるまで指導するという形で進めています。

技術的に優れた社員が集まり、「技術的な価値を通じてプラスアルファの価値を生み出す」というミッションを担っています。 今後の拡大や技術的な優位性が得られることを見込めるプロジェクトに参画し、技術的な課題の解決やお客様への提案の幅を広げる活動を行います。 さらにそこで得られたインプットの全社展開も担当しています。

SICPの初版をリリースしたのは15年前の2006年ですが、プロセスは生き物ですので、これまでもそれぞれの案件からフィードバックをして改善を繰り返してきました。 ただ、今回のDXへの対応では必要な要素が大きく変わってくるので「SICP Advanced」と新しい開発標準を策定しており、年内には改めてリリースしたいと考えています。 

メインテーマとして置いているのはUXとアジャイルです。

アジャイルは元々のSICPにも組み込まれていますが、現在の開発はアジャイルかウォーターフォールかという単純な対比ではありません。 最初はウォーターフォールで、後半はアジャイルでというような、ハイブリッドアジャイルと呼んでいる形式の開発も増えているんです。

他にも「スコープの見える化」というものがあります。 案件が失敗する要因となる「スコープのブレ」をなくすためのものになります。

アジャイルが“変更に強いプロセス”だと知られることで「仕様をいつでも変更して良い」と思われてしまうんです。 それで技術者が変更要望を何度も受けて苦しくなると失敗の要因になりますので、この「スコープの見える化」はハイブリッドアジャイルへのキーになると思います。

ファシリテーションという言葉は「ステークホルダーをゴールに導いていく力」と解釈しており、この能力は強化することが必要だと考えています。 確かな技術や立派なプロセス定義があっても、それをしっかり伝えられないとDXは実現できませんから。

メリットは「お客様はこう考えているのではないか」「こういう資料を作った方がスムーズに提案をできるのではないか」と非常に具体的なアドバイスが可能なことですね。 加えて、事業責任者の経験があることで現場と上長の間に立って手を差し伸べやすい存在にはなっているのかなと思います。

反面、前へ前へと出て現場のリーダーと話していくと、事業部門の独立性を損なう可能性があります。 主体性を損なうのは本意でないので、そこのバランスについては気を付けています。 実際にレビューを行ったメンバーでも振り返りを行い、「ここは現場に任せよう」「ここは早めに介入しよう」など、その進め方についてもチェックしています。

元々、開発経験のあるメンバーが在籍することは多くなかった部署だったため、それだと開発面の細かい問題をキャッチできないこともありました。 開発経験者がチェックの立場に回ることで、開発面でも問題が起こりそうな可能性を察知して事前にフォローアップができています。

PMO室の副室長は大型の請負案件を回してきた実績もあるので、レビューの段階で「こういう視点が足りてないんじゃないか」と的確なアドバイスが行えています。 現場からすると、「口うるさいおじさん」と思いつつもメリットを感じてくれていると思います。

当社は意識的にそういう形にしていますね。 品質管理の役割を持つ部門としては、年齢も他社よりも若いかなと感じています。

ソリューション本部でAI（コグニティブ）サービスに所属しておりまして、主にAIやIoTなど先端技術の研究・開発を行っています。 立ち上げ期から参画しておりまして、今年で5年ほどになります。

プロジェクトの現場にいるとどうしても視野が狭くなるので、見落としへのアドバイスも有難いですし、経験に沿った第三者目線の意見はすごく役立ちます。

プロジェクトのリスク面の評価についてはこれまで点数化できてなかったので、PMO室主導で、チェックシートを作成して過去のプロジェクトのリスクを点数化する取り組みを試験的に行っています。 ただ、チェックの頻度や項目が増えると現場の負担になるので、「評価項目が妥当なのか」という目線も入れつつ作成しているところです。

そうです。重点プロジェクトは、案件の背景や狙い、お客様の性質、参画するメンバーのレベルなどを勘案して選定しています。 PMO室がピッタリと寄り添って週次で会議することもあれば、基本設計の3か月のうち半分くらいなどを目処に内容をチェックすることもあります。

「重点プロジェクトになるルール」は存在しますが、ルール以外に重視しているものはあります。 「このプロジェクトを成功させたい」という営業戦略に基づくこともあれば、「この体制は甘く見ていると危険だ」と感じるものをこちらからお願いして重点プロジェクト化することもあるんです。

新しく取引を始めるお客様については、そのお客様の文化なども分からないといけないんですが、それが「分かっていない」ということが分かるだけでも大きいです。 リーダーがリスクを見落としていることに気付けますし、点数の重みづけはまだまだPDCAが必要ですが、イメージとのギャップの把握には非常に役立っていると感じています。

基本的に全員が現場経験者なので、お客様への対応ではなく社内への対応に過度に工数を割くと良くないことは分かっています。 ただ、忖度しすぎると役割を果たせません。 「品質管理は社内の嫌われ者であるべき」であり、チェックする立場だという意識を持つことが重要だと考えています。

元々は別々だった組織をまとめているんですが、その一番の理由は品質監理部に「プロセスを定義する」というミッションがあり、それを実現するためには技術と距離が遠くてはいけないからです。

定義したプロセスを実際に動かしていくにあたって、技術は切り離せません。 ピックアップしているDX、アジャイル、ハイブリッドアジャイルといったテーマに対応するならDevOpsなどの基盤が必要になります。 例えばハイブリッドアジャイルという型を作っても、それを回していくには絶対にCI/CDへの自動化への基盤は作らないといけないですし、別々に進めていては非効率なんです。

今後を見据えて、その先にあるローコード開発ツールの選定やテストの自動化についても当社としてのやり方を決めていきたいですね。 現在は限られたメンバーで策定したDevOpsの導入支援サービスについて、実績とノウハウを蓄積している段階です。

各メンバーがそれぞれの分野でトップクラスの技術を持っています。 そのため、ほとんどのメンバーが稼働の半分以上をその技術的な強みが生かせるプロジェクトで使い、活躍しています。

プラスアルファを生み出すことがこの組織のミッションだからです。 現場に100%コミットしているエンジニアにプラスアルファを求めるというのは難しいし、こちらも「できないかもしれない」と思いながら求めることになってしまうので、100%のアサインをしないようにしているんです。

もちろん各現場ごとの目的や解決すべき問題があるのでそれが優先ですが、その目的の達成や問題の解決にあたって使った技術は一般化できるものなのか、そのプロジェクト固有のものなのかを常に考えてもらっています。 そうして自社に持ち帰った技術やノウハウが、新しい案件にも繋がっていくんです。

この組織は出来た当初からウォーターフォールがなくなって完全にアジャイルになりましたし、「要件からお客様と一緒に考えてく」という感覚で進めてきました。

DXが盛り上がる以前からの取り組みだったので、意識はしていませんでしたし、気付いたら会社も周囲もDXという形で盛り上がっていたという感覚です。 ただ、この言葉が出て来て「仕事のやり方として、これで合っていたんだな」と思えましたね。

ソリューション事業立ち上げ時から取締役が責任者なので、これまで得たインプットは中長期経営計画や新しい開発標準であるSICP Advancedにエッセンスとして入っていくと思います。 先端技術事業を扱うプロジェクトでのインプットが、当社の進化につながっているんです。