kazukiyunoue-work

働くを考える

業務を捨てて、チームを軽量化する3つの方法

業務を新しく始めることはそんなに難しいことじゃないですよね。「とりあえずでいいからやってみようか」とか、「これやっといてくれる?」などから新しい仕事のひとつが始まることは良くありますし、頻繁にブレストと称したミーティングで現状の問題点を洗い出し、その解決を目指す新たなプロジェクトを立ち上げることもあるでしょう。マネージャーがどこからともなく仕事を見つけてくる場合もあります。それ自体は良いことだと思うのですが、意義や意図といったものが明確でなかったり、その業務の結果が計測できなかったりすると、時間とともにタスクだけが引き継がれた仕事、または伝統的に続く"おまじない"的な仕事、いわゆるゾンビタスクとしてチーム内に残り続け、モチベーションも得られないままチームが日々タスクに追われる状況に追い込まれる危険性があります。そういった業務を減らすことは簡単ではありません。なぜなら勝手には死なないからです。ゾンビですしね。しかしいつまでも変化もなく、同じことだけを繰り返すチームに未来はあるでしょうか。ないですよね。そこで業務を捨て、機動力のあるチームにする3つの方法を検討したいと思います。

3つの方法

業務のサービス化による見える化

業務をウェブ化する」でも述べたように、手持ちの業務をすべてウェブサービスのように扱います。窓口をウェブ化し、アクセス数や利用数、CVR(顧客が目的に到達した率)といった加点方式の指標をフィードバックに、ウェブマーケティング的な活動を通じて、顧客のニーズや定量的な利用状況を見える化するのです。そうすれば顧客がどのようなニーズを持っていて、何を期待しているのか、かなりハッキリ明確化できるはずです。

自問自答

上記の見える化で得た情報をもとに、チームで「結局我々は誰にどんな価値を与えることができるのか」について議論しましょう。その際に役立つのが、ジェイソン・フリード氏、ディヴィッド・ハイネマイヤー・ハンソン氏の著書「小さなチーム、大きな仕事」にある「やめたほうがいいものを考える」の一節にある問い群です。小見出しを以下に羅列します。

  • なぜ行うのか?
  • どういった問題を解決するのか?
  • これは本当に役立つのか?
  • なにか価値を加えているのか?
  • それは行動を変えるのか?
  • もっと簡単な方法はないのか?
  • かわりに何をすることができるのか?
  • 本当にその価値があるのか?

これらの問いはリーンスタートアップキャンバスやアジャイル開発のインセプションデッキのような、物事の本質を問い直す良い問題集ではないでしょうか。これらをヒントに、今のこのメンバーで、本当に価値があり、誰かにとって役に立つ、取り組むべき何かを議論してみてください。

成長見込みがあり注目に価する業務を作る

不思議なことに、「無くなる」という変化に対して、人は極度に嫌う傾向にあるようです。もしあなたが既存の業務を明日から取りやめると周知したとしたら、どこからともなく反発があるでしょう。中には今までほとんど関わりのなかった人も騒ぎ出す場合もあります。そういったネガティブな感情は拡散しやすく、物事の進展の妨げになる可能性もあります。そこで、捨てずに残した業務や新たに空いたリソースで取り組む業務を、成長の見込みがあり、多方面から注目に価する業務にする努力を重ねましょう。なるべくポジティブなニュースの発信を心がけ、「◯◯(成長業務)をやってるチームね」という印象を持ってもらえれば、より業務の整理は付きやすくなると思います。

生き残りを賭けた世界規模の戦い

組織内には不思議なくらい山のような業務があります。どこにどのようなものがあるのかも分からないくらいあります。しかもそれらはどれもパッとしないもののような気にさせられます。組織内業務なのだから仕方のないことなのでしょうか。クラウドサービスやSaaS化が進む昨今、世の中には部分的でありながらも、非常に巧く設計された業務系のサービスがたくさんあります。中にはあなたの業務と完全に競合しているものもあるでしょう。それらは他のサービスと有機的(システム的)に連携するなどしてその価値を高めています。それを尻目に組織内だから、コンプライアンスだから、伝統だからと油断していると、いつゲームルールが崩壊し、立場が危うくなるかも分かりません。生き残る意味でも、捨てて、伸ばしていきましょう。

ティザーサイトから始める社内プロジェクト

社内プロジェクトのあるある話。プロジェクトの対象が既存の社内業務だったり、その置き換えだったりする場合がほとんどなので、特に顧客に当たる実際の利用者とコンタクトを取らないまま完成させ、いざ管理職の会議等で報告、現場まで伝わる頃に突如「聞いてない」「使いにくい」という不満が続出して、最悪プロジェクトが振り出しに戻るパターン。もうひとつが、逆に顧客、パートナーである関連部署、ステークホルダー、果ては無関係な人などが明確な線引きのないまま"中の人"としてプロジェクトに流入し、とめどない肥大化の後、アレの動く城の如く崩壊していくパターン。組織内には、こういったエピソードに事欠きません。酒の肴には申し分ないかもしれませんが、そうも言っていられないですよね。ではどうしたら防ぐことができるのでしょうか。

MVP

リーンスタートアップにはMVP(実用最小限の製品:minimum viable product)という考え方があります。これは顧客のニーズ等を検証し理解する(つまり学習する)ことを念頭にしたプロトタイプのことです。これを顧客に提示しその反応をまた次のMVPに反映しながら、製品を完成へと導く考え方です。エリックリース氏の著書「リーン・スタートアップ」では、ドロップボックスの例として動画型MVPが挙げられています。難解なコンセプトのサービスを動画のデモとして顧客に提示し、多くの見込み顧客の獲得に成功しています。僕はこの考え方は社内プロジェクトにも活用できると考えています。流行りのウェブサービスのトップページや人気の製品の詳細ページを参考に、写真や動画、そしていくつかの特徴を記したプロジェクトでやろうとしていることのページを作るのです。作る場所としては、社内のwikiConfluenceQiita:Teamなどの情報共有の場を活用しても良いと思いますし、もっと本格的にやりたいならウェブページを作れるwordpress等の汎用CMSコンテンツマネジメントシステム)を利用し、「wordpress ティザーサイト テーマ」等で検索して得られるテーマが活用可能かと思います。もし外部に情報が出ても問題ないなら、ウェブページを作成するウェブサービスであるWeeblyStrikinglyWixを活用すればもっと簡単に作成できるでしょう。問い合わせフォームやプロジェクトのメールアドレスを記載しておき、フィードバックを得られる仕組みにしておきます。あとは顧客から反応があればそれらをコンテンツに反映し、またフィードバックを得る、このループを回すのです。

あなたの仕事をより価値のあるモノに

おそらくティザーサイトのローンチ後はその驚くほどの反応の薄さに驚くことでしょう。それは往々にして「そのプロジェクトでやろうとしてることが何なのかよく分からない」という事に起因しています。ですので、ローンチ後は顧客(とされる人)に直接会いに行く等のアプローチを繰り返して、フィードバックを得る努力を重ねましょう。椅子に座っている場合ではありません。ループを何度も繰り返しているうちに、顧客のこともそして顧客のプロジェクトへの理解も深まっていることでしょう。「で、いつできるの?」と言われたら、もうこちらのものですね。あとは作るだけです。そこまでする必要があるのか、と疑問に思うかもしれませんが、個人的には十分にあると思います。足で稼いだ顧客との強い関係性は、導入期における顧客の拒絶反応の立派な緩衝材として働いてくれますし、自分の意見が反映されたものの方が良いに決まってますよね。大事なのはステークホルダー向けのプロジェクト憲章ではなく、顧客との関係性です。というわけでその社内プロジェクト、ティザーサイトから始めてみませんか?

ビシネスワークフローから抜け出し、独立独歩なチームになる

組織内には多かれ少なかれ、何かしら物事を実現するためのビジネスワークフローがあると思います。それらは工場の製造ラインのように、より効率性を追求する上ではとても理にかなっていますし、重要なことだと思います。例えば、マーケット部門->企画部門->研究開発部門->生産部門->営業部門や、企画部門->編成部門->アプリケーション開発部門->システムインフラ部門などが挙げられるでしょうか。しかし、重く錆びた鎖のようなワークフローには問題点もあります。ひとつは(時間やお金の)コストがかかること、です。それぞれの部門や部署が自らの業務に責任を持つが故に、各所でバッファーが組まれます。2日で出来ることは念のため3日に設定されるでしょう。これらが積み上がれば決して無視できない無駄なコストです。これはワークフローが長ければ長いほど顕著です。ふたつめは変えられないこと、です。製造現場では当たり前のことなのですが、なぜかビジネスにおけるワークフローには第三者的な観点でそれらを短縮したり、組み替えたりする組織や仕組みが全くと言っていいほどありません。当然、全体像が見えず、上流から来た仕事を下流に流すだけの状態になってしまった"中の人"が、問題点を指摘することもできません。最近では業務外の活動を通じて関連部署の信頼関係を築くやり方も注目されていますが、「信頼関係があると衝突を避けるためコストは下がらない」という以前見た記事にも納得感がありますし、信頼関係を築いた相手に「もっと良い部署があったのでさよなら」とは言いにくいものですよね。そこで個人的には敢えて離れてみるのが良いのかなと思っています。外部の組織や会社とやり取りするように、厳格で戦略的な関係にするのです。それを実現するために、"中の人"として、現場として、できることを3つ挙げました。

3つの実践

サービス化を徹底する

業務をウェブ化する」でも述べたように、自身の業務を徹底してサービス化しましょう。窓口をウェブ化し、内部の運営も可能な限りシステム化して自動化します。また依頼数や利用数、満足度といった加点方式の数値を指標として計測し、数値の上昇を狙って、特定部署だけでなく広く受け入れられるような業務に変えていくのです。また、ここで判明するであろう、ほとんど必要とされていない業務は潔く定量的に切り捨てましょう。

承認をしない、させない

ワークフローで多いのが承認というフェーズです。もしくは事前の根回しです。どんな些細なことでも、事あるごとに承認を要求する傾向にありますよね。予算の仕組み、責任の分解や所在の明確化という意味で致し方ない部分もあると思いますが、ほんとうに必要なのか、検討と議論の余地はあるでしょう。特に事後でも問題ないかは一考です。インバウンド側(あなたが依頼する側)に対しても、承認なしで実現可能か、もしくは簡略化できないか働きかけましょう。

信頼できるパートナーとだけ組む

インバウンド側に強い依存があると、自身の業務に支障を来たしたり、満足のいくものにならなかったりする危険性があります。万が一、インバウンド側の他部署の業務レベルが低いなら、サービス化によって得た業務の分かりやすさと定量的なパフォーマンスの数値を武器に、強く要求していきましょう。もしそれでも改善が見られないなら、その業務を自分たちで出来ないか、もしくは他部署で実現できないか、真剣に検討しましょう。他部署が原因で、自分たちが思い描く理想を追求できないのはナンセンスです。それも難しいようだったら、自身の業務(サービス)の質や立ち位置、存続含めて改めて議論しましょう。

独立して生きていけるか

何より重要なのは、ワークフローが用意してくれているであろう、インバウンド側の大きな後ろ盾や、アウトバウンド側(あなたに依頼する側)のあなたに間違いなく仕事を要求するであろう既知の他部署がなくとも、意義や価値のある業務が行えているか、ということです。現実のビジネスがそうであるように、何年も続いたワークフローが突如崩壊し、自身の存在が危ぶまれる事も考えられます。ワークフローに強く依存するのはリスク以外のなにものでもありません。脱ワークフローをすると、孤独感に苛まれたり、自分たちがちっぽけな存在に感じたりしますが、サービス化によって最小化し、質が圧倒的に向上したあなたの業務は必ずあなたを守ります。

効率化やコスト削減そのものを目的にしてはいけない理由

今より業務にかかる時間を短縮するとか、印刷物を減らすとか、会議を減らすとか、そういった効率化やコスト削減の業務は良くあることだし、また非常に良いことだと思います。しかしそれ自体を目的にしてはいけません。なぜなら、減らすことそのものが目的だと、突き詰めると、極論、そのモノや業務、ひいては自分自身の存在を否定するような、自己矛盾を内包してしまう危険性があるからです。

「月次報告書の作成に時間がかかっているから減らそう(目的化)」

「では作成するのをやめましょう(極論化)」

「おー」

「!?(自己矛盾)」

減らさなきゃいけないけど、自分たちの存在理由(とされるもの)でもある業務は捨てられないとなってしまっては、思い切り業務に取り組めなくなりますよね。

ではどうしたら

これも自身の業務の顧客像とその課題(ニーズ)が明確化できていない証拠だと思います。効率化して時間を短縮したいのは、顧客にもっと早く提供したいからとか、顧客にもっと安価に提供したいから、ですよね。一旦立ち止まり、これは誰のための何なのか、を考え直したり、皆で議論したりするのをお勧めします。また、業務の指標となるものを加点方式に切り替えるのも重要です。例えば、業務完了時に収集する満足度アンケートのポイントとか、業務の依頼数や利用数などを指標とし、効率化やコスト削減によってそれらが増加する(もしくはしない)ことをフィードバックにするのです。これは業務の評価者にとっても非常に分かりやすく、自身のモチベーションにも大きくつながります。

ソリューションはあなたの仕事の一部

効率化やコスト削減はあくまでソリューションであって、リーンスタートアップリーンスタートアップキャンバスが示す通り、ソリューションはあなたの一部でしかありません。しかもその割合は思うほど大きくないのです。重要なのは顧客と課題です。仮にソリューションの形式(タスク形式)で業務を割り当てられても、冷静に顧客とその課題について考えましょう。きっともっと良いソリューションが見つかるはずです。あなたのボスもそんなことを期待しているかも、しれません。

業務をウェブ化する

突然ですが、みなさんは普段どうやって仕事を受け付けていますか?メールやBTS(バグトラッキングシステム)、マネージャーからの口頭による指示でしょうか。もしくは、MicrosoftさんのOffice365のSharePointサイボウズさんのデヂエといった帳票系システムでしょうか。往々にしてそれらは曖昧だったり、または多義に渡っていたりしませんか?結果、言った言わないという不毛な議論したり、間違った解釈によって手戻りが発生したりしていませんか?また、誰がどれくらいの頻度や回数で、そしてどういった心持ちでそこに至ったのか正しく把握できない傾向にあります。そうすると、左から右へのこなすだけの仕事になりがちですよね。仕事が作業になる瞬間です。

3つの利点

業務改善としてのリーンスタートアップでは、あなたの業務はあなたが提供するサービスで、あなたの仕事を受け取る人があなたの顧客であり、その顧客行動だけがあなたの仕事のパフォーマンスを示すものだと考えます。どんな些細な業務でも、です。では、具体的にサービスにする、とはどういうことなのでしょうか。ひとつには、あなたの業務への入り口をウェブアプリケーションで用意する、という方法があります。つまりあなたの業務をウェブサービスのように扱う、ということです。ウェブアプリケーションには大きく3つの利点があります。1つめは、分かりやすさです。ウェブアプリケーションというパソコンのブラウザ上で誰にでも目に見える形で提供されるので、顧客にとっても分かりやすく、またチームメンバーやステークホルダーにとっても、自分たちの業務は一体何なのか、ということが非常に伝わりやすく、チームの方向性が統一されます。また、入り口を集約し、入力データの制限を正しく設定すれば、不適切な情報を除外でき、取り違いや解釈の相違を防ぐことも可能です。ウェブアプリケーションを用意しただけで瞬時に分かりやすくなるとは限りませんが、分かりやすくしたい、良くしたいという感情が生まれ、業務をサービスとして捉えるひとつのきっかけになるでしょう。2つめは、顧客行動を計測する仕組みが豊富に取り揃えられている点です。たとえば、Googleアナリティクスのような汎用的な分析ツールを導入するだけでも、どれだけの顧客がいて、あなたの業務へのアクセスの頻度や回数、時間帯といった基本的な情報を瞬時に回収することが可能です。またウェブアプリケーションに改良を加えれば、A/Bテスト的に、例えば50%にはAという説明ページを用意し、もう50%にはBという説明ページを用意したとき、それぞれがどれくらいの割合で目的に達成するかを比較すれば、顧客のニーズや考えをかなり定量的に汲み取れることができます。あなたの仕事のパフォーマンスを示し、あなたのモチベーションの原動力になる顧客行動を簡単に収集可能でしょう。3つめは、とにかく楽しい、ということです。この楽しさは上記2つのウェブアプリケーションという実体である点と顧客のフィードバックを得やすい点がモチベーションの向上に寄与し、圧倒的なやりがいとなって、自分やチームメンバーを後押ししてくれるでしょう。

働くのより良い未来

自分の業務はITとはまったく関係がない、もしくは何もそこまでコストをかける必要がない、と思うかもしれませんが、僕の個人的な感覚では結果的にこのコストはペイできると思っています。使いにくく、提供しにくい業務をひたすら我慢して続けるのか、業務改善の基盤を作り未来永劫的に改善を続けられる状態にするのか、その業務の未来を決める極めて重要な分岐点のように思います。まずは、情報システム部や開発部門のエンジニアにコンタクトして、こういうことをしてみたい、と是非相談してみて下さい。最近は技術の進歩で簡単にウェブアプリケーション開発が可能になってきています。興味がある方は自分で開発してみるのも可能でしょう。エンジニアの方は自分で頑張ってください!そして、周りに広めてください。自分の業務をウェブ化して、よりよい未来をつかみましょう。

あなたの業務に口出しする人を、あえて顧客と捉えることで仕事が少し前向きになる、かもしれない話

どこにでも口出しする人というのは居るもので、それは所属する部署のメンバーだったり、管理職などのステークホルダーだったり、はたまた全く関係のない部署の人かもしれません。

「それは◯◯でも実現できるのでは?」

「それをすることで発生するコストはどうする?」

「誰がそれを使うの?」

そういう口出しをする人に限って、全く手を動かさなかったり、もしくはそもそもその業務の担当ではなかったりするものです。そうしてあなたの仕事は止まり、評価面談での報告に窮する羽目になるでしょう。

顧客と捉える

あなたの業務はあなたの提供するサービスです。それを受け取る人はあなたの顧客であり、顧客に関する指標だけがあなたの仕事のパフォーマンスを示し、支えるものです。そこで、口出しをする彼らを、あえてあなたの顧客と捉えてみてはいかがでしょうか。そして、彼らを初期のユーザー、アーリーアダプターとして、あなたのサービスのファンにするのです。アーリーアダプターですから、あなたのサービスに強い思い入れがあるはずで、そこからあなたの業務が組織全体へと広く展開する可能性だってあるでしょう。

あなたを導く名脇役

彼らの瑣末にも見える意見を、外野の小言と扱うのは早計です。裏を返せば、あなたのサービス(業務)の不明瞭さをありありと物語っているものです。それは、他のソリューションとの差別化であったり、コスト情報の欠如であったり、顧客像の定義不足であったりするでしょう。ひとつずつそれらを修正しながら、徐々にでも口出しをする彼らを納得させ、味方にするのです。そうすれば、あなたの業務はより円滑に、かつ高い評価を受ける基礎が出来上がっていくことでしょう。それってなんだか、とっても愉快なことなんじゃないかと思うんですよね。

 

全ての仕事には顧客がいる

企業や団体といった組織の中には、たくさんの業務、仕事があると思います。それこそチームの数だけあって、それらが複雑に重なり合い、あるワークフローに従って、日々執り行われています。この20世紀から続くシステム化された働き方によって、より多くの複雑な課題解決と効率性を手に入れてきた訳ですが、一方で「誰のためなのか?どれだけの価値があるのか?」といった、働くやりがいや喜びと直結する問いとその答えが、希薄になったようにも思います。巨大で凝り固まったワークフローや、反対に組織間の曖昧さなどによって、一体誰が顧客なのか分からなかったり、どれだけ存在するのか知らなかったり、そもそもそんな意識の必要性がなかったりはしないでしょうか。特に事業の実際の顧客と接点のないような、例えばIT部門やバックオフィス部門等では、自分の仕事の顧客をイメージする、意識するという考えは稀かと思います。その結果、どうしても仕事がタスクに見えてきます。でも"仕事"って"タスク"ではないですよね。

仕事の顧客

リーンスタートアップが顧客行動のフィードバックを重視するように、あなたの仕事にもそれを待っている顧客がいると捉えてみるのです。それはどんな些細な仕事でも、です。顧客は隣の席の人かもしれませんし、別のチームやグループかもしれません。または、組織全域かもしれません。そのように顧客像とその課題を仮定し、定量的なフィードバックで検証しながら、仕事をより良く変えていくのです。目の前のタスクをこなすと捉えるか、顧客に価値を提供すると捉えるかは、その仕事の質やモチベーションに驚くほど強く影響します。

顧客とわたし

例えばあなたのお店で、あなたの作ったものを、あなたのお客が買っていく、簡単なことではないと思いますが、それでもやっぱり、やりがいと大きな喜びのあることだと思います。それは自身で事業を営む人だけに許された特別なものなのでしょうか?もちろんそういう向きもあるとは思いますが、私は全ての"仕事"、全ての"働く"がそうであっても良いと思うんですね。業務改善としてのリーンスタートアップという枠組みが、組織内の全ての人々をそう変えていけたらいいなと思っています。