業務版GitHubをつくる
こんにちは、BYARDの武内です。
先週はオフラインのキックオフミーティング@福岡を実施しました。
社員やフルタイムの業務委託者が四半期に1回集まるもので、BYARDのメンバーは様々なところに住んで普段はフルリモートで業務を行っているため、必ずしも東京に集めるのではなく、「旅するキックオフミーティング」と称して様々な都市で開催しています。
これまではSmartHRの支社などをお借りして実施することが多かったのですが、人数が増えてきたため、今回は福岡・天神の貸し会議室で実施しました。
オフラインとオンラインでは、会議の体験は全く違いますが、だからといって毎日・毎週対面でミーティングしないといけないとも思いません。
オンラインでの業務やコミュニケーションは、オフラインに比べると確かに「伝わらない情報」は多いのですが、そういう前提でコミュニケーションを組み立てればいいだけで、それを補って余りある「自分の時間をコントロールしやすい」というメリットがあります。
すべての人及び業務がリモートワークに向いているわけでもないと思いますが、少なくともBYARDは日常的にはオンラインで業務をする前提で組織もプロダクトも組み立てています。
ただ、やはり一度も会ったことがない相手とやり取りするのは難しいですし、双方向のディスカッションはオフラインでやった方が圧倒的に質が高くなりますので、四半期に1回は必ずオフラインで集まる場をつくるようにしています。
さて、今回のキックオフミーティングでは、BYARDのMission・Visionなどを社内に発表しましたが、今日のnoteはその中からProduct Visionである「業務用GitHubをつくる」について書いていきます。
1.開発組織におけるGitHub
GitHubは2008年にリリースされたサービスです。2005年にオープンソースとして開発された「Git」はコードをバージョン管理し、過去のバージョン履歴も保持することができましたが、そこに共同作業を行うためのレポジトリを保管するサービスを付加し、エンジニアの共同作業を行うことができるという付加価値を提供したのがGitHubです。
スタートアップ界隈にいらっしゃる方であれば、エンジニアでなくてもGitHubの名前ぐらいは聞いたことがあるでしょう。GitHubのエポックメインキング的なところは、コードの分散管理とエンジニア間のコミュニケーションを円滑化したことでした。
「その特徴はGitHubじゃなくて、Gitのことじゃないか？」というツッコミを受けそうですが、私の認識では技術基盤としては確かにGitはコードのバージョン管理をする上での画期的な仕組みだった思いますが、プラットフォームとしてのGitHubが登場する以前はその取り回しの難しさや面倒さから、開発における主要な選択肢にはなっていなかったはずです。（このnoteのほとんどの読者はエンジニアではないので、超ざっくり説明しています）
概念が素晴らしい、機能が優れている、というだけではそのプロダクトが使われる理由の10％も満たしていません。いわゆるUXと呼ばれる分野、多くのユーザーにとって使いやすい体験を提供してはじめて、使われるプロダクトになるのです。
よって、BYARDが目指すのはあくまでもGitHubだと思っています。
（1）ウォーターフォール開発の問題点
ウォーターフォール開発はシステムやソフトウェアの開発で用いられる、開発手法の一つです。ウォーターフォール（Waterfall）は英語で「滝」を意味します。その言葉通り滝のように上から下へ、つまり上流工程から下流工程へと順番に開発が進められていく開発手法です。
ウォーターフォールは、事前に要件をきちんと定義し、概要設計、詳細設計へと落とし込み、その都度レビューを行いながら設計を固めてから、ようやく開発に入ります。事前に要件が全て洗い出され、設計もきちんと行うことができれば、機能する開発管理手法です。
変化のスピードが緩やかだった時代はウォーターフォール開発でも問題ありませんでした。ただ、ある程度の規模のシステムになると、プロジェクト開始から完成まで数年かかることはザラです。
ウォーターフォールの大前提は「事前に要件が見通せていること」ですが、この変化の激しい時代、5年後どころから来年の見通しを立てることも容易ではなく、どんなに丁寧に要件定義をやろうとしても完璧な見通しを立てることは困難です。
また、要件定義段階では業務を根本から見直すようなことは難しく、現在やっている業務の延長線での要件（というか要望）が集まりがちです。基幹システムの更改プロジェクトでユーザー部門に要件を聞いても「今やっていることを、できるようにしてください」という答えしか返ってきません。
既存の業務を大幅に見直して業務効率を上げる、というのは企画者の机上の空論に過ぎず、実際に仕事を抱えている現場の方々からすると、目の前にある業務をこなすことが最優先であり、システムはそのためのツールにすぎないのです。
もし仮に現場の要望をすべて要件定義段階で盛り込めたとしても、業務は日々動いていますし、法律や顧客の要望への対応もあり、開発を進めている途中で要件が変わっていくことは十分にあり得ます。どんなに頑張って要件定義をしたとしても、その段階では見えていない要件を盛り込むことはできません。
尖ったソフトウェアエンジニアの方の「ソフトウェア開発においては、ウォーターフォールにはなんのメリットもない」という発言もあったりしますが、ウォーターフォールの最大の問題は、要件定義からローンチまでの期間が長いことによって要件そのものが変質してしまう可能性が高いこと、かつ、不確実が高い要件を無理矢理システム設計に落とし込むことによって誰も欲しくないものを作ってしまうことです。
失敗例としてはみずほ銀行のMINORI（統合システム）のケースがあまりにも有名でしょう。
大規模な基幹システムや金融系のシステムは別だと思いますが、私がいるSaaSの世界ではウォーターフォールはもはや死語になりつつあります。
（2）アジャイル開発
アジャイル（agile）とは直訳すると「素早い」という意味です。アジャイル開発は、システムやソフトウェアの開発手法の1つで、計画から設計、実装、テストまでの一連の開発工程を小さな機能単位に分割して行い、短いサイクルでそれらを素早く繰り返しながら進めていくことが最大の特徴です。
ウォーターフォール開発の問題点は「変化に弱い」「最初の段階では完璧に要件を定義するコトができない」という点でしたが、アジャイル開発では、「プロジェクトに変化はつきもの」という前提で進めることができるため、要件の不確実性が高い状態であっても一定の仮説を持っていれば開発を進めることができ、開発を進める中で要件をクリアにしていくというやり方もとることができます。
納品という概念がなく、ずっと機能をアップデートし続けるSaaSの開発は基本的にアジャイル開発で行われています。また、GitHubの分散管理とコラボレーションという強みはアジャイル開発を進めていく上では欠かすことが出来ないものです。
GitやGitHubが広がる前からアジャイル開発という概念はありましたが、バージョン管理がきちんとできる開発プラットフォームの存在なくしてそれは絵に描いた餅だったはずです。やってやれなくはないが、運用がしんどすぎてあっという間に破綻してしまうでしょう。
特にGitHubがあることによってエンジニア組織における共同作業の重要性が注目され、スクラムガイドに代表される「どのようにしてチームで成果を上げていくか」というメソッドが急速に広まりました。孤高の天才プログラマーや納品前のデスマーチというステレオタイプ的なエンジニア組織ではなく、生産性の高いエンジニア組織を作ることでいいプロダクトが作れる、という価値観に変化したことは大きいと思います。
2.間接部門におけるBYARD
（1）科学的管理法の呪い
間接部門の業務で重要とされるマニュアルや手順書、そしてチェックリスト。この源流を探っていくとフレデリック・テイラーの「科学的管理法」にたどり着きます。
過去のnoteやスライドなどで何度も触れてきたテイラーの「科学的管理法」ですが、職人芸の世界だった製造業の業務を標準化し、大量生産を可能にするという文脈でのパラダイムシフトを起こすきっかけとしての貢献度は計り知れません。（科学的管理法＝大量生産、というわけではありませんが、業務の標準化や分業という概念をもちこんだという意味で）
業務を標準化して、分業体制を確立し、大量生産を可能にしつつ、品質も維持していく。職人が師弟関係を作って、技術を継承していくのとはまったく違った世界観です。
大量生産やグローバル展開といったものが経済成長の条件となる中で、科学的管理法をベースにしたマネジメント手法はどんどん磨かれていき、世界中で管理者と労働者のヒエラルキーをはっきりと浮かび上がらせ、一部のエリート階層が大企業を率いるということが当たり前になりました。
ここ10〜20年ぐらいでこの図式が崩れる（大企業の凋落）ケースが頻繁に起こるようになったのは、ソフトウェアが主流になったことによって変化のスピードが上がってしまったからだと個人的には考えています。
科学的管理法の概念は素晴らしく、まったく間違っていないとは思いますが、それを実現するために20世紀に構築された様々な手法が、その時代のスピード感を前提にしており、ソフトウェアやインターネットがある現代の経営手法としては、全くもって有効性をなくしてしまっているのです。
マニュアルや手順書は、ないよりももちろんあった方がいいですが、それらを作ることをゴールにしてしまうと、なにかがおかしくなります。また、変化が激しく、先行きを見通すのがどんどん難しくなっていく中で、不確実性をゼロにすることなど不可能なのですが、PDCAの「P」にいつまでも時間をかけてしまうと、周回遅れになりかねません。
さらには、一度作ったマニュアルなどを見直すサイクルも、果たして数年に一度でいいのかという問題もあります。トヨタ自動車の「カイゼン」は小さな改善をずっと繰り返すことで大きく生産性を向上させる手法ですが、作ったそばからマニュアルは陳腐化するぐらいの意識でいれば、最初から完璧なものを作る必要はないことが理解出来ます。
細かな業務手順までガチッと固めるのはいいのですが、そこでパワーを使いすぎてしまうため、その後の改善がおざなりになっているケースが本当に多いのです。業務プロセスは標準化しつつ、細かな業務手順はずっと見直し続ける必要があるということを理解する必要があります。
テイラーが「科学的管理法」で言いたかったのは、「マニュアルやチェックリストを作れ」ということではなく、「業務を標準化しよう」ということだったはずです。それがいつの間にか、手段に過ぎなかったマニュアルやチェックリストを作ることがゴールになってしまったため、多くの現場で業務のやり方が硬直化し、改善することが出来なくなってしまっているのです。
（2）業務をコードのように扱えないか
私自身はエンジニアではありませんが、アジャイル開発やスクラムというもの横目に見ていて、「これってトヨタ生産方式の“カイゼン”にも通ずるところがあるよな〜」と思っていました。
「○○DX」というバズワードで盛り上がっても、結局はその「ツール導入」だけにフォーカスが当たってしまって、運用や改善のことは軽視されたまま、という状態をなんとかしたいとずっと考えていました。
間接部門でも、なんとか継続的に改善し続けられる業務の仕組みを取り入れられないか。そのために欠けているピースはなにか。
そういうことを、コロナ禍で世界中がロックダウン状態のときに、ずっと考えていました。
そこで思い至ったのが、業務を管理するためのプラットフォームです。
エンジニアにとってのGitHubのようなもの、セールスにとってのSalesforceのようなもの、それを間接部門の業務にフォーカスしてプラットフォームとして開発出来ないか、というところから始まったのがBYARDというプロダクトです。
私とCTOの辰本さん、プロダクトデザイナーの平岡さんの間では、開発に着手する前から「業務をコードのように扱えるGitHubのようなもの」というキーワードは出ていましたが、今回は改めて「業務版GitHub」という言葉をProduct Visionに盛り込むことにしました。
BYARDで最も重要な概念は「“人”と“業務”を切り離す」ことです。
ただ、切り離したままではダメなので、今度は“人”と“業務”をつなぐためのプラットフォームが必要になります。それがBYARDということなのですが、これをエンジニアに一言で分かるように説明するためのキーワードが「業務版GitHub」でした。
BYARDが「テンプレート」というものを重要視しているのも、そこに業務の型があり、それを標準として置きつつも、案件毎の例外処理や必要に応じたアップデートを取り込めるようなプラットフォームにしていきたい、という思いがあるからです。
まだ機能としてはご提供できていませんが、将来的には「テンプレート」に対してのPull-Requestも実装予定です。概念としてはPull-RequestやMergeですが、「業務」を扱う場合にどのようなインタフェースで提供するのが良いのかはまだ私たちにも完全には見えていません。
現時点では多くの企業で、Pull-Request以前に現状業務の棚卸しや可視化が出来ていませんので、まずは現在の業務をBYARD上に落とし込み、BYARD上で業務をコントロールすることができるようにするという観点で開発ロードマップは作成しています。
人間はシステムのように合理的ではないのですが、それが人間の良さでもあります。「業務をコードのように扱う」というのは、業務というものをコードのように無機質にしていくことではなく、逆に人間のもっている曖昧さやその場の判断のようなものも、うまく受け止められるようにしたいと考えています。
Aをしたら、次はBをする。
こういう機械的な指示だけで私たちの仕事は構成されているわけではありません。人間の柔軟さや調整力を受け止めることができてこそ「業務をコードのように扱う」ことができるのです。
「業務版GitHub」はあくまでも分かりやすい標語であって、GitHubそのものを再現しようとしているわけではありません。ただ、業務の標準化という観点で、自動化やマニュアルの詳細化とはまた違ったアプローチがあるはずだと考え、今回「業務版GitHub」を掲げました。
まだまだプロダクトとしては未熟な部分も多いですが、将来的にはGitHubのように「BYARDというプラットフォームが業務の中心にある」状態をイメージして、これからもプロダクトを作っていくつもりです。
BYARDのご紹介
BYARDはツールを提供するだけでなく、初期の業務設計コンサルティングをしっかり伴走させていただきますので、自社の業務プロセスが確実に可視化され、業務改善をするための土台を早期に整えることができます。
BYARDはマニュアルやフロー図を作るのではなく、「業務を可視化し、業務設計ができる状態を維持する」という価値を提供するツールです。この辺りに課題を抱える皆様、ぜひお気軽にご連絡ください。
ノートの内容が気に入った、ためになったと思ったらサポートいただけると大変嬉しいです。サポートいただいた分はインプット（主に書籍代やセミナー代）に使います。