QAからみたシンプルフォーム開発組織

シンプルフォームという会社でQAエンジニアをやって中澤です。
過去4社ほど（第三者検証会社含む）の企業でQAエンジニアを行ってきました。

なぜ記事を書こうと思ったか

冒頭でも記述したようにQAエンジニアで過去4社ほどの開発組織に属した身として、
シンプルフォームの開発組織の文化や、考え方の素晴らしさをぜひ多くの方に知って欲しいと思ったからです。
この記事を通して、シンプルフォームの開発組織の良さを知っていただけると幸いです。

シンプルフォームの開発組織について

シンプルフォームではスクラム開発を採用しており、3つのチームで構成されています。
QAチームは、３チームに対して横断的なチームとして関わりを持っています。

また横断的な活動の他に、リリース前の新しい機能や改修が問題なく動作していることを確認する「受け入れテスト」を担当しています。

いま現在、QAチームはエンジニアやチームがどんどん拡大している中で、QAの人数がそれに追いついていないという課題があります。
しかしながら、シンプルフォームではエンジニアそれぞれが品質の意識を高く持ち、またQAチームの活動に協力的でいてくれるため、受け入れテストや品質がリリースのボトルネックになることはありません。

ここではQAチームからみた目線での「シンプルフォームの品質を守るために、エンジニアが取り組んでくれていること」を紹介させていただきます。

要件仕様の詳細な洗い出し

シンプルフォームではユーザーストーリーのをベースに機能開発を推進しています。
プロダクトマネージャーがユーザーストーリーに要件を書き起こし、エンジニアはこの段階で徹底的に仕様を詰めます。

• この操作をした時にプロダクトはどう振る舞うか？
• この条件の時はなにが表示されるか？
  など、実装に動き出すタイミング前に仕様を深く追求します。
  それにより仕様考慮漏れや認識の食い違いによる手戻りを限りなく少なく抑えることが出来ています。

初期段階で仕様を追求し、詳細化することで仕様考慮漏れによるバグの発生を抑止し、様々なパターンを予め考慮した実装ができ後述する「初期品質」の向上に繋げることが出来ています。

品質に対する意識が高い

シンプルフォームにJoinし、一番良いと思ったことはエンジニアが品質に対する意識が高いということです。
なぜ品質の意識が高いと思ったのか、以下の2つの理由があります。

本番障害の検知の仕組みが整っている

シンプルフォームでは本番障害が発生した際にslackの障害チャンネルを用いて全社に共有します。
共有されるフローは主に以下の2つに分かれます。
1、Biz/CSへのユーザーからの問い合わせ
2、社内（主にエンジニア）検出

上記2つのトリガーがありますが、圧倒的に「社内（主にエンジニア）検知」が多いです。
他のプロダクトだと、概ねユーザーから問い合わせがあり、ユーザー影響が出てしまってからの対応に追われてしまうと思います。
しかし、シンプルフォームの強みはユーザーに知られる前にエンジニア自身が検知し、対応しています。
なぜ、エンジニア自身が検知できるのか。それは、適切なエラーの通知と不具合が発生していることを検知する仕組み化を徹底しているからだと考えています。
障害が発生しない側面と、障害が発生した後の対応の側面で仕組み化を考えていられており、ここまで社内（エンジニア）検出ができている組織はあまりないのではと感じています。

ポストモーテムの建設的な議論と徹底的な仕組み化

シンプルフォームではスプリントのイベントの中に全エンジニアが参加するポストモーテムを設けています。
発生した本番障害に対して、発生原因、根本原因、対策などを全エンジニアで議論し、改善を行っています。
本番障害が発生したりポストモーテムを実施すると担当者にヘイトが向きやすかったり、担当者のみが対策を考えていたりすると思いますが、シンプルフォームでは全エンジニアが1つの課題に対して、どうすれば防げるかを仕組み化の側面から議論を行っています。
障害を発生させてしまったファクトよりも、どうすれば仕組みで解決できるのかのみで議論を行うことにより、組織全体で品質の意識を向上させ、仕組み的解決が行える組織形成がなされている点が、品質向上に大きく貢献していると感じています。

初期品質が良い

ここで表現している初期品質が良いというのはテストを行う前、開発の実装が完了した後のことを指しています。
初期品質が高いことで、ユーザービリティ向上に対したテストに多くの工数をかけることができます。
そうすることで狩野モデルでいうところの魅力的品質に近づけることができます。

初期品質が高い組織は他にもあると思いますが、なぜシンプルフォームのエンジニア組織の初期品質が高いのか
もちろん新機能を実装する度にUTのテストケースの拡充など、多くの要素が考えられますが、一番の理由は「バグを検出した時の圧倒的当事者意識」だと思っています。
バグを無くすことは不可能に近いです。シンプルフォームでももちろんバグは発生してしまいます。
ただ、そのバグを検知した後の対応や、バグを作り込んでしまったことに対しての改善/仕組み化の意識が他の開発組織に比べて圧倒的に高いと感じています。

最後に

今回は開発組織のQA観点からの品質に対する意識について記述しましたが、そのほかにも魅力があります。
品質に関しては「QAがやるべき」という開発組織も多くないと思っています。
そんな中でここまで品質に対してエンジニア側から寄り添い、建設的な議論と仕組み化を協働で進められる開発組織はあまりないのではないかと思っています。
この記事を見て少しでも興味や参考にしていただけると幸いです。