キャッチアップをすることについて
僕は今まで7回ほど転職をしており、いろんなソフトウェア開発に携わってきた。
小規模なものから大規模なものまで、新規開発からレガシーシステムまで。
会社の規模も様々で、スタートアップ、メガベンチャー、老舗中小企業、SIer、グローバル企業。。
いずれの組織に関わる場合でも共通して必要になったタスクがキャッチアップである。
「転職してきた人材」には必然、即戦力が求められる。初日からコントリビューションすることは求められないが、まぁジョインして2-4週間くらい経つまでには何か小さな1つのタスクを完遂してみようという方針はどの組織でも共通していたように思える。
そんなわけで、僕は少なくとも7回はキャッチアップをする状況に置かれていたわけだが、となると「いかに早くキャッチアップを進められるか」という課題に思考を巡らせることになる。
キャッチアップを別の言葉で表すと「業務知識と業務フローを理解する」ことだと思う。大抵の組織ではwikiやConfluenceにある程度の情報がまとまっている。wikiやConfluenceが存在しない組織もある（多くの情報が暗黙知として存在している状態）。いずれの場合でも分からないことは無数に出てくるので、その分質問をする必要がある。
このとき大切なのは「どんなに小さい疑問でも質問する勇気を持つこと」「効率よく質問すること」だと考えている。
どんなに小さい疑問でも質問する勇気を持つこと
- こんな初歩的な質問して怒られないかな
- 〇〇っていうニッチなケースの場合はどうすれば良いんだろう。でも重箱の隅をつつくような感じで嫌なやつだと思われないかな。。
という気持ちになることがある。でも気にせず質問していいと思う。あなたの質問に対してキレる人がいた場合、それはあなたの問題ではなくキレた人の問題だからだ。それはその人の人格の問題かもしれないし、たまたまストレスが溜まっていたのかもしれない。また、ニッチなケースについて質問することは、組織やシステムに対する未知の課題を発見したということかもしれない（第三者の視点が入ることにより、未知の課題が明らかになる状況はしばしば発生する）。いずれにせよ、キャッチアップをする段階で質問が生まれることは自然なことで、あなたは何も悪くない。キレられたら他の人に質問をしてみよう（可能なら、その人がキレた理由も質問してみよう）。未知の課題を発見したのなら、それは早速組織に貢献できたということだ。
効率よく質問すること
あなたが質問をするということは、あなたの質問に対して回答をする人が存在するということだ。1つ2つの質問ならチャットや口頭でパパッと聞いてしまえばいいのだが、キャッチアップをする場合は一度に10個以上の質問が出てくるなんてことはザラである。上手に質問できないとやり取りが発生して時間がかかってしまうかもしれないし、自分が期待したものとは違う観点から回答が返ってくるかもしれない。できることなら、お互いコストを掛けずに質問し、回答したいものだ。
- チャット/口頭では一問一答の形式で質問をする。1度に2つ以上の質問をしない
- 質問リストを作成する
- 質問事項に対して、現時点で自分が理解していることと考えていること、知りたいことを明確に記載する
これはあくまで私の経験上の話であって科学的なエビデンスは一切ないのだが、人の脳は2つ以上の質問を同時に処理できないように設計されていると思う。よくある例としては、チャットで2つの質問を投げたとき、どちらか一方の質問に対してのみ回答が返ってくるという場面がある。改めて確認すると回答者はもう片方の質問にも回答できる知識を持っているのだが、なぜか1つの質問に対してしか回答が返ってこない。どういう理由でこうなっているかは分からないが、とにかく色々な人がこういう振る舞いをするということだけは観察できている。なので、チャットベース/口頭で質問をするときは一問一答の形式で話をするとよいだろう。
質問リストを作ることの意義は、多くの人が実践していることなのであまり詳しく説明する必要はないかなと思う。僕がやっているプラクティスとしては、「緊急度が高い質問は質問リストに記載の上チャットでメンションします。それ以外の質問はお手すきの際にご確認ください」と伝えることくらいだ。
ただし、質問をする際には、その時点での理解度、知りたいこと、質問する背景はできるだけ詳しく書いたほうが良いと思う。回答する側としては、
「〇〇」って何ですか
と質問されるよりも
「〇〇」について質問があります。こちらについて社内ドキュメント(orインターネット検索で得た情報)を拝見する限りXXXかなという認識をしておりますが、合っておりますでしょうか。背景としては、現在のタスクを進めるために△△△をしたいと思っています。
のように質問されると、「あぁこの人はこういうことをやろうとしていて、この部分までは理解できていて、この部分で躓いているんだな」と状況を正確に把握することができるため、コミュニケーションギャップを減らすことができる。
この他、「大枠から理解を進める」「質問したことは必ずメモする」「回答をもらったあと、自分の言葉で回答内容を説明し理解できていることを確かめる」といったプラクティスもある。これから新しい会社/プロジェクトに参画する人たちの助けになれば幸いである。
プロセスを導入/改善するときに意識していること
既存の開発プロセスに新しいプロセスを導入したり、プロセスを改善したかったりするときがある。
僕はそういうとき、その場の状況によって２つの方法を使い分けている。
①既存のプロセスが存在せず、新規に立ち上げる場合
例えば、１人目QAとしてチームにジョインしQAプロセスを立ち上げがミッションとなっている場合。この場合は、JSTQBのシラバスや専門書を参考にしてフローチャートや図、表を作って数枚のスライドにまとめる。そして、開発チームのメンバーに「こんな感じで進めたいと思うのですがどうでしょう」とプレゼンする。フィードバックを基にして数回ブラッシュアップし、チームの合意を取ってからプロセスの実施を開始する。
形式張っているというかフォーマルというか、セレモニーを経て導入するイメージ。そこそこ大きめのプロセスを導入する場合はチームに与えるインパクトも大きくなるし、そのプロセスに関して専門知識を持たないメンバーもいると思われる。そのため、関係者と事前に打ち合わせて、影響範囲やリスクを把握した上で導入したほうが良いだろうと思っている。
②既存のプロセスが存在しており、これを改善したい場合
例えば、テストデータの作成がボトルネックになっていて、これを自動化したい場合。この場合は、まず個人レベルで実験を繰り返して試行錯誤し、効果が出たらチームメンバーに紹介するようにしている。別にコソコソやる必要はないんだけど、かといってセレモニーを経たり合意が必要な粒度ではないため、まず自分でやってみて効果を実証してからジワジワ広げていくと良いだろうと思っている（このとき、ドキュメントを用意したりハンズオンセッションを開催したりすると、他のメンバーにも伝わりやすくなる）。
逆にアンチパターン的な振る舞いは何かあるかな、、と考えてみたところ、「虎の威を借る狐」「野次馬」は推奨されなさそうだと思った。
①虎の威を借る狐
例えば、
〇〇っていう技術が話題なんです！A社もB社も導入しています！QA界隈で有名なCさんも使ってるって言ってました！私達も今すぐ始めるべきです！！
みたいな、皆がやってるから凄いんです的な説明の仕方は、チームメンバーから理解を得るのは難しいだろうと思う。「チームの課題は何か」「そのプロセスを導入/改善することで何が得られるか」をロジカルに説明すると納得感が得られると思う。
②野次馬
例えば、
この課題解決するためには〇〇っていう技術を使うといいらしいですよ！すごくないですか？さあ始めてください、ほら、ほら！！
みたいな、要は口は動かすけど手は動かさない的な振る舞いも理解を得られなさそうだなと思った。まずは自分で動くことが大事だと思う。
「システム運用アンチパターン」を読んだ
最近、
ソフトウェアの品質のみを業務の対象と捉えるのはQAエンジニアの活動として不十分ではないか。運用やオペレーションまで含めた組織のプロセス改善を考えなければ、、
という謎の使命感に囚われていたため、オライリーの「システム運用アンチパターン」を読んだ。
結論から言うと、「そうだよね、システムを運用しだすとこういう課題出てくるよね」と身に覚えのあるトピックがうまく言語化されており非常に面白かった。
また、タスクの自動化や可視化、文化の作り方や情報の取り扱い方など、具体的な解決策も挙げられていてウンウンと頷きながら読むことができた。
身近な話だと、QA業務においてもタスクの自動化は重要で、例えばテストデータの作成に毎度毎度複数日費やしていたり、開発環境-テスト環境-本番環境がいつの間にかそれぞれ異なる設定になっていたりすることがある（このような場合、テストの結果を信頼できないため再実行する羽目になる）。僕もこのような課題に対してスクリプトを書いて解決してきた経験があるので他人事とは思えない内容であった。
本書で特に興味深かったのは「大きなインシデントが発生して組織にトラウマが生まれたときどう解決するか」というトピックで、よくある解決策として「承認プロセスを追加する」というアイデアが採用されるが、これはDevOps的には悪手で、何故かというと、特定の人物に業務と責任が偏るし、承認プロセスの追加により生産性の低下やリリース頻度の低下を招いてしまうからというものであった（例えば、タスク自体は60分で完了するはずなのに、特定の承認プロセスを挟むせいで2-3日間手が止まってしまうことがある）。
全体を通すと、マインドセットの持ち方やコミュニケーションの取り方、課題への向き合い方など、心や意志にだいぶページを割いていたのが印象的だった。とてもよい読書体験ができた気がする。
ムーブメントを起こすときに大事に持していること
まずは、とにかく自分がハチャメチャに楽しんで行動すること。そして、楽しんでいる様子をパブリックに公開すること。すると、そのうち誰かが興味を持って僕の様子を眺めたり話しかけたりするようになる。そして、同じような行動をする最初の人が現れる。継続して行動し続けていると、僕たちの行動に興味を持った人が徐々に増えていく。
このトークを初めて観たのが10年ほど前で、それ以来、新しいムーブメントを起こしたいときには思い出すようにしている。
（ビジネス的に）品質の良いソフトウェア
品質の良いソフトウェアってなんだろうと考えていて、想いを一瞬で忘れてしまい、ようやく思い出したので書いておく。
僕は職業QAエンジニアだからビジネスコンテキストで考えるけど、いま一言で表現するなら「より少ないコストでより多くの利益をもたらすソフトウェア」かなと考えている。
バグが少ないとか、当たり前の価値を備えているとか、魅力的な価値を持っているとか、保守が容易であるとか、堅牢であるとか、運用が容易であるとか、いろんな観点がある（し、それで良い）と思うんだけど、ビジネス的にはまず売上をあげることが大事で、となると「コスパの良さ」はソフトウェア開発における品質のいち観点として無視できない要素なんじゃないかと思う。
「売上をあげていて合法で、マナーを守っているなら、バグがあってもいいし、当たり前の価値がなくても良いし、魅力的な価値がなくてもよい」という考え方はあってよい気がしている。実際、（名前は挙げないでおくが）バグがあり、特に魅力的（or当たり前）な価値が見当たらなくても、広く認知され利用されているソフトウェアを幾つか知っている（このような状況が発生するのは、ビジネスの仕組みが優れているからだとも考えている）。利用者は、しばしば文句を言いつつも、なんだかんだそれらのソフトウェアを使うことを辞めない。なんなら、「またバグが出たよ～～ｗ」と話のネタにさえしていることもある。すごいことだと思う。
もちろん、バグは少ない方がいいに決まっているし、当然のように期待される機能は実装されているべきだし、可能な限り魅力的な価値を提供した方が良いに決まっている。ソフトウェアだけを見るならそうあるべきだと思う。しかし、開発コストと売上とのコスパ、ビジネスとソフトウェアの融合を考えたときに、最適解となるバランスは何か？優先するべきもの/切り捨てても良い要素は何か？を考えると幸せになる人が増えるんだろうなと思った。
「品質文化」とは言うけれど
個人開発やってると、正直、「動くものを作るのに精一杯で品質のこと考えている余裕がない」と思うことが頻繁にある。
QA界隈では「開発チーム（実装担当者やPdM、デザイナー等ステークホルダー）に対して品質を意識する文化を築いていこう」的なムーブメントがあるように思うんだが、これって彼らにとっては結構な負担じゃないか、などと想像したりする。
僕のソフトウェア開発スキルが弱いだけかもしれないが、僕がQA以外のステークホルダーだったら「いや趣旨は分かるんですが実際問題こっちも余裕なくてですね、、」と言いたくなりそうな気がしている。
各企業のテックブログなんか読んでいると、「開発者が品質を意識してくれるようになりました」「E2EテストやAPIテストを実装してくれるようになりました」みたいな記事が散見されるんだけど、これって開発者の（品質を意識することにより増幅した）負荷をどれくらい考慮したものなんだろう、気づけているのかな、どうやって負荷を増やさずに品質文化を醸成しているんだろう、果たして？？なんて疑ってみたりもする。
上記はあくまで個人開発をやっている中での感想だが、チームでアジャイル開発をやるとなると２-3週間毎に実装開始～リリースまで到達しなくちゃいけなくて、自動テストはおろか、コーナーケースや異常系を考慮しながら実装するのも大変に困難ではないかと思う。
- 仕様やアーキテクチャを検討している段階で不具合/違和感に気づけたら良いよね
- コーナーケースや不具合発生時のインパクトを考慮しながら実装できたら良いよね
- 不具合の検出は早ければ早いほど修正コストが低くなるから、テスト環境にデプロイする前に実装担当者側で最低限テストしたほうが良いよね
いずれも正論だと思う。しかし、じゃあ実践できるの？と問われたらかなり厳しいんじゃないだろうか。もし僕が、切羽詰まった（例えばスプリント後半の）段階でこれを言われたら
そうですよね、全くもってあなた方が正しいです。それでは、次回から2-3スプリントほどで良いので実践していただけますか？口を動かさなくて結構です、頭と手を動かしてやって見せてください。私のロールモデルになってください。
などと噛み付いてしまうかもしれない。
もちろん私は、QA側の発言に敵意がない（むしろチーム/会社に寄り添った意図での振る舞いである）ことは知っている。ステークホルダーも特に反論しようとは思わないだろう。そのうえで、品質文化について言及したりそれを浸透させようという行動を起こすときには慎重になったほうが良いんだろうなと思う。例えば、開発者が意識せずともある程度の品質が自動的に担保されるような環境をQA側で提供しながら対話を進めると良いかもしれない。ビジネスをやっている以上、品質は間違いなく大事で、それは皆分かっている。分かっていながら実現が困難であるという状況を起点として歩んでいけると良いのではないかと思うし、この課題感こそがQAエンジニアの存在意義なのではないかと考えている。
脳死でテストケースを減らす知恵（Amazon Cognito編）
Webサービスのユーザー管理と認証をAmazon Cognitoで行う場合は、パスワード設定の制約（最小文字数やパスワード要件）をコンソールから設定できる。
Webサービスをテストする際にはアカウント作成周りのテストケースが地味に多くなりがちなんだけど（2バイト文字とかメールアドレスまわりとかパスワードの組み合わせとか文字数とか）、ここの設定を確認すれば数件の正常系と異常系をテストするだけで済みそうだなと思った次第。少なくともコンソール側で設定した部分の品質についてはAWS側が保証してくれているわけだからね。
全然関係ない話題になるけど、AmazonやMicrosoftがサーバー周りの設定や開発を便利にするクラウドサービスを普及して市民権を得ている現在、ソフトウェアの開発工数見積ってどうやればいいんだろうとか考えるなどした。
