経営改善と業務改善(その25)

今回も経営改善と業務改善についてお話します。

前回は、PMBOKの第7版についてお話ししました。この中に出てきたアジャイル開発を少し掘り下げて、今までの改善との違いについてお話しします。

アジャイル開発

まずは、「アジャイル」の意味からですね。agileは素早いとか機敏とか活発なという意味があります。そこから「アジャイル開発」とは、迅速さを優先する開発を指します。具体的には小さな結果を出して、設計・開発・テストを繰り返しながら、最終ゴールに向かっていく、反復型・適応型の開発です。

1回の開発サイクルをイテレーションとかスプリントとか呼び、これを何回も繰り返していきますが、全体目標(最終ゴール)が見えないとよくないので、リリース計画を立てて、個別ゴールとイテレーションの長さを決めておきます。モバイル用アプリの開発に向いているといわれています。

結果は途中で確認できますが、ユーザーの望む姿の確認によって仕様変更も受け付けることもできるので、最終ゴールが最初と異なることもあります。

ウォーターフォール開発

一方、これとは異なり昔からの開発手法として、ウォーターフォール開発というのがあります。こちらは、最終的な結果を予測して、完成形を描いたのち、設計・開発・テストと一つずつの段階をきちんと終わらせながら、全体目標を達成するもので、逐次型・予測型の開発となっています。

設計・開発・テストで成果物をつくりますが、ユーザーが触れる姿になるのは最後の納入時だけになります。基幹システムの開発に向いているといわれています。ゴールが最初と異なることはないですが、ユーザーが望んだ姿になっているかを確認するのが最後なので、思い描いた通りかどうかが微妙です。最初のイメージがしっかり固まっていないとダメなことが多いです。

じっくり考えて、結果を予測する方が無駄な寄り道をしないようでいいように感じますが、昨今のように急激な時代変化にはついていきにくいです。昔ならば、15年使えるシステムといって誰も異議を言わなかったと思いますが、今は15年前にはiphone(2008年)もipad(2011年)もなかったことを考えると変化が加速化していることを肌で感じていると思います。

ウォーターフォール型改善とアジャイル型改善

つまり、これを改善に置き換えると従来型のウォーターフォール型改善は、しっかりとした大きな目標を考えて、その目標達成のための手順や基準を丁寧につくったのち、改善に取り組む流れです。当然、中間報告は改善活動の進捗報告のみで、結果が何もない場合も少なくありません。期限は守られますが、改善結果は終了報告までのお楽しみといった感じです。

一方、アジャイル型改善は大きな目標を小さな目標に分解して、まずはその目標を達成させ、結果を出し、その結果をもとに次の目標を見直すといったことを繰り返しながら、最後の目標にたどり着くようにする流れです。中間報告では、途中の結果は見えていますが、状況によっては、最後の目標や手法等は見直しが入っている可能性もあります。

ウォーターフォール型がいいとか、アジャイル型がいいとかというわけではありませんが、それぞれ、利点と欠点があります。とはいえ、時代の変化を考えると、こまめな結果が出るアジャイル型の方が最近はニーズが高いように思います。言い換えると年度目標を立てるのは問題ないですが、月度目標も立てて、結果を都度確認していくことも必要だということです。

経営改善計画で、3年とか5年の計画を立案する場合、年単位や月単位の目標設定がついおろそかになりがちです。そのため、年末しか結果を確認できずに、最終目標に届かないといった例が少なくありません。

これは、コロナ感染、ウクライナ情勢といった予測できないものや都市型水害、異常気象のような対応が難しいものによる影響もありますが、改善に不慣れなために進捗がうまくいっていないことを途中で結果として確認していないからだとも思います。

こういうときこそ、アジャイル型改善です。経営改善計画の元、複数の業務改善を考えることになりますが、大きな改善効果を期待する時間のかかるものだけでなく、改善活動を見える化できるような小さな業務改善をきちんと組み込むということです。

最初は1週間や1カ月で成果がでる業務改善を考え、徐々に2ヶ月、3ヶ月といった期間を広げていくようにします。できれば、四半期(3ヶ月)単位では結果が出るような目標設定にしましょう。これならば、年間で3回も結果に基づいて見直しをかけることができます。改善文化を定着させる方法としても使えると思います。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする