IT部門が不要論を乗り越える上でプライベートクラウドサービスという考え方はオススメできる、と思う

IT部門や開発部門の不要論、無能論とも言える論調が登場して久しくなりました。
itpro.nikkeibp.co.jp
木村岳史氏の人気連載「木村岳史の極言暴論！」でも幾度となく取り上げられています。原因はいろいろあり、それらが複雑に絡み合っての今だとは思いますが、当初意義や思想といった面で納得感があった部門の役割分担だったものが、納期や成果物の質、実現可否といったリスクを受け取るだけの、十分なリターンがないことに尽きるかと思います。実際の給与に反映される評価もそうなのですが、やはりやりがいがないことが一番の問題ではないでしょうか。まさにやりがいが赤字です。別の言い方をするならば、やりがいという名の売り上げを生むビジネス（業務）モデルがない、もしくはビジネス（業務）モデルが現状にそぐわないといったところでしょう。ソニックガーデンの倉貫義人氏がSIer業界に感じた一括受託モデルの問題点と似ています。
www.sonicgarden.jp
ソニックガーデンさんがオーダーメイド＋サービス提供型の「納品のない受託開発」を推し進めるように、IT部門もまた、やりがいを得られる業務モデルを考え、構築する必要があるように思います。

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

その際、
kazukiyunoue-work.hatenablog.com
「業務を（プライベート）クラウドサービス化する」でも述べたプライベートクラウドサービスという考え方が役に立ちます。これはすべての業務をあたかも世にあるクラウドサービスかのように提供することです。IT部門ならば多くがインフラやプラットフォームといった基盤提供のIaaSやPaaS、さらにそれらの関連ソフトウェアや、経営、業務支援系のソフトウェアのSaaSに該当するでしょう。前述の倉貫氏の記事で言うプロデュース＋サービス型であるクラウドベンダーになるのです。ネットワーク経由でアクセスするクラウドサービスですので、目に見えるウェブアプリケーションが窓口になり、誰にとってもわかりやすいものになります。さらに、ウェブアプリケーションはリクエスト数やユーザ数といった顧客行動の指標が非常に計測しやすいため、業務の価値を説明する上で大いに助けてくれるでしょう。普段は見向きもされず、問題があると怒られるというような減点方式ではなく、顧客行動の指標を積み上げる加点方式が業務の前提になり、楽しくそしてやりがいを得やすくなります。クラウドサービスは規模の経済が重要なので、サービスそれぞれはより汎用的に、そしてより多くの利用顧客を得ようと作用するでしょう。結果、ITインフラの選択と集中が行われ、全体最適が促進される可能性もあると思います。当然、各事業部の細やかな要望は結果として「断る」ことになりますが、それはそれこそ外部のSIerやクラウドベンダーに任せてしまいましょう。自分たちは自分たちが考える自分たちにしかできない最高のモノ（プロダクトやサービスなど）を作るということが何よりもやりがいにつながるのではないでしょうか。基盤に有用なカードが揃えば、改めて事業部門に対してソリューション提供の業務ができるようにもなります。

外界へ

その行き着く先は分社化や組織を独立させ、外部に対してもサービスを提供する状態です。晴れてパブリックなクラウドサービスと競合になります。驚くことではありません。なぜなら、すでに多くの業務がパブリックなクラウドサービスと競合関係にあるわけですから。不要論、無能論を乗り越えて、強烈なやりがいと喜びを持って次のステージへ向かうIT部門の皆さんに、プライベートクラウドサービスという考えが何かの参考になれば幸いです。

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

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

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

業務を提供する側（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!システムそのものの存在理由に疑念を抱く危険性すらあります。こうしてモジュール間で無用な押し問答とその連鎖を重ね、全体として低価値なものを長時間かけて作り上げる悲喜劇の幕開けとなるでしょう。もちろんこれは極端な例ですが、こういううまくいかないエピソードは現場に溢れていますし、事象が見えにくいためビジネスサイド側からは理解されません。どんな最先端の開発手法や開発フローを選択していても起きている印象があり、これらはプログラミング言語の選択や開発手法の問題ではないのです。

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

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