※この記事は、Speee Advent Calendar13日目の記事です。 昨日の記事はこちら
こんにちは。Speeeの岡部です。
5月からSpeeeに入社してプロジェクトマネージャーをしています。
前職はネット広告の代理店で2年間は広告の運用を、その後2年間は業務改善系のプロジェクトをいくつか担当していました。
そんな僕が最近、ひしひしと感じていることがあります。
「業務改善って本当に難しい！」
「オペレーション・エクセレンス」という言葉をよく耳にするようになりましたが、それを実現するのはすごく難しいです。それどころか業務を改善しようとして、かえって悪化するケースもあるんです。「え、そんなことあるの？」と思うかも知れませんが、結構起こりがちです。
僕も何回かやってしまったなーという経験があります。
- その改善施策を実施して、削減される時間とコストはいくらですか？
- その改善施策を実施するには、どのくらいの時間とコストがかかりますか？
- その改善施策を実施して、解決される課題は何ですか？
- その改善施策をやらなかったとして、どのような悪影響がでますか？
やらかしたなーと思ったときはだいたい上記の質問に答えられないような状態でした。
どのような業務改善施策であれ、これらの質問にスラスラ答えられないとプロジェクトとしては黄色信号です。知らず知らずのうちに、
- 本当の課題が解決しないままフローが複雑になってしまった
- 人件費含む投下コストが回収出来なかった
- ほんとは取り組まなくてもいいようなことに時間を使ってしまった
といった「目的を達成しない余分な仕組みや取り組みをやっただけ」に陥っていることがあります。この記事ではこういった状態を「業務改悪」と呼んでいきます。
そんな「業務改悪」をやってしまわないようにするために、注意するべき点は3つあるんじゃないかなと、僕は考えています。
- 課題をきちんと特定する
- その課題は解決するべきものかを判断する
- 制約条件を見定める
今回は業務改善に関わっている人、あるいはこれから関わっていく人に向けて、
「業務改悪」にはどんなパターンがあるのか、どういった点に注意すればよいのかを仮想の事例を踏まえて解説していきます。
担当案件を増やすプロジェクトの仮想事例
=================================================
あなたはWEB制作会社に勤めている開発チームの一員です。
この会社はさまざまな企業の自社HPを作成する会社で、営業チームと開発チームの2つのチームに分かれています。
営業チームが契約を受注しクライアントの要望を集め、開発チームは営業チームがまとめた要望を元に適切な構造やデザインを考えて実装し納品します。
営業チームは毎月たくさんの契約を取ってきますが、開発チームは一人当たり3社担当するのが限界で会社の売上は伸び悩んでいます。
そんな中、「開発チームが一人当たり5社担当できるようにしてほしい」という相談があなたのもとに来ます。
「うーん、今の業務であと2社増やすのは無理だな～。」
「やっぱりサイト構造の設計に一番時間がかかるんだよな。」
そんなことを考えながらプロジェクトを進めていくことになりました。
=================================================
イメージをつかんでもらうために仮想の事例を作ってみました。
こういった事例の業務改悪になりがちなのは、
「いろいろやって開発チームで5社持てるようになったけど、大目的である売り上げ増につながらなった」というパターンです。
上記のような状態にならないように、どうやってプロジェクトを設計していくのかを
- その課題は解決するべきものかを判断する
- 課題をきちんと特定する
- 制約条件を見定める
の3つの注意点にそってみていきます。
①その課題は解決するべきものかを判断する
意外と見落としがちなのが、そのプロジェクトはそもそもやるべき事案なのかという検討です。
業務改善系の話のなかには、掘り下げてみると実は課題はそこじゃない、みたいなことがよくあります。
今回の例でいうと、「開発チームで一人5社担当せよ」というお題の裏には以下のような前提条件があります。
- 「会社の売上が伸び悩んでいる。」
- 「売上が伸び悩んでいる原因は契約社数が増えないからだ。」
- 「契約社数が増えないのは開発チームのリソースが逼迫しているからだ。」
プロジェクトに取り掛かる前にこれらの前提が本当なのか確認する作業は必須です。
この確認をしないと、「必死に頑張って一人5社担当できるようになったけど、結果として会社の売上全然伸びてない！」みたいな悲しいことが起こります。
例えばよくよく確認した結果、「契約企業数が増えない本当の理由は、営業の受注率が低いことだった」であれば、開発チームのキャパを増やしても契約社数増にはつながりません。
もっと前段まで確認すると「売上が伸びない理由は契約社数ではなく、提供サービスに対して単価が低いから」ということもあるかもしれません。その場合もお題をクリアしても大目的の「売上増」にあまり寄与しないという結果になりかねません。
いきなりプロジェクトに着手する前に「このお題はどんな前提条件のもと成立するのか」「そもそもその前提条件は正しいのか」を確認することが必要です。
②課題をきちんと特定する。
今回の例だと「サイトの構造設計に時間がかかっていること」を課題感として捉えています。プロジェクトに取り掛かる前の当たり所を探る段階であればよいですが、本格始動するタイミングでこの状態では具体的な改善アクションが定められないので不十分です。
僕が課題の特定のためによく使うフレームワークは「What,Why,How」です。
「What,Why,How」の思考法はいろんな場面で使われますが、課題解決の場合は
「What」：「我々を困らせている事象は何なのか」
「Why」：「なぜその事象が起きているのか」
「How」：「どうやってそれを解決するのか」
と問いを立てると整理しやすいです。
特に重要なのは「What」と「Why」です。この2つが見えればおのずと「How」も見えてくることが多いです。
今回でいうと
「What」は「サイトの構造設計に時間がかかっていること」と設定し、
「Why」で「なぜ時間がかかっているのか」と要因を洗い出します。
（個人的には「Why(なぜ)」よりも「What made（何がそうさせているのか）」と置き換えたほうが適切な課題設定ができる場面が多いです。）
「サイトの構造設計に時間がかかっていること」の「Why」を掘り下げると、例えば
- 「営業の集めた要望を読み解くのに時間がかかっている」
- 「設計に必要な情報を何度も営業を介して先方に確認することで時間がかかっている」
等といった要因が出てくるとおもいます。
ここまで課題特定が進んでくると手段も見えてきます。
「要望を読み解くのに時間がかかる」のであれば、「営業のヒアリング項目をフォーマット化しよう」だったり、業務の性質上どうやっても確認がおきるのであれば、「営業にサイト構造設計までやってもらう」も一例としてはありです。
③制約条件を見定める。
「制約条件を見定める」というと「お金とか時間とかの守らないといけない部分をはっきりさせるってことでしょ」と思いますが、ここで言いたいのは「守らないといけないと思っていた部分が実はそうでもなかった」というケースがあるということです。
そうした「誤った制約条件」を打破すると、「オペレーション・エクセレンス」な改善ができることが多いです。
例えば上記の例だと「一人5社担当」ときくとみんな5社ずつ担当するような印象になってしまいますが、実は重要顧客の担当者は3社担当のままで、シンプルな要望の顧客担当者は10社抱える、といった方法もありです。
②で上げた「営業にサイト構造設計までやってもらう」という手法も「開発チームの業務範囲は維持する」という「誤った制約条件」を排除して生み出されるものです。
最後に
ムダを減らすためにやったことがムダにならないように
業務改善をやろうとして、それが負の遺産になってしまうことはとても悲しいことです。会社として損失になることもですが、なにより本人が頑張ったことがムダになってしまうことがしんどいです。
自分の経験をもとに3つの注意点を紹介しましたが、本質的には「目的思考」を持ち続けることが重要だとおもいます。
この「目的思考」は僕らが特に大事にしている価値観1つです。「何のためにこれをやるのか」という問いを持ち続けることが、こうした悲劇を減らし、さらには本当の「オペレーション・エクセレンス」を実現することにつながると思います。
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで仲間を募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
