エクセルとプロセス定着だけで社内の雰囲気と動きが改善され、システム品質が向上した事例をご紹介します。
この時私は、品質改善部門の立ち上げメンバーとして参加させていただきました。
その中で私が行った取り組みに焦点を当てて記載させていただいております。
スポンサーリンク
お客様企業概要
金融系システムを開発・運用するシステムベンダー
24時間365日の稼働を求められ、高いシステム品質が要求される
背景と問題点
システム障害が多発しており、多数のお客様から全社的な改善要求を求められている
自社開発のパッケージシステムを導入しているプロジェクトが20あり、プロジェクト感の情報共有がなく同一障害が発生している
パッケージシステムとしての品質が低下し、お客様ごとに修正・カスタマイズが発生していてコストが増加している
お客様ごとにプロジェクトチームが構成されており、プロジェクト間の情報共有の仕組みがない
社内情報共有のためのツール導入に費用をかける文化がない
ソフトウェアエンジニアが多いため社内ツールを作成しようと思えば作成できるが、日々の業務に忙殺され対応できる気力がない
対応方針
要件整理とツール導入に時間を掛けるよりも、手元にあるツールと情報でシステム障害の情報と対応内容を共有する仕組みを作り、チーム間の連携を高めるようなプロセス構築と運営をする。
スケジュールと対応内容
各プロジェクトへの現状ヒアリングと管理実態の調査を行うと同時に、プロトタイプを作成しながらより関係性の強いプロジェクトチームから試験運用に着手しました。
構築したツールとデータの流れ
改善前は、お客様とプロジェクトチームが１：１になっており、システム障害はお客様から連絡が合ってから対応していた。
プロジェクトチーム同士の連携がないため、同じようなシステム障害を何度も発生させるような事態になっていた。
改善後は、一度発生したシステム障害は内容が共有され、発生していない他プロジェクトにも情報共有され、お客様に積極的な不具合報告を行うことでシステム障害を未然に防止することができた。
具体的な実施内容
私が参画させていただいた品質管理部門は、新設の部門であり、社内では比較的立場の弱い部門でした。
各プロジェクトリーダーは自身のプロジェクト運営に責任感を持って運営されているので、他の部門から口出しされることはあまり良い気分では無いという雰囲気でした。
その中で、情報共有の仕組みを作り上げるためにおこなった実施内容とステップを紹介します。
１．情報が運営事務局に集まるようにした
まずは私たちを知ってもらう活動と情報そのものが集まるようにしました。
これは足で稼ぐ部分が強く、プロジェクトリーダーとこまめに接点を持ち、営業活動に近い形でプロジェクト周りを始めました。
- メールで情報共有をしているプロジェクトチームには、チーム内のメーリングリストに入れてもらうようにした
- BTSをすでに導入しているプロジェクトの場合、システム障害を示すフィルタ条件を確認し、アクセスできるようにしてもらった
２．口頭でシステム障害に関する情報伝達を行うようにした
1週間に一度、プロジェクトリーダーが参加する会議の後半で時間をもらい口頭で情報共有する時間を作りました。
収集した情報をまとめて発信することで、事務局に情報が集まっているという状態を伝えることができてきました。
ポイント
ここでのポイントは会議を新しく作ったのではなく、もともとある会議に参加させていただき、話す時間をもらったという点です。
新しく会議を作ると、「何の会議？」「参加する意味ある？」などと会議に参加してもらうまでに時間がかかる場合があります。
すでにある会議の議題に追加してもらう程度であれば調整は会議の主催者と行うだけで済みます。
始めは挨拶と重要ポイントの説明という形で、5分程度の短い時間をもらうところからでした。
翌週には10分になり、20分になり、徐々に持ち時間が長くなっていきました。
また、始めは聞いているだけの参加者でしたが、システム障害の情報共有を行うと、他のプロジェクトチームでも
「うちもこれやっておかないと大変になるぞ！もうちょっと詳しく教えて」
という発言が出て、議論が活発化していきました。
会議が終わってもその後の進捗状況や積極的に話しかけてもらえ、会話する場面が増えてきたのです。
３．会議の前に情報を更新してもらえるようにお願いし、いつでもデータを閲覧できることを伝えて情報が活発にやり取りできるようにした
始めはもともとあった会議に参加させていただいて5分間の枠から始まった会議ですが、30分以上の議論がなされるようになると流石にメインの会議に影響が出てきます。
そこで、運営の見直しを行いました。
会議でやり取りをする前に事前にさらに詳細な情報を更新してもらい、
それを見た他のメンバも疑問点があればコメントを書いてもらうようにしました。
ほとんどは会議をせずとも解決する内容ですが、文字だけのやり取りでは伝わらない内容を対面で話すという形に変化させました。
さらに、「システム品質改善会議」という形で会議体を設けました。
この会議は説明するまでもなく、今までやっていたことをやるだけです。
「参加してください！」と召集する必要はありませんでした。
この会議に参加すれば有益な情報を得られるとわかっているので、必ず参加するようになります。
参加しなくてもエクセルファイルを閲覧すれば情報確認ができるのですが参加率は高いままでした。
４．システム障害の発生状況と改善状況を数値化してプロジェクトチームごとに競わせた。
プロジェクトチーム間の連携がより活発化するように次の取り組みとして、システム障害の発生状況とその改善状況に関する数値をグラフ化しました。
お客様の規模や取引量、システムの量状況などによって発生頻度や改善負荷などのバラツキがあり、全てのプロジェクトが1つの指標で比較できるような数値はありません。
システム障害の重要度や緊急度をカテゴリ分けするとともに、各プロジェクトチームの進捗具合を毎週報告しました。
さらに、社内のポータルサイトを作成し、週次で進捗状況がアップデートされるようにしました。
感覚で把握しているのと数字で把握するのではやはり取り組み姿勢がかわり、より前向きに取り組むことができるという声をいただきました。
５．情報共有の内容が事象だけでなく、対応内容、修正内容、修正モジュールなど多くの情報がプロジェクトチーム間で共有されるようになった
それぞれのシステム品質が向上してくるとプロジェクト内に余裕も生まれ、情報共有の質が向上してきました。
これまでは、プログラム修正を自分たちのプロジェクトに合うように作成していた内容をパッケージソフトに取り込める形に標準化して作るようになり、そのまま修正を加えずに他のプロジェクトではそのモジュールをとりこむだけでアップデートが完了してしまうという状況が起きてきました。
この内容を読んでいる方は、最初から何故そうしないの？と思われる方がほとんどだと思いますが、冷静にこの記事を読むのと日々の業務に追われながら標準化や共通化を行うのはかなり難しいです。
1分1秒を争う状況でそんなことは考えてられない。
というのが現場の声です。
標準化・共通化と口にするのは簡単ですが、それを現場に浸透させる場合はステップが必要になります。
改善効果
障害発生の未然防止によってシステム品質が向上した
システム改修コストが大幅に減少した
お客様からの信頼性が向上した
プロジェクト間の連携強化および意識が向上した
システムベンダーなのになぜBTSツールを初めから使用しなかったのか
Redmine、JIRA、Backlog、Tracなどさまざまなツールが各プロジェクトで使用されていました。
プロジェクトリーダーごとに裁量権が与えられており、独自でツールを使用していました。
また、運営方法や管理プロセス、ツールの機能カスタマイズなどが各チームで行われており、統制が難しい状況でした。
例えばRedmineとした場合、Redmineを使用していないプロジェクトチームからは2つのツールを使うことになるため手間が増えることを嫌い、導入が難しくなります。
また、すでにRedmineを使用しているプロジェクトチームからも現在使用している運営ルールとは異なる手順を支持されるためチーム内で混乱が発生していしまいます。
さらに、ソフトウェアエンジニアがほとんどで、プログラム開発がメインになると、プログラムコードの単位で管理することが主となります。修正したモジュールやプログラムコードはBTSからソースコード管理ツールのGithubやGit、Subversionを経由してリリースされます。
開発チームの管理はこれで成り立っていますが、お客様向け、経営層向けにはプログラムコードの話をしても伝わらないため、問題点とその修正点をわかりやすく説明し、報告する必要があります。
単純に考えるとBTSを初めから導入したほうが良いと思われますが、社内の文化やチーム特性を考慮するとエクセルの方が都合の良い場面が出てきます。
エクセルベースだから「できるプロジェクトチーム」は自前でツールを作ってしまう
すでにBTSを導入しているプロジェクトチームの中には自動的にエクセルと連動させるようにマクロを作成したりするチームも現れました。
これらのツールは横展開し、使いたいチームは使えるようにしました。
その後の展開｜業務プロセスが定着したのでBTSにスムーズに移行
エクセルを使用して業務プロセスが問題なく周り、障害件数も減少していきました。
業務プロセスそのものが定着してきましたので、自然発生的にツール化の話がでてきました。
エクセルにてデータ構造や業務プロセスが確立しているので、ツールに移し替えること自体は何の問題もなくスムーズに行われました。
このときはJIRAを使用して構築しました。
私自身がサーバーの構築からOSのインストール、DBの構築と、JIRAのインストール、AD連携、管理画面の運営とダッシュボード運営、などのシステム周りの構築を一人で行ったことはまた後日別記事で書きたいと思います。
投稿者プロフィール
- プロジェクトファシリテーター
-
フリーランスのITコンサルタント として、CIO代行サービスで多くの企業をサポートしています。
企業のIT戦略 立案・実行支援を行い、
ITを活用した情報システム の導入・マネジメント支援しています。
IT利活用 に関して気軽な相談から経営に関わる支援まで幅広く受け付けています。
普段私が仕事をする時にお客様やプロジェクトチームの方々に実際に話している内容をたくさんの方々に届けます。
DX（デジタルトランスフォーメーション）が好きすぎるので「DX王子」と呼ばれています。
最新の投稿
仕事術2024年8月29日面談前に職務経歴書などの提出をお願いする理由を解説します！
フリーランス2024年3月22日フリーランス年収1000万を目指すなら「誰の言葉か？」が重要
仕事術2024年3月19日なぜオンラインミーティングを録画するのか！？メリットしか無いからです！
フリーランス2024年3月4日50歳以上のエンジニアに送る！あなたに仕事がない理由
