「ソフトウェア維持管理の現場改善（２）」

・

前回の要約

• 世間の変化の激しさが、既存プリケーションへの変更要望を増やしていること
• 保守費削減の流れからチーム体制は徐々に縮小されてきていること
• 時代を経て保守すべきアプリケーションは増え続けていること

・

負のスパイラルを抜け出すためには

・

５つのステップ

図1　５つのステップ

1. 自分達の仕事を層別する
   一般に維持管理チームでは、性質などが異なる雑多な仕事に追われているのが実情です。例えばある組織を例に挙げてみます。
   • 期日が決まっており、スケジュールを作って推進すべき数週間から数か月の比較的大きな機能追加変更（以降、プロジェクトと呼びます）
   • 随時電話やメールで来る問合せ、問合せから発生する調査
   • 発生したら徹夜してでも復旧しないといけない障害の対応
   • 改修案件の相談、それを実施した場合の概算見積もり
   このように維持管理チームの仕事は多様であり、そのボリューム（工数）、重要度、期日の切迫度合などが異なっています。これらを客観的に把握することが出来ていないと、常に目の前に現れる仕事に振り回されることになり、そのやり方が非効率を生んで、負のスパイラルを回す燃料となります。それゆえまず自分達の「仕事」にはどういう種類があり、どういう特徴を持っているのかを整理します。
2. 阻害要因を考える
   往々にしてこれらの仕事は、相互に阻害します。それゆえその関係について考えます。例えば急な障害対応は、プロジェクトとして進めている機能改修作業の予定を大きく狂わせます。目の前の仕事ばかり先に進めてしまうと、次の機能追加変更の調査や見積もりが停滞して実務部門を待たせることになります。
3. 戦略を立てる
   阻害要因を低減するための戦略を考えます。例えば、「プロジェクト作業を効率化することで品質向上のための時間をねん出する」、「実務部門からの問合せを減らすことで機能追加変更のための時間を確保する」など。この戦略はその組織の置かれている状況によって変わります。逆に「プロジェクト作業の優先度を下げて、問合せや相談の回答までのリードタイムを短縮する」という考え方もあり得ます。プロジェクト作業が大事なのか、実務部門のサポートが大事なのか。戦略を立てるとは要するに「自分たちのチームの価値をどこに置いて何を優先するか」という命題でもあるわけです。「全てが最優先」では、何も手を打てなくなります。
4. 戦術としての改善活動を考え推進する
   上記の戦略に基づいて、それぞれをどのような戦術で解決していくのかを考える必要があります。例えば、プロジェクト作業の効率化であれば、「手順化できる部分を手順書として整備し誰にでも出来るようにする」などが考えられます。逆に阻害要因である問合せに着目し、「類似した問合せについてFAQを作成し、実務部門に展開することで問合せを減らす」といった方向もあります。現場のメンバーがその気にさえなれば、いろいろなアイデアが出てくるでしょう。
   
   これらは、それほど斬新なものではないかも知れません。しかし日常の仕事に追われている現場メンバーにとって、この１～４のステップは意外と違う観点が求められるようで、私の経験でも「いままでこういう発想で自分の仕事を考えたことは無かった」という反応が多いのです。
   
   
5. 実行し結果を評価する
   そして何よりも実行です。ここでも発想の転換が必要です。一度に多くを狙わず、実施する施策を絞り込むこと。そして短いサイクルで振返りを行うこと。常に目的に立ち戻り、目的に合致した活動になっているかを確認することなどがポイントになります。

・

改善を駆動する手法

・見える化

アジャイル開発でも推奨されていますが、付箋に日々のタスクを書き出し、壁やボードに貼ることで、「見える化」することが効果的です。維持管理メンバーの負荷状況を直感的に把握できる上に、メンバー同士も互いの状況が把握できるので、助け合いや気遣いが生まれてきます。また課題や目標も周囲から見えるところに掲げることで、ブレない改善活動が出来るようになります。

・ムダに着目する

打合せで全員が揃うまでの待ち時間、サーバから資料を探し出す時間など、たとえ些細なことでもムダにこだわり、ムダを排除することで、意外と効率が上がります。人間は一日中仕事に没頭している場合であっても、仕事そのものの価値を増やさないムダなことに時間を使っているものです。特に割り込み、滞留、手戻りは、大きなムダを生み出すので、まずはこれらの観点で仕事を「見える化」する工夫をしましょう。また何がムダで何が価値なのかを真剣に考えるだけでも大きな意味があります。

・ジャスト・イナフを心がける

上記の４ステップ目の例として手順化やFAQ作成などを挙げましたが、いずれも従来のドキュメント作成の発想で作ろうとすると時間がかかってしまい、うまくいきません。例えば弊社のあるチームでは、タスクの見える化のために貼り出した付箋をそのまま手順書として運用しています。また個別の問合せ応答の内容のメモを、ほぼそのままFAQとしてまとめているチームもあります。つまりこれらの例に限らず、「即座に効果を実感できる範囲までを行う」「必要以上に労力を割かない」という発想でなければ、継続できません。

・デイリーのミーティングで振返りを行う

今までのミーティングサイクルを見做し、週や月の単位ではなく、日の単位での振返りを行います。月次や週次のミーティングや報告書作成ではなく、朝一番や昼一番などにデイリーミーティングを行い、見える化のボードの前で、各自の状況を会話するのです。特に大きなムダを生み出す遅延、滞留、手戻りなどは漏らすことなく会話しましょう。

・

成否を決めるのは手法ではない