LoginSignup
28
3

プロジェクト参画時の自己紹介の心得

Last updated at Posted at 2023-12-18

この記事はLITALICO Engineers Advent Calendar 2023 シリーズ2の18日目の記事です。

はじめに

2022年9月にLITALICOのQAとして入社した @marst_xxx です。
QAとして自動化推進をメインミッションとする傍ら、社内の単発依頼をちょこちょこ担当しております。
単発依頼など初めましてのチームとお仕事する際に、上長がQAグループのミッションについて紹介してくれるのですが、
自分たちの紹介をした現場とそうでない現場とでは、その後の働きやすさが違います。
QAやテストエンジニアとして参画するにあたり、大事だと思うことを振り返りを兼ねてまとめていこうと思います。

紹介できなかった現場

自己紹介ができなかった現場を前職で経験しました。
前職の紹介はこちら。

  • テスト会社
  • 単発・短納期の案件を主に担当
    • 初めましての現場に参画する機会が多い
    • プロジェクトの期間が短い
    • 次のプロジェクト開始までの期間が短い
    • 複数のプロジェクトを掛け持ち

チームで年間150案件前後担当していたのですが、
終始時間に追われてしまい、全ての案件で自己紹介の時間を確保できておりませんでした。

紹介できなかった現場の困り

これはどのエンジニアでも同じかと思いますが、
案件の開始時に一緒に仕事をする方とすり合わせができていないと、
その後の期待値のコントロールが難しくなることが多くなりやすいです。

見積もりのために一度説明をしていたとしても、入場前後にあらためて見積もりの内容や背景を共有する、が大事です。(案件開始までに期間が空く場合は特に。)

テスト工程は開発の後半になりやすいので、開発が佳境に入っていることも多く、事前に話した内容や送付された資料を確認する余裕がないこともあります。
テスト担当者が入ってくれるらしい、というような相手の期待の抽象度が高い状態で参画すると、案件としては成功しているはずなのに、満足度が低い = 一緒に仕事した方が「なんか思ってたのと違う」と感じる状態で終了することがあります。
例えば、現場の方はユーザー視点でテストして欲しいと思っているけど、契約内容上は仕様確認のためのテストがメインになっている、など。
自己紹介できなかった案件はこういった期待について話せないので、ずれに気づくのが遅れ、対応が後手になってしまったまま案件終了となってしまうことが…。

当時はテスト技術やマネジメントスキルを身に着けることで対応力を上げようとしたのですが、あまり目覚ましい効果はありませんでした。
技術やスキルももちろん大事なのですが、大事な場面でちゃんとコミュニケーションをとること、が何よりも大事だったなーと反省です。
お互いに期待値を確認しあって調整(=コントロール)ができれば、違和感を除いた状態で案件終了できます。

コントロールできない状態で突き進むと、心象が悪くなったり、取り返しがつかなくなったり、いわゆる沼にハマる可能性が高まります。
技術やスキルで沼から脱出することも可能ですが、違和感を抱えた状態だと印象の改善に時間がかかりやすいことが多いので、素直にお話をしてみることが大事かなと。

ぜひ案件開始前後に自分たちが今回何をしに来たのかを共有し、課題感と参画理由がずれてないかを確認してみてください。

大事な心得1

  • 入場時は「私たちはどんな課題を解決するためにいるのか」を共有する
  • そのために自己紹介やキックオフの時間をちゃんと設ける

品質やQAという言葉

そもそも、なぜ期待値のコントロールが難しいのでしょう?

ここで質問です。
ソフトウェアの「品質」や「QA」という言葉を聞いて、どんなものを想像しますか?

QAはテストをする人と認識する人もいれば、上流工程から品質活動を行う人と認識する人もいます。
品質なら、プロセス品質を思い浮かべたり、プロダクトそのものの品質を考えたり。
その人が品質やQAをどう捉えているか、今の現場ではどう定義しているか、によって認識が大きくずれます。
身近な言葉だからこそ、今自分のいる環境に影響されやすいのだと思います。

「わざわざ話さなくても、品質もQAもなんとなくわかるしなー。」
と思った時こそ、
本当にイメージや目指している方向性が一致しているのか?
をしっかり言葉にして確認することが大事です。

大事な心得2

  • 品質やテストは人や現場によって意味が異なる
  • お互いの言葉の認識を合わせよう

たとえば

LITALICOのQAグループは品質を作ったり、成長させるために様々な活動に取り組んでいますが、
最終的に開発者だけでもある程度の品質を担保できるようになった方がいいよね、としています。
そのためにまずQAが品質を安定させよう、安定させるために何が必要か整理しよう、といった感じでそれぞれのプロジェクトに参画しています。

こういったミッションを持っていることを伝えなかった場合、
テストしてくれる人がジョインしてくれたぞ!
ずっとテストしてくれるんだよね?
といった、本来のミッションとは方向性の異なる期待を抱かせてしまい、お互いの違和感につながりかねません。

違和感がある状態は精神衛生上よろしくないですし、言い換えればリスクがある状態です。
そしてこのリスク、気づくのが難しい部類に入ります。
長期間一緒に働けるなら気付けるかもしれませんが、
短期間であれば我慢してしまったり、そもそも次が無かったりします。

方向性をちゃんと伝えて、信頼関係の構築におけるリスクを早期に取り除いていきましょう。
悪化してから改善するよりも、ずっとコスパのいい対策だと思います。
人間関係もバグも、未然に防ぐのが肝要ですね。

大事な心得3

  • 信頼関係の違和感 = リスク
  • リスクは 未然 に防ぐべし

入場時に伝えたい4つのこと

とにもかくにも、新しい現場に入るときにはしっかり自己紹介をしましょう。
相互理解が深まるだけでなく、どんな仕事をする人かが明確だとお互いに仕事がやりやすくなります。

そんな自己紹介で話しておきたいことを、独断で4つに絞りました。

  • 名前(お顔)
  • 自分(たち)のゴール
  • できること
  • できないこと

名前(お顔)は良いとして、残り3つを上げた理由を簡単に説明します。

自分(たち)のゴール
どんなミッションを持っているか、何をやるのか、を現場のメンバーとしっかり話しましょう。
想いや背景を伝えることで、初めて理解できることは多いです。簡単でいいのでぜひ伝えてみてください。
何を話せばいいかわからないという場合は、まずその確認のコミュニケーションをとるところから始めましょう。確認が取れたら、ぜひグループの紹介資料を作ってみてください。
できること と できないこと
やること、やらないことでもOKかと思います。
会話した上で詳細を確認する、擦り合わせられるとなお良しです。
できること、やることはアピールポイントになりますし、伝えやすいのでいいのですが、 できないこと、やらないことは意識から漏れやすいです。
ちゃんと伝えておかないと後で困ることを事前に伝えておくと、想定外の期待をされない=正しく期待してもらえることになるのでやりやすいです。
何より、困った時に助けてくれる人が増えるので、恥ずかしがらずに伝えていきたいなと思います。

おわりに

技術の話とかしたいなーと思ってアドベントカレンダーに立候補したものの、自分が話したい話をしてしまいました。
でもこれはこれでエモいのでヨシ!
次はちゃんと技術(特に自動化)の話できるようにネタを考えておきます。

次は@akira_saigoさんの記事です。お楽しみに。

28
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
28
3