SaaSは仕事を「価値」にフォーカスさせる

どうも、エンジニアのgamiです。

先日7/30に、Developers Summit 2021 Summer（デブサミ）というイベントの40分セッションで登壇してきました。

Developers Summit 2021 Summer（2021.07.30）

セッションのタイトルは "DXの本質と、「開発しないエンジニア」のキャリアパス" 。開発者（Developers）向けのイベントなのに「開発しないエンジニア」の話をするという矛盾を孕んだ内容でしたが、Twitterではそれなりに反響をいただき、公開したスライド資料も5,000pv以上見られたようです。

40分のセッションを真面目に作るのは割と大変で、ここ2ヶ月くらいはずっと頭の片隅でDXやSaaSやxOpsについて考え続けていました。最近のnoteでも関連する内容の記事をいくつか書きました。今回はこの一連の思考に区切りを付ける意味で、登壇資料やこれまでのnoteでは書ききれなかった具体に踏み込んで、「SaaSはみんなの仕事をどう変えるか？」について考えます。

楽しく働く人を増やす

資料にもあるように、僕は「楽しく働く人を増やす」というのを当面の個人ミッションとして仕事や個人活動をしています。日本では「仕事はつまらないもの」と思いながら働く人がとても多い印象です。一方で、楽しくてお金も十分にもらえる仕事というのは世の中にあり、なるべくそんな仕事をする人の割合を増やしたいと思っています。

今回の資料では、DXが求める仕事上の変化として「アジリティの獲得」を挙げました。さらに「仕事の楽しさ」に寄せていえば、それは「価値にフォーカスして仕事ができる状態」を目指すということでもあります。

ここで言う「価値」の基準は人や会社によって様々です。僕は「顧客の仕事を楽しくする」とか「環境負荷が下がる」などといった価値を重視しますが、別に利益や人気の獲得に価値をおく人もいるでしょう。

一方で、自分が目指す価値にフォーカスできない状況が続くと、人は自分の仕事を楽しくないと感じます。顧客の笑顔を増やしたいのに社内調整の仕事ばかりでその価値を実感できない、など。これはどんな価値を目指していても共通の「つまらなさ」です。

アジリティとは、不確実な状況でも価値にフォーカスし続けるために必要な能力であるといえます。組織のアジリティが低いと、「目の前の状況は変わっているのにプランを変えられない」という状態に陥ります。状況の変化に応じて価値を得るための最短経路も変わるので、こうしたアジリティの低さは価値へのフォーカスを阻害します。価値につながらないとわかっているものをずっと作らされるような仕事は、多くの人がつまらないと感じるのではないでしょうか。

こうした「価値へのフォーカス」に、SaaSがそれなりに寄与するんじゃないか。それが今回考えたい仮説です。

アジャイル開発と価値へのフォーカス

資料では、「開発業務」と「それ以外の業務」の対比を多用しています。そこには、「ITを前提とした業務プロセスの改善」というDXの要請に応えるためにはソフトウェア産業がこれまで積み上げてきた学びを参考にするべきだろう、という前提があります。

前述のように、アジリティは不確実な状況でも価値にフォーカスし続けるために必要でした。開発者が向き合うプロダクト開発というプロジェクトは、まさに数多くの不確実性と向き合いそれを削減していくプロセスの連続です。

エンジニアリングという行為は、何かを「実現」することです。実現のために、不確実性の高い状態から、不確実性の低い状態に効率よく移していく過程で行うすべてのことです。
（中略）
ソフトウェアを開発していくときには、市場に溢れた不確実性に向き合う必要があります。その不確実性は、要求仕様の不確実性に変わり、次に実現手段の不確実性に変わっていきます。

（『エンジニアリング組織論への招待』 1-3. 情報を生み出す考え方）

さて、現代のソフトウェア開発におけるベストプラクティスの多くが、「アジャイルソフトウェア開発」という考え方をベースにしています。改めてアジャイルソフトウェア開発宣言を読み返してみましょう。

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

ここで挙げられている4つは、まさに「仕事によって生み出される価値」にフォーカスするのに必要なものと考えることもできます。価値あるソフトウェアとは何かについて対話し、実際に作りながら価値の検証をし、価値を受け取る顧客と目線を合わせて、価値を生む手段の変化にも柔軟に対応していく。

こうしたアジャイル開発のムーブメントの中で、ソフトウェア開発業務は、その業務プロセス自体をエンジニアリングの対象として改善し続けてきました。そこでは、テクノロジーの利用を前提により良いアジリティの獲得が志向されています。様々な業務がより大きな不確実性に曝されているいま、ソフトウェア開発チームが経験したのと同様の変革があらゆる業務部門で必要とされているように思います。実際、DXの実践に関する言説の中でもアジャイル開発の用語がたくさん登場します。

タイムボックスで区切り、意思決定を繰り返す。ふりかえり、むきなおる。つまり、分断を乗り越えDXを前に進めるためには、アジャイルに運営することが一択だと市谷さんは断言します。CoE（引用注: Center of Excellence. 組織やチーム横断のメタ的なチーム）こそ、やることが適宜変わっていくので、線表を引いて……というわけにはいきません。
　両利きチームと各現場・プロジェクトのバックログを分ける。両利きチーム自体をスプリントで運営する。
　そして、DXを推進する組織でアジャイルに運営していくための、二項対立から二項動態へと促す組織の遊撃手が「アジャイル・ブリゲード」になります。全体と詳細を段階と断面で同期。経営と現場をメタスクラムで接続。既存事業と新規事業を越境で橋渡し。
　そしてこのアジャイル・ブリゲードは、事務局ではなく第二の当事者として関わることが求められます。忙しい中で、「当事者」ではない人間の意見は聞いてもらえない。「ともに越える」姿勢が求められます。もっとも不確実性の高い場所に存在することになるため、あいまいさ耐性が求められます。

（組織の二項対立から脱却しDXを推進する「アジャイル・ブリゲード」とは――レッドジャーニー市谷氏が解説）

地に足ついたDXを知れる素晴らしい記事。DXのhowとは、全社でスクラムしたりアジャイルになったりすることなのかも？
"二項対立から二項動態へと促す組織の遊撃手が「アジャイル・ブリゲード」になります。全体と詳細を段階と断面で同期。経営と現場をメタスクラムで接続。"
https://t.co/VQQQr2P7Pb

— gami@デジタル教育系YouTuber兼エンジニア (@jumpei_ikegami) July 30, 2021

SaaSは文化や組織を変える指針を与えてくれる

他方、僕が今回の資料で提示した問題は、「エンジニアリングスキルの不足した業務部門がテクノロジーの利用を前提により良いアジリティの獲得を目指すにはまずどうすべきか？」という点でした。理想的には、エンジニアリングやアジャイルのプロであるエンジニアがあらゆる業務部門に遍在して様々な業務プロセスをアジャイルに変えていくべきです。しかし現実は厳しく、そのようなエンジニアを確保することはかなり難しい。それに対して、「SaaSが当面の特効薬として使えないか？」というのが僕の今の答えです。

あらゆる業務部門が開発部門と同様の変革を目指す上で、主に2つの困難があります。

1つはエンジニアリングスキルの欠如。アジャイル開発の流れの中で語られる変革は、ときにエンジニアの存在を前提とします。たとえばDevOpsでは当然のようにプログラムによる作業の自動化が推奨されます。

これについては、資料で指摘した通り、SaaSの発展や利用者の成長によって徐々に克服されるはずです。SaaSとは非エンジニアがシステム構築を主導できるようにしました。また、「NoCode」という甘言に唆された非エンジニアがSaaSを使う中で自然とエンジニアリングスキルを身に付けるケースも増えるでしょう。

2つ目の困難は、ナレッジの欠如です。開発業務を前提とするアジャイル開発のプラクティスを、そのまま全てそれ以外の業務に当てはめるというわけにはいきません。業務変革のプロセスや必要なシステムは、営業、マーケティング、採用、労務、などそれぞれの業務で違うものになるはずです。言い換えれば、自分たちの業務を「価値にフォーカス」できるよう変革するためには何をしてどう変わればいいのかがわからない。そんな問題がここにはあります。

難しいのは、ツールやプラクティスの導入それ自体を目的にしてはいけないという点です。アジャイル開発界隈でも、 "Don't just do agile. Be agile." と言われます。ツールやプラクティスはあくまでも何らかの理想状態を実現するためのきっかけや手段でしかありません。どんな状態を目指すべきかを自分たちで明確にしつつ、実践の中で軌道修正をしていくことになります。

特に後者の「どう変わればいいのか」問題については、デブサミの資料で書けなかったところです。この点についても、僕はSaaSプロダクトが利用企業に対して変革のガイドラインを与えてくれると考えています。まだ思考は生煮えなのですが、おそらく重要なのは「アーキテクチャ」と「コミュニティ」です。

そもそもある特定の業界や職種に特化したSaaSプロダクトは、その業務の理想的な進め方について考え抜いた結果をソフトウェアとして表現したものです。営業であればSalesforceを使いこなすことを、人事労務であればSmartHRを使いこなすことを、最初にやるべきwhatに置くことでひとまず一歩進むことができます。各SaaSプロダクトには利用者がプロダクトから価値実感を得るまでのオンボーディングプログラムがあり、それに従って使い慣れていく中で、自然と自部署の理想の業務プロセスを再考させられます。

意図をもって高度にデザインされたプロダクトは、そのアーキテクチャの中に「理想的な使い方を促す仕掛け」が組み込まれています。たとえばSlackを使っていると、「オープンで雑然としたコミュニケーションが仕事の生産性を上げる」という信念を随所に感じます。実際Slackのアーキテクチャ自体が、発言やリアクションのハードルを自然と下げる作用をもっています。そのアーキテクチャに合わせて自分たちの仕事の仕方を変えていくことで、徐々に文化を変革していけるかもしれません。

また、アジャイル開発がエンジニアを中心とするコミュニティ活動によって深まり広がったように、ある業務におけるベストプラクティスの発見や浸透は会社を超えたコミュニティ活動によって加速します。たとえばあなたが労務部門の社員だとして、自社の労務についてどんなに考えても既存の枠組みを超えられないかもしれません。一方、同じSaaSプロダクトを使っている別の会社の労務の話を聞く中で、自社に取り入れられるプラクティスを学ぶことができます。実際、SmartHRなどBtoB SaaSプロダクトではしばしばユーザー会と呼ばれるコミュニティ活動が催され、会社を超えたナレッジのシェアが行われています。

普段、他の会社の労務関係の方とお話する機会が無いので、どのようなことをされているのか、どんなツールを利用されているか等大変ためになりました。

（年末調整シーズンこそ交流を。SmartHRユーザー会「PARK mini」レポート 2020年11月編 - SmartHR ガイド）

従来のカスタマイズ前提のオンプレシステムとは異なり、SaaSには「利用者全員が同じシステムをシェアして使う」という前提があります。この「同じシステムを使っている」という状況は、利用者に共通の話題や手段を提供し、コミュニティ形成をやりやすくします。またSaaSベンダー側としても、利用者により長くプロダクトを使ってもらったりプロダクト改善のヒントを得たりする上で、コミュニティから得られる価値はたくさんあります。そのため、SaaSベンダーは利用者コミュニティを積極的に支援するインセンティブがあります。

良いアーキテクチャを持つSaaSに利用者が集まり、コミュニティが形成され、業務をアジャイルに変えるためのwhatやhowに関する議論が進む。その結果生まれたナレッジは、SaaSプロダクト側の機能開発に活かされ、さらにその機能を利用する利用者に再び還元される。SaaSプロダクトを核とするコミュニティを介してこういったナレッジの循環サイクルを回すことで、様々な業務のカイゼンが前に進んでいく。そんな夢を、僕はSaaSの未来に見ています。