無料ブログはココログ

« [#Agile] 組織的改善から現場改善へ #JaSST_Kansai | トップページ | [#TiDD] チケットが放置される理由 »

[#TiDD] チケット駆動による理想的なプロセス改善 #JaSST_Kansai

JaSST関西2013togetter私的まとめ)で基調講演と共に聞きたかったのは、 赤羽根さんの「ソフトウェアの品質向上に資する、開発・運用現場の情報管理」でした。

この発表では、システム障害と重大(サービス)停止に苦しむ現場にITS(Redmine)を導入して、7年間でシステム障害を1/10、重大停止を1/20にされた事例発表です。

プロセス改善の難しさ

90年代にCMMと共にプロセス改善はブームになりました。当時の反応は多様で、ソフトウェア工学の成果を能力成熟度の視点で体系的にまとめたという評価の一方で、「修身」だとの批判的な意見も聞かれました。

CMMに賛同する人の反応も色々で、中には変に利用されないようにと、進んで組織的なプロセス改善を推進するSEPG(software engineering process group)に志願された方もおられました。

SEPGが素晴らしい標準プロセスを作っても、現場がやらされ感を感じていい加減な開発をしていては改善は進みません。現場と組織が一緒になって積極的に改善を進めることが求められます(その方策として開催された社内ワークショップが評価され、SRAの発表が2003年のSEPG Japanで表彰されるなどしました)。

プロセス改善をどう考えるか?

CMMはDoDなどがカーネギーメロン大学と共に、高品質なソフトウェアを調達すべく考えられたソフトウェア開発組織の能力の成熟度を示す段階モデルで、「業者を識別するツール」です。

いわば認証のような物ですが、能力が成熟するとレベルが上がるので「達成」と呼ばれます。アセッサ(アプレイザ)の資格を持つ人に「ここまでできた様ですね」とお墨付きをもらいます。

つまり、発注側が「それぐらいはしておいてもらわないと」という組織のプロセスが実施されるようにする「底上げ」の仕組みです。実際に「レベル5でこの品質か」と当初言われていた海外の企業でも、何年後かに「レベル5だけのことはある」と言われるようになったと聞いた事があります。

しかし、これを「属人性を排除するツール」と考えてしまうと、結果を安定させる必要が生まれます。標準プロセスの置き換えは出来ても削減ができなくなって、標準プロセスはドンドン膨張して減らせなくなります。

重いプロセスは開発者の負担が大きく、開発者はやらされ感を感じてしまいます。するとプロセスモデルの持つ、伝達、教育、ディスカッション、改善といった特徴ではなく、まさに修身のような強制と重圧から、ごまかす事を考える様になってしまいます。

CMMの誕生の経緯のように、標準プロセスは底上げの道具して用いるべきだと思います。そうすると必須でないものも見えてきて、よりふさわしいプロセスが見えてくると思います。

赤羽根さんの事例

赤羽根さんの事例では、まずそこにシステム障害という課題がありました。毎日のようにトラブル対応に追われ、残業も多かったそうです。

その原因は年間3万件を超える多くの変更要求によるもので、コミットも年間2万回もあるそうです。それをエクセルで管理していたのでファイルを開くのに3分もかかっていた様です。赤羽根さんいわく「エクセル、素晴らしいですよ!」とのことなので、適材適所でなかったということでしょう。

このような背景から、管理しきれないバラバラの情報をRedmineのチケットでまとめて管理する事を考えられて、組織内に広げられました。

理想的なプロセス改善

赤羽根さんのIRedmine導入はプロセス改善としては、とても理想的です。

◎導入時にメリットを説明して合意を得ている

情報交換会でおうかがいしたところ、オフィス文書の更新差分が確認できるなど、現場の担当者にとって、理解しやすいメリットを説明されたそうです。わかりやすいメリットを説明して、改善に向けて前向きになってもらえたのはやらされ感がなく、とても理想的です。

CMMブームの頃、信頼性が上がれば、障害が減って、利益が増えて、給料も上がる、との説明を聞いた事があります。「情けは人の為ならず、巡り巡って我がのため」のような、わからなくはなくても、今ひとつ乗り切れないような、気がしました。

◎現場と組織にメリットがあった

直接的なメリットだけでなく、本来の目的である「障害と残業の削減」という現場と組織の共通のゴールが設定され、しかも、達成されました。現場のわがままでも、管理の都合でもないwin-winの改善です。

作業の効率化によって楽をする事は大切です。それと共に仕事ですので、会社に利益がないといけません。

◎結果を公開して次につなげている

改善の結果を数値にまとめて公開する事で、管理者と現場にフィードバックされています。改善の効果が見える事で、今後も継続できると思います。

進捗報告などで、たまにほめたり、支援するなど、作業の意義をさりげなく伝えることは、活動を維持する上で大切な事だと思います。

◎必要な規律を守っている

サブ・タイトルに「現場主導によるITS導入」とあるように、現場手動で改善を進められました。このような場合、組織内でバラバラになってしまいがちです。

しかし、管理者としてポイントを絞って、Redmineの環境を維持されました。カスタムフィールドはドンドン増えてしまい易いので、必要な物だけに制限されているそうです。全体をよりよい状態に保つ事は、組織的な活動として重要な事だと思います。

まとめ

組織的にプロセス改善を進める事は大切です。しかし、それが現場の負担になって、身動きが取れなくなるようでは問題です。改善の効果が得られないだけでなく、状況が不透明になるなど、様々な弊害を生むようになるでしょう。

赤羽根さんの事例は現場主導で底上げとして改善を進めつつも、組織として守るべき事は守るという理想的な改善活動でした。ITSおよびチケット駆動は現場にもメリットが多いので、よく考えて導入すれることで大きな効果が得られたのだと思います。

以上、期待を裏切らない講演で、充実した1日を過ごさせていただきました。

【告知1】 2013/8/24(土)
GxP社「SIの現場で使えるチケット駆動開発」セミナー
「チケット駆動開発の知っておくべき大切な事」と題して講演させていただきます。

【告知2】 2013/ 10/16(水)-10/18 (金) 
SPI Japan 2013 - ソフトウェアプロセス改善カンファレンス 2013 -
「チケット駆動開発によるプロセス改善 -現場重視、管理重視、それとも情報共有重視 - 」と題して事例発表させていただきます。


« [#Agile] 組織的改善から現場改善へ #JaSST_Kansai | トップページ | [#TiDD] チケットが放置される理由 »

Redmine」カテゴリの記事

チケット駆動開発」カテゴリの記事

コメント

まさにそのとおりだと思います。
私も40人を超える開発チームで、現場SEPG的なことを実施しています。
不具合や顧客からのクレームが多発し、その都度対策を検討し、開発現場に導入しています。
しかし、開発現場にとっては、「やることが増えた」「やらされている」という状況です。
会社のSQAからも指摘を受けさらに組織プロセスが肥大化し悪循環に。
顧客からもプロセスが開発の邪魔をしてるんじゃないか?と疑問の声も・・・。
顧客のためにやっていることが顧客に迷惑をかける結果になっている。
まさにLose-Loseの関係です。

開発現場には成功体験が必要なのですが、40人を超えると手を当てる部分も多く、どこから手をつければよいか・・・。

一度Redmineを使い管理しようと試みましたが、40人となると運用が難しく、チケットが放置され・・・使われない結果に。
(問題に対して真因を見極めずにITSを導入した結果なんだと思いますが・・・)

大規模開発に適用するために何かポイントがあればご教授いただきたく。

既にされているかもしれませんし、状況がわからないので外しているかもしれませんが、みんなの力を活かす方向で考えるというのはいかがですか?

・ふりかえりなど意見を聞く場を作る
 現場の人は、色々と気付きや思いがあると思います。
・問題意識を持っている仲間を増やす
 一緒に考えてくれる人が多いほどうまくいくと思います。
・プロセスチャンピオンがいれば応援する
 熱意があってファシリテーションできる人がいれば、ドンドン応援されてはいかがでしょうか?

権限がある人に対して、反発する人や任せてしまう人が居ると思います。そう言う人に限って色々と考えているかも知れません。他に良い方法があれば必ずしもRedmineにこだわらないというスタンスなら、案外良い意見が出るかもしれません。サーバントリーダーシップを発揮されてはいかがでしょう。

40人というのは一つのチームとしては難しい人数かもしれませんが、組織としてはそれほど多くないと思います。良い感じの分割統治体制が取れれば良いのですけど。

かつてのQCサークル活動は自分たちの問題を見つけ出して、その改善を自分たちで行おうという活動でした。私はQCサークル活動自体には小さな改善を少しずつしか進める力しかないと思っています。が、一方で「自分たちで問題を見つけて、その問題の改善方法をシステム視点で考え、それを実施してよりよくしていく」という意識変化の面で非常に効果のあるトレーニングだと考えています。
個人の意識ではなかなか改善は難しいですから、利益を共通にするチームを対象にして、そのチームに自分たちで問題を考え、システム視点で問題の改善を自分たちで作り、それを実施するという体験をしてもらうことで意識変化が生まれるのではないか?と考えますがいかがでしょうか?
「やらされる」ではなく、「やるべき問題点を指摘される」、「解法の一例を例示されたので自分たちのやり方に置き換えてみる」というプロセス改善の導入を変化させることが大切なように思えますし、プロセス改善において、SEPGが主役ではなく、あくまでも現場の技術者個人個人が主役なんだと推進者自身の意識変化も重要だろうと思いますよ。
まずは、40人をいっしょではなく、4~5人程度のチームで、自分たちの改善を競う態勢にするのも一助かと。

CMMのレベル3程度なら、きちんとばらつきが制御できれば、バグゼロ程度は十分に可能です。

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

« [#Agile] 組織的改善から現場改善へ #JaSST_Kansai | トップページ | [#TiDD] チケットが放置される理由 »