「アジャイル」を開発だけでなくビジネスや組織運営に持ち込むと超捗るけどPMとデザイナーが足りない（推薦図書付き）
会社員時代、ひいては学生時代の頃から、多くの時間を「何かを作り変えたり、ゼロから何かを作ることで物事をより良くする」ことに費やしてきた。サークルや団体の運営を立て直してみたりとか、毎日面倒だと思っていたFXや日経225のトレーディングを（半）自動化するために生まれて初めてプログラムというものを書いてみたりとか、受託気質の強い会社や新進気鋭のスタートアップで新規事業を立ち上げたりとか。
そういった活動の中で自然と培われた「こうすると結構うまくいく」という自分なりのパターンのほとんどが「アジャイル」や「リーン」や「DevOps」という文脈の中で体系化されていることを知って以来、私はこれらの思想が好きになった。
（代表して「アジャイル」と呼ぶことにする）
「アジャイル」という思想は、不確実性が潜むあらゆる活動について、効率性と成果とリスクのバランスを上手く取りながら進んでいくためのものだと思う。
常に不確実性とどう向き合いながら進んでいくか試行錯誤してきた自分にとって、もはや当然の「空気」のような存在でもあった。
2年半前の2018年11月にリーガルテック・カンパニーMNTSQ（モンテスキュー）を立ち上げたとき、せっかくだから自分の考える最高の組織を作りたいと思った。
良い組織って何だろう？
最初から強くて、それからもずっと強い会社にとって大切なことって何だろう？
そんなことを考えながら作り上げてきた弊社のカルチャーや運営手法は、あらゆる活動においてアジャイル的であることを志向しているように思う。
いずれ弊社のカルチャーや運営手法はまとめて公開したいと考えているが、
今回は、「あらゆる活動においてアジャイル的である」ことの例として、セールス活動の運営と組織運営フレームワークの2つを紹介しようと思う。
セールス活動をアジャイル的に運営する
セールス活動をアジャイル的に運営する、というのは2つの側面がある。
1つ目の側面は、セールス活動の標準プロセスをある種のプロダクトと見なし、通常のセールス活動を遂行する傍ら標準プロセスの改善活動をアジャイルっぽく進行するということだ。
理想的なセールス活動と現行プロセスの差分としてひらめいたアイディアや、実際にセールス活動をしている中で困ったことなどをissueとしてどんどん共有し、それらにPriorityを付けながら各自が担当を持って改善していく。
これは、標準プロセス自体がドキュメントやSalesforceの設定などで可視化されていることが重要で、各issueの解決策はドキュメントの修正やSalesforceの設定更新の提案といった形でアウトプットされ、レビューや議論を経て反映されていく。
※もちろん、セールス活動は標準化できる（すべき）部分と個人の特性に合ったやり方を採用した方がいい部分があるので、標準プロセスの強制度合いは柔軟に議論されることが前提である。
弊社は非技術者用の講習を用意して全員がGitHubを使えるようにしているため、下記のような運営を行っている。
・GitHub Issuesで起票
・Projects機能でカンバン管理
・標準プロセスのドキュメントはマークダウンファイルで管理
・標準プロセスの更新提案はPull Requestで提出
もう1つの側面は、セールス活動もプロダクト開発のための活動の1つであるということだ。
上述のようにプロセスの改善に向き合う中で、「これはプロセスじゃなくてプロダクトの問題ではないか？」という問いかけも当然のように発生するし発生すべきであるが、やるべきことはそれだけに留まらない。
我々のプロダクトは常に不完全で、市場や顧客の目にさらされるたびに新たな発見が生まれるものである。セールス活動を行うメンバーの1人1人が、プロダクトの価値仮説や顧客ニーズに目を光らせ、情報を社内にフィードバックすることが求められる。
具体的には、あらゆる提案資料や議事録は社内で誰でもアクセスできて追いやすい形で共有されるようになっており、そういった投稿を起点に社内で議論が巻き起こるという流れが作られている。
このような、「標準プロセスを明確にすることで課題を可視化し、どの課題から向き合うかの選択を行い、1つずつ改善していくあり方」や「業務領域を区切らず、目指すべきことのための課題解決に向けてあらゆるメンバーがコラボレーションする様子」は、まさに創業当初に思い描いていた姿であった。まだまだ稚拙な部分も多いしスクラムらしい進め方の習熟度が高いとは言えないが、こういう方向性であらゆる業務活動を運営していきたいと思う。
組織運営をアジャイル的にやるフレームワーク
次は組織運営について。組織運営という言葉は広いのでもう少し具体化すると、大枠この2つかなと思う。
「組織開発」・・・コーポレート・ミッションの実現やあらゆる業務をアジャイル的に行うために重要な組織のあり方を定義し浸透させるための活動
「コーポレート基盤改善」・・・組織のあり方に基づいて具体的な組織運営オペレーションを詰めて整備していく活動（戦略やマイルストーン共有, 社内ツールの利用設計, オフィス運営, バックオフィス効率化, etc.）
これらをアジャイル的にやる、というのはどうやっているかを紹介したい。
ここでも、実は根底にある考え方はセールス活動のときと同じで、
すごくシンプルに言えば「現状を明確にしたうえでIssueを可視化し、1つずつ取り組んでいく」ことに尽きている。
簡単に図解するとこのような形だ。
ただし、これをまともに運用しようとするのは、それなりに骨が折れる。
アジャイルは規則だけ作ればいいのではなく浸透/運用が命と言われている。
これはビジネスのあらゆる活動や組織運営にアジャイルを援用する際にも同様のことが言えるだろう。
上記のようなフレームワークで組織運営をアジャイル的に行う場合、最低限しっかり徹底できていなければならないことのハードルはなかなかに高い。
例えば..
#1 ドキュメント・ポータルの整備
現状の合意内容が明確化されたドキュメントが集約される場。
MNTSQ社ではMembers Portalと呼ばれ、GitHubで管理されている。
また、当然ながらドキュメント・ポータルの閲覧や変更提案は、全社員ができなければならない。
#2 戦略とオペレーションの一致
せっかくドキュメント・ポータルがあっても、絵に描いた餅では意味がない。「書いてあるけど、まあ建前に過ぎないよね（笑）」みたいな状況では、本質的な問題提起も議論も生じるはずがないのである。
合意したことはしっかり徹底する（現実と一致させる）という基礎があって初めてIssueの認識が可能になる。
ソフトウェアの場合は、コード通りにプログラムが動いてくれるためあまり意識する必要がないが、ソフトウェア以外の領域ではここの重要性が大きくなる。
#3 Issue Raise
Issueを見つけたら、どんなものであっても必ず共有すること。
MNTSQ社ではGitHub Issuesにとりあえず何でも共有することが全社員の責務となっており、これを怠ることはとても問題視される。 ..etc.
他にも、Opennessを確保するための情報管理の設計やら、官僚主義/大企業病に陥らないようにするための心構えやら、「Issues」の概念を理解したり解決のためにいろんなメンバーを巻き込む仕事の進め方を体得するためのサポート体制やら、各メンバーが解決推進やコラボレーションをしやすくする仕組み作りやら、組織としてやることはたくさんある。
MNTSQ社では、組織運営をアジャイル的にやるために組織戦略を明文化し、創業当初から浸透と改善に取り組み続けている。
参考に、現在のドキュメント・ポータルの体系を載せておく。
総論、すごく捗るが 「「 惜しい 」」
アジャイルをいろんな領域に援用しているという事例を紹介する過程で大変さの強調が過ぎた気がしないでもないが、本当にすごく捗るのでオススメしたい。
全体像が見えなくなったとか、面倒な手続きが増えて部分最適が目立つようになったとか、本質的な課題に向き合った議論が起きないとか、そういったことが起きにくいように思う。
（とは言っても、弊社はまだ25名程度のスタートアップなのでそもそも運営難易度が低いのであるが）
ただし、相応に「惜しいな」と思うことが増えてきたのも事実である。
社内のあらゆるところで改善に関する議論が行われ、いろんなメンバーが改善に取り組んでいることは非常に素晴らしいのであるが、やはりissueにはPriority（重要度 / 緊急度）とは別に「難易度」という尺度があり、一定程度以上の難易度を持つissueに対応できるメンバーは限られてきてしまう。
例えば「5個くらいのissueを個別に解決するんじゃなくてフローの再設計をした方が良さそうだね」とか「これ上手くツール組み合わせれば全然効率化できそうだけどな」というものは、ある程度の技術とツールを組み合わせて業務フローを設計するスキルに長けたメンバーが適度にヘルプに入れないと、進行になかなか苦労する。
（時間をかけてコラボレーションすれば解に辿り着けるのであるが、やはり活動には一定のリズムというか速度が必要で、ずっと改善案を考えてるけど策がまとまらない状態だとトーンダウンしてきてしまうものだ）
MNTSQ社があらゆる領域に対してゼロベースで改善に取り組むからこそ、幅広い領域に対して物事を深く洞察し技術とツールを駆使して解決に導くことに長けた職種として、PjMやエンジニアやデザイナーに対する需要がとても高い。そして、弊社では既に組織として持っているそういったケイパビリティは既に枯渇に近い状態にあり、今のタイミングで解決しておきたい数々のissueに対して手を出せないでいる。
弊社のソフトウェア・エンジニアはまだ2名だし、PjMとデザイナーに関しては私1人しかいない（PdMとフロントエンドエンジニアと組織/コーポレートの管掌を兼務しているのでそもそも捻出できる時間がそこまで多くない）。
この非常に「惜しい」状態を打開するため、弊社はPjMとデザイナーを特に募集している。（もちろんソフトウェア・エンジニアも）
とりあえず転職意欲がなくてもいいので、少しでも気になったら是非話を聞きに来てみてほしい。
「こんなことやってる会社があるんだなぁ〜」程度で全然大丈夫です（敬語）
最後に推薦図書
僕がこういった組織づくりを志向するようになったきっかけにあるような書籍を簡単な一言紹介文と一緒に置いておこうと思う。
「1. イシューからはじめよ」
実は大学生の時、コンサルタントという職業に憧れていた時期が僕にもあり、そのときにオススメされて読んだ本。すべての始まりだったかもしれない。
「2. リーン・スタートアップ」
新規事業を初めてやるときに読んだ本。何からやればいいかが見えた気がする。
「3. ザ・ファシリテーター」と「4. クリティカルチェーン」
どうやったらもっとうまく進行を回せるかな？という漠然とした課題感を持っているときに出会った、ストーリー調の良書2つ。
「5. 組織パターン」と「6. LeanとDevOpsｎ科学」
アジャイルとかDevOpsという言葉を認識するようになって、明確に組織への活用に意識が向き始めてから読んだ本2つ。発見があるというより整理されているという印象だが、組織の形を考案するのにとても役に立った。
↓はアジャイルとは直接的には関係ないものの、これらも少なからず影響を受けているので一応置いておく。
ラストは、弊社取締役の安野が書いた、弊社の組織運営に関する紹介記事である。また違った雰囲気が見て取れるかと思う。
本当の最後にもう一度、We're Hiring !
弊社は組織規模の拡大ペースが高いわけではないが、常に一緒に働く仲間を探している。
非常に不本意ながら、社員からもカジュアル面談でお会いした方からも「創業者4名が全員東大卒でEnterprise向けのビジネスをやっている関係で、応募のハードルがとても高く感じていた」と言われてしまっているのだが、
カジュアル面談の場で「話を聞いてみたら自分にもできそうなことが多そうでワクワクした」と言っていただける事が多いので良かったらとりあえず↓のリンクから話を聞きに来てもらえると嬉しい。
We're Hiring!
最後まで読んでいただき、ありがとうございます。 またタイミング見て記事を書くので良かったら見にきてください。