ソフトウェア開発チームの考え方やプラクティスをもっとBiz組織に取り入れたい
こんにちは、BetaMindの吉田です。
今日はタイトルのような内容について、最近考えていたことを書いてみます。
簡単に自己紹介
改めまして、BetaMind代表の吉田と申します。
これまでの経歴は、UZABASE（ISインターン1年） → リクルート情シス（1.5年） → xenodata lab. 事業責任者・PM（3.5年） → 起業という感じです。
リクルート在籍時はタウンワーク事業部の情シスに所属し、5,000名規模の営業組織の顧客管理システムのリプレイスプロジェクト（オンプレからSalesforceへ）の企画・PMを担当。
転職し、シードスタートアップに1人目の社員として参画した時は、フェーズによって役割を変えてあらゆることをやっていたんですが、最初の1-2年は、エンジニアチームと一緒にプロダクトを開発・デリバリーすることに半分以上の時間を注いでいました。
そして、現在はBetaMindの代表としてウェビナー・動画マーケティングSaaS「Vidbase」事業と受託開発事業を展開しています。
私自身、キャリアの早い段階でシード期のスタートアップに移ったこともあり、特定領域での高い専門性はあまりありません。「自分は何の人？」と聞かれると、「営業の人」でも「マーケの人」でも「エンジニア」でもない。
何だろうと考えた時、どの会社でも「プロダクト開発」には常に携わり続けていて、自分も強い情熱を持っているなと気づき、最近は自分としては「プロダクト開発の人」と捉えることにしています。
この記事を書こうと思ったきっかけ
この記事を書こうと思ったきっかけは、先週とあるスタートアップの代表の方とお話していた時です。
「自社のビジネスチームの運営・生産性」といった話題になりました。
タスク管理や優先順位判断、朝会/夕会のやり方、アウトプットを最大化するために取り組んでいること、組織の考え方等について話していた際に、私たちの普段のチームの取り組み方をとても面白がってもらいました。
私としてはいつも取り組んでいることが面白がられたのが意外だったのですが、後でよく考えてみると、面白がられた考え方や取り組みの多くがソフトウェア開発組織の考え方やプラクティスから応用したものだったと気づいたのです。
そこから少し思考が進み、このnoteのタイトルにあるような「ソフトウェア開発の考え方やプラクティスをもっとBiz組織に取り入れると良くなることあるのでは？」といった考えに至り、頑張って書き進めています。
想定読者
そんな背景もあり、この記事の読者としては以下のような方を想定しています。
- ビジネス組織のマネージャやメンバーで、より良いチームづくりやチームの生産性に関心ある方
- PdMやPMMのようにBizとProductの両面を持つ職種の方
- このnoteのタイトルで「確かにそうかも」と思った方
私の原体験
これに関する私の原体験は、2社目のxenodata lab.に転職した頃に遡ります。
新卒で入社したリクルートでは情シス部門に所属し、顧客管理システムを担当していましたが、企画寄りの業務が多く、「システム開発」からは少し距離がありました。
それが転職後、シードスタートアップのプロダクト開発チームで、経験豊富な先輩エンジニアと一緒にプロダクト開発をすることになりました。これが、私が本格的な「ソフトウェア開発チーム」に所属した最初の経験です。ビジネス組織でずっと仕事をしていた私にとって、その考え方やチーム運営の一つ一つがとても新鮮でした。
例えば…
2週間のスプリントを定め、スプリントの最初にタスクの見積もりとプランニングをする。タスクはストーリポイントで見積もる。
チームのパフォーマンスはヴェロシティで測る。
スプリントが終わったら振り返り（レトロスペクティブ）をする。良かったことと改善点を議論し、改善アクションを決める。
といった、一般的にはスクラム開発とか呼ばれるようなやり方を、自社に最適化して運営されていたたプラクティスから、
問題は”個人”ではなく”仕組み”にあると考える。
同じことはなるべく2度やらないようにする。
チームメンバーにきちんと感謝を伝える。
非同期コミュニケーションの質を高めるための努力をする。
といった考え方まで、当時の先輩方に多くのことを教えてもらいました。
こうした考え方やプラクティスは私にとってはとても新鮮で、またキャッチアップにとても苦労したこともあり、原体験として強く残っています。
※ 今思えば完全に自分の実力・経験不足で沢山ご迷惑をかけたなと改めて思い、当時温かく受け入れてくださって、成長を促してくださった先輩方には今更めちゃくちゃ感謝しています、当時のチームの皆さん、ありがとうございました。
ベースとなるソフトウェア開発の考え方・プラクティス
ソフトウェア開発チームの運営方法や考え方については素晴らしい書籍や記事、noteが沢山あるので、ここでは詳述はしません。
興味を持たれた方は、「アジャイル」や「スクラム」といったワードでググっていただくと、良いものが沢山出てくると思います。参考に、シンプルなものを貼っておきます。
Bizチームで取り入れてよかったもの
現在、私たちのビジネスチームはまだ数名のチームですが、私がチーム運営する中で、そういえば開発チームのやり方から取り入れているかもな、と思うものを考え方とプラクティスに分けていくつか書いてみます。
考え方1. 同じ作業はなるべくしないようにする
「サボるための努力を全力でする」という言葉を当時の上司が使っていたのをよく覚えています。同じ作業はなるべく2回やらない。自動化やテンプレート化といったアプローチでなるべく同じ作業をしないようにする。
Bizチームでも同じ考え方を取り入れ、外部向け資料や議事録のテンプレート化、タスクの自動化に可能な限り取り組むようにしています。
考え方2.非同期コミュニケーションを最大限活用する
この考え方をベースにBiz組織で特に意識していることは、「ドキュメンテーション」です。とにかく記録を残す。
ドキュメントと言っても、キレイなパワポの資料を作ることではありません。Notionに箇条書きでいいので意思決定の背景だったりTipsや簡単な議事録を残しておく。
これによって、副業やパートタイムの方でも事業の状況へのキャッチアップもコストが下がり、以前の意思決定背景を振り返ることができるようになるメリットもあります。
「明日の自分は今日の自分とは別人」とよく当時の上司が言ってましたが、本当にその通りで、ドキュメントを残すことはチームのためだけじゃなく自分のためでもあるなと感じています。
考え方3. 問題は個人ではなく仕組みで解決する
これは、私が開発チームにいる中で一番影響を受けた考え方かもしれません。
事業をやっていると必ずトラブルや問題がおきます。その時に、それを個人の問題として捉えるのではなく、チームや構造の問題として捉え、仕組みでの解決を目指すというものです。
こういった考え方をベースにしつつ、以下のような開発チームのプラクティスを実際にビジネスチームでも取り入れています。
プラクティス1. デイリースタンドアップ
いわゆる、「朝会」です。
毎日決まった時間に集まって、実際に立って（大事！）、前日からの共有と今日やることを確認します。
朝会自体は多くのチームで実施されているかもしれませんが、この時意識していることは「スタンドアップの場では共有だけにとどめて議論が必要なら別の場でする」です。
プラクティス2. タスク管理とプランニング
私たちはまだ少数チームなこともあり、全てのBizタスクをチームで1つのKanbanで管理しています。
KanbanはIcebox、Today、Wip、Waiting/Review、Doneのステータスがあり、各タスクにはざっくりの時間見積もりを入れています。
その日のスケジュールと各自がタスクに使える時間を考慮し、スタンドアップの中でその日のタスクを決定します。
Bizタスクは差し込みや優先度変更が頻繁に起きるため、1週間単位のプランニングはできませんが、このボードを見ればチームとしてのタスク進捗がわかり、優先順位の目線が常に合うように取り組んでいます。
プラクティス3. 振り返り
週に1回、1時間ほど、振り返りの時間を確保しています。
日々膨大なタスクがあるとどうしても振り返りの時間がおざなりになってしまう経験は皆さんあると思います。私たちのチームでは週に1回の振り返りをして、しっかり改善アクションを決め、サイクルを回しています。
「KPT」と呼ばれる手法を使うことが多いですが、最近は「リーンコーヒー」と呼ばれる、雑談に近い形式を取ることもあります。
※ この辺は一長一短あったので、別でnoteを書きたい。
プラクティス4. Win Session
これも、開発チームのプラクティスというよりはOKRのプラクティスかもしれません。金曜日の夜に、「Win Session」としてその週の進捗をみんなで祝い、お互いに感謝を伝え合う場を設けています。
「振り返り」とは別で設けている理由としては、振り返りはどうしても問題や改善点の議論が中心になってしまうため、「とにかく良かったことにフォーカスし、進捗を祝う場を用意したい」という背景があります。
また、人数が増えすぎると難しいですが、「それぞれのメンバーからそれぞれのメンバーへ感謝を口に出して伝える」こともアジェンダに入れていて、これも好評だったりします。
以上が、私たちのBizチームで取り入れている、開発の考え方やプラクティスです。きっと、他にも沢山あるのかもしれませんがざっと思いつく限り書いてみました。
最後に
思ったより長くなってしまいました。書いてみると、そんなに特殊なことやってなくて、内容価値あるのか…？と思いましたが、出してみます。
こうした考え方やプラクティスは、「知識として知っていること」と「チームに合わせて運用できること」の間に壁があるようにも思います。実際に、自分の経験値が一番伸びたのは「プロダクト開発チームの中で実際にもがいている時」でした。沢山失敗して、今も常に試行錯誤しています。
自分自身が、コードも書けない、デザインもできないけどプロダクト開発にずっと携わってきたこと。そして、いろんなBizチームに所属する中で今回のような着想を得ました。これからも自分の経験と考えに根付いた、最適なチームづくりを模索していきたいです。
最近はPdMやPMM等、エンジニアやデザイナー以外でプロダクト開発に携わる職種も少しずつ増えてきていますし、こうしたプラクティスの融合もどんどん進んでいくのではと思っています。他社からも学びたいです。
読んだ感想や自社での取り組みなど、ご感想いただけるととても嬉しいです。
おしまい。