チームの外から開発プロセスを改善するときに考えていた10のコト

この記事を書くに至った背景

エンジニアである僕が、開発プロセスを改善することになり、2ヶ月が経過しました。がむしゃらに走ってきたので、何を意識したのかを、改めて言語化してみようと思い、この記事を書いています。（言語化をする上で知識の整理をしていて、その過程で知ったトヨタ生産方式に出てくる言葉に、本記事はだいぶ影響を受けています ）

1. 部分最適ではなく全体最適にする

部分最適とは

『組織の一部や個人にとって最適な状態を優先する』
ref: https://bydesign.scskminori.co.jp/blog/24

全体最適とは

『企業や事業などの組織全体を最適な状態にすること』
ref: https://bydesign.scskminori.co.jp/blog/24

外にいることで、俯瞰して物事を見やすくなります。さらに言えば、チームの外にいるからこそ、全体最適を実現するための行動がとりやすくなります。
（チームの中にいるから全体最適を考える必要がない、とか、チームの中にいると全体最適を考えることができない、というわけではないです）

改善活動は、どのスコープを全体とするかを決めて、現状の全体像を描くことから始めます。

本記事での例は、すべて開発における企画~リリースまでをスコープとします。

上記であれば、まずは、開発に関わるメンバー（開発者、QA、PO、etc…）と開発プロセスのイベントやフロー（リファインメント、プランニング、開発、テスト、etc…）を図など視覚的に理解できる形でまとめ、正しく理解してから改善を始めます。

2. 標準を作る

現状を把握しただけの状態では、改善活動は始めません。
改善活動を行う時点で標準がない場合、その標準を作ります。

ここでいう「標準」は

現時点で最善とされる作業のやり方や条件
ref: https://toyokeizai.net/articles/-/130961

を指します。

標準通りにできないのは、何らかの要因が潜んでいるためであり、それが異常です。
作業者を一旦決めた標準に無理やり合わせるのではなく、環境や仕事に応じて常に見直し柔軟に標準を逐次変更していくことも必要です
ref: https://www.consultsourcing.jp/3331#hyoujunnomokuteki

とある通り、

• 標準と現実のギャップを埋める
• 環境などの要因に応じて、標準を変えていく

大きくこの二点を意識しながら、改善活動を行なっていきます。

（開発プロセスでいうと、企画~リリースまでの人とイベントとフローはどうあるべきか、を考えることから始めます）

3. 各種イベントの成果物を定義する

完了の定義を満たしていないと次に進めない、というルールは、

• どのプロセスに時間がかかっているかを計測可能にする
• 手戻りを減らす

という2つのメリットがある、と考えています。

どのプロセスに時間がかかっているかを計測可能にする

「作業時間を短くする」を実現するための情報を得るために、計測可能にすることが望ましいです。

逆に計測ができないと、どのプロセスで時間がかかっていたか、を正確に判断できず、ボトルネックの特定に必要な情報の信憑性がなくなります。

手戻りを減らす

要件を満たさない機能を顧客に提供されるのを防ぐことに、役立つと考えています。

また、不具合の修正にかかるコストは、工程が一つ進むことに大きくなります。コストがかかってしまう手戻りを防ぐためにも、成果物（完了条件）は強く意識しています。以下の記事がより詳しく解説しているのでよければご覧ください。

4. ムダを減らすことを考える

作業は以下の3つに分けることができます。

• 付加価値のある作業
• 付加価値はないけどやる必要がある作業
• ムダな作業

現状動いているプロセスがある場合、まずこの3つの観点で分類します。
改善するにあたって、現状のプロセスがが最高なのかというと、確実に「No」と言えます。
ムダはどこかに必ずあるので、まずムダをなくします。

人の判断ミスによって発生する作業もムダなので、

• 判断を減らす
• 自動化する

のどちらかの改善を行います。

ムダの改善に関しては、以下の資料が参考になるので、よければご覧ください。

5. トレードオフを受け入れる

トレードオフとは

何かを得ると、別の何かを失う、相容れない関係のこと
ref: https://ja.wikipedia.org/wiki/トレードオフ

のこと。

ムダが生まれる余地を作りたくないから、本当は、このイベントやフローを入れるべきではないよな、と思うこともあります。

しかし、現状（組織、チーム、メンバー、プロダクト、ソースコード、etc…）を鑑みて、このステップを組み込んでいかないと、幸せではない人が生まれるな、と考えて、あえてイベントを追加することを許容しています。

6. イベントやフロー等を1つ増やしたら、1つ以上減らすもしくは自動化する

「ムダを減らすことを考える」で話した、ムダな作業を0にしたい、というスタンスを持って改善に臨んでいます。

しかし、

• 改善する中で、先ほどの「トレードオフを受け入れる」で書いたようにイベントやフローを追加してしまう
• 標準に沿って行動していく中で、標準を変えるべきだよね、とイベントやフローを追加する

など、イベントやフローが増える機会はたくさんあります。

そのため、「イベントやフロー等を1つ増やしたら、1つ以上減らすもしくは自動化する」という意識を持って取り組むことで、ムダが入り込む余地をなくそう、と考えています。

例えば、開発プロセスにおいて、デザイナーによるデザインレビューをする必要が出てきたとして、デザインレビューが必須のチケットは必ずデザイナーにレビュー依頼出してね、としても

• 開発者がチケットのデザインレビュー依頼の有無を判断する
• 開発者がデザインレビュー依頼をデザイナーにSlackで連絡する

というような運用は、ストレス以外の何者でもないです。開発者に必ず守ってもらう、は難しいので、判断と連絡をJira Automationで自動化する、などのイメージです。

7. どうしたら改善したと言えるか、指標を決める

「AAAという改善施策を打ちます！」に対して「どうなるの？」といった質問に答えられないなら、行動しない方がいい！くらいに考えています。

そしてその結果に関しては、定量的に示したいです。

開発プロセスの改善という文脈において、特に何も計測していないときに最初は何を見ればいいのか、とかなり絶望してしまっていましたが、

• ベロシティ
• バーンダウンチャート
• バグ作成割合
• QA検証工数の予実差

など、いくつか参考にできる結果やプロセスの指標が存在するため、定点観測する指標を決めます。決めた上で、まずはここを目指そうね、といった共通認識をとりつつ改善を行います。

（ここは結構苦戦していて、今も定点観測している指標が正しいかは不安）

8. どうしたら計測できるか、を考える

指標を決めたとしても、指標を作ることに、労力はかけたくありません。

どうしたら労力をかけずに計測できるようにするか、を考えると

• 計測しやすくするために、プロセスを変更する
• 使っているProject Tracking System（Jiraなど）の使い方を変える
• ツールを使い倒す
  • Jira、Google Spread Sheet、Looker Studio、etc…

など、いくつか方法はあるため、どうしたら計測を自動化できるか、を考えます。計測方法に関しては、以下の記事にまとめたので興味があれば、読んでみてください。

9. 分岐はなるべく作らない

Aの場合はこうする、Bの場合はXXする、みたいな分岐の多いプロセスを作ったら、

• 指標が取りづらくなる
• 自動化も大変
• そして、分岐の数だけそのプロセスにおける作業者の考え事が増える

と誰も幸せじゃないです。
少なくとも自分は頭良くないので、複雑なプロセスを頭に入れながら仕事をすることができません。

だから、

• Aの場合はXXして、Bの場合は、Cの場合にYYしてDの場合はZZする

という複雑なプロセスではなく

• こうしたらこうする（なる）、以上

で済むような、プロセスにしようと努めています。

要するに、KISSの原則に従うことを心がけています。

Keep it simple, stupid.（シンプルにしておけ！この間抜け）
ref: https://ja.wikipedia.org/wiki/KISSの原則

（なるべく、と言っているのは、現場の要望でどうしてもこれは外せない、となった時だけ、議論を重ねた上で分岐を作ることはあります。これは「トレードオフを受け入れる」で書いたことに則った形です）

10. 振り返る

必ず、振り返ります。

改善の結果どうなったか、を定期的に振り返ることで、実際にムダはなくなっているか、同じミスは起きていないか、を確認し、確実にプロセスの改善を前進させます。

つまり、前進するために、立ち止まることが必要と考えて、振り返りを行います。

僕らのチームでは、このプロセスを改善してみた結果どうだったか、をリリースサイクルに合わせて行っています。KPTというフレームワークを使っていますが、チームの状況などに応じてYWTやFun/Done/Learnなど振り返りのフレームワークを選定すると良さそうです。（各種振り返りのフレームワークの説明は以下リンクを参照していただければと思います）

まとめ

この開発プロセスの改善、という活動は、自分以外の人の仕事の進め方にも影響を与えるため、どう変化するのか、そしてそれはどう良くなるのか、を丁寧に説明しながら進めないといけませんでした。
そのため、エンジニアとして機能開発していた期間とは全く違う脳の使い方をしなければいけませんでしたが、ある意味刺激的で、エンジニアとしての経験も活かすことができたので、自分にとっても意味のある活動になりました。
正直2ヶ月活動しただけなので、まだまだ改善の余地はあります。今後はもっと改善を押し進めて良い開発プロセスを目指していきます。