こんにちは。てぃろです。
これまで”大規模ソフトウェア開発の品質を考える”というシリーズでソフトウェア品質をどのように改善していくか？を議論してきました。今回はそれらを長期間実行してきた結果のまとめです。
結論として、およそ10カ月で品質は改善し、継続的に品質を維持向上させるための文化醸成まで成功しました。
ここまでいくために、結局一番重要なのは以下の2点でした。
- 現実的に実行可能な範囲で少しずつ実行すること
- 各種作業を、その作業が必要な理由や作業手順一つ一つの背景を説明し続けること
もっとスマートな方法でやりたかったですが、やはりそうはならなかったです。人間がやることですからね。
しんどくてもちゃんと根気よく丁寧にやり遂げるからこそ人はついてきてくれるしチームができあがる。そんなチームには文化があるので今後は私がいなくてもちゃんと品質を守っていってくれることでしょう。
そんな風に思える程度にチームには文化ができてきたと思うので、そんな文化醸成ができるまでにやったことの総論として、この10カ月の活動を振り返っていきます。
各論については”大規模ソフトウェア開発の品質を考える”のシリーズをご覧ください。
何がそのソフトウェアの品質を悪くしたのか？
ことの始まりは、2021/4にあるiOSアプリの品質向上のミッションを与えられたことでした。
ただ品質向上をしなさい、と言われても何をすればいいかそれだけではわかりません。上司からはとりあえず品質が悪いしか聞かなかったので、まずアプリがどんな状況なのか？を自分の目で確かめることからスタートしました。
すると、以下のような現象が見えました。
- 単体テストが動いてない
- コンパイル警告やlint警告が消化されていない
- E2Eテストが実施されているらしいが、その内容が書き残されていない
- 重複コードやログメッセージの統一化がされていないなど、コードに無駄が見える
これだけ見ると単体テストをやってないならやる、という気になってきますがそれは拙速過ぎました。
上記の通り、単体テストコードは動いていないだけで、一部開発はされていたのです。単体テストが計画にも含まれていました。lintツールも入っていたし、UIテストをしようと標準化が試みられたあともあった。コーディングにおいては変更容易性を考えたアーキテクチャも決められてログ出力の標準化ドキュメントもあった。
でも、今は何もやっていない。
つまり問題は、標準化や品質維持の計画が存在していたはずなのに、品質維持向上の活動がされない状態になってしまっていたということです。
長期的な品質維持向上には文化醸成が不可欠
さらに問題を深掘って根本原因を考えた結果、開発者それぞれの品質に対する意識が低いことが原因だと推測しました。
これは”E2Eテストの内容を書き残していない”ということに象徴されていると思います。
開発工程においては、自分が開発した機能が問題ないことを証明するために再現性のあるテストを実施することが不可欠だと思います。逆にこれをしないと自分でやってて怖いです。
しかし、それがなされてなかったということは、それが意識的か無意識的かに関わらず、品質の証明ができなくても気にしない人が多かったということです。
このように品質に対する意識が低いまま品質を高めるための具体的施策を整備しても、機械的な作業に終止して細かい問題を見逃してしまい肝心のときに問題が頻出して開発が炎上し、また施策が無視され…という形で、最初の状態に戻ってしまう恐れがあると思います。
そうならないようにするには、品質を高めるための具体的施策を作ることと同時に、品質に対する意識を高めることこそが必要なのではないかと思います。そうして最終的には品質にこだわるという文化のあるチームを目指すべきだと考えます。
チームとしての文化が醸成されていくと、チームの人員の入れ替わりが発生したとしても新人もその文化からチームが大切にしている品質を意識しやすくなるので、長期的に品質を確保しやすくなっていくと思います。
では、どうやって文化を醸成していけばいいかというと、具体的施策を進める中で徐々に意識を変革していってもらうしかないと思うのです。
品質を守る仕掛けで作業を変革し、声掛けで意識を変革する
まず、具体的に品質維持向上のために何をしてきたのかを少しお見せしたいと思います。
- 自動テスト環境の整備
- 自動テスト実行状況の可視化
- 各種静的解析ツールによる品質分析とそのやり方の解説
- 単体テストの再定義（詳しくはコチラの記事で解説）
- 単体テスト環境の整備
- 単体テスト計画（品質目標や確認ポイントの考え方などを定義）
- 自動UIテストの整備（詳しくはコチラの記事で解説）
これもまるめて書いているので細かいことを言えばもっといろいろなことをやってきています。しかし、これらの施策を出すため考え方がありました。それが以下の２点です。
- 自動化できるところは自動化する
- 品質確保のために必要な作業を定型化する
現場を知ってる人からすると当たり前のことしかしていません。でも、改めてこれらが重要と考えたのは、品質に注意を向けることに最大限の脳のリソースを割いてもらうようにしたかったからでした。
なぜ品質に対するこだわりが少なかったのかというのを現場の人達の気持ちになって考えると、余裕がなかったからなのではないかと思います。当時の状況を見るに非常に多くの開発テーマがあって全員が手一杯という状況なのは見ればすぐに分かりました。
ただ、品質向上施策はそんな中でもやらなければならないことなのです。
しかし、品質向上施策は作業量を純粋に増加させてしまいます。すでに余裕がない人たちに品質をあげなきゃいけないからと作業を追加したところでできるはずはありません。
ならばと、時間を作るという意味で自動化するだけでは足りません。すでに忙しい開発者にただ作業を振ると機械的に実施しておしまいになってしまいます。
ではどうするかというと、品質について意識を向けてもらうための仕掛けや声掛けを徹底します。
仕掛けは上述の通りにいろいろな作業の定型化のことを言います。
別の記事でも書きましたが、品質に対する意識が低い人たちは、何を確認すれば品質が確保できたと言えるかがわかっていないことが多いです。そのため何をすることが品質を確保することに繋がるのか、作業を定型化しチェックするポイントを明確化することで自然と品質が確保できる方法をとれるようにしておきます。これが仕掛けです。
さらに、その作業背景を説明していきます。一回説明してもすぐに全員が徹底できるようにはならないので、説明し続けます。何度も何度も説明し続けます。何度言ってもわかってくれないことも多いですが、そういうときには言い方を変えたり、別の人を通して言ってもらったりして工夫し続けます。これが声掛けです。
こうして仕掛けと声掛けを根気よく続けることによって、作業を変革しながら意識も変革し、最終的には文化の醸成を目指していきました。
結果として、10カ月程度たったころには、後輩くんが私が気づくよりも早くCIジョブの失敗に気づいて即修正をかけてくれたり、開発パートナーさんが単体テストを当たり前に実施したりと、昨年は考えられなかったような品質に対する意識を見せてくれるようになりました。
まだまだチームとして技術的に未熟な部分も見え隠れするのですが、まずはそんな品質に対する意識をチーム全体で共有できていたら安心なのではないでしょうか。技術はあとからでも自然に身に付いてきますから。
まとめ
今回は長期的な品質維持向上のための文化醸成を目指してきた話をしました。
実は品質向上担当を任されたときに、私はいつまでもこのチームで品質向上担当をしていくわけではないので、自分がいなくなったあとのことを考えなければいけないな、と思いました。
ソフトウェアが作って終わりだった時代はもう遠い昔の話。今はソフトウェアを継続的にアップデートしてグロースさせていくのが当たり前になりました。
ならば、ソフトウェアの長期的な品質維持を考えるのは必然であり、そのための施策を考えておくことこそが品質向上担当には求めらているのではないでしょうか。
最近では、SREという考え方やロールもできているくらいに、プロダクトの長期的な安定運用が明確に求められる時代になっています。その考え方は自社プロダクトを持つスタートアップたちだけのものではなく、受託開発の保守・維持管理をしているSIerにも関わるもののはずです。
ただし、残念ながら自社プロダクトを持つスタートアップたちとSIerが違うのはリリース後にソフトウェアにかけられるコストが違うことです。
受託開発の保守・維持管理の場合、ユーザ企業側がリリース前の開発に比較してお金を出さないことが普通です。そうするとSREのような人を確保することが難しい。オフショアパートナーはどんどん入れ替わる。社員も数年で入れ替わる。ソフトウェアも変わるから作業もどんどん変わる。
でも品質は守らないといけない。だからこそきちんと品質にこだわる意識だけは継承してもらわなければならないのです。
人がいい文化を作るから、そんな文化の中でいいモノができていくんじゃないかと思います。
これからも人と人との関わりの中で良い文化を築いて、よりよいモノづくりをしていきたいですね。
