継続は力になるの?英語学習を100日間やってみた。

はじめに

仕事用に机とかいろいろ買ったけど、椅子はどうしても座って決めたいけど座りにいくチャンスが存在しないジレンマに悩まされています。こんにちは。
タイトルの通りなんですけど、英語の学習(単語の勉強)を100日間、毎日やってみることに成功したのでレポートです。

きっかけ

去年の冬から急遽、海外拠点のエンジニアが助っ人に来たPM1エンジニア2人の混成チームの一員になり、否が応でも英語と触れ合う機会になりました。(背水の陣!)
他にも、会社の若い同僚が英語学習を習慣にしている話を聞いていたので、「もちろん普段から勉強していますよね!」と言うキレイな視線に後ろめたさを感じていたので、きっかけとしてはちょうど良かったです。

目標設定

勉強らしい勉強(自己学習)は高校生以来で、読んだ英文が頭の中でカタカナの羅列になっているように感じた時から苦手意識を持っているのですが、仕事で使うのでなんとかせねばと言う感じです。
とりあえず、目標は流暢に喋るとかではなく、最低限の仕事のコミュニケーションが取れる状態(お互いが頑張れば意思疎通が出来る位)を目指しています。

と言うわけで、まずは単語の勉強を始めることにしました。(単語が分からないとストレス感じるので。)

勉強内容

使った書籍はこちら。そもそも、自分のレベルがイマイチ分かんなかったのでまずはBasicって書いてあるやつで始めました。
触った感じ、1日分じゃ少なかったので、1日30分~45分ぐらいの学習が出来るよう毎日3日分を進めるようにしました。
大体、50単語弱くらいの量です。自分は手で書いて覚える派なので毎日ルーズリーフ1ページ半くらいを書くような感じです。

ec.alc.co.jp

日本語の意味+フレーズで1周、センテンスを1周の合計2周やってみました。
3日分進めると大体3週間くらいで1周が終わります。
1周終わるとルーズリーフの数もそれなりに貯まるので達成感を感じます。

また、後になって気付いたのですが、この本は大学受験用らしいですね。 TOEIC用のがあるのは後で気付きましたが、TOEICも目標にしてないしこれでいいかってなってます。

ある程度、覚えた(気もする)ので次のテキストを買いました、同じシリーズです。

ec.alc.co.jp

これについては知らない単語ばかりだったので、日本語の意味+フレーズで2周、センテンスを2周の合計4周やってみる予定です。
(今3周目に入ったところで100日経過しました)

TOEICを受けようとするが…

本当は一月半ほど勉強した3月に、TOEICを受けて自分の英語レベルがどんなもんなのか知りたかったのですが、昨今の事情により試験自体が中止になってしまいました。
なので、この記事を書いているこの瞬間も自分の現在地を定量的に測る機会がなくなってしまったのですが…続けてます。

100日後、どうなったのか。

すごく当たり前なんですど、単語の勉強しかしてないので話せません。でもまぁ、知らない単語が出てきてそこでつまづいて後ろが全部わからなくなる…みたいな頻度が減った気がします。

また、英語の記事を読んだりしてみようかなって思えるようになったので、英語の苦手意識が少し減りました。勉強の成果をどれくらい出せるか試そう!みたいなポジティブな気持ちになれるようになりました。

あとは実戦で海外拠点のエンジニアの面接に出た時には、簡単だけど自分の思いを話して伝えられた気がします。(入社してくれたので多分伝わってるはず。)
Slackでの簡単なコミュニケーションならgoogle翻訳使わずに出来るようになったので、仕事のストレスが多少軽減しました。なので、個人的には良かったなと思ってます。

おわりに

その他にも…休みの日(特に午前中)に勉強すると、それ以降何しても許される免罪符を手に入れたような気分になるのでお勧めです。
たまにかかって来る外国人エージェントとの英語の電話のコミュニケーションが聞き取れるようになりました。(ちなみに、これまでは何言ってるか全くわからなかった。)

単語の勉強だけでも、効率がいいかは分かりませんが変化は感じ取れ、積み上げることの大事さを改めて感じ取りました。
どこまで続けるか分かりませんが、来年以降とかでこの学習の時間を他の勉強とかに置き換えてもいいかもなとは思えました。

継続は力になりそうだよーと言ったところで今回の記事はおわりにしたいと思います。

おわり。

【ポエム】最近のもやもやを供養する

はじめに

最近、普段の「なんだかなー」って思うもやもやしたことが増えてきて、何にもやもやしているのか上手く言葉にできないところがあるので時間をとって考えてみました。
なので今回は完全にポエム回です。 もやもやしただけだと、まったく建設的じゃないのでこうすればいいのでは?っていう一文も添えることでギリギリコンテンツになる…ならない気がする。そんな記事です。

もやもや1:”みんなで”解決策をディスカッションして決めたいと思います… ”みんなで”共倒れパターン

リーダーシップを取るポジションの人がノープランの時にこの手の発信をしている気がする。
また、結構な割合で「仲の良い組織を目指します!」みたいな手段が目的化してるケースが多いと思う。
結果を出せるチームは仲が良いことは多いと思うけど、仲が良くなれば結果を出せる訳ではないと思う。
こういった時は大抵、複雑な問題に直面しているのでディスカッションしてもなかなか有効な解決策がでないので多くの時間を使ってるのをみるともやもやする。
それでもって議論の末に出た、いろんな人に忖度した帯に短し襷に長しみたいな誰のためにもならない施策に残り少ない時間を使って残念な結果になるのを見ると…別の未来はなかったのだろうかみたいな気分になる。

じゃあ、どうするか。

複雑な問題に直面しているときは一つの施策でどうにかなるような銀の弾丸は無いのだから、いろいろな施策をたくさん試す必要があると思う。
ただ闇雲に打ちまくっても無意味なので、なにを大事にするかはきちんと決めるべきだと思う。
なので結果的に一部のメンバーの意に合わない決断をすることもあると思うけど、自分が決めたことを信じて一生懸命やるべきだと思う。
そういった決断を呑んでくれた人の分も含めて。

もやもや2:合議制を取った結果、とんでもない珍戦術が飛び出すパターン

これは逆にリーダーシップを取る人がいなくなったときに起きるパターン。最近の身近な例なら感染症対策に「お肉券」か「お魚券」を配ろうとか言いだすのが近いかも。
「この施策の責任者は誰ですか?」って聞くと静まり返る系のやつですね。頭を失ったゾンビみたいなオーナー不在の仕事にメンバーの時間を使うことになるのは、もやもやポイントが高い。
上手く行かなかったとしても誰も偉い人が責任をとらないのがこれの一番怖いポイント。失敗しても平気で第2、第3のゾンビを送り込んできます。

じゃあ、どうするか。

メンバーを動かして進めることに対しては責任をもって進めて欲しい。
お肉券を配る人に対して「私が考えました!絶対に必要なことなんです!」って胸を張って言えるのか、一度冷静になって考えてほしいですねー。
まぁ、そこに責任持てないから責任者不在のゾンビが生まれるのだけれど。

もやもや3:責任範囲を明確化するフリして自分の仕事じゃないアピールしてる…けどやっぱりあなたの仕事ですよねパターン

SESだったりウォーターフォールのプロジェクトにいた時は工程ごとに仕事を受けたりするので、責任の範囲は(きちんと決めていれば)明確になります。
会社間の仕事だったりするとそういうところできちんと役割を分けたり、リスクヘッジするのは分かります。自分も前職はSESだったのですごく分かります。
でもそれをやるのなら契約だったりした会社間のきっちりした間柄でやって欲しい。事業会社の中で、それも同じ部署の同僚間でそれをやるのは結構もやもやします。

しかも大抵これが起きるとき、柵で囲った責任範囲が狭い方の人が主張してるアンフェアなケースが多い気がする。 渡そうとしてるの対象の範囲が広く担当するのをいいことに、自分の仕事を少なくしようとする魂胆が透けて見えると…うーーーーんってなる。
自分のチームなら「いや、おかしいでしょ。」って言っちゃうんですけどね。(なので言わない。)

じゃあ、どうするか。

渡そうとしてる人も同じ同僚で同じ目的を達成する仲間なんだから、もうちょっと広い視野で見てほしい。
我々がやろうとしてることは、特定の範囲だけを守る仕事じゃない…と思うんですけどね。
広い範囲を持ってる人はチームの中でも難しい、大きな課題に挑んでいるんだから自分のできる範囲のボールは協力して拾うべきだと思うなぁ。

…まぁ、この手のもやもやを感じる時はそれぞれの中間じゃなくてあきらかにアンフェアな場合なので協力以前にフェアにやろうぜって感じだけど。

まとめ~もやもやの共通点を探す~

ここまでつらつらと書いたところ、共通点がありそうなことに気が付きました。
もやもやしてる時は大抵「自分の保身」に走っている人が視界にいることに気づきました。

「決められないから責任を分散しよう」

「失敗するかもしれないから責任を曖昧にしよう」

「自分の仕事さえ少なくなればいい」

みたいなやつですね。
なるほど、ちょっと理解できました。チームプレーの中で利己的なメンバーがいると上手く行かないのをこれまでの経験の中で感じ取ってるからもやもやしている様子。
個人的な気づきが得られたのでポエムを書いたのはよかったのかもしれない。
ある程度収穫があったタイミングで終わりにするのがキリがよさそうに思えたので、この辺で終えようと思う。

おわり

なぜQAとして発信するのか考えてみた話。

はじめに

自分が勉強会の登壇や、外部への発信をやっている理由は端的に言うと「同じ価値観を持つ仲間に知ってもらいたいから」だと思っています。
理由として「同じ価値観・経験を持つ人」が業界の構造としてかなりの少数派であることが挙げられます。今回はそこら辺のことは短めの文章で書こうと思います。
※あくまで個人の見解です。

目指している姿

スクラムチームのエンジニアの理想像は「T字型人材」だと考えていて、開発チームにおけるエンジニアの枠組みの中にQAエンジニアも含まれていると思っています。
なので、スクラムチームがswarmingするときは開発だってするし、仕様検討だってするし、テストだってする。
その中で「一番得意なのがテストだよ」…っていうようなエンジニアをQAエンジニアとして考えています。

参考:Swarmingとは スワーミングがアジャイルチームを助ける

日本のIT業界におけるQAエンジニア人材

といいつつ、こういったエンジニアは少なくとも自分の会社のカジュアル面談の場にはほとんどやってきません。そもそも、QAエンジニア・テストエンジニアの人が少ないです。
PRや採用側の問題…とかもあるかもしれないのですが、日本のIT業界は責任範囲を明確に絞り、その領域に特化した人材で開発を進めてきたこと…とかも理由として考えられます。面接に来ていただける候補者の多くがテストの設計と実行の経験だけという場合が多く、計画や評価を含めたすべてのテストプロセスを担当した経験がある人の方が少ないように感じます。
※テストプロセスについては下記に載せておくので興味があったら参考リンクをご確認どうぞ。

JSTQB TestAnalystにおける テストプロセス

  • 計画、モニタリング、およびコントロール
  • 分析
  • 設計
  • 実装
  • 実行
  • 終了基準の評価とレポート
  • 終了作業

JSTQB認定テスト技術者資格-シラバス(学習事項)・用語集-

そのため、経験領域と目指している姿にギャップがあるのは分かった上で、難しい採用活動を進めているのは理解しているつもりです。
しかし、(あくまで自分が見える範囲の)海外に目を向けてみると目指すべき姿とマッチした経験をもった人は日本よりはいるように感じています。
ISTQB Agile Testerを取得できる国もあるので、そういった部分も関係があるかもしれないですが、計画からレポーティングした上で、継続的なテストの推進を経験してる人…とかもたまにいる印象です。

なのでどうするか(まとめ)

グローバルな観点で言えば、海外の品質保証のスタンダードを取り込みながら働くべきだと思っています。
そうしないと独自の品質保証の仕組みを推進した結果として、今度は海外でメンバーが取れなくなるリスクが発生するからです。
なので、日本における採用は経験を持つ人が少ないのは認めた上で、同じ価値観の人に来てもらうしかないかなと考えています。

やったことないのであれば覚えればいいし、そういった成長込みで仕事をするメンバーと一緒に働けたらいいなぁと思っています。
なんでもやるような「T字型人材」を目指すような人に向けて今日も発信していこうと思っているので、引き続きよろしくお願いします。

おわり

JaSST'20 Tokyo RejectCon 登壇の裏側レポート

ブログに書いて欲しいというネタが複数あったので、今回の記事は個人ブログの方に書くことにします。
来る2月3日(節分ですね!)に開催されました。「JaSST'20 Tokyo RejectCon」という勉強会で登壇してきたレポートになります。
個人ブログの方がもう少しフランクに書けるのかな…文体が安定しないので、変わらないかもしれない。

概要

connpass connpass.com

ブログ枠の方のレポート qiita.com

masskaneko.hatenablog.com

勉強会全体のレポートについてはブログ枠の方が発表していますので主に自分の事について書こう。

はじめに

今回の発表は @tsueeemura さんからお誘いいただきました。
TwitterのTLで開催することは知っていましたし、今年はTokyoに出してないなーぐらいに思っていましたが、対面でお誘いされたので断るなんてことはできません。
加えて「なんでも大丈夫です!!」と強く言われたので、なるほど…それなら一昨年に出してダメだったやつでも大丈夫だなということで参加を決めたのでした。

勉強会自体はみなさん各々の話したいことを発表されていたので、いい意味でRejectConっぽくない勉強会で楽しい感じでした!
実際に勉強会に行ってみてRejectConっぽい発表が自分くらいしかしてなかった…気がするので無駄な心配でした。

実際の発表

speakerdeck.com

発表で使った資料は上記ですが、結論から言うと一昨年に出した内容を発表するのってすごく大変でした。

大変だった理由

  • 思い出す&過去の失敗をリカバリするのが大変
  • RejectConとはについて悩む(構成について悩む)
  • 普通に忙しくて大変

思い出すの大変&過去の失敗をリカバリするのが大変

そもそも事例発表のアブストを提出したのが2018年の秋なので一年以上経過しているわけで、まずは過去のアブスト引っ張り出してくるのに苦労し…加えて過去のものを読み直してみると色々粗があるので、発表に足りる内容まで昇華することが大変でした…。
びっくりしたのが、過去の自分が「健康診断に例える」と銘打ちながら肝心の健康診断は一部分で、アブストの中で話したいことは主にアジャイル開発と品質の捉え方の話をしている訳ですね…。

当時の自分は新規性だったりキャッチーな内容を散りばめたかったのでしょう。
(健康診断の件は結構いろんなところで言われてますけどね…。 ) 過去の自分と対話しながら、当時どういうことをしたかったのかを思い出しながら、今の自分だったらこうする…みたいなのを混ぜながら今回の発表を作りました。

…ちなみに普段の仕事でCIサーバーをいじってる時は逆のケースもあり、過去の自分の残してくれた崇高なドキュメントを見ながら、過去の自分が思い描いていた理想を現在の自分が追いかける…みたいなこともたまにありますw

RejectConとはについて悩む(構成について悩む)

JaSST北海道にでて分かったことはJaSSTは学術的なイベントだと感じたので、普段の勉強会より真面目な印象を持っています。
なので、その真面目モードの発表をそのまま持ってくるのは果たしてRejectConに本当にふさわしい内容なのかと悩みました。

Rejectされた内容に対して勉強会の参加者が得たい情報ってなんだろう」…と。

とか真面目に悩んだ結果、以下の内容を発表に組み込むことにしました。

  • 不採択の理由を含めて振り返り、発信する
  • 具体的な事例よりも伝えたいエッセンスにフォーカスする

1つ目は事例を出したい人が参加するかもしれないので、その人に向けて情報が残ればいいなぁという思いがあったので組み込みました。
2つめについては実際に事例発表の場でないので、本来厚めに語る具体的な施策・事例の部分だったりといった部分を削減することで伝えたいことを残しつつ15分の発表に押し込みました。

結果としてはRejectConっぽい発表だけど、事例発表っぽくない発表になったので大筋で思惑通りです。
あとはAutifyさんにゴマすりもできたので完璧。

普通に忙しくて大変

結構安請け合いしちゃうタイプなので自分のリソース管理は苦手です。
そんな中、社内の勉強会(ほろよいてっく)に向けたLTつくって、今回の登壇資料作って、QAメンバーのAL取得のためのテスト技法勉強会の準備したり…この頃は普段の仕事以外のタスクを引き受けすぎました。
本当に間に合うか怪しい瞬間もありましたが、無事に発表できてよかったです。
とはいえ、結果的にどれもある程度良い結果になったので必要だと思ったことはこれからも引き受けちゃう気がします。

まとめ

最近、自分の忙しさにかまけていたせいか参加も含めて久々の勉強会の参加となりました。
別の会社のQAエンジニアの人とお話したり、自分が企画した勉強会の話をして頂いたりと、普段の仕事とは別の刺激になりました。
こういった活動は大事にしていきたいと遠のいていた自分に反省をしつつ頑張ろうと思いました。

おわり

2019年の振り返りと2020年の目標作成

はじめに

2019年も残りわずかになったので、2019年の振り返りと2020年の目標を書く投稿を準備しておく。
2020年の終わりに見て、どれくらい達成できてるか見ると楽しいかもしれない。

2019年の目標を振り返る

2019年にやりたかったことをつらつら振り返る。
毎年、自分はやりたいことをいくつか用意していて、その中でいくつかできたら嬉しいなーくらいの温度感で実施している。
今年の目標を一言で言うと、「自力をつける」みたいなイメージ。

QAチームリーダーをしているので、ある程度やってみせたり、仕事の振る舞いや自分の背中を追いかけてくれる人がいる。
そういった人たちにとってQAエンジニアとして恥ずかしくない人になりたかったというのが理由の半分。

もう半分はスクラムチームが求めるT型人材という名のフルスタックエンジニアになりたかったというのがある。
未知の問題に対しても苦しみながらもきちんと成果をとって来れる、そういう人になりたいっていう漠然とした目指したい姿を持っていて、過去に自分を引き上げてくれた先輩エンジニアの背中を追いかけているのでした。

◎:JSTQB ALの取得

2月にTest Analyst試験 合格 8月にTest Manager試験 合格 まさか両方取れるとは思わなかったけど、日々の積み重ねが試験勉強の範囲をカバーしてたのかな。
TA試験の勉強方法についてブログを書いていたので、TM試験についてもそのうちブログを書きたい。

◎:認定スクラムマスターの取得

7月30-31日にScrumIncの認定スクラムマスター研修を受講(LSM)。
スクラム開発に携わってかれこれ5年くらいになるので、とりあえずこれまでの棚卸しを兼ねて形にしておきたかった。
まさか自腹で研修費を支払うことになるとは思わなかったけど…。

◎:JaSSTの登壇

8月30日のJaSST北海道でスクラム開発と品質保証と言うテーマで登壇。
QA×スクラムマスターの働き方について事例発表を行った。
スクラムマスターとQAの働き方は親和性ありそうなので、他の人もそういった人が増えている…のかな?

teamspirit.hatenablog.com

△:コードが書けるQAになる

GWを使ってTech CAMPのイナズマコースを受講。
Ruby on Railsを使って簡単なMVCのWebアプリを作れるようになった。
何かフレームワークを覚えたいなと思っていたのでまとまった時間を使って取り組めたのはよかった。
その後、カスタマーサポートに異動になったり、リーダー業の比重が高まってコードを書く機会が減ってしまったのはちょっと残念。
来年は業務以外の個人でE2Eのテストコード書いたり、新しいアプリ開発してみるのも楽しいかなとか思っている。

作ったもの
github.com

また、Salesforceの標準機能を使った機能開発とかする機会があったので、仕様検討と設計とかの業務をすることができた。
仕様検討→設計→実装→テスト→ドキュメンテーションの流れを一人でできたのはとてもよかった。

△:英語学習

2019年になって、海外拠点のメンバーとの会議や仕事をする機会が増えた。
1時間まるっと自動テストについて会議したり、1ヶ月間同じチームになって一緒にバックログ作ったり仕様検討したりした…。
相手側もゆっくり話してくれたりしたおかげでなんとかなったけれど、現状のままでは非常に厳しいというのを痛感した。
そして、リスニングはもちろんだけれど自分の話したいことを伝えるには圧倒的にスピーキングの練習が必要だと感じた。 来年はこういった機会がさらに増えそうなのでもっと頑張らないとなぁ…。 

2020年の目標を定める

2020年も引き続き「自力をつける」は継続の予定。
QA系は新しいスキルと言うよりも新たな分野に挑戦するような仕事をしたい。
あとはスクラムチームの外に対しても影響力を発揮できるようなエンジニアになりたい。

Salesforce系の資格を取る

2019年はカスタマーサポートを通してSalesforceの知識をいろいろつけることができた。
きりの良いところで形にしておきたい。

認定プロダクトオーナーを取る

スクラムチームのメンバーに対して認定スクラムマスター研修はすごく役に立った一方で、スクラムチームの活動についてステークホルダーにきちんと理解してもらったり、最終的な判断を下すPOの力になることでもっと良いチームになるかもと思ったので2020年は認定プロダクトオーナー研修に行きたい。

コードを書く

自分の働き方としては、仕事でコードが書ければ一番嬉しいことなんだけれど、周りから評価される・求められる働き方が違いそう。
スクラムマスターやったり、QAチームの仕組みを作ったり、困っているチームのスポットのヘルプに入ったり、スポットの特設チームの立ち上げしたりするとこを求められたりする。
場合によってはそのうちプロダクトコードの修正したり自動テスト書いたりも求められそうなので、きちんと準備しておく。
2019年はRubyだったけど、2020年は今のチームが使っている言語・フレームワークについて理解を深めることはしておきたいなぁ。

ブログを書く

2019年はほとんどブログを書かないで一年が終わってしまった。
2019年の後半では自分の思いや考えている施策について発信する機会が増えたので、あらかじめきちんとまとめたり・書いてあったりしたら便利なのでブログとかに残しておきたいなぁと思っている。

英語教育

これはまずいと思ったので英語力のベースアップを頑張る。
正直、自分の英語力はあまりにもひどいので、何をやっても前進しかなさそう。
なのでとりあえず、単語の勉強と英会話の機会を増やして自分の中で文章を構成するトレーニングを行いたい。

映画を楽しむ

ここまでカタめな話だったので、趣味の話。
毎月、映画館で映画を観る人は趣味は映画と名乗っても良いそうなので映画についても感想だったりを書けたら良いなぁ。

終わりに

と言うことをつらつら書いてたら2019年も残り1分だということなのでここら辺で一区切り。 2019年は仕事としてはとても躍進したので、2020年も同じ勢いで進んで行きたい。

おわり

2019年に学んだ「意思決定」の際に大切にしていること

はじめに

12月も下旬に差し掛かろうとしているので、この機会に本年の振り返りを行い、頭の中も整理しようということで備忘録を兼ねて投稿。

 

QAチームのチームリーダとして役割を担い始めたのが2018年の12月なので、今年は丸1年リーダー業をなんとか実施することができた。

あらためて今年を振り返ってみると、2019年は否応なしに「意思決定」を求められた一年だったと思う。
QAチームのリーダーをやりつつCSチームに異動したり、タスクフォースを1年間継続させるために奔走したり、これまでに実施したことないプロジェクトを成功に導くためには全体の流れを自身で描きつつ問題に対して解決策を実践することが必要で、その時々で重要な意思決定を迫られる場面が何度かあった。

思い返すと、上手く行ったものや、別の手があったかもという筋の良くないものもあったが、何度かそういった意思決定を繰り返し経験をすることで、自分の中で重要なポイントみたいなものが存在することを朧気ながら感じた。

今回は大事だと思ったポイントや考えについて、共感した書籍・ブログ記事等を紹介しながら書き残すことにした。

  

 

 

素早く決める。決断のハードルを下げる。

普段過ごしているチームの開発手法であるスクラムはよく分からない事(不確実性)に対してアプローチする手法だと考えている。

仮設検証を短いサイクルで回しフィードバックを受けることで、目的に対してその都度方針を修正しながら大きな目標に向かっていくフレームワークだと思っている。
そのため大事なことは、方針を素早く決める(仮説検証サイクルを回すこと)だし、決めた後もその都度修正するものだからこそ、選択自体に時間をかけないことは重要だと思っている。

意思決定の速さみたいなのはSmartHRの代表、宮田昇始さんのブログはとても共感できたので非常におススメ。(この記事は短いのですぐ読める。)

また、やってみるとわかるのですが、ミスって変なものを頼むことは少なく、結果に差を感じないんですよね。逆に、熟考しても失敗することはある。よく『 "5秒で考えた手" と "30分かけて考えた手" は、実際のところ86%が同じ手である』と言いますが、「熟考しても結果に大差はない」「結果が悪くても大したことない」ということを日常的に刷り込むのがいいのかなと思います。

 

blog.shojimiyata.com

 

 

選択の先を見極める。「不可逆な意思決定」は慎重に検討する。

では何でもかんでも素早く判断すればいいんだっけと聞かれたら、自分の答えはNoだ。
なぜなら、一度判断したら取り返しのつかないことや撤回することができない選択も中には存在するからだ。


重要なことは先ほど書いた、「素早く決めるもの」と「慎重に決めるもの」を見極めることだと思う。

 

前の項目で書いた通り、「素早く決めるもの」=「後で修正できること」だと思えば分かりやすい。

では逆に「慎重に決めるもの」は何だろう。自分の中では下記のブログの「不可逆な意思決定」というのが自分の中でしっくり来たので紹介したい。

不可逆な意思決定とは、一言でいえば、「一度決めて前に進めてしまうと、簡単に元の状態には戻せない意思決定」のことです。スタートアップにとってはまさに資本政策がそうですし、価格を下げる意思決定なども(価格は一度下げてしまうと上げずらいという意味で)不可逆な意思決定に当てはまると思います。

 

medium.com

 

他にも、普段自分が大事にしなければいけない観点も「慎重に決めるもの」に含まれると思う。

例で言うと、QAエンジニアなら「人・モノ・カネに関係するテスト」は繊細に扱うテーマなのでこう言ったものも判断材料を集め、慎重に検討する意思決定の類だと考えられる。

 

 

勇気と蛮勇 ~重要な決断で犬死はしないこと~

不可逆な決断や重要な決断をするときに大切なことは、適切なタイミングや目的に即した決断なのか客観的かつ冷静な判断が必要だ。

2019年の自分はあまり出来なかったと思っている部分だと考えている。
結果として、自分に起きる変化・影響は考えられてもチームのメンバーの影響やもっというと周りがどう思うかまでは考えが至らず、多大なる迷惑をかけ失敗したこともあった。

実際、仕事上の決断なので命までは取られないのだけれど、危機的状況の中でも冷静な判断を下すということはすごく難しい。

そういったメンタルや心の在り方について、新渡戸稲造は「武士道」の中で「勇」として言及しており、とても参考になった。(できるとは言ってない。)

下記は書籍の中の水戸光圀の言葉

「戦場に飛び込み、討ち死にするのはいともたやすきことにて、身分の賤しき者にもできる。生きるべきときは生き、死ぬべきときにのみ死ぬことこそ、真の勇気である」 

武士道 | 新渡戸稲造著 岬龍一郎訳 | 書籍 | PHP研究所

  

 

聞こえの良い理想だけではなく、現実を生きるために覚悟を決める

危機的状況に陥った時や、あるべき姿と現実が乖離している場合、なんらかの手段を講じる必要があるのだけれど結構な割合であるべき姿、理想に向かって一直線に進もうとした結果、上手く行かないケースをよく見てきた。

そうしたケースは理想と現実の乖離があまりにもかけ離れている場合がほとんどで、その時の急場をしのぐ最善の手段になっていないからだ。

大事なことは急がなければならないのはもちろんだが、焦らないことこそが重要だと思えるようになった。
理想と現実の乖離を埋めるため、決定したことを実現するために、耐え忍びながら変化していくことを受け入れる必要がある。
現在の課題を一気に解決してくれる銀の弾丸は無いし、忘れがちな当たり前のことを積み上げていく意識をすり合わせすることの大切さを学んだ。

 

ちなみに、改革をテーマにしたときに戦略企画室の方に「上杉鷹山」についておススメされたので本を読んでみたところとても共感できたので紹介しておく。

備えのほうは予定通りには進まない。そのうちに困難な事態のほうが先に押し寄せてきてしまう。これに対してどうすればよいか。

有効な手段などあるはずがない。最善の方法がなければ、次善、三善の策を、それもなければ、少なくとも最悪でない方法を取るよりほかにはあるまい。

www.mikasashobo.co.jp

 

また、本の中で鷹山の根底にあるものは以下と書かれており、TeamGeekのHRTを思い出した。

米沢藩における鷹山の政治および経済政策は、ただ施策として優れていたばかりではない。その底には、鷹山の無比の誠実さと謙虚さ、そして人々に対する地合いの心がゆるぎなく根を下ろしていた。

 

HRTとは

  • 謙虚(Humility)
  • 尊敬(Respect)
  • 信頼(Trust)

www.oreilly.co.jp

 

 

おわりに

つらつらと思ったことをいろいろ書いた結果、結構な量になってしまったけれど、普段自分の意思決定がどのように考えて、何を大事にしているかみたいなのの一片をアウトプットできたのは個人的にはよかったかなと思う。

 

重要な決定をした後は、その選択を正しい結果に進むように努力する必要があると思っていて、そのためにチームリーダーは、協力できるための仕組み・環境を整備したり、意思決定のプロセスがメンバーが納得できる説明・透明性を確保することなんだろうなぁと思っている。

もちろん自分もスクラムチームの一メンバーでもあるので、最後に自分が大切にしている「銃士の姿勢」を紹介にして終わりにしようと思う。

大事な決断って結構メンタル削られたり、不安だったりするのでそういう人を見かけたら一緒に共犯になって片棒を担ぐようにしている。

開発チーム(とスクラムチーム!)のメンバーは、三銃士と同じ姿勢を持たなければならない。「ひとりはみんなのために、みんなはひとりのために」である。この銃士の姿勢は、仕事を成し遂げる責任をチームメンバー全員が負うという点を強調する 

 

www.amazon.co.jp

 

おわり。

 

 

 

以上の記事はチームスピリットアドベントカレンダーのExtra Post枠(控え)

adventar.org

 

 

QAからCSへレンタル移籍をしてきた話

はじめに

プロフィールでは「スニーカー好きのQAエンジニア」と書いていましたが、若干訂正があり…。
実は2019/06/10 ~ 2019/10/31のおよそ5か月の間、社内のカスタマーサクセス(CS)チームへレンタル移籍に行っていました。
なのでここ5か月弱くらいはほとんどカスタマーサクセスサポートがメイン業務でしたので訂正しておきます。
とはいえ振り返ってみると、QAエンジニアとしてはとても良い経験だったのでここに書いておきたいと思います。
(また、11月からはQAエンジニアとして再始動です。)

レンタル移籍の経緯

件のチームメンバーの退職&産休が重なり、局所的にメンバーが不足するということで、ヘルプのメンバーの招集がかかり、開発チームから自分とバックエンドエンジニアの二人でヘルプに行くことになった。
他の職種にチャレンジする際の注意事項として、伝えたいことは一言だけです。

望んだメンバーだけ行くべきで、絶対に他人に強制してはならない。

今回はチャレンジに前向きなメンバーでヘルプに行ったため、二人とも非常に実りがある時間を過ごすことができました。
一方でもしそうでない場合は、トラブルになりかねない出来事だと思うので要注意。
ホントに注意。

CS(Customer Success)チームの仕事内容

Salesforce上のアプリケーションなのでユーザーのシステム管理者からComunity Cloud上であげられるサポートケースの調査・回答がメインの業務として行いました。
開発チームでの詳しい領域(勤怠管理)のケースを中心に割り振られて回答していました。
その他アカウント管理や、データ修正もあわせて実施。

この辺りはQAエンジニア前の前に運用プロジェクトのエンジニアとして働いていたこと、サポートチームが手厚い研修をしてくれたため、比較的すんなりと働くことができました。
また、偶然二人で行く形になったのですが、同じ境遇の同期(厳密には違うけど)がいるのはかなり良かった。
分からないながらも助け合うことができたり、互いにレビュー等ができたので、それもまた良い方向に作用したかなと思っています。

よかった事・悪かった事

〇:ドメイン知識がついた

サポートケースに回答する以上、質問を正確に理解して正しい回答をする必要がある。
製品に関する知識、Salesforceに関する知識、勤怠管理にまつわる業務知識、が質問者と同等の理解にないとケースには回答できない。
そのため、検証環境を用意して、実際に問い合わせ内容が再現できるか・案内した手順が実施できるか検証を行う。
この仕事は開発でのバグの再現確認等とかなり近しい仕事に感じられた。

違いとしては、QAの時はある程度で調査を切り上げてfixを担当するメンバーに任せることができたが、原因を突き止める(回答として伝えられる)まで調べる必要があるのが大きい。
結果としては粘り強くやることや、限られた時間の中で戦略的に進める力が養われ、自信の知識を整理やさらに深めるために有意義な時間となった。

〇:ユーザーの声が聴ける

人事や総務が片手間で対応する場合や、システム開発部の担当などシステム管理者といっても様々な属性があることが分かった。 そして、作る側にとって難しい仕様は大抵ユーザー側も理解するのが難しい機能になるということが認識できた。

また、ユーザーにとって、問題が製品部分なのか自身のブラウザやネットワークなのかは関係なく、「機能が使えない」という一つの状態になってしまう。 そして、往々にして状況を切り分けるための情報が足りていないことが多い。
そのため、サポートで切り分けやある程度は相手の気持ちになって状況の推理する必要がある仕事だということが分かった。
(ちなみに変に勘ぐってしまい検討違いの回答をする可能性もあるので、思い切ってきちんと状況を整理する等のコミュニケーション力も必要)

〇:様々な背景のメンバーと話せる&仲良くなる

前職で人事の営業だったり、歴戦の導入メンバーだったり、普段開発チームにはいないようなメンバーと話す・一緒に仕事をすることができた。
日々の会話の中で新しいインプットが入ってきたりすることで、また別の刺激になった。
サポートケース対応がないときは、仲良くなった営業メンバーが使う資料のデモ画面の準備を手伝ったり、開発メンバーの時とは違った種類の差し込みタスクは新鮮。

×:引継ぎは計画的に

突発的に移動してしまったので、残されたQAメンバーに負荷を与える結果になってしまい、本当に申し訳ないことをしてしまった。
本当に申し訳ない気持ちでいっぱいです。
結果的にお詫びの肉をおごることで難を逃れたが、きちんと仕事の引継ぎはするべきだと思いました。
あれ、でも…自分も肉おごられても良いのでは…。

まとめ

QAエンジニアに必要なスキルとしてはテストの技術といった「テクニカルスキル」のほかに「ドメインスキル」が重要だと思っている。
そういう意味でいうと製品のドメインや顧客の属性など様々な情報をインプットすることができたので非常に有意義な時間を過ごすことができた。

一方で、有意義な時間を送れたからといって全員が同じ経験をすべきかというとそうでないと思っている。
CSチームでのやりがいはお客様の成功(カスタマーサクセス)を通して感じれるかどうかがポイントになりそうだと思った。

自分の場合は、困っているシステム管理者がケースを通して課題を解決していく姿に立ち会うことで開発とは違ったやりがいや仕事の意義を見出すことができた。

一方で、開発チームとしてのやりがいというのは難しい機能・案件をリリースしたりチームに貢献したりすることで感じる部分だと思っている。 なので、互いにやりがい・難しいポイントが違うからこそ、合わない人が同じ経験をしたところでなんの実りにならない時間を過ごすことになってしまうので…要注意。

QAエンジニアの自分としてはとても良い経験だったので、ちょっと伸び悩んでて興味がある人はあえて新しい環境に身を置くことで新しい発見があるかもしれないと書いておく。
ただ、望んだメンバーだけ行くべきで、絶対に他人に強制してはならない。という一言に尽きるかなと思う。

【おまけ】QAエンジニアとしての活動+その他

CSチームに所属しながら…

勉強会を開いた&登壇したり…

【増枠】QuALiTy~QAエンジニアによるLT大会~ - connpass

speakerdeck.com

認定スクラムマスター研修受けたり…

会社のオフィスの引っ越しをしたり…

www.teamspirit.com

JSTQBテストマネージャ試験受けたり…

JaSST北海道で登壇したり…

speakerdeck.com

してました!
(意外といろいろやってた)

おわり