サービスプロダクトとしての社内IT環境を考える

仕事に関する話ですが、少し思想的・抽象的な話をしましょう。長いので、お疲れの方はこの冒頭と次の章、そして最後の章だけ読むことをお勧めします。

僕は社内IT環境はサービスプロダクトと同様の考え方で構築・運用されるべきものだと考えています。社内IT環境の目的地がプロダクト同様に表現でき、また同じような考え方で運用するのが最終的な全体最適へとつながると考えるためです。

今回は社内IT環境をプロダクトとして捉えたときに重要となる視点を定め、それを要素分解することで、理想がどう実現されるべきかを考えていきたいと思います。

ちなみに「社内IT環境」が指す範囲は、会社にあるIT資産のうち、プロダクトそのもの以外の全部です。PCからネットワーク、セキュリティ、IdPといった足回りから、各種業務システムやCRMといった社内ユーザが使うもの、およびヘルプデスクを始めとしたコーポレートIT部門が提供するサービスを含めた全部です。したがって総論であり、特定製品の運用のコツや実例には言及していません。

「サービスプロダクト」の定義

「サービスプロダクト」だけでは少し抽象的なので、ここでは以下のようなものと定義します。

・サービスプロダクトとは、作り手が想定する層に、作り手の想定するアウトカムを達成させるためのものである
・サービスプロダクトとは、作った後も継続的に改善されていくものである

どんなプロダクトも、何らかの課題を解決するために存在します。また作り手のリソースが有限である以上、ある程度ユーザ層を絞って（＝マーケティング）、その人達の課題解決を念頭に置いて開発されます。

したがってサービスプロダクトとは作り手が絞り込んだ特定のユーザ層に、作り手の想定するアウトカムを引き出させるためのものと言えるでしょう。

また「サービス」は無形で（プロダクトが存続する限り）ずっと使われ得ます。これは「永遠のベータ版」を標榜するソフトウェア・サブスクリプションが持つ重要な特徴でもあり、作ったら終わりではなく作った後もユーザの観察を重ねて継続的に改善される性質があります。

この定義を出発点として、話を進めたいと思います。

社内IT環境が引き出すべきアウトカム

社内IT環境の利用対象は当然社内にいる人達なので、最初の時点でユーザ層が絞れています。そんな「層」にいる人達から社内IT環境が引き出すべきアウトカム、成果は何でしょうか。

それはユーザが環境を利用することで組織のルールや思想に沿うようにさせる、です。

一見、社内IT環境は効率化のためにあるように思われますが、ITはあくまで道具であり効率化自体はその前段階、すなわち業務デザイン時点でなされるべきものです。業務設計には会社のルール、ルールにはMVV・理念・不文律等の思想が反映されている（はずである）ため、社内IT環境は結局の所、組織のルールや思想を実現するための道具といえます。

ベテランであろうとジュニアであろうと、提供された環境を使って仕事をしていれば自動的に組織のルールと思想に沿うようになっているのが「プロダクト」の目指すところです。

ただし、組織のルールや思想を体現するためなら効率性やユーザのUX（User Experience）を無視していいわけではありません。UXはむしろ極めて大事とするのがこの文章の趣旨です。これに関しては後述します。

（いやそうじゃない、個々人でローコードツールを使って改善していくことが求められることだってあるじゃないか！と考える方もいるかと思いますが、それは組織の思想として現場レベルでの有機的な改善が奨励されているにすぎません。改善の余地を残したITの作り方となっているでしょうし、ローコードツールだってより大きな考えのもとに配置されているはずです。）

プロダクトとしての社内IT環境の特異性

社内IT環境は「社内に展開するプロダクト」であることによる、以下4点の特異性があります。

①：マネタイズを志向しない
②：トップダウンで強権的に使わせることができる
③：ユーザの個別最適によりアウトカムを達成できなくなるリスクが有る
④：作り手とユーザの距離が至近で、コンフリクションが起きやすい

それぞれについて以下で説明します。

①：マネタイズを志向しない

大抵の場合、社内IT環境自体が直接お金を稼ぐことは期待されず、ユーザの道具として機能するために提供されます。プロダクトの性質としては官庁や自治体が市民に対して提供するサービスと似ています。ユーザから金銭的な見返りをもらわずに、上述の通りルールに沿った処理をしてもらうための「道具」です。

それ自体がお金を稼がない以上、自ずとコスト管理はシビアになります。作っても（導入しても）お金が出ていく一方なので、定性定量両面のROIを慎重に考慮しつつ、経営陣としっかり合意した上で施策や改善が走ります。他部門から見て、全社展開するような施策が走るまでのスピードが鈍いように見える理由は主にここにあります。

②：原理的にはトップダウンで強権的に使わせやすい

上述のとおり、IT施策は「経営と握った投資行為」として走ります。そこから作り手（IT部門）は経営陣の威光をかさに、ユーザに強権的にプロダクトを使わせ「やすい」性質があります。こんなことはほとんどの商用サービスではありえないものの、前項と同じく官公庁や自治体は取れるムーヴです。

多少使いにくいUIでもパワーバランスを利用して強引に使わせることができてしまうので、同時にヘイトも溜めやすい構造となります。

③：ユーザの個別最適によりアウトカムを達成できなくなるリスクに晒されやすい

社内IT環境は全体最適を企図し、それを使うことでアウトカムを引き出すことを狙ったものです。しかし、なんか使いにくいなーと感じたエンドユーザが自然と自らが使いやすいようにフローを部分的に「カイゼン」することにより、環境の全体最適を前提としたアウトカムが達成できなくなるリスクがあります。

例えば、社内Teamsの雰囲気が極めて悪く情報伝達がスムーズにできないと思った社員数人がプライベートなLINEで仕事のやり取りをするようになった場合に、会社が定めたルールが守られなくなるようなケースがここで言う「リスク」です。

④：作り手とユーザの距離が至近で、衝突が起きやすい

お互いが距離的にも心情的にも近いため、一般的なプロダクトに比べて作り手・ユーザ間の衝突が起きやすい特異性があります。

例えばUIに定評がある話題のツールを使いたいと一部の部署から申し出があるも、よく調べると監査機能がすごく弱いなどの脆弱性が判明した場合、社内IT環境の「作り手」としては身を挺して「No判定」を出さねばなりません。このとき、互いに想像もしないような衝突が生じるケースがあります。

この場合どちらが悪いというのもないのですが、互いの近さ故にこうしたコンフリクションが根深い禍根となり、結果として③に至ることが（よく）あります。

社内IT環境にとって大切なこと

「社内IT環境」は上記のような狙いや特性のあるプロダクトです。では、そんな社内IT環境にとって、最も重要なことは何でしょうか。

それは使われること、です。

社内IT環境は強権的に使わせられる特性がある一方で、上述のLINEの例のように、ユーザ側もやろうと思えばその枠から外れて自らの目的を達成を試みるのが可能です。いくらルールで縛っても人の口に戸は立てられません。

かつて「とある出版社」の社内LANがあまりにも融通が効かない運用だったため、非IT部門のPCオタク社員の独断で光回線を新規契約し、そのオタク社員の部署だけは会社のファイアウォールをバイパスして外部と通信していた事例があったそうです。確かにこれは極端な例で、しかもそんなバイタリティと権力のあるエンドユーザも稀とはいえ、原理的には可能です。

アウトカムを達成するにはユーザが「まあ使ってやってもいいかな」「むしろこれを使いたい」と思う創意工夫、使ってもらうためのデザインが必要です。

ユーザも仕事なので、本来は提供されたツールを使わなくてはなりません。しかし人間の心理として押し付けられたツールを納得せずに使い続けるのは不可能です。例えば出入りの激しいスタートアップでは、この微妙な違和感ですら退職にも繋がり得ます。ユーザの心理状態を整えていくのがこの「使ってもらうためのデザイン」です。

「使ってもらうためのデザイン」に必要なこと

デザインというとUIに終始しがちですが、「ユーザがそれを見て、使ってみてどう思うか」を考え抜いた上で環境を作る試みがここで言うデザインです。「設計」をあえて使わないのは、この行為は多分にユーザの心理や感性に訴えかけるものであるべきと考えるためです。

デザインは3つの側面から練り上げていきます。

①：プロダクトが沿うべき思想やルールは妥当か
②：UXは適切か
③：「作り手」への信用があるか

①：プロダクトが沿うべき思想やルールは妥当か

つまり、それは実現に値するアウトカムなのか。アウトカムの妥当性が説明できないプロダクトはそもそも使ってもらえないでしょう。

例えば会社の理念やMVV（ミッション・ビジョン・バリュー）。よく練られた理念やMVVはそれに沿ってさえいれば組織や個人の成果に結びつくようになっており、例えばAmazonの「リーダーシップ・プリンシプル」は、すべての従業員がこれに沿ったアクションを取ることが制度的に求められています。こうした組織の行動指針が社員個々の利益に沿っている場合、社員側にも行動指針に従うインセンティブが働きます。

それゆえにMVVがお題目に過ぎず社員に浸透していない場合、全体最適を標榜する社内IT環境を作る難易度が跳ね上がります。環境を貫く思想がないためで、この場合おそらく個別最適化した島宇宙が点在することとなります。

なお、理念の浸透が弱い組織ではITのみならずあらゆる社内施策が無効化すると思われます。施策の論拠がない中で社員に施策に乗ってもらうためには、即物的なインセンティブや罰をばら撒くほかないからです（野球の応援に来なかったら人事考課マイナスな、とか）。そんな施策に意味があるかといえば、おそらくないでしょう。

逆にMVVが十分に浸透している場合でも、成果物たる社内IT環境がMVVをこじつけていたり、全く無視しているようであれば振り向いてもらえません。ユーザが期待するアウトカムが達成できないからです。おそらくモチベーションの高いユーザがよりよい仕組みを考案して、経営の支持を得てさっさと乗り換えてしまうでしょう。

こうした理念や思想とのミスマッチには常に気を払っておく必要があり、何か施策を打つ場合には、必ず思想に強い思いを持ちかつ責任のある人の目を通して思想と乖離がないかを慎重に図りながらすすめるべきです。僕が勤めるnote株式会社では、大きめのIT施策をやる場合には必ずCEOの目を通すようにしています。（MVVに少しでも反するようなポイントは必ず突っ込まれます。）

思想のみならずセキュリティ上のルール等もまた、それが正しく設定され、かつ理解されているかに気を払わないと簡単に「ハック」されてしまいます。セキュリティというのは一般従業員からしたら（展開側もだけど）面倒極まりないものです。「なぜそれが必要で、やらないとどうなるか」をしっかり伝えてわかってもらわなくては、ユーザの行動変容は促せません。

例えば、自社でカード情報の取扱予定がないにもかかわらずPCIDSS規格に則ったルールを作って一生懸命説明したところで、ユーザからしたら「なんでそこまでやる必要があるの？」とアウトカムのインセンティブが働きません。また逆にカード情報の取扱予定ができて、PCIDSSに則る必要が出た場合にも、それを正確に理解・咀嚼してユーザに伝えない限りは重要性を理解してもらえないでしょう。

以上のように、アウトカムの妥当性を各所との細やかなコミュニケーションの中で説明・確認していくことが、このデザインにおいては重要です。

②：UXは適切か

誰もが経験のあることと思いますが、使っていて気持ちよくない道具やサービス、アプリはいつの間にかなんとなく使わなくなります。社内IT環境も同様で、待ち時間がちょいちょい発生したり複雑だったり面倒な手続きを強いられる仕組みは使われなくなるか、使われたとしても諦観を伴ったヘイトを持たれてしまいます。

作り手が界隈のデファクト・スタンダードとされるSaaSを集めて「これで効果的な統制ができるぞ！」とウキウキしたところで、ユーザにとってはそれ自体はどうでもいいことです。もしそのデファクト・スタンダードを使った仕組みがどんなにセキュリティ的な隙がなく、ユーザの行動を効率的に制御できる仕組みであったとしても、業務のリズム感を損ねたり人間の認知に逆行するようなUXを強いる仕組みであった場合、いくら経営の威光を傘に着たところで、やはりなんとなく使われなくなるでしょう。

そのためユーザの使いやすさつまりUXを追求する営みは、このデザインにおいて極めて重要と言えます。この点をnoteで実際にどう考えてきたかは別の機会に書ければと思います（長くなるので）。

しかし極限までUXに配慮した上でも、例えば使っているSaaSの都合で新しいアカウントを追加するには、注文書を印刷してサインして角印を押した上で郵送してようやく先方の事務処理が始まるので2週間は待ってなど、どうしても技術上・運用上の制約により不利益を飲んでもらわないといけないケースがあります。

こういった不利益をユーザに強制する局面では、その事情を丁寧に開示する必要がありますがそれ以前に信用を築けていなくてはなりません。

③：そもそも作り手への信用があるか

人間の自然な感情として「誰なんだよお前」という人の話を聞くのは難しいでしょう。もう少し分解するとまず「お前」が何者で、それまで「お前」と我々（ユーザ側）の間にどういう関係性を築いてきたのかが明らか、かつポジティブなものでなければ話を聞いてもらいにくい、のはある程度自明かと思います。

それを実現するためのチェックポイントとして、以下の3つが考えられます。

A）自己開示をしているか
B）こちらから事前にギブできているか
C）相手を知る努力をしているか

これらについて以下で説明します。

A）自己開示をしているか

良好なコミュニケーションの基礎に「自分が何者であるか」を明らかにするのは論を待たないと思います。それは自分を知ってもらうことであり、また、上手くやれば自分をどう見てもらうかの演出にも繋がります。

その媒体は問わず、日々の会話もそうですし、Slackなどの社内グループウェア、SNS、会話が苦手な人はnote等でまとまったアウトプットをするのもいいでしょう。自分の考えや、極端に言えば単に好きなものでも、ある程度真摯に熱量をこめて語っていけばそれは（その語り口も含めて）立派な自己開示になっていきます。

大事なのは自らが能動的に働きかけてコミュニケーションをしているかです。こういった自己開示がないまま行われるコミュニケーションは、むしろその物理的な距離が近ければ近いほど没交渉としかなり得ません。（冷え切った夫婦のコミュニケーションを想像してみてください）

B）こちらから事前にギブできているか

「いや、お前俺たちに何もしてくれないじゃん」という場合にも話は聞いてもらえません。当然ながら、これまで相手にどう働きかけてきたかも大事です。上述の通りこれまで十分なコミュニケーションをとってきた実績があり、かつ、その結果がポジティブでないと人は相手の話を聞こうとしません。

これを満たすため、我々コーポレートITの領域ではヘルプデスクがかなり重要です。というより、まずヘルプデスクがしっかりできていなければ何やってもダメとすら僕は考えています。

返報性の原理（相手に何かをやってもらったら、こちらも何かをしなきゃいけないと思う心理）に訴えろというわけではありません。しかし、困って頼ったヘルプデスクで塩対応や放置されてしまったユーザの心理的安全性の悪化は、経験的にヘルプデスクの提供側が想像するよりもずっと深刻です。

放置されている状況で、あたかもそれを忘れたが如く「作り手」として使ってねと言われたところで、「いや、お前らあの時助けてくれなかったじゃん」とあっさり無視してしまうのがオチでしょう。仕事として毛嫌いされがちなヘルプデスクですが、コミュニケーションの基礎として機能する以上、疎かにするわけにはいきません。人を入れてでもしっかり整えるべきです。

ちなみにnoteではITヘルプデスクを仕組み化し「初動のリアクション」までの時間を最重要のKPIとして実務にあたっています。合言葉は秒で反応です。

その上でこれまで社内IT環境の施策としてやったことがユーザの利益となっているかも「ギブ」の尺度となるでしょう。レスも早いし、一生懸命尽くしてくれてるんだけど、やることのピントがいつもズレてるんだよね〜という場合にもユーザは反応を示してくれません。

ただし、微妙だと思う点が印象に残るのに加えて、ベネフィットはすぐに慣れて忘れられやすい、さらにはユーザが気付かない場合すらあるので、時折「現在地」を報告する会（これもnoteでたまにやってます）等を設定して組織がいい方向に向かっているのをアピールする必要があります。経験的にIT施策の成果は本当に気付かれにくいので、積極的に打って出たいところです。

C）相手を知る努力をしているか

「自分のことばっかり話して、こっちに興味なさそうな人の話は聞きたくないな」という心理に誰もが思い当たる節があるのではないでしょうか。ユーザの状況を考えずに打ち出した企画や試作がスベった例は数しれず。

前項二つも最終的にはここに関わってきます。つまり「相手のリアクションを引き出す前提として、こちらから働きかける」ということです。これは話を聞いてもらう素地を作る上でも大事だし、ユーザのニーズを知る上でも大事です。

ユーザの全てを知ることは当然ながら不可能です。それでも可能な限り知る努力をするのは重要ですし、その姿勢を見せるだけでもだいぶ違うのではないでしょうか。

ユーザ側から「こんなこと困ってんだよね〜」と明確なパス要求がくれば楽ですが、そんなケースは稀です。しかし明確なパス要求がない中でも、例えば仕事について語ったアウトプットを見聞きすると大事にしている価値観はもちろん、抽象的なニーズが現れていたりもするので、そういったところから「こんなパスがほしいのかな」と類推するのは可能だと考えます。

noteはアウトプットする社員が多いのに加え、定期的に仕事観を問う社員インタビューが企画されたりするのでこの作業が極めてやりやすい組織です。例えば僕個人としては以下のようなアウトプットから価値観やニーズを解釈して施策に結び付けたりしてきました。（ほんの一例です）

まとめと、「デザイン」の最重要ポイントについて

このあたりで話をまとめたいと思います。本文の趣旨は以下のとおりです。

・社内IT環境はサービスプロダクトとして捉えるべき
　・ユーザの行動を組織の思想やルールに沿わせるためのプロダクトである
　・ゆえに「使ってもらうためのデザイン」を考えていくのが大事
　　・「使ってもらうデザイン」で考えるべきことは以下の3つ
　　　①：プロダクトが沿うべき思想やルールは妥当か
　　　②：UXは適切か
　　　③：「作り手」への信用があるか
　　　　この度合いを測る尺度は以下の3つ
　　　　　A）自己開示をしているか
　　　　　B）こちらから事前にギブできているか
　　　　　C）相手を知る努力をしているか

趣旨としては上記のとおりですが、やはり最後の「作り手」への信用の形成が最も重要だと思います。これがないとどうにもなりません。

社内IT環境がプロダクトである以上、状況に応じた変化を免れる術はなく、その過程でユーザに不都合や痛みが生じるケースも生じます。特にnoteのようなスタートアップであればなおさら、数年ごとのパラダイム・シフトに伴うハレーションは必至です。これなくして企業は大きくなれないからです。

大きなハレーションに面した場合でも「作り手」の信用がきちんと醸成されていれば、少なくとも話は聞いてもらえます。これだけ読んで「おやおや、話せば分かると考えちゃうクチですか？」と思われる方もいらっしゃるでしょう。しかしユーザ側の「話を聞いてもらえない」は往々にして「話しても無駄」「話をする気が起きない」だったりするので、会話のテーブルに着いてもらえる余地のあるなしは大きな違いです。

こうしたハレーションと健全なコンフリクトを経て社内IT環境はより強固で効果的なものとなり、組織文化に再帰的に埋め込まれていきます。つまり、社内IT環境はコーポレートIT部門だけで作るものではない、組織のみんなで作るものです。これまで「作り手」と表現していたコーポレートIT部門は、その実プロトタイプを作って巻き込む役と言ってもいいでしょう。まさに「永遠のベータ版」ですね。

「作り手」とユーザの「共創」が垣間見られる社内IT環境は「いい環境」と言い切っていいとすら思います。なぜなら、いいプロダクトには必ず作り手とユーザの間に健全で有機的なコミュニケーションが発生するものだからです。

現在一線で使われているサービスプロダクトの例を見ても、作り手とユーザの間に良質なコミュニティが形成されているプロダクトは、やはり単なるファンを越えた双方の「共創」的な考え方でプロダクトが成り立っています。有り体な言い方では「ワシが育てた」感の醸成と言ってもいいでしょう。

例えば少なくともある時期までのLINEはこの考え方を大事にプロダクトを育ててきたように見えますし、コーポレートITに馴染み深いところだとJamfも良質なコミュニティ形成に心血を注いでいます。もちろんメディアプラットフォームのnoteでもかなり力を入れている領域です。「なんか言えば少なくとも聞いてはもらえる」、こうした期待感や安心感は「共創」の前提となります。

ベタな終着点ですが、結局は使ってもらいたい人と良質なコミュニケーションが取れるかが勝負です。そのためにもやはり「作り手への信用」をいかに形成するかが大事だと考えます。

＊＊＊＊＊

「まとめ」だけでも長くなってしまいましたが、ここまで読んでいただきありがとうございます。社内IT環境というプロダクトを構築するコーポレートITエンジニアリングは「開発」はもちろん、社内に向けていわゆる「コミュニティ形成」「マーケティング」「セールス（社内営業）」「カスタマーサクセス」のような幅広い領域を範疇にしつつ、ニーズと正しい理想を実現するために技術と知識も追求しなくてはならないタフな仕事です。

追求しなければならない技術や知識だって幅広い。JNSAの「セキュリティ知識分野（SecBoK）人材スキルマップ2021年版」によると、「IT企画部門」および「ITシステム部門」が備えているべき技術・知識の領域は200を優に越えています。

理想に反するような状況とも正面から対峙し、必要から生じたコンフリクトには少々嫌われようと勝ち切らないといけない。タフで、ある種のヘイトを集めやすい割に「介護」的な役回りをも強いられがちなポジションゆえ、仕事に辟易している同業の同志がいることは重々理解しています。しかしここまで説明してきたようにコーポレートITの仕事はコミュニケーションを土台とし、自分自身の知識・技術力をテコにして、クリエイティビティを最大限発揮できる仕事です。しょうもないこと、やるせないことがたくさんあるのも事実。それでも僕はすごく楽しい仕事だと思ってやっています。

みなさんは、どう思いますか？