こんにちは。 ユニファのエンジニアマネージャーをしております田渕です。
今年も早くも15日を過ぎまして、「もう今年の24分の1が終わったね。」と会話していたら「時間に追われている人の言葉だ。」と横からツッコミを頂きました。 確かに!と思います。
昨年末は二度目の取り組みとなるアドベントカレンダーで盛り上がりまして、おかげさまで沢山の方に閲覧頂けました！ 継続は力なり、ということで、開始当初は殆ど閲覧くださる方もおらずひっそりと更新しておりましたこちらのブログも、更新すると一定の方が見てくださるようになりました。
2021年の初めのブログは何にするか？と若干ハードル高く悩んでおりましたが、難しく考えずに社内の他のブログに乗っかろうユニファ開発チームの最新の情報をお届けしようと思います。
皆様メリークリスマス。ユニファでCTOをしてます赤沼です。
2020年も残り僅かですね。ユニファアドベントカレンダーも最終日。メンバーの協力のおかげで今年も無事に完走できました。
アドベントカレンダーのゴールの記事として適当なのかどうかは自信がないですが、心理的安全性の醸成もまずは自分が弱さを晒すところから、課題の改善もまずは現状認識から、ということで、今回は自分の弱さを書き散らかしてみます。そして年末年始には改めて2020年を振り返ってみたいなぁなどと思っています。
私が入社してから5年の間に、会社全体としても開発チームとしても何倍にも大きくなりました。残念ながら私の力不足で離脱するメンバーもいましたが、今年だけで考えても多くのメンバーが入社してくれました。また、7月には組織構成を大きく変え、それによってさらに開発チームが大きくなりました。
チームはスケールしました。では私自身は適切にスケールできているのか？数年前の規模の時と同じつもりでやっていないか？逆に大企業のようなつもりでやっていないか？
今はまだ残念ながら適切なスケールはできていないと思っています。どちらかというと大きさに囚われ、メンバーから見ればすぐに変更して当然なことも、大所帯になったことで変更にブレーキをかけたくなる部分が強くなってしまっているなと時折感じています。
自分は今の規模の開発チームのトップが務まる人間なんだろうか。自分には向いてないのではないかと思う一方で、いやいや向き不向きとか甘っちょろいこと言ってないで、やるべきことはやれるようになれよ、と思う自分もいるわけです。他社のCTOのブログなどを読む度に、すごい、参考になる、と思うと同時に、自信を失う自分もいるわけです。
多くのマネージャーやCTOの役割の一つは、メンバーが仕事がしやすい環境を提供していくことかと思います。特にCTOは開発組織のトップであり、良くも悪くもCTOのスタンスが開発組織に大きく影響を及ぼします。では私は良い環境を提供することができているのか？メンバーがハードワークしたくなるような組織を作れているのか？
開発者は、面白い仕事、面白い環境があれば、何も言われなくてもどんどん動きます。それらを用意するのが自分の仕事だと思いますが、まだまだ不十分だと日々感じています。
結局自分はリーダーとしてどうなのか？経営陣の1人としてバリューを出せているのだろうか？全然不十分だなと思いいつも悩みます。まだまだメンバーの力を引出し切れてはいない。メンバーからはどう見えているのか。自分は強力なリーダーシップを発揮するタイプではない。メンバーからしたらトップは自信満々にチームを強く引っ張って欲しいと思っているのではないか。こんな風に自分の弱さを出すのはマイナスなのではないか。
一方で、自分が向いてないことを無理にやろうとするのは、結局チームにとってもマイナスなのではないか。できる人に任せた方が早くてクオリティも高い。自分が退いた方がチームのためなら退くべきだとも思うのです。
結局、自分1人では大したことができないなぁといつも思うのです。プロダクト開発にしても、組織作りにしても、みんなの助けがないと大したことはできません。今までも散々助けてもらっているわけですが、来年も助けてもらえるよう、助けたいと思えるようなチームを作っていけたらと思っているわけです。
そしてさらに多くのメンバーの助けを必要としているので、しょうがない、助けてやるか、と思われた方はぜひ一度お話しさせていただければと思います。
来年は少しでも自信を持ってできていると言えるようにしたいと思いつつ、それではみなさま、良いお年を。
こんにちは。機械学習やデータ分析に加えてインフラ周りでも修行中の浅野です。今年の始めにさいたま市が導入した保育所マッチングシステムがトラブルを起こしたというニュースがありました。それをきっかけに保育所マッチングではどのような技術が使われているのか興味をもったので少し調べてみました。このユニファアドベントカレンダー24日目の記事ではその技術の基礎的な部分について書いてみようと思います。
続きを読むはじめまして、プロダクトデベロップメント本部で副本部長をやっています西川です。 UniFaアドベントカレンダーの23日目、メリー・クリスマス・イブイブの記事をお届けします。
さて、唐突に話を始めてしまいますが、マリオの生みの親でお馴染みの任天堂 宮本茂さんの名言のひとつに、
アイデアとは複数の問題をいっぺんに解決するもの
という言葉があります。
(おそらくはCEDEC 2008での)初接触から今に至るまでずっと深い共感を覚え続け、また、仕事の仕方に強い影響を受け続けてきた、私にとっていわゆる「座右の銘」のひとつです。
しかし、ずっと「なぜ、そうなのか？」「だからどうすればいいのか？」を明確な言葉にすることができないままでいました。
それが先日、散歩中に何の脈絡もなく突然、「あ、これだ」と自分なりの理解が急にクリアな言葉・論理・映像として浮かんできました。
せっかくなのでどこかでいつか文章としてまとめておきたいな…と思っていたところで、社内で今年もアドベントカレンダーやるよという声が上がってきました。
そういうわけで本日のテーマは、宮本さんの名言への自分なりの解釈を記したいと思います。
続きを読む
こんにちは。人間中心設計(HCD)専門家のやまぐち(@hiro93n)です。
主にプロダクトマネージャーやQAエンジニアの部署でマネージャーをやっています。キャリア的にはデザインの部署のマネージャーのやりたさもあるのでデザイナーにかかる課題解決などにも首を突っ込んでいます。マネージャーばかりでゲシュタルト崩壊しそうですね。自分はしました。
そんなわけでこの記事はユニファAdvent Calender 2020、22日目の記事です。
続きを読むこんにちは、データエンジニアリングチームの宮崎です。この記事は、UniFaアドベントカレンダー2020の21日目の記事となります。 最近、文字を自由に編集できるLINEスタンプがあることを知りました。いつの間にか色々進化していますね・・・！ そこで今回はDeepLearningのモデルを使って、以下のように写真からLINEスタンプ風画像の自動作成を行ってみたいと思います。
こんにちは！ユニファアドベンドカレンダーをご覧頂きありがとうございます！ ユニファQAチームの斉藤です。 このブログは、UniFaアドベントカレンダー 20日目となります。
今年はコロナで大変な１年でしたね。ユニファQAチームも今年の早い時期からフルリモートに切り替えて活動を行ってきました。もともとリモート勤務可能ではありましたが、案件が去年の２倍以上に増えたり、メンバーの入れ替わりがあったりしたので、フルリモート体制で乗り切るには大変な１年だったなぁと感じています。
そんな中ですが、新しい取り組みにもチャレンジしてみました。リスクベースドテストです。 今回はそこから学んだことをふりかえってみたいと思います。
冒頭のごあいさつさらっと記載しましたが、今年はテスト案件が去年に比べて大幅に増えました。
去年までは当時のQAチームメンバーでもなんとか回せる量だったのですが、今年の春頃から数か月規模の案件が並行で走り、秋頃からさらに増えて、現在は多くの案件が並行して動いています。案件が増えることは計画内だったので、今年の春頃から「案件が増えた時にそなえて、テストを考えねば」という話題はチーム内であがっていました。
そこで当時のQAチームリーダーから提案されたのが、リスクベースドテストでした。
では、リスクベースドテストとは何でしょうか。
JSTQB用語集で引くと、以下のような記述が出てきます。
リスクベースドテスト（risk-based testing）： プロジェクトの初期段階からプロダクトリスクのレベルを低減させ、ステークホルダにその状態を通知するテストの方法。プロダクトリスクの識別の他、テストプロセスをガイドする際のリスクレベルの活用もこれに含まれる。
プロダクトリスクというものを識別し…テストプロセスをガイドする…なるほどわからん。
私の理解をざっくりいうと、要はプロダクトリスク（そのプロダクトで起きてほしくない事象）の重大度と発生率を整理して定義し、それに基づいてテストする機能やしない機能を選んでいく、というテスト戦略です。
プロダクトリスクのリスクタイプやリスクレベルも、以下のようにリーダーの方で定義して頂いたので「それに基づいてテストする機能やしない機能を選んでいくのだよ」の具体的な方法を、いよいよQAチームメンバーで考えていくことになりました。
ユニファQAチームは、メンバーによってテスト設計から実装までのやり方が少し異なります。このリスクベースドテストを導入しようとしている時は、複数プロダクトにそれぞれメンバーが分かれてアサインされていました。 いつもだと、それぞれのプロダクトに合わせてメンバーがテスト設計をしますが、このリスクベースドテストを導入するなら、複数プロダクト統一したやり方じゃないとレビューがしにくいな～と考えました。
そこで複数プロダクト間である程度、統一できるやり方として、テスト観点を抽象化したリスク設定要素、基本リスクレベル、補正リスクレベルという項目を使ってみようと考えました。
リスク設定要素とはいわゆるテスト観点です。
ユニファQAチームで行うリスクベースドテストでは、このテスト観点をできるだけ抽象化したものをリスク設定要素と名付け、これに重みづけすることで「テストする機能やしない機能を選ぶ」ことをやってみようと考えました。
このリスク設定要素（テスト観点）は、ユニファQAチームメンバーの認識をそろえるため、全員参加でマインドマップを使ってブレストして決定しました。
次に基本リスクレベルです。
基本リスクレベルとは、リスク設定要素の基本的な重みづけです。
リスク設定要素とリスクタイプでマトリクスを作り、QAチーム全員で話し合いながら1～5点の間で点数をふっていきました。（5点がリスクとして一番重い点数です）
全てのリスク設定要素に基本リスクレベルとして点数を設定したら、次にそれを、プロダクトリスクレベルへマッピングを行いました。
リスク設定要素のもつ下限値～上限値を均等にリスクレベルへわりつけ、該当するリスク設定要素をマッピングして、QAチームで眺めてみました。
結果、リスクレベルとリスク設定要素の組合せに違和感はないね！ということで、基本リスクレベルの設定が完了できました。
基本リスクレベルの設定が完了しました。この後のフローとしては、機能・画面ごとにリスク設定要素をあてはめて、QA保証対象以上のリスク設定要素のみに対しテスト設計をしていく、という形にいったん整いました。
ただ機能・画面によっては、リスク設定要素（基本リスクレベル）通りにあてはめてしまうと、具合が悪いというものもあります。 たとえば、リスク設定要素の「バリデーション」や「画面UI」は、QA保証対象外ですが、機能・画面のビジネス的な重要度によっては、QA保証対象とした方がよいこともあります。
これを補うために、補正リスクレベルを使うことにしました。
補正リスクレベルとは「基本リスクレベルを見ると、QA対象もしくは対象外だけど、担当QA判断によってレベルを調整してよい」というものです。
レビュー時にレビューアに対して「ここは重要もしくは重要でないと判断したから、確認してくれ」というアピールとしても使えると考えました。
やってみた結果は以下です。
①工数はあまり削減できなかった
②短期間のテスト実行で、重要度の高いバグが検出できた
①については、もともとリスクベースドテストは「工数削減」が目的ではなく、「少ないリソースで品質を担保するためにテストするしないをプロダクトリスクに基づいて決めていく」やり方なので正しいのですが、今回は「テストしない」と決めた部分についても
という動きをしてしまい、結果、QAチームはQA保証対象外のリスク設定要素についても、なにがしかの形でテスト設計することで工数削減効果はあまりなかった、という結果になりました。
リスクベースドテスト時、工数も適正な量に抑えたいのであれば、QA保証対象外部分については「やらない」という選択をすること、「やらない」代わりに問題発生した時はどのようにするか等をステークホルダーと話し合っておくことが必要そうだな、と感じました。
②はまさに、リスクベースドテストで狙いたいところだったので、満足いく結果でした！
リスクベースドテストをやってみたのは2020年初夏～秋頃のテスト案件なのですが、現在ユニファQAチームではリスクベースドテストを行っていません。
理由としては、案件がさらに増えたため外部QA会社さんに入って頂いたりと大幅なQA体制変更があったこと、並行して複数案件が走っているので日々変わりゆく状況変化に対応することの方が、QAチームとしても重要になっているためです。
ユニファQAチームって、品質をあげるための活動は何でもできることが魅力です。 今はQA体制の安定化に力を入れていますが、いつかリスクベースドテストももっとブラッシュアップした形で取り組みたいと思っています！
ここまでお読み頂き、ありがとうございました！ まだまだコロナで大変な時期続きそうですが、体調に気をつけて、元気にQA＆テストエンジョイしていきましょうね！では！
カジュアル面談も大歓迎です！
「ちょっとならお話してあげようかな」って思われた方はWantedlyの求人ページから「話を聞きに行きたい」ボタンをクリックお願いしまーーーーーーす！
