開発における不確実性を下げるために、この半年の間で行ったこと
こんにちは。株式会社助太刀の開発部のエンジニアリングマネージャーをしている赤星です。
今期のテーマとして「開発組織の生産性の向上」と「不具合の削減」がありました。不具合の削減に関しては別でお伝えするとして、今回は「開発組織の生産性の向上」についてこの半年間やったことを振り返りたいと思います。
さて、最初から結論を申し上げますと、今期は開発生産性が上がるようなことはできていません。何を持って開発の生産性が高いか、という議論は昨今活発に行われていますが、こちらの記事でも発信されているように、画一的な開発生産性を図る指標はなく、このプロダクトが最大限に価値を発揮するために、どういった指標を追うべきなのかは開発者体験の文脈で語られることも多く、しっかりした設計であることと同時に、定量的で健全な議論を通して、事業部との対話が必要だと感じています。ちょうど現在進行系で進めているものであり、またその取組みは別の機会に記事にしたいと思っています。
では私はこの半年何をやっていたかと言うと、一言で言えば不確実性を取り除くことにフォーカスした半年でした。
今回は不確実性と向き合い、アジャイルの開発手法であるスクラムの導入を通して、秩序ある開発を行うためにやったことを書きたいと思います。
1. まずは自己紹介
赤星 孔太
株式会社助太刀の開発部のエンジニアリングマネージャー
事業部とのやり取りやpjm、スクラムマスター、開発効率化を担当
前職はオンライン英会話のiOS / バックエンド を担当
最近はポーカーにハマっています
2. 簡単に助太刀の説明
建設業界には330万人以上の職人がいるにも関わらず工事会社では「職人不足で大きな現場が受けられない」、「閑散期に仕事が欲しい」といった課題に悩まされています。助太刀では、工事現場の発注者と受注者を繋げるマッチングプラットホームを提供しています。
業界の課題やプロダクトのポテンシャルについてはこちらに詳しく書かれているので、よろしければ御覧ください。
3. 開発の生産性を滞らせる「不確実性」
不確実性とは一般的に、AかBはっきりつけられない、曖昧である、確率が残っている状態などを指します。エンジニアリングとはそのプロセスを通して、その不確実性を0にしていく作業だと言えます。
開発における不確実性は、プロジェクトの進捗や成果に関する未知の要素のことを指します。それらの要素には、開発チームのスキルや経験、要件の変更、技術的な制約、スケジュールや予算の制限などが含まれます。これらの不確実性は、プロジェクトのリスクを増大させ、開発チームが予期せぬ問題に直面し、スケジュールや予算を過剰に超える可能性を生じることがあります。具体的には以下のようなものです。
技術的不確実性 = 新しい技術や複雑なシステムの開発において、技術的なリスクや課題が発生する可能性がある。
例：決済システムの改修に伴う影響範囲はどれくらいだろう…？
スケジュール不確実性 = 開発スケジュールやリソースの調整において、スケジュール遅延やコストオーバーの可能性がある。
例：この機能は○月までにリリースできるのか？
人的不確実性 = 開発チームやステークホルダーの人的な要因によって、開発の遅延や品質の問題が発生する可能性がある。
例：コミュニケーションコスト / 認識のズレ
需要不確実性 = 開発する製品やサービスのニーズや市場動向が不確かな場合、需要の予測が困難になる。
例：この機能はユーザーが求めているものだろうか？成功失敗を判断する指標は何か？リリースした際のオペレーションは整っているか？
アジャイルの文脈で語られる、「不確実性コーン」と呼ばれるものがあります。これは開発の工程が進むことによってそれらの不確実性のボラリティが収束していくことを表しています。
エンジニアリングマネージャーの仕事の1つとして、こういった不確実性を敏感に察知し、収束させていくことで開発者が目の前の開発に集中し、最大限価値を発揮できるような仕組みを構築することが挙げられます。
4. スクラムの導入
アジャイル開発とは「迅速かつ適応的にソフトウェア開発を行う開発手法群の総称」であり、スクラムという開発手法はその一部です。今ではスクラムで開発を行っている会社が増えており、スタンダードな開発手法になっています。
スクラムの具体的な特徴としては
・短いイテレーション（通常2-4週間）で開発サイクルを回すこと
・チーム全体で共同作業を行うこと
・細かく進捗を見て、細かく改善していくこと
これらを通して、定期的な期間で頻繁に機能をデリバリーすることが可能になります。
少し弊社の開発手法について説明させてください。弊社は前述のとおり建設業界という比較的レガシーな業界を対象としたサービスを開発しています。そういった市場の繊細なニーズに答えつつ、柔軟な開発を行うためにはアジャイルという開発手法を選択する必要がありました。
そのような状況で開発を進めていく中で、開発に関する課題は減っていくどころかむしろ増えてしまっている状況でした。その問題に対して試行錯誤している中でその問題が「不確実性」という問題に集約されることがわかりました。ちょうど弊社がオフショアから内製化の動きが加速されていく中で、よりチームとして自己組織化され、それぞれの不確実性に対して取り組む準備が必要だと考えるようになりました。スクラムの導入を検討したのはその頃です。スクラムの導入それ自体が不確実性を解消するものではありませんが、期間を区切ることによって課題を明確に捉えることが出来るようになると考えています。
5. 分からない未来を経験で予測する
話は変わりますが、開発と工数見積りは切っても切れない関係にあります。未来は不確実性の集合です。何が起こるか分からない状況において、時間で見積もりを上げることは適切でないと考えています。
前提として、もちろんスケジュールというものはビジネスにおいて重要なものであり、どの機能がいつリリースされるのかはエンジニアリングマネージャーとビジネスサイドの間で絶えず会話されることが重要です。
ただ、何か予期せぬ出来事があった際に、もちろん開発者が寝ずに必死でやればその納期までに完成するかもしれません。ただそれは属人的なものである為コントロール出来ないという点や、時間的制約を守ることと同じくらい品質的制約を守らなければならないという点、短期的なスピードを優先した結果、更なる大きな機能を作ることに時間がかかってしまう(いわゆる技術的負債)という点が話を更にややこしくします。本質的な開発スピードを上げ、健全に改善するプロセスを構築する必要があります。
経験主義、という考え方があります。不確実性を確実なものにする唯一の方法が「行動する、実際にやってみる」ことです。情報を入手するために行動を起こし、その結果を観察し、そこから問題解決を行うという考え方を経験主義と言います。その経験主義を応用した見積もり方法が、ストーリーポイントで見積もる、という方法です。
ストーリーポイントはユーザーストーリーに基づく見積もり方法です(ユーザーストーリーの説明は割愛します)。一般的には
1. 実際に過去に行ったタスクで換算でき
2. チームとして統一基準をもった
3. タスクの大変さ
を絶対値で表すものです。弊社ではフィボナッチ数列(１、１、２、３、５、８、１３、２１…)で表現します。フィボナッチ数列である理由は、自然な指数関数的な増加を示しているという性質上、複雑さを表現しやすいという点、またそれを分解しやすいという点です。例えば２１は１３と８で分解でき、８は３と５で分解できます。
ストーリーポイントについての詳しい説明はこの記事がわかりやすかったので引用します。
20 kg のダンベルを持ち上げることを考える。筋肉ムキムキの街雄さんは軽々と 100 回連続で持ち上げられるが、最近太り気味のひびきさんは 1 回持ち上げるのがやっとだ。
この場合、20 kg というダンベルの負荷が、ストーリーポイントに相当し、何回持ち上げられるかがタスク完了までの時間に相当する。
誰が持ち上げたとしても 20 kg というダンベルの重さは変わらない。街雄さんが持ち上げると 5 kg 分になるから、100 回連続で持ち上げられる、ということにはならない。同じ重量でも人によって連続で持ち上げられる回数が異なるのは、筋肉量が違うからだ。
ここでいう筋肉量が個人の能力や知識量に相当するもので、能力や知識量が多ければ多いほど、他の人よりも早くタスクを終わらせることができる可能性が高い。
例えば、以前に行った「プロフィール画面の表示文言を変更する」というタスクのストーリーポイントが 1 だった場合、今回のタスクである「申込画面の注意文言を変更する」というタスクもレイアウトを修正する、という観点ではほぼ同じなので、ストーリーポイントとしては 1 になります。
同様に「ユーザーの検索項目を1つ追加する」というタスクが発生したとしても、以前に行った「新しいプロフィール項目を1つ追加する」というタスクが8だった場合、「ユーザーの検索項目を1つ追加する」というタスクは不確実性が高いとはいえ、少なくとも 8 と同じかそれ以下であろうという予想が出来ます。(何れにせよ新しいパラメータを追加する、という点や、プロフィール項目を追加するということは、基本的にはその検索を追加する必要があるからです。実際はそこまで単純ではありませんが….。)
大きい機能、例えば「リファラル機能」等と言った抽象度の高い機能でも分解すればストーリーポイントの集合体として表現することができます。
スクラムでは毎回のSprintごとに、最初の機能の見積もりを行い(Planningと言います)、開発を行います。最終的にそのSprintで行ったタスクのストーリーポイントの合計をベロシティと言います。
このベロシティが「今の開発チームが1Sprintで開発できる総量」になります。チームの健全性(生産性ではありません)をこの数値で測り、課題を改善していくことと同時に、少なくともこのベロシティ分の開発は行える、という少し先の未来を具体性を持って可視化することができます。
長々と説明してきましたが、生産性を改善する土台である「不確実性を最小にする」ということはこういったプロセスをたどります。
6. じゃあお前は何をやったのよ
不確実性の説明というか、ポエムに3500文字も使ってしまいました。ここからは私がこの半年で何を行ったのかを書いていきたいと思います。
1. タスクを整理した
弊社の開発タスクの管理はBacklogで行われていました。課題として、各開発者が放置された課題を担当者として数多く抱えている状態であり、また
・「課金を整える」という抽象度激高チケット
・ APIのエラーが記載されているだけのチケット
・APIの開発とフロントエンドの開発が1つになっているチケット
等、それぞれの粒度も異なるものでした。
またチケットのステータスも膨大に存在していました。その時期もスクラム(のようなもの)やっている関係上、一応一定のSprintで開発期間を区切ってはいたので、毎回それを私がひっかき集めてスプレッドシートにまとめ管理し、なんとかリリースに持ち込む、という事を行っていました。また開発ステータスも膨大で、すべて開発者ではなく自分で更新し、アサインまでしてしまっていました。
開発者が開発に集中できるようにと自分にタスクを集中させた結果、開発状況が曖昧になり、具体的な改善もしにくい、でも死ぬほど大変という、一言でいうと悲惨な状態でした。
なのでまずは一度現状のBacklogのプロジェクト上にある1500程のチケットをすべて棚卸しし、新しいプロジェクトを作成し、必要なチケットはそちらに移行するという作業を1ヶ月程かけて行いました。具体的には以下を行いました。
・少なくとも「Backend」「Frontend」「iOS」「Android」毎にタスクを分ける。不明点がある場合調査チケットを作る。
・抽象度が高いものや、起票から1年以上経過しているものは移行しない
・開発ステータスを最小限にする(未対応、処理中、待ち、レビュー中、処理済み)
・原則として、1人1つまでのタスクしか持たないようにルールを策定
これらを通してタスクの粒度を一定に整え、誰が何をやっていて、それがどういう状態かを可視化するようにしました。（余談ですがこの新しく作ったBackLogのプロジェクトは、更なる効率化のためにNotionに移行することとなり、3ヶ月足らずで役目を終えることとなります。ただ、この時期に行った整理が今も活かされている実感が有るので、無駄ではありませんでした。）
2. スクラムの仕組みを整えた
❏ 明確なイベントを導入
これまでもスクラム(のようなもの)を取り入れていたのですが、具体的には2週間でSprintを区切るということと、振り返りを行う、ということしか出来ていませんでした。実際にSprintが始まると私からタスク内容を説明し、開発が開始され、その開発が終わると私からタスク内容を説明し、を繰り返し2週間が経過したらそれをすべて自分でテストし、修正依頼を投げ、それがすべて修正されたらリリース、というサイクルでした。
今回からは明示的にPlanning等、スクラムの各イベントを導入しました。その頃は私がすべてのチームを見ていましたが、去年の2月にスクラム開発を経験してきたサーバーサイドエンジニアがジョインしてくれたこともあり、スモールにサーバーサイドチームだけで進め、やり方が定着してきたタイミングで他チームに広げていく、という方法を取りました。浸透までもだいたい1,2ヶ月程度でした。このタイミングで自分はアサイン業務を無くし、Planningされたタスクを各々の開発者が取ってステータスを更新していく、という運用となりました。
また、2週間で開発するが、QAを挟むと実質的には月に1度のリリースになってしまい、定期的なリリースになっていないという問題がありました。これに関してはプロダクトチーム(PM業務を専門とするチーム)やQAチームと協議を重ね、2週間に1度のリリースにするように運用を改善しました。
❏ ストーリーポイントの再定義
ストーリーポイントも概念としては知っており、導入してはいたのですがPlanningの際に「ここは経験がないので or オフショアが書いたコードなので、ストーリーポイントは128です」のような、それが不確実であるということしか分からない見積もりしか出来ていませんでした。熟練度や経験によってポイントが上下し安定しない状態になっていました。それ以外にも定義が曖昧であり、毎回のベロシティが安定しない状態が続いていました。それぞれの課題に対してのアプローチは以下です。具体的には定義をより明確にし、最小単位で分解させるような仕組みにしました。
・ポイントは必ず1,3,8でつけるようにし、それ以上の場合は1,3,8で分割するようにした。
・不確定なものはまず調査タスク(1 - 3 に収まるもの)を入れた。
・啓蒙する。熟練度や経験ではなく、過去タスクと比較してポイントをつけるようにPlanningで促す。
3. プロダクトチームとの連携を強化した
先程も一部記載しましたが弊社にはプロダクトチームというPM業務を専門とするチームがおり、PRD(仕様書)の作成などはそのチームが担っています。もともとは大枠の開発優先度を私(とデザインチーム)が決め、仕様を作り、開発に連携しリリースまでを一貫して行なっていましたが、業務が集中することで、工程とコミュニケーション両方のボトルネックに私がなってしまい、その改善の為にチームが発足する流れとなりました。
さて、Planningを行う上で、そのタイミングまでにPRDが完成している必要がありますが、半年前の段階だと、そもそも開発チームとプロダクトチームのオフィスの階が分かれておりそもそも物理的に遠く、プロダクトチームとしても「開発が開始できるに足るPRDが何か」を模索している段階でした。こちらに関してやったことは地道ではあるのですが、基本的にはチームビルディングです。
Notionで全行程を管理するように変更。NotionにProductBacklogの役割を持たせ、開発チームとプロダクトチームが同じPRDを見ながら共同で作り上げていくようにする。
プロダクトチーム × 開発チーム での振り返りを隔週で行う。
週に2日は近い席で働くようにする。またそれ以外にも「何に困っているのか」等1日に1度は話しかけるようにする。
管轄やレポートラインは開発チームとプロダクトチームは異なりますが、いいプロダクトを作る、という目的は同じである以上、私の中では勝手に同じ1つのチームとしての振る舞いをしています。1つのチームで工程は違えど同じものを作り、細かい頻度でプロセスを改善していく思想は基本的にはスクラムに根付いています。
7. 終わりに
今回は区切りとして、半年間の間に行なったことをまとめました。自分も試行錯誤して進めたこともあり、本来の定義や方法論に一部誤りがあるかもしれません。また、これらは自分1人でやりきったものではなく、チームが強化されていくプロセスの中で確立されていったものでもあります。年末に振り返りとして以下のようなつぶやきをしました。
年末なので今年1年の振り返りをする。あまり表には出てないが、実は弊開発チームはこの1年が一番成長した1年だった。
— Kota Akahoshi (@objective_r) December 31, 2022
2,3年前、1人で物事を進めていた時と比べ、自分だけで行えることが如何に微々たるかということと、チームで物事を進めるということの意義が、月並みですが実感できたような気がします。
何よりも大事なことは「チームで」「ユーザーへの価値提供を最大化するものづくりを」「細かく正しい方向へ1歩1歩進めていくプロセスを構築する」ことであり、エンジニアリングマネージャーの仕事はそういった面白みがあると感じています。
助太刀ではエンジニアリングマネージャーを含めて、すべてのエンジニアを募集しています。詳しくはこちらをご覧ください。
助太刀が立ち向かう建設業界という市場は、規模60兆円を超える巨大市場にも関わらずICT化が進んでいない、という課題を抱えています。それを一緒にテクノロジーの力で解決するプロダクトを一緒に作っていきましょう。
助太刀では一緒に働く仲間を募集しております！
求人一覧
https://herp.careers/v1/sukedachi
エンジニアオープンポジション
https://herp.careers/v1/sukedachi/8upXMlCpwNLc
2月にDevelopers Summitで弊社CTOが登壇します！
皆様是非ご参加ください。
https://event.shoeisha.jp/devsumi/20230209/session/4188/
この記事が気に入ったらサポートをしてみませんか？