ビジネス環境の変化が激しい昨今、業務改善を行うにも素早く対応しなければまたすぐに状況が変わってしまいます。今回は変化の激しい状況に対応できる開発手法としてアジャイル開発と言う概念を、業務改善という切り口で解説します。
目次
概要
アジャイル開発について業務改善の切り口から解説する前に、まずは一般的な説明としてWikipediaの説明を確認します。以下、一部を抜粋します。
アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。 近年、アジャイルソフトウェア開発手法が数多く考案されている。 ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。 アジャイルソフトウェア開発手法の例としては、エクストリーム・プログラミング (XP) などがある。 非営利組織 Agile Alliance がアジャイルソフトウェア開発手法を推進している。
（中略）
アジャイルソフトウェア開発手法の多くは、反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化しようとしている。 1つの反復の期間は、プロジェクトごとに異なるが、1週間から4週間くらいであることが多い。
（以下略）
つまり、プログラミングとレビューを短い期間で反復しながら完成度を高めていくソフトウェア開発手法の総称だと言えます。
アジャイル開発と言う概念のメリット
非エンジニアでも採用できる概念
ここからは業務改善と言う切り口でアジャイル開発という概念を見ていきます。まず、概要の項で抜粋したWikipediaの説明ではソフトウェアの開発手法とされていました。これは非エンジニアの事務職が手がけるVBAによるちょっとした自動化ツールの開発でも適用できる概念です。このようにプロのエンジニアでなくても取り入れられる点がメリットの一つです。
ソフトウェア開発だけではなく、業務改善全般に適用できる概念
アジャイル開発というのは一般的にはソフトウェア開発の開発手法群です。しかし、ここでは業務改善全般に適用することを考えます。業務改善とは業務のプロセスを変更したり新たにプロセスを導入することによって業績向上を図ろうという活動のことです。
業務プロセスの構築や改善を開発と捉えると、まずは小さく始めて、変化を観察する。その変化に応じて必要な修正を行う、という手順が考えられます。これはまさにアジャイル開発の考え方です。
ビジネス環境の変化が早い昨今、プロセス構築の立案部分、計画部分に時間を割くことは時間がもったいないです。また、時間が掛かっている間に状況が変わってしまうだけでなく、結局やってみると全てが想定通りには生きません。結局修正が発生することになります。
そこで、結局修正が発生するのであれば、とりあえずある程度のモノを出して、その結果を見てみようと言う事です。そしてその結果を次に生かす修正をする方が、入念な計画を立ててなかなか実行に移せないよりも速く前進させることができます。
これが、ソフトウェア開発だけではなく、業務改善全般に言えることだという意味です。
「とりあえず」は投げやりではない
前項で、「とりあえずある程度のモノを出す」という説明をしましたが、これは質の低いモノでも良い、とか、雑だったり投げやりなやり方でも良いと言う意味ではありません。修正を前提に開発をすると言うことは、修正のための良質なフィードバックを得る必要があると言うことです。まずやってみる、と言っても、狙いや方向性はしっかりと出した上でやってみると言うことです。例えばベータ版を出すにしても、試しに使わされるユーザーからしてみれば、できるだけ良いモノ(ソフトに限らず)を使いたいことは変わらないはずです。
フィードバックを得られることのメリット
アジャイル開発等位考え方は開発と修正の反復を繰り返します。その差異修正に使うフィードバックを得られると言うことは非常に大きな事です。実際の反応が得られるからです。悪影響も含めて実際の反応が得られることは大きいです。
そのため、まずは小さく初めて見ることが成功の鍵となります*1。
具体例
VBAによる自動化ツールの場合
VBAでちょっとした便利ツールを作成するなら、
①入力する内容を入手する
②どう加工したいのか、何を出力したいのかを確認する
③早速手をつける
④使ってもらう
⑤フィードバックを得る
で進めるのが最短で、しかも使ってもらう人の満足度も高くなります。理由は、
「とりあえず作ってみたから使ってみて」と言えるまでの期間が短いので、それだけで依頼した方の満足感が得られるからです。フィードバックを得た後の修正もすぐできるので、「お、大分良くなったな～」と感心してもらえます。
素人が厳密な要件定義をするのはまず無理で、しかも大変です。しかも細かい仕様まで決めてから着手しても「こういうのじゃない」と言う事が起きて、作った側も使う側も不幸になります。
まず着手。そして修正。失敗を許容していると言うわけでは無く、修正がある事を前提に軽く着手する。
業務プロセス改善の場合
たとえば販売リードタイム短縮のために受注生産方式から在庫販売方式への変更を検討しているとします。このような場合、在庫増加額や倉庫管理費用の算出くらいは必要ですが、詳細な在庫量の推移予測を作成すると言うのは意味がありません。
まずは、影響が大きすぎない程度の品目をいくつか抽出し実際に新しい方式を適用すればいいのです。そしてうまくいったり、うまくいかなかったりする部分が必ず出てきます。それらのフィードバックを踏まえて、対象の品目を拡大する事で素早く実務に落とし込みながら新しい業務プロセスの導入を図ることができます。
このように現場を巻き込みながらプロセス開発を行う事により、現場とのギャップが生まれることがなくなり、スムーズな本番稼働を行う事ができます。これはソフトウェア開発でも同様です。
注意点
アジャイル開発で留意すべき事は、ドキュメントが少なくなる点です。まず着手してみる、必要に応じて修正すると言う特性上、予め綿密な仕様を決めません。そのため、仕様書がないまま開発が進み完成してしまうと言うことがあります。
これを防ぐ為、どのような目的で開発をしたのか、どのような仕様なのかと言った仕様書を完成してからでも構わないので作成するようにします。
これはソフトウェアでもその他の業務改善でも同じです。
まとめ
この記事をまとめると以下の通りです。
- 一般的にアジャイル開発と言えばソフトの開発手法
- この記事ではその考え方を業務改善全般に当てはめる
- とりあえず、着手してみるというのは投げやりでも雑でもいいと言うことではない
- フィードバックを得られるという事のメリットが大きい
- 現場との乖離が小さく導入がスムーズにできる
- 仕様書は後追いでもいいので作成するようにする
＜関連記事＞
*1:AI・人工知能の世界ではいきなり一番大切な事から入るべきだという考え方もあります
