Stagesで文書管理・テーラリング・規格対応を最適化！
導入事例と効果

はじめに

この記事では、皆さまがよくお困りになっているプロセス管理の課題と、プロセス管理システムStagesがそれらの課題をどう解決できるか、そして、実際の事例をご紹介します。課題ベースの内容になっているため、気になる課題の部分だけでもお読みいただけると幸いです。

課題1：文書ベースで理解しづらい

プロセス管理者：文書ベースで定義するのが結構大変
開発者　　　　：文書を読んでもよくわからないし、作業の流れのイメージが持てない

プロセスは文書化して共有されることが一般的かと思われますが、プロセスを定義している人たちはどうしたら開発者にとってわかりやすいものにできるかと四苦八苦しています。わかりやすい文章を心がけ、関連個所のリンクを貼り、書式を整えて…。このようにして作られたプロセス文書ですが、そもそもプロセス自体がわかりづらいため、開発者が文書を参照しても、いまいち作業の流れがつかめなかったりします。

【Stagesなら】モデルベースでわかりやすい！

直感的な操作でプロセスをモデル化できるため、膨大な文書作成の手間を省きます。一画面でプロセスの定義を進めていくことができ、効率的にプロセス定義・改善活動を行っていけます。このプロセスをモデル化できるというのはプロセス管理者だけでなく、プロセスを参照する開発者にも嬉しい機能です。「誰が」「何を」「いつまでに」「どのように」やるのかが見える化でき、プロセスを理解した上で開発を進めていくことが可能になります。

Stagesでは、プロセスを構成する活動や役割などをそれぞれ要素ごとに定義し、それらを組み合わせてプロセスを作っていきます。文書ベースの定義では、同じものを指しているはずなのに、異なる名称で記載してしまっているということが起こりがちです。その点、Stagesなら共通化された部品のようなイメージで定義できるため、重複を防ぐことが可能です。この仕様により、定義の際だけでなく、修正をする際にもStagesの良さが活きます。ダイアグラムも自動で生成、修正されるため、文書ベースで起こりがちな文書とダイアグラムの乖離を防げます。

プロセスがなかなか定着しない要因の一つとして、プロセス管理者が開発者に十分に理解させられていないことが挙げられます。Stagesなら見える化で理解を促進し、プロセスの定着を図ることが可能です。

【事例】プロセスがエンジニアに受け入れられやすくなった

従来の文書ベースでの定義だと、プロセスを理解するには、文書をよく読みこまないといけませんでした。エンジニアはプロジェクトに追われ忙しい人が多く、かつ意識はプロジェクトに向いているため、プロセスに対して拒否感を示す人も多くいました。Stagesを導入したことで、自分のプロジェクトに合ったプロセスが見える化 (→ 課題3：テーラリングが難しい でもご紹介) されたため、エンジニアにプロセスが受け入れられやすくなりました。

課題2：プロセス文書が散在している

プロセス管理者：プロセス文書が散在していて、管理が面倒
開発者　　　　：プロセスを確認するとき、どの文書を見ればいいのかわからない

プロセスの管理はExcelやWord、PPTで行っているという企業様が多いのではないでしょうか。そうなると、どうしても、いちいちそのファイルを開くのが面倒でプロセスのメンテナンスを怠ってしまい、いつの間にか現行のプロジェクトと合わないプロセスになっている、なんてことが。エンジニア側からすると、プロセスごとに規程やガイドライン、テンプレートなどが存在し、どれを見ればいいのやら。結局そのプロセスに関連したファイルを全部開いて中身を確認して該当箇所を探さないといけなくなるため、面倒になり、プロセスをないがしろに…。

【Stagesなら】Webアプリで一元管理できる！

Stagesはただのお絵描きツールではありません。
プロセスの定義から、規格対応、プロジェクトでの使用、そして改善活動をこれ一つで、というのがStagesの強みです。

【プロセスの定義】
Webページ上での管理になるため、プロセスを定義する際やアップデートする際にいくつものファイルを開く必要がなく、サクサク行うことができます。面倒だったリンクを貼る手間などもなくなるため、純粋にプロセス定義に集中することができます。共有もWebでできるため、たくさんのファイルを開いては該当箇所の確認…なんてことをする必要はなく、一つのページから、各活動、インプット/アウトプット、ロールなどの要素の詳細を追っていくことが可能になります。また、コメント機能を利用してのやり取りができるため、フィードバックを楽に行うことができます。

【規格対応】
Stages上でプロセスと規格要件を紐づけることができます。今までは規格対応に膨大な時間を費やし、そのレポーティングも大変でしたが、ツール上で一貫した管理が可能になります。各規格のコアは共有可能である点に着目し、プロセスに対して複数の規格要件を紐づけることで、規格ごとにプロセスが乱立してしまうことを防ぎます。標準レポートを活用することで、どのプロセスがどの規格要件と紐づいているか、どの規格要件がまだ満たされていないかをワンクリックでかんたんに確認することができます。(→ 課題4：規格対応が大変 でもご紹介)

【プロジェクトでの使用】
プロセスの配布もWeb上のため、参照もかんたんです。標準プロセスとして参照可能なだけでなく、各プロジェクト専用のプロセスも確認することができます。それにより、プロジェクト向けに整えられたプロセスに沿って迷うことなく作業を進められます。また、プロジェクトマネジメントツールと連携しプロセスをチケット化したり、ファイルマネジメントツールと連携しプロジェクト中で作成した実際の作業成果物もStages上から管理することが可能です。このような連携機能により、作業者がプロセスを意識せずとも、自然とプロセスに準拠した活動を行えるようにすることも可能です。

【改善活動】
プロジェクト中やプロセス改善活動で利用可能な各種レポートが標準で約20種あります。プロセスの変更率やプロセスに対して付けられたフィードバックコメントを収集するレポートでしたり、定義されている作業成果物一覧とそれに対応する実際の作成ファイルの対応もレポートでかんたんに出すことができます。

【事例】開発効率が30%向上

従来の文書ベースでは、プロセスを理解するのに時間がかかりましたが、Stagesではプロセスがわかりやすく見える化されているため、解読にかかる時間を削減することができました。また、プロセス改善が積極的に行われるようになり、従来複雑だったプロセスがよりシンプルに最適化されていき、より効率的な手順で作業を行えるようになりました。そして、Stagesをプラットフォームとして他のツールと連携してプロジェクトを行うことで、ツール間を移動する手間を減らすことができ、開発効率30%UPを達成しました。

開発効率30%向上という具体的な成果はStagesの強みの一つです。組織全体の課題解決や、サイロ化を防ぐプロセス整備にご興味があれば、ぜひこちらの事例もご覧ください。

課題3：テーラリングが難しい

プロセス管理者：テーラリングガイドラインは作ってあるけど、はたして活用されているのか？
開発者　　　　：テーラリングの仕方がわからない、いちいちガイドラインを見てやるのが面倒

テーラリングは、テーラリング指針に沿って、プロジェクトリーダー (PL) が行うことが一般的です。しかしそうすると取捨選択の判断はPLによるものとなるため、属人化してしまいがちです。さらには、ある程度の時間とノウハウが必要になるため、プロジェクトによってはテーラリングが十分に行われていないということもあります。

【Stagesなら】QA式テーラリングで属人化を防ぐ！

プロセス管理者があらかじめ質問と回答を用意し、プロセス要素に結び付けておくことで、プロジェクトでテーラリングする際は、質問に回答するだけでプロジェクトに合った大まかなテーラリングが可能になります。

ときにはテーラリング作業を行わずにプロジェクトを進めてしまうことがあります。時間の都合上、テーラリングをしている暇があるなら開発をどんどん進めたいというときでしょう。慣れている人でも、テーラリングには1～3時間の工数を必要とします。Stagesのテーラリング補助機能を活用することで、テーラリングに割いていた工数をぐっと削減することができます。さらに、用意された質問に回答するだけのため、ノウハウに左右されずに誰でもでき、属人化を防ぐことができます。

もちろん、手動でのテーラリングも可能なため、QA式のテーラリングで大まかにプロジェクト向けのプロセスにし、細かい部分は手動テーラリングで対応することができます。また、テーラリングの際には根拠を記載することが必須となっているため、なぜこの活動は除外されたのか、その根拠を辿ることができます。テーラリングの根拠がきちんと示されていないまま活動が除外されてしまっている、というのも従来のプロセス管理でありがちな課題かと思いますが、そこもしっかりとケアすることが可能です。テーラリングの質問例としては、プロジェクトの規模やリスク、規格に準拠する必要があるかや、どの部署で行うのかなどです。

【事例】プロジェクトに合ったプロセスで開発ができるように

従来はテーラリングガイドラインは存在するものの、プロジェクト向けのテーラリングはPL任せになり、妥当性のあるテーラリングができていませんでした。Stagesでは、システマチックなテーラリングを行うことができるため、PLの経験に左右されずに一定レベルのテーラリング結果を得られます。そのため開発者は、より自分たちのプロジェクトに適したテーラリングがなされたプロセスを元に開発ができるようになりました。

課題4：規格対応が大変

プロセス管理者：プロセスを作るのも、監査も大変。各規格向けのプロセスが乱立してしまっている。
開発者　　　　：規格に準拠して作業してと言われても、よくわからない。

規格対応プロセスを策定するには、対象や規模にもよりますが数百万から数千万円かかります。策定する作業だけでなく、監査対応にも膨大な労力と費用を要しますので、本当に骨の折れる活動です。また、要求される規格ごとにプロセスを作ってしまい、規格対応プロセスがそれぞれ乱立してしまっているなんてこともあります。

【Stagesなら】対応プロセス策定からレポーティングまでかんたんに！

プロセスと規格の紐づけをツール上で行うことができます。また、規格のコアは共有可能という点に着目し、共通部分のプロセスは複数の規格と紐づけ、規格固有の部分はそこにアドオンする考え方を取ることで、規格対応プロセスの乱立を防ぐことができます。

紐づけや対応状況のレーティングだけでなく、レポーティングまで行うことが可能です。どのプロセスと規格が紐づいているのかリストをボタンひとつで出力することができるため、監査の際にもエビデンスとして提出できます。プロジェクト向けのプロセスでは、実際に作成した作業成果物を連携リポジトリに登録することで、規格で定義されている作業成果物をきちんと作成したかまで確認することができ、規格に準拠した作業をサポートします。

【事例】監査の準備工数を50%削減

求められる規格が多くなり、毎年50件以上の監査対応が必要で大変な労力を費やしていました。Stagesを導入することで、監査への準備を効率的に行うことができ、工数を50%削減することができました。また、レポートでのギャップ分析を活用することで、目標としていた CMMI Level 3 も達成しました。

監査準備工数を50%削減できたように、Stagesは具体的な規格対応にも効果を発揮します。規格対応や製品認証取得のプロセスにご興味があれば、こちらの記事もご参照ください。

まとめ

いかがでしたか？

今回はプロセス管理の課題とその解決に役立つプロセス管理システムStagesの利点と事例をご紹介しました。
ツールでプロセスを管理することにより、管理工数を削減できるだけでなく、プロセスの理解を深め、さらに効率的に開発を進めることも可能になります。

機能や利点、事例のご紹介をさせていただく 個別デモ、
短時間でStagesの利点、機能をレクチャーさせていただく 体感セミナー 、
そして効果を出せそうかをしっかり確かめられる本格的な PoC も行っておりますので、
ご興味をお持ちいただけた方は、是非お気軽にお問い合わせください。

---