アジャイルな業務プロセス改善
こんにちは、BYARDの武内です。
倉貫さんの新書『人が増えても速くならない』を先週は一気読みしました。
『人月の神話』という非常に有名な本がありますが、あちらはエンジニア向けのエッセイであるのに対して、こちらの本は開発サイドの実態を経営者やビジネスサイドに知ってもらうことを目的としており、非常に分かりやすく書かれております。
BYARDにおいては私もプロダクト・オーナーという立場で開発には関わっていますが、コードを書くわけではないため、本書を読むことで新たな学びがたくさんありました。
今回のnoteは本書でもメインテーマであるアジャイル開発のように、業務プロセスをアジャイルなアプローチで改善してことについて書いていきます。
1.アジャイルな業務プロセス改善
何か物を作るような製造現場であれば、一般的には人数を増やせば、その分だけ生産性が上がるはずです。その分のコストはかかるにせよ、人数に比例して生産性を上げることはできます。一方、ソフトウェアを生み出すプログラミングにおいては、じつはそうではありません。人数と生産性に、必ずしも短期的には相関関係がないのが特徴です。
こちらはソフトウェア開発に対する言及ですが、私はバックオフィスにおいても同様のことが言えると考えています。一見するとバックオフィス業務は作業ばかりで、人数を増やせばそれだけ処理量が増えると思われがちですが、大量生産品をつくる工場とは違ってそれなりに個別性が高い対応も多く、セル生産方式に近い業務であるため人数が増えるだけでは生産性はあがらないのです。
アジャイル開発は、ソフトウェア開発におけるプロジェクト開発手法のひとつで、大きな単位でシステムを区切ることなく、小単位で実装とテストを繰り返して開発を進めていくやり方です。
SaaSはサブスクリプション（継続課金）モデルですし、長く使ってもらうためにもずっと改善し続けることが重要です。クラウドコンピューティングやGitなどの開発環境の発展もあり、アジャイル開発を前提としたチーム体制など、組織の作り方もエンジニア組織においては大きく変化しました。
一方で、バックオフィスはというと、業務量が多くなってくると次から次へとタスクが振ってくるため、効率化とか改善とか考える暇もなく手を動かす対応になりがちです。ここ10年で日本のバックオフィスも様々なSaaSの恩恵を受けてきたはずですが、業務のやり方がほとんど変わっていないため、エンジニア組織ほど大きな変化は訪れていません。
働いている人達は限界まで頑張っています。しかし、その頑張りはあくまでも個人プレイによるもので組織力の向上にはほとんど繋がっていないように私には見えます。優秀な人も多いだけに、ここがもったいないとずっと思っていました。
プロダクト開発や中長期的なプロジェクトとは違って、バックオフィス業務は数日〜1ヶ月程度で完了する業務プロセスを繰り返し行うことが大きな特徴ですが、これをある意味アジャイル開発のように「小さい単位でサイクルを回しながら改善していく」と捉えるのはどうでしょうか。
生産性がなかなか上がらないバックオフィスを見ていると、繁忙期は猛烈に忙しくてとにかく処理するので精一杯、閑散期になったら色々と改善しようといつも思っているけれど、あっという間に次の繁忙期がきて、同じことの繰り返し、というパターンが多いように感じます。
閑散期になったらあれもやろう、これもやろう、というのはほぼ実現されません。それであれば、改善を後回しにせずにそれぞれの1つの処理の中で小さくPDCAサイクルを回して、小さく改善し続けていく方が半年後・1年後には圧倒的に成果に繋がりやすいのです。
業務を処理して終わりではなく、Check・Actionまで毎回行う意識が重要です。一つの改善は本当に小さなことでOK。業務を何度も回す中でこそ気付く改善点もたくさんあるので、最初から業務プロセスをカチッと作り込む必要はありません。
しかし、既存のタスク管理ツールやプロジェクト管理ツールでは、Check・Actionまで毎回行うということが困難でした。だからこそ私たちはBYARDというプロダクトを開発しています。
2.業務プロセスを常に見るから改善したくなる
BYARDは2022年10月にローンチしたプロダクトであり、現時点では「業務プロセスを可視化する、設計する」という機能について支持をいただいているケースが多いです。
Excelやドキュメントツールなどでマニュアルやフロー図は作ることが出来たとしても、それらが業務プロセスの全体感を理解するうえでは、ほぼ機能していないことは過去のnoteでも繰り返し指摘してきました。
マニュアルやフロー図はもちろん必要だと思いますし、内部統制上もきちんと整備する必要があるのは間違いないのですが、それが社内メンバー間の情報共有やコミュニケーションを円滑にしたり、業務を進める上で役に立っていないのです。
だからこそBYARDのストリームという形式はマニュアルともフロー図とも違う業務プロセスの可視化手段として支持されています。これは本を読んでもよく分からなかったけれど、説明が上手な人に解説してもらうと一発で理解出来た、ということに似ていると思います。
多くの企業では業務プロセスの可視化・共有が行われていないので、BYARD導入後には一つずつストリームを作っていく必要があります。手間がかかることではあるのですが、関係者を集めて業務プロセスの全体像をストリーム上で表現していく時間は、これまで見えていなかったものが見えるようになるため、導入いただいた企業の担当者様には「やってよかった」とのフィードバックをいただくことがほとんどです。
しかし、BYARDのバリューは可視化・共有して終わりではありません。これまで見えていなかったものが見えるようになるだけで、業務効率は確実にアップしますが、業務プロセス上で進捗管理やコミュニケーションが行える、という体験は利用者全員に「業務の改善ポイントに気付く」きっかけを与えるのです。
そう、BYARDを使って業務をすると自然と改善をしたくなるのです。私たちは機械ではありませんし、マニュアルなどで定められた業務手順も完璧であるとは限りません。業務を処理ながらそこに改善ポイントを見いだしていくことができるのも人間が仕事をする上での強みです。
誰がやっても同じ仕事、システムが処理した方が早くて正確な仕事があるのと同様に、世の中にはまだまだ人間が対応した方が良い仕事が無数にあるのです。BYARDはそういう仕事があることを前提に構築された業務プラットフォームです。
チェックリストやマニュアルを見ながら仕事をしても、その業務を改善したくはなりません。フロー図も同様です。ストリームという形式での業務の可視化は、仕事の進め方や改善サイクルにもいい影響をもたらします。
私たちが目指しているのは、アジャイルに改善され続ける業務プロセスを運営する組織のプラットフォームになることです。「マニュアルやフロー図が更新されずに放置されている」という悩みが発生しない状態を作るのがBYARDの役割です。
BYARDのご紹介
BYARDはツールを提供するだけでなく、初期の業務設計コンサルティングをしっかり伴走させていただきますので、自社の業務プロセスが確実に可視化され、業務改善をするための土台を早期に整えることができます。
BYARDはマニュアルやフロー図を作るのではなく、「業務を可視化し、業務設計ができる状態を維持する」という価値を提供するツールです。この辺りに課題を抱える皆様、ぜひお気軽にご連絡ください。
ノートの内容が気に入った、ためになったと思ったらサポートいただけると大変嬉しいです。サポートいただいた分はインプット（主に書籍代やセミナー代）に使います。