2012年6月19日火曜日

貧乏暇なしをどう打開するか


短納期のプロジェクトにて時間がないために、
えいやーで設計書を作成しとけ!
もしくは、テスト工程を圧縮するんだ!
その結果、品質が悪化し対応に追われる。

なんとか終わった!
よし、次のプロジェクトだ!
ところが先に納品した既存システムでトラブルが続出し、ただでさえ短納期の新プロジェクトがさらに圧迫される。

さらには連日の残業による疲労が蓄積して作業ミス、そこからトラブル発生。
そして、負担が更に増える対策。
「作業は必ず二人以上で実施、二重チェックします!」

以下スパイラル・・・

よくありますよね、こんな話。
まさしく目の前で日々繰り広げられています。
エンドレスに地獄行き。
いや、既に地獄かもしれない。

デスマーチは終わりがあるけど、この場合は終わりがない。


さて、こういう状況でどうやってカイゼンするの?というお話。
カイゼンしようにも恒常的に時間がないのでどうしようもない、みたいな。


私見で拙いですが、道はひとつしかないと思っています。

時間を作って、手間のかからないカイゼン案を考えて、実施する。
ダメなら別の案を考えて…もう単純にPDCA回すしかないと思うのです。

こんなこと言うと、当然「だから時間がないっつってんだろうがバカヤロウ」と言われます。
この「時間を作る」が難しいんですよね。

色々考えてみたんですが、結局、【人を増やす】以外にないです。
するとまた「単純に人を増やしても余計に手間が取られるだけ」と言われます。
特に現場から。
僕も言いそうです。

いやでもね、人増やして何かしらカイゼンしていかないと、ずっとしんどいんですよ?
だったらとりあえず人を増やして時間作れるようにしましょうよ。

ただ、何の考えもなしにとりあえずで人を増やすのはあり得ないです。
人を増やして何をしてもらって、どういう状況になれば、時間が作れるのか。
まずはこれを検討/実施してPDCAを回しましょう。
それは、「ドキュメントを整備して、調査を迅速にする」だったり「作業の自動化ツールを作成して、作業時間が圧縮する」だったりするわけです。

なお、これら第1段階のPDCAを回すために必要な人材は、業務システムの構築をやっているチームであれば、その(業務システムの構築の)経験がある人が望ましいです。
違和感が少なく参画できますからね。


さて、ここでやっと時間ができる状況がやってきます。
おそらくこの時点まで半年〜1年くらいかかるのでは、と思います。

この状態のままでは、コスト過多の状態ですので、恒常的に負荷を下げ、かつ品質を向上する必要があります。
それは、アジャイルなのかウォーターフォールなのか、はたまたスクラッチなのかパッケージなのか、といった要因により変わってくるので、ここではパッケージ利用の場合で考えます。

現時点で、僕が関わるPJの殆どがパッケージ利用ですので。
(もはや職場に提案しようとしている内容・・・)

最初に、単体テスト/結合テストの自動化を進めます。
パッケージ利用であれば、運用シナリオの根幹は同じはずです。
当然ユーザによってカスタマイズが入ってシナリオの変更や追加が発生しますが、基本の路線は同じでしょう。
ですので、基本となる運用(テスト)シナリオを作成し、テストの粒度も統一します。

次に、環境構築を半自動化します。
環境構築時のミスに起因する障害って案外多いですよね。
ですので、環境構築を反自動化してしまいます。
ちなみに「半」としているのは、パラメータ設定で柔軟に対応できるようにするためです。

最後に、ユーザ単位にCI環境を構築し、週に1度は実行します。
もしくは、ハード的には全ユーザを1ヶ所でもかまいません。
全ユーザを1カ所にする場合、2番目に作成した環境構築ツールを使用します。
流れとしては、1)環境構築ツール、2)結合テストシナリオ、3)環境構築ツール・・・以下ループ。

ここまでテストの工程を自動化すれば、品質の向上は十分見込めるのではないかな、と考えています。
ま、結果が出なければまた別の策で試してみるしかないです。

なお、カイゼンの効果が出てくるのは1年半〜3年程度かかるのではないでしょうか。
カイゼン策は慣れないツールを使う場合も多いでしょうから、習得にも時間がかかるでしょう。
何より、それくらい長い目で捉えて考えないと長期的に通用するカイゼンにはならないと思います。


以上、貧乏暇なしをどう打開するか。
とるITエンジニアの拙い意見でした。

0 件のコメント:

コメントを投稿