読者です 読者をやめる 読者になる 読者になる

kazukiyunoue-work

働くを考える

“働く”を変える、コマース型グループウェアの可能性について

今まで何度も当ブログ内で企業内における業務を執り行う上でのモヤモヤについて話してきました。日々細切れになったタスクに追われることで、この仕事が一体誰のどんなことにどれだけ役に立っているのかわからず、やりがいを感じられないこと。隣の部署が何をやっているのか知らないので、欲しい業務が探せなかったり、異なる部署で同じような業務をしてしまったりすること。情報をやり取りする際、メール、チケット、チャット、専用ウェブアプリケーションや口頭など様々なので、言った言わないの不毛な議論や曖昧な責任範囲に起因するトラブルが起こること。こなすだけの仕事になった質の低い業務によって、長期間の待ち状態が発生したり、実現を諦めたり妥協したりしなくてはいけないこと。などなど、挙げれば枚挙に暇がありません。これらモヤモヤはあらゆる組織に散在し、夜の酒の肴に語られるのを待つある種の「仕方のないもの」として存在を許されているかのようです。しかし、これが不条理ギャグマンガならいざ知らず、企業活動や仕事そのものの質を一層高めるためには、業務を提供する側としての大きなやりがいを感じられて、業務を享受する側としての満足度を高める仕組みが必要ではないでしょうか。

コマース型グループウェア

業務を提供する側(B)と業務を享受する側(C)、そしてそれらを取り持つ仲介役(B)で考えると、これは楽天市場などのEコマースに代表されるBtoBtoCモデルだと言えます。そこで企業内の業務をウェブ上で売買するようなコマース型グループウェアの可能性について考えました。業務を提供する側はEコマースにおける店舗、業務を享受する側はEコマースにおける一般ユーザにあたります。店舗は業務をEコマースにおける商品のように写真や名前、コスト等を登録し、店舗ページ、商品ページ、特集ページなどを作成します。購入(申請)があれば購入処理に当たる実際の業務を処理します。購入画面に窓口が統一され、どんなユーザがどれだけ利用しているかも店舗管理画面から一目瞭然ですし、レビュー等の満足度を示す指標のフィードバックの仕組みがあれば、より一層定量的に業務の価値が測定できるでしょう。何より自ら考え、店作りをし、利用者の顔がはっきり見える仕事は、やはり大きなやりがいがあります。結果、もっと良くしよう、もっと改善しようと、自然なモチベーションと業務の質の向上が促されることでしょう。

業務を享受する側にもメリットがあります。使い慣れたEコマースと同じ仕組みで迷いませんし、Eコマースのモール機能である商品(業務)をカテゴリーやキーワードで検索したり、月間の利用ランキングを見たり、レビューを見たりすることで、企業内のあらゆる業務にアクセスすることが容易になります。異なる部署で同じような業務をすることも減少することでしょう。(もっとも、戦略的に競合する業務を許可することもアリでしょう。)定期購読(サブスクリプション)の機能で様々な業務にも対応できますし、実際の業務のコスト金額で売買すれば、予算管理とも連携ができるでしょう。業務の引渡し時期やコスト等、いわゆる"特定商取引に基づく表記"に当たるような業務のSLA(サービスレベルアグリーメント)の表記を義務付けることで、責任範囲の明確化も図れます。経営者が各店舗(チーム)の実績を分析できるようにすれば、今まで以上にチームの動向が確認でき、一層正確な業務運営の邁進にもつながるでしょう。

"働く"は変えられる

冒頭で挙げた業務のモヤモヤが無くならないのは、現場の人たちそれぞれが、どこかできっと誰かがいつか霧を晴らしてくれるだろうと思っているのかもしれません。しかし、経営者やIT部門が長い時間をかけてお膳立てした仕組みで、各チームそれぞれの業務改善を実現するのは実質不可能ですし、それでは遅すぎます。重要なのは、現場の人たち自ら課題意識を持って、自らの意思で改善でき、やりがいが得られる、そんな仕組み、または場なのではないでしょうか。そんな可能性をコマース型グループウェアに感じております。

社内プロジェクトでは特に”「ご近所さん」を探せ”が重要

失敗プロジェクト

失敗するプロジェクトで良くあるのが、完成までの間、一切一般の利用者とコミュニケーションを取らず、完成した後に共有され、そこで認識の不一致や大きな不満が続出して破綻するパターン。もうひとつがプロジェクト開始直後から、利用者、関連部署等の関係が少しでもありそうな人や場合によっては全く無関係そうな人までがプロジェクトの”中の人”になり、利用者に過度な負担を強いたり、様々な立場の人の様々な企てが錯綜したりして破綻するパターン。これらはプロジェクトにおけるコミュニティの分析と明確化の不足によるものだと思います。

「ご近所さん」を探せ

ソフトウェアの開発手法であるアジャイルの中にインセプションデッキという仕組みがあります。これはいくつかの質問に答える形で資料を作成すると、プロジェクトやプロダクトの方向性を明文化できるというものです。その中に、”「ご近所さん」を探せ”という問いがあり 、これはまさにコアチーム(中の人)を中心に、プロジェクトに関わる人を図式化するものです。どうもこの問いは軽視されがちな傾向にあるようにも感じますが、「アジャイル・サムライ」での失敗プロジェクトのエピソードにもあるように、当初想定される関連部署を洗い出していなかった結果、完成間際になって物言いが付いてプロジェクトが失敗するというのも珍しくないのではないでしょうか。特に社内プロジェクトでは曖昧になりがちであるとともに、これに起因してプロジェクトが失敗しているようにも感じます。プロジェクトに関わる人物は大きく以下のよう分かれると思います。顧客、パートナー、無関係、ステークホルダー、競合の5つです。まず第一に顧客との関係性を密にする意味でも、顧客に当たる人物像は明確にすべきです。そうすることで、このプロジェクトが「誰のための何なのか?」がはっきりし、向かうべき方向や詳細が自ずと決まるはずです。パートナーやステークホルダーに当たる相手や組織も明確にし、さらに責任範囲ややり取りのフロー等も当初から明確にしておきましょう。そうすることで、「言った言わない」や「突然の方向転換」を防ぐことができるはずです。そして、無関係に当たる一群に関しては徹底して気にしない姿勢でいるべきですので、こちらも明確にしましょう。もちろん、新規顧客開拓の際は大いにアプローチが必要です。

顧客に届く

特に社内プロジェクトは意義や意図が十分に明確でなかったり、伝わらなかったりする場合があります。タスクとして始まる傾向にあるでしょう。結果的に顧客像をはじめ、登場人物が明確にないまま、進行しているように感じます。"「ご近所さん」を探せ"を意識して、しっかり顧客に届くプロジェクトにしましょう。

 

業務を(プライベート)クラウドサービス化する

企業の中には多くの人が多くの業務に携わっています。それらがある一定のフローに則って処理されていることでしょう。しかし、日々細切れになったタスクに追われていると、「結局この仕事が誰にとってどれだけの価値があるのか」ということを忘れがちです。マネージャー陣のジャストアイディア程度で始まった業務が、時間の経過とともに意義や思想が希薄化し、結果的に良く分からないがやることになっているおまじないタスクや誰が見ても価値がないことが明白なのに捨てることのできないゾンビタスクでフロアは溢れかえっています。当然、そうしてこなすだけの仕事にモチベーションはありませんし、受け取る側も満足することはできません。双方にとって良いことは何ひとつないのです。

プライベートクラウドサービス

一方で世の中には多くのクラウドサービスが存在します。クラウドサービスとは、ネットワーク経由で様々なサービスを提供するものです。利用者はパソコンやスマートデバイスなどで、どこからでもアクセスが可能です。例えば、Gmailなどの電子メールやグループウェアといったソフトウェアの提供を行うSaaS(Software as a Service)、独自のソフトウェアを動かすための環境を提供するPaaS(Platform as a Service)、また共用ディスクといったインフラ設備やハードウェアを提供するIaaS(Infrastructure as a Service)などに分類されます。企業によってはそれらを導入ならびに利用しているところも少なくないでしょう。多くのクラウドサービスは業界のスタンダードに則り、非常に巧く設計されております。つまりタイトルの通り、モチベーションが高くそして価値のある業務を提供するには、それら業務をクラウドサービスのように提供することがひとつの方法だと考えます。プライベートクラウドサービスと言っても良いかもしれません。イメージとしては、クラウド◯◯(自身の業務)サービスといったところでしょうか。そうすることで業務を届ける相手を顧客とし、価値を届けて対価を得ることが前提となり、そのためにできることを考えて、実践していくことが仕事になります。例えば、業務を受け付ける窓口になるウェブアプリケーションを作ったり、提供するサービスやプロダクトを改善したり、より多くの顧客に届けるために効率性や生産性を検討したり、また見込み顧客へのプロモーションや既存顧客へのサポートといったマーケティング活動もそのひとつです。利点は大きく3つあります。ひとつは業務が目で見ることのできるウェブアプリケーションになり、窓口がひとつに統合され、利用者やステークホルダー、また自分たち自身にとっても「わかりやすい」ということです。さらにウェブアプリケーションはリクエスト数やユーザー数といった顧客行動の指標が非常に「計測しやすい」ため、上司やステークホルダーに価値を説明することが容易になります。そしてこれら加点方式の指標は、頑張れば頑張るほど伸びるので、モチベーションが高く、なにより「楽しい」ということです。価値の提供とそのフィードバックというループが備わったクラウドサービスにすることで、改善が容易で誰かの役に立っている実感を得られる有意義な業務になることでしょう。業務に対するモチベーションも必ず変わります。

おわりに

なにもそこまでする必要があるのかと思うかもしれません。決められた業務を決められたフローで正しくこなせばそれで良いと感じることでしょう。しかし変化の早いこの時代に、仮に巨大なビジネスフローの中にひとつでも変化できず価値のない部分があるとすれば、それは企業活動そのものに大きな影響を及ぼす可能性があるとも言えるでしょう。別の言い方をするならば、そこまでやる必要がないなら、そもそもやる必要がないのかもしれません。前述の通り、外部には優れたクラウドサービスが世界中で競争し価値を高めています。おそらく自身の業務と競合するサービスは必ず存在するでしょう。ひとりひとりが、そういったクラウド(インターネット)を通して世界中のプレイヤーと競争関係にあるという認識と、ある種の危機感を持つことも重要かもしれません。

業務のサービスマップを描いたら、業務の掛け持ち具合が良くわかった、という話

兼務、組織横断的チーム、マトリックス組織、なんとなしに始まった所属不明なプロジェクト。こういった異なる業務を掛け持ちする仕組みや状況はどんな組織にもあります。これらは物事をより効率的に進められる手段として広く認識されていると言って良いでしょう。しかし、実際には業務を切り替えるコスト(スイッチングコスト)の高さなどから、巧くいかないことが様々なところで論じられています。(「マルチタスクで仕事は遅くなる」)

優先順位付けのジレンマ

現場で感じるもっとも業務の掛け持ちが良くない理由は、業務の優先順位付けが当人に委ねられている点です。主務であるA業務と組織横断的チームで実施しているB業務、またジャストアイディアで始まった組織体すら持たないCプロジェクト、これらの日々発生するタスクの優先順位を当人が日々判断しなくてはならないのです。当然、それぞれのチームや組織にとってすれば、それぞれのタスクが最優先事項であるため、相談することはできません。当人にとって、A業務の成否、B業務の成否、Cプロジェクトの成否というリスクの増加によって、必要以上のバッファが組まれ、どの仕事も大幅な時間がかかり、また十分な成果が出せない状況になる危険性があります。チームの立場からしても、兼務を持つメンバーの稼働状況が分からないため、仕事を任せにくく、リスクを感じます。さらにこのジレンマは、同一のチームや組織内でも発生する可能性があるでしょう。この場合の大きな問題は、業務1のリーダーがAさん、メンバーがBさん、業務2のリーダーがBさん、メンバーがAさん、という状況です。Aさんは当然業務1を、Bさんは当然業務2を優先して取り組むでしょう。このようなチーム内ジレンマを作ってしまっては、どの業務も迅速に高い成果を出すことは困難です。

まずは見える化から

そのチームで持つ業務をサービスとして捉え、サービスマップを作るのをオススメします。メニュー化する、と捉えても良いかもしれません。チームで提供する業務をメニューのリストとして一覧にし、それぞれの業務に責任者と必要なだけのメンバーを記載するのです。その際、上記のようなジレンマが発生しているのなら、それは業務が多すぎます。まさに「小さな(例え大きくとも)チーム、多すぎる仕事」です。見える化できたのなら、そこから少しずつでも「選択と集中」で業務の統廃合を進め、掛け持ちやジレンマのない状況を作り、より価値のある仕事に集中して取り組めるようにしていきましょう。

社内プロジェクトはなぜ大成功もしなければ(中止という意味での)失敗もしないのか

誰からも望まれて、拍手喝采のうちにその完遂を迎える社内プロジェクトをほとんど見たことがありません。どちらかといえば、そもそもその存在に気づいていないか、他人事のように感じることの方が大多数です。自分に関わりのあるプロジェクトだとしても、期待感というよりある種の諦めや不安に似た感情を抱き、完成した成果物自体もお世辞にも満足の行くものではない、というのがほとんどです。それでありながら、中止の判断が下されるプロジェクトもまた稀なのです。誰がどう見てもすでにプロジェクトは瓦解し、あるのは"例の動く城"のごとく崩壊の一途しかないのにもかかわらず、人と金が注ぎ込まれていくプロジェクトというのも良くある話かなと思います。ではなぜ、社内プロジェクトは大成功もしなければ、(中止という意味での)失敗もないのでしょうか。

顧客と課題の不在

ひとつは"顧客"とその"課題"の不在だと思います。リーンスタートアップがMVPというプロトタイプを介して、顧客とその課題へのアプローチを短いスパンで実験し学習していく方法論であるように、またリーンスタートアップの実践ツールであるリーンキャンバスが顧客と課題を1番目と2番目に記入せよと論ずるように、物事を実現する上で、両者は極めて重要なのです。しかしながら社内プロジェクトというのは、ソリューションから物事を始めてしまっているんですよね。「◯◯システムを作る」や「コストを◯◯まで減らす」、または「◯◯という技術で実現する」などでしょうか。タスクややることと言ってもいいかもしれませんが、このようなソリューションやその実現方法を起点に物事を始めようとする傾向にあると思います。仮説やきっかけとしては良いと思いますが、「誰のための何なのか」という議論がすっ飛ばされていますよね。結果、何が良いのか分からずに誰も満足させられることが出来ないだけでなく、何が悪いのかも分からないので、それらを止めることすら出来ないのです。「ティザーサイトから始める社内プロジェクト」でも述べたように、どんな業務プロジェクトであろうと顧客に該当する"実際に使う人"は居るでしょうし、彼らに何かしらの価値を提供できると考えられるからそのプロジェクトはあるのですよね。ですので実際に顧客へアプローチし、そのニーズを汲み取って、プロジェクトでやろうとしていることに反映するという行為は、プロジェクトを遂行する上で極めて重要なのです。

顧客指向な雰囲気作り

もうひとつの理由は、とはいえ仮にそうであっても、マネージャーから指示があれば、なんであれ実現せざるを得ない状況だという点でしょうか。結果、プロジェクトを顧客不在で進め、顧客の期待が下がり、ますます顧客不在という負の連鎖が生まれていると感じます。マネージャーが実際の顧客であることのほうが少ないでしょうし、マネージャーの発言もあくまで未検証の仮説であることを考えれば、プロジェクトがソリューションの議論に移るその前に、顧客と価値の検証を行うべきなのです。エリックリース氏の著書「リーン・スタートアップ」でコダックが新規事業をするときの確認すべき4つの質問が参考になります。

1. 我々が解決しようとしている問題に消費者は気づいているか? 2. 解決策があれば消費者はそれを買うか? 3. 我々から買ってくれるか? 4. その問題の解決策を我々は用意できるか?

これらを確認できる"社内版Kickstarter"のような場や仕組みがあっても良いかもしれません。新規のプロジェクトを投稿し、実際の金銭のやり取りはなくとも、Like!やいいね!のような投票で、一定数を獲得したらプロジェクトを開始する、というような雰囲気作りは可能ではないでしょうか。合わせて、コメント機能等でニーズの理解を深めることができれば一石二鳥です。

"指示"ではなく"支持"

こういった仕組みを通じて、マネージャーの指示ではなく、実際の顧客の支持が全てであり、ニーズを汲み取ってマッチしていくことが重要だという暗黙の了解や雰囲気を組織全体で醸成できたら、もっと状況は好転すると思います。提供する側はやりがいを得られ、提供される側は満足の行くものが手に入る、こういった満足の正の連鎖が、すべての組織で起こることを願ってやみません。

楽しいモノリシックアーキテクチャ開発

ソフトウェアがビジネス活動において重要なのは疑う余地がありません。同時に、複雑化しているのも誰もが認めるところでしょう。ことWeb開発においてその兆候は目覚ましく、伊藤直也氏がスライド「開発組織のマネジメント」でこう述べています。

相対的にWeb開発は昔より難しくなっていて、昔より重要性が高い

その複雑化に対応するため、ウェブアプリケーションを含むあらゆるソフトウェアがモジュール化、部品化を進め、それに合わせ組織体制も整備されているところかと思います。ですが、ビジネスやサービスの観点でみれば、どれだけ部品化したところでひとつの大きなシステム(モノリシックアーキテクチャ)でしかなく、にもかかわらず部分最適化が進んだ組織には、全体のビジネスの意義やそれに伴うやりがいといったものが極めて希薄化、見えない化している印象があります。それは特に実際の顧客から離れた基幹のAPIやインフラといった部分に関わるメンバーほど顕著なのではないでしょうか。開発の遅れや品質に問題のあるモジュールが全体の足を引っ張ったり、それを理由に周囲のモジュール群の進捗が遅れたりする状況はままあるように思いますが、効率化を意図としながら本末転倒であることは明白です。顧客像や全体的な価値がもっと正しく見える化されるべきではないでしょうか。

マイクロサービスでも不十分な理由

マイクロサービスやSingle Purpose Services、サービス指向アーキテクチャーといった考え方があります。これらはひとつひとつの部品を限りなくシンプルに、かつデプロイといった関連作業を含め分離し、HTTPといった高次で汎用的な手法で連携する設計思想です。非常に有用で、これらがベースになることは間違いありません。ですが、さきほどの課題を解決するには不十分です。なぜなら例えば、"1"が入力されると感情豊かに「Yes!Yes!」と応答し、"0"が入力されると感情豊かに「Nooo!」と応答するシステムをまかされたとしましょう。シンプルですので開発は容易ですし、運用するのも難しくありません。ですが、一体のこのシステムが誰のための何になっているのかいたって不明瞭です。「もっと感情豊かにしてくれ」と要求されても正直あまり響きませんし、そうする意義も伝わりません。結果的にもうひとつYes!を付け加えて"Yes!Yes!Yes!"に変更する程度のやっつけ仕事になる可能性があります。さらに例えるなら、このYes!No!システムで利用するミドルウェアの管理運用チームはどうでしょうか。彼らはある意味、そのミドルウェアが稼働していれば業務を完遂しています。そこに「もっと高速に"Yes!Yes!Yes!"と応答したい」とか「いつどちらを応答したか記録するので巨大なデータベースがほしい」という要求があったとしても正直あまり響きませんし、意義も伝わりません。Yes!No!システムそのものの存在理由に疑念を抱く危険性すらあります。こうしてモジュール間で無用な押し問答とその連鎖を重ね、全体として低価値なものを長時間かけて作り上げる悲喜劇の幕開けとなるでしょう。もちろんこれは極端な例ですが、こういううまくいかないエピソードは現場に溢れていますし、事象が見えにくいためビジネスサイド側からは理解されません。どんな最先端の開発手法や開発フローを選択していても起きている印象があり、これらはプログラミング言語の選択や開発手法の問題ではないのです。

見えない何かの可視化の仕組み作りを

システムを行き交う電子的な情報の流れとは別に、それを逆流するもっとメタ的で感情的な情報の流れが必要です。それは顧客の喜び、満足度、シンプルに売り上げかもしれません。良いアイディアはありませんが、どんな些細な部品を担当していてもエンドユーザーを感じることができて、全体を俯瞰すると依存度や影響度の高いモジュールを発見でき、その重要度が誰でも(ビジネスサイドの人間でも)理解できる、そんな仕組み作りが重要かもしれません。各モジュールのアクセス数、訪問者数や稼働率といった実際のシステムの指数と兼ね合いを持たせると、より具体性が増しそうです。見えない何かの流れを可視化することが、巨大ソフトウェア開発を気持ち良く円滑に進められる一助になるのではないでしょうか。

どんな些細な業務でも、マーケティングは必須である

今、あなたの業務を受け取っている人がどれくらい居て、依頼する可能性のある見込みの人数がどれくらいで、彼らは何を思い、そしてどれくらい満足しているのか、これらの問いの答えを、スラスラと自信を持って言える人は極めて少ないのではないでしょうか。すでに大きなビジネスワークフローが出来上がっていたり、単純作業としてタスク化されていたりすると、これらの問いを意識すらしないかもしれません。しかし、ただこなすだけの仕事のクォリティなんて、たかが知れてますよね。そうして誰もが満足のいかない仕事を受け取り、満足のいかない仕事を手渡す、そんな不満の連鎖は、あたかも当たり前のようにあらゆる組織に内在しているように思います。そして夜の酒の肴に語られるのを待つ、ある種の必然として、その存在を許されているかのようでもあります。でも、それを断ち切り、強烈なやりがいを得ることも可能なのではないかと思うんですよね。

顧客する

その方法のひとつは、"マーケティングする"ことだと思います。仮にあなたの仕事がどんなに些細な業務だとしても、です。マーケティングの適切な日本語はなく、販促や営業活動と思われがちですが、それだけではありません。石井研二氏の著書「ガッチリ成果を出す Web担当者の教科書」内の「ホームページとマーケティングの関係をおさえる」の章に、マーケティングについてこう説明があります。

市場を知り、市場を育て、そこに働きかける

"市場"は"顧客"と言い換えても良いかも知れません。つまり、あなたの仕事の顧客を知り、顧客を作り、顧客に働きかける活動が、どんな些細な業務にも重要なのです。具体的にはどうしたらいいでしょうか。例えば"顧客を知る"には、シンプルにインタビューも良いでしょう。どんなニーズがあるのか、不満はないか、自分たちとのギャップに気づく良い機会です。他には、人事情報等を使って大まかな顧客の全体像を把握することもできるでしょう。また「業務をウェブ化する」でも述べたように、業務の受付をウェブアプリケーションにし、利用者の人数や利用数、ニーズといったものを定量的に計測可能です。"顧客を作る"ところでは、ブログ等で最新情報や変更情報を頻繁に発信したり、マニュアルやQ&A、事例等を記載したコンテンツを用意したりして、既存顧客のサポートも重要です。また、これらコンテンツは、そこからニーズの在り処を探ることもできるでしょう。メルマガや月次等のレポートで"忘れられない努力"も怠りません。"顧客に働きかける"方法としては、組織内の情報発信の場でのプロモーションやミーティング、ちょっとしたディスカッションでの宣伝活動が挙げられるでしょうか。

自分たちで、する

自分のした仕事が、それを受け取った人を満足させる、実にシンプルなようですが、やりがいがありますし、働くことの意義そのもののようにも思えるんですよね。そしてこれらのマーケティング活動は、なにも課長や部長、経営陣のトップダウンの決定がなくとも、実施可能だということです。椅子に座り、"一定時間感情を廃し、高速に単純作業をこなせる"特殊能力を使うのはやめて、今すぐ顧客に会いに行きましょう。そして聞くのです。

「今満足していますか?不満はありませんか?」