第一回 Yayoi (Engineer) Beer Bashを開催しました!

こんにちは。弥生でエンジニアをしている宮崎です。
普段の業務では、オンライン会計サービスの開発を担当しています。
(興味のある方がいらっしゃるかわかりませんが、好きな勘定科目は「通信費」です。)

今回は10月に開催した「第一回 Yayoi (Engineer) Beer Bash」の様子をお届けします!

Yayoi (Engineer) Beer Bashとは?

Yayoi (Engineer) Beer Bash は、オフィスでピザやビールを楽しみながら交流する社内イベントです。*1
LT枠を用意しているので、興味のあることを発信したり発表練習をする場としても利用できます。
イベント名に(Engineer)とありますが、エンジニア以外の参加や、技術と無関係なLTも大歓迎です。

気軽に情報発信やイベント参加を楽しんでもらいたい!という想いから、以下を目的として開催しました。

  • 弥生のエンジニア同士のコミュニケーション促進
  • 情報を発信する文化の促進
  • 情報発信やイベント開催、イベント参加のハードルを下げる

第一回だけで終わらせず、今後も年に数回ほど実施していこうと計画しています。

第一回Beer Bashが開催されるまで

2023年春に社内の勉強会について検討する会ができ、そのメンバーでBeer Bashを企画しました。
余談ですが、私が「勉強会とかスキルアップを検討する場ができたら参加したいのですが…」とCTOに相談し、興味のある方に集まっていただいてできた会です。
相談してから「やりましょう!」とメンバー募集が開始されるまで30分足らず。
思わぬ急展開にびっくりしつつも、やりたいことを後押ししていただけてとても嬉しかったです。

そこから、こんな勉強会があったらいいな、という意見を持ち寄ったり社内でアンケートを取ったりして、いくつかの案の中から採用されたのが今回のBeer Bashです。
学びよりもコミュニケーションを重視しているので勉強会らしさはあまりありませんが、技術イベントへの参加や社内の情報共有の活発化につながればいいなと考えて実施しました。

運営も気軽に参加できるイベントがいいよね、ということで準備は最小限に。
動ける人ができる範囲で動く方針で進めました。
個人的には、どんなトッピングのピザを注文するか選ばせてもらったのが楽しかったです。

当日の様子

イベント当日は20名前後の方に来ていただきました!
ピザを食べつつLTを聴いたり、ビール片手におしゃべりしたり、思い思いに楽しい時間を過ごしました。

ちなみにLTのテーマはこんな感じです。

  • コーヒー沼極まってきた人が考えていること
  • はじめまして、ラーメン二郎
  • 私の好きなキングダムのシーンをシェアするよ
  • 真の男を目指す、おまえたちへ
  • 2年間マニキュアをつけている私が、マニキュアを付けていない人に伝えたいこと
  • Anyflowハジメマシタ
  • 勝負(ギャンブル)における心理戦とビジネスハック

内容はご想像にお任せします。仕事と関係あったりなかったり。
参加者の方から「このくらいの内容でいいなら発表すれば良かった」「次回はLTやりたい」と言っていただけて、開催して良かったなと思いました。

今後に向けて

当日の様子や参加者の方々の声から、第一回としては成功だったと感じています。
今後は、オフィスに来られない人もリモートでBeer Bashに参加できる仕組みを考えたり、LT初心者の人も手をあげやすい雰囲気を作っていきたいです。
社外カンファレンスやもくテク*2の登壇はまだ勇気が出ないけど、Beer BashのLTなら挑戦できるかも…と思ってくれる人が増えると嬉しいです。

次回は私も発表する側になってみようかな…?

一緒にはたらく仲間を募集しています。

herp.careers

*1:お酒が入るので業務外の扱い

*2:弥生が運営する技術勉強会

WebディレクターがUXデザイナーにキャリアチェンジした話

この記事は 弥生 Advent Calender 2023 の11日目の記事です。

弥生株式会社の "1000old" です。

他のメンバーに乗っかって好きな勘定科目を挙げると、私は「広告宣伝費」です。
これまではずっと Webディレクター だったので、Web制作費や外注費などはこれで処理されていたのかなと思うと、ときめきを感じずにいられません。

ちなみに、弥生では Webディレクター ではなく UXデザイナー をやっています。
近ごろ、WebディレクターのキャリアアップにUXデザイナーを推す記事などを見かけますが、私の実感ではキャリアアップというよりキャリアチェンジに近い印象です。

私自身、弥生から声がかかるまではUXデザイナーを選択肢としてあまり深く考えていなかったのですが、面接で話を聞くとWebディレクターとしての経験が結構使えるのでは?とアピールしたので今がある、といった感じです。

今回は、同様のキャリアチェンジを考える人の背中を押すべく、実際の状況などをまとめてみます。
一緒に働く仲間が増えてくれたらいいなぁ、という願望も込めて。

バックグラウンド

まず、私のバックグラウンドを簡単にまとめておきます。

  • 情報系学科の大卒でプログラマーを目指すが、派手にバグを出しメンタルと天狗の鼻が折れる。
  • 自社のWebサイト制作をきっかけにWeb業界へ。
  • 当初はWebディレクターの定義自体が明確ではなく、結局全工程を担当できる一人親方状態に。
  • 某レンタルサーバーの管理画面の設計経験があり、UIやUXの基本的な知見はある。

ここからは、Webディレクターに必要と言われる一般的なスキルが、UXデザイナーではどう使えるかという点を中心に整理してみましょう。

調整・コミュニケーション

調整・折衝先がお客様と社内の違いはありますが、どちらも綿密なコミュニケーションを求められます。

コミュニケーション
職種 業務内容
Webディレクター お客様の夢をヒアリングし、予算・工期との折り合いをつけるために、あの手この手で調整する力が求められます。
UXデザイナー 社内とのコミュニケーションが多くなります。
あらかじめPBI(プロダクトバックログアイテム)などで定義された機能を画面に起こしたあと、UXの重要性を粘り強く説明し、エンジニアさんにゴキゲンに仕事をしていただく必要があります。

企画・プレゼンテーション

どのようなアウトプットでプロジェクトを成功に導くのかを考え、見せるという点は、両職種に共通しています。

プレゼンテーション
職種 業務内容
Webディレクター Webサイトの目的や目標から完成形を、どれだけファンタジーに見せられるかにかかっています。
UXデザイナー ユーザーにどんな成功体験をさせるか、サービスの世界観、魅力をどれだけわかりやすく言語化できるかが腕の見せどころになります。

課題抽出・分析・仮説・検証

方向性や成果物は異なる部分があるものの、プロセスや使用する情報、仮説・検証の流れなど、外から見るほど大きな差はないというのが実感です。

分析

なお、ABテストはUXデザイナーが中心と思われがちですが、Webディレクターもテストツールによるコンテンツ出し分け検証を行ったりしますし、CTAボタンの配置やデザインなど、コンバージョンにつなげるためにUX的な観点を取り入れたりします。

職種 業務内容
Webディレクター ターゲットユーザーの分析からデモグラフィックレベルのペルソナ定義、カスタマージャーニーマップの作成などを行います。
そして、解決したい課題から仮説を立て、アクセス状況などをもとにそれを検証し、提供するコンテンツなどを検討、ワイヤーフレームを作成します。
UXデザイナー ターゲットを知るためにペルソナをサイコグラフィックレベルまで深掘りし、画面遷移に沿ったカスタマージャーニーマップを作成します。
そして、ユーザーの成功体験を実現するために仮説を立ててプロタイプを作成し、テスターを使って検証後、さらに改善を進めます。

Web制作・デザインの知見

一緒に仕事をする人にもよりますが、さまざまなバックグラウンドはどこかで必ず活きてきます。

検討過程
職種 業務内容
Webディレクター もともとコーダーやデザイナー経験を持つ人が多いので、ディレクション側に回っても、成果を上げられるアウトプットのクオリティに気を配ることができます。
UXデザイナー コーダー経験があるとエンジニアさんと会話がやりやすくなるし、デザイナー経験があるとピクセル単位での調整の根拠を言語化できるので、説得力が上がります。

スケジュール管理・マネジメント

両職種とも、スケジュールとアウトプットの進行状況に注意を払うことが求められます。

交通
職種 業務内容
Webディレクター 管理系の仕事が大半を占めるかもしれません。スケジュールされた公開日を遅滞なく守るために、進行を管理してメンバーを効率的に動かすスキルが必要です。
UXデザイナー スクラム開発の進行に合わせてアウトプットを準備したり、デザインスプリント1による仮説・検証プロセスの実践するなど、工程全体を俯瞰したマネジメントが必要になります。

使わなくなったスキル

予算管理

Webディレクターは、予算交渉、見積書作成などで地味に時間を削られますが、今はお金の話をすることがなくなりました。

SEO

Webサイト全体のUX改善となると話は別ですが、現在は契約中のお客様に提供する画面を設計しているので、SEO観点でキーワードなどを意識したライティングは不要になりました。

ただ、UX的な観点でターゲットに最適なライティングを心がけるようにしています。

追加で必要なスキル

Figma

これまではWebサイトのページ遷移を見せるだったのでAdobe XDで十分でしたが、プロトタイプを動かしてテストまで、となるとFigmaは欠かせません。私も改めて習得しました。

そもそもAdobeがFigmaを買収し、XDもFigmaに収斂していくので、今後はWebディレクターでもFigmaのスキルは必須になるかもしれません。


【2023/12/22 追記】
本記事公開の約1週間後に、AdobeがFigma買収断念との報道がありました。
終了に向かっていたAdobe XDの今後は不透明ですが、いきなり高機能になって復活することは考えにくいので、Figmaのスキルが必須であることに変わりはありません。

やはりキャリアアップではなくキャリアチェンジだ

ここまでいろいろ書きましたが、WebディレクターとUXデザイナーは、ブラウザでお客様の課題を解決するという根底の部分が同じなので、どっちが上とか下とかではなく、やはりキャリアアップというよりはキャリアチェンジというほうがふさわしいと思います。

アウトプットが「Webサイト」と「Webアプリケーション」の違いがあるので、ゴールに行き着くまでのプロセスは共通する部分も異なる部分もありますが、脳の使い方や比率をちょっと変えることで十分対応は可能というのが私の結論です。

これを見ているWebディレクターさんで、少しでもUXデザイナーに興味があるならば、キャリアチェンジの選択肢に入れて視野を広げてみてはいかがでしょうか。

もくにゃん


弥生では一緒に働く仲間を募集しています。一緒に、進化するチームで働きませんか?

herp.careers


  1. デザインスプリント:製品やサービスなどのアイデア・仮説を短いサイクルで具現化し検証するプロセス。詳細は、同僚のUXデザイナーが『弥生 Advent Calendar 2023』12月21日に掲載予定です。

QAエンジニアがプロジェクトマネジメントにトライすることになった話

自己紹介

この記事は弥生 Advent Calendar 2023の6日目の記事です。

こんにちは、弥生で「弥生会計オンライン」の開発プロジェクトのsubPM*1を担当しているシダタクです。
今回はタイトルにある通り、QAエンジニアからのキャリアチェンジについてお話しします。

私は2021年12月に、弥生にQAエンジニアとしてジョインしました。
弥生内では「QL(クオリティリーダー)」と呼ばれるポジションです。
弥生のQA業務については、ぜひこちらの記事もご覧ください tech-blog.yayoi-kk.co.jp

前職も含めると、2019年頃からQAエンジニアとして活動していたので、前職の経験も活かして業務に励んできました。
一方で私のキャリアには「プロジェクトマネジメント」のプの字もなく、PMはあまり縁のないポジションでした。

PMに挑戦することとなった話

そんなある日のこと、とある社内のエライ人から急に打ち合わせに呼ばれました。
何かやらかしたかな…とビクビクしながら話を聞くと…

シダタクさんsubPMやってみない?

という話でした。 社内事情により、subPMのポジションが空席となったため、そこへの異動を打診された形です。
そこで私は一瞬悩んだふりをして

はい、やります!

と無謀にもオファーを受けることとしました。

私自身、QAエンジニアとしての業務は望んだものであり楽しくやっていました。
ただ一方で、今後の自身のキャリアを考え、より影響力の強いポジションを目指していたのも事実です。
そんな中での打診だったので、これは千載一遇のチャンス!!と、ハイエナの如く食いつきました。

とはいえ、前述の通り私はプロジェクトマネジメント業務は未経験です。以下のような不安がありました。

不安
メインのPMが他作業を複数兼務しているため、自身に実質的なPMとしての動きが求められる
QA業務を生業にしてきたので、技術面の知見に乏しい
プロジェクトマネジメントの基礎が備わっていない
他システムの動向などをどう探ればいいかわからない

ただ、何かあっても「自身を選出した会社と上司の責任だから、大丈夫大丈夫~♪」と、できるだけ気楽に始めるよう、自分に言い聞かせました。

2か月続けてみた

時の流れは早いもので、もう12月です。
このブログを読んでいるということは、私は既にプロジェクトにはいないでしょう・・・
ということはなく、何とかsubPM業務を全うできております。

さて、実施前の不安についてはどうなったでしょうか?

不安 結果
メインのPMが他作業を複数兼務しているため、自身に実質的なPMとしての動きが求められる 却ってメリットになった
QA業務を生業にしてきたので、技術面の知見に乏しい テクニカルリーダーを頼る
プロジェクトマネジメントの基礎が備わっていない 社内に研修があった
他システムの動向などをどう探ればいいかわからない 各種ミーティングでキャッチアップできる仕組みができていた

それぞれ簡単に説明します。

自身に実質的なPMとしての動きが求められる

元々、PM/subPMの役割分担は社内で明確化されていないため、その役割や責任範囲はチームごとに異なります(subPMが居ないチームもあります)
私のチームの場合、メインのPMが兼任で大変な状況なのはわかっていたので、役割分担を「PMという立場でしかできない業務以外*2は、全てsubPMが担当する」としました。
一見無謀な分担に見えますが、個人的には
・一通りの業務を経験できるため、より早く成長ができる
・メインPMという後ろ盾があるため、思い切った動きができる
・なにかあった場合は、実質的にPMが2人いる形で分担して対応できる
といったメリットを感じることができています。

技術面の知見に乏しい

弥生では以下のチーム構成でプロジェクトを運営しています。

テクニカルな領域には、TechL(テクニカルリーダー)という頼れる存在がいるため、技術的な相談は彼らに一任しています。

テクニカルリーダーについては、過去にもくテクで取り上げたこともあります。 ログミーTechさんにまとめて頂いた記事がありますので、ぜひこちらも参照ください。

logmi.jp

自身としても技術的要素を勉強する、という選択肢もありましたが、それよりも、PMとしてプロジェクト全体を俯瞰し、問題を早期発見・対策することでプロジェクトを成功させるというのが何よりのミッションであるため、ここは完全に作業分担しています。 なにか問題があった場合には、TechLの意見を踏まえて意思決定を行っています。 (TechLには足を向けて寝れません。)

プロジェクトマネジメントの基礎の不足

弥生では研修制度も充実しており、新任のPM向けの研修もあります。 これは弥生社員が講師として実施するものであり、一般的なPM論というよりは、弥生のPMとして必要なマインドを教えてもらうものです。
一般的なPM論は書籍などで学習できるものの、PMとしての実務で求められる動きは、会社や組織、チームごとにバラバラなのが実態です。 そんな中で「弥生という組織内で求められる動き」を早々に学べたのは、非常に大きかったと感じました。

他システムの動向のキャッチアップ

弥生には多種多様なサービスがあり、それらの開発プロジェクトがあります。 また、製品・サービス開発だけでなく、外部告知や営業活動などのマーケティング活動を行う部や、お客様のサポートを行う部門なども存在しています。 各ポジションの代表者が一同に集まって情報共有を行うミーティングが、複数種類・定期開催されているため、そこで最低限必要な情報を得ることができました。

ミーティングの拘束時間が多いというデメリットはあるものの「情報を得る機会がある」というのは大きなメリットだと感じています。
(当然ですが、より深い情報を得たい場合は、ある程度自分で動く必要があります。)

余談ですが、前職はコンサルファームのような側面もあったことから、基本的に情報は自分から積極的に取りに行く必要がありました。
そこから考えると、情報収集のハードルは大きく下がったと感じています。
一枚岩で動けるのは、事業会社の強みであると強く感じています。

今後の課題

前述の通りチャレンジのし易い環境であったため、滑り出しは順調でした。
一方で、自身の判断力やリード力には力不足を感じているため、基礎を盤石にすることで自信をもって振舞えるようになるのが目下の課題です。

また、技術的な部分はTechLに任せているとはいえ、自身としても広く浅く理解する必要があると考えています。 理由として、技術的な話が上がったときに「これは〇〇さんに聞けばいい」「これはチーム内での解決は困難なため、情報システム部に相談が必要」といった一次切り分けが必要なためです。 無駄な情報を回すことでチームのパフォーマンスを低下させることは避けたいため、最低限の知見は必要であると考えています。

おわりに

私のようにキャリアチェンジ/キャリアアップしたQAエンジニアもいれば、QA業務に全力投球しつづけるQAエンジニアもいます。 多種多様なキャリアに寄り添ってくれると言う意味で、非常に恵まれた環境だと感じています。

私自身、折角チャレンジの機会を得たので、今後はメインのPMとなれるよう努力していきます。 今後の成長や苦難なども本ブログで綴っていきたいと考えてますので、お楽しみに。

弥生では、一緒に働いてくれる仲間を募集しています。 QAエンジニアもプロジェクト責任者も募集中です。

herp.careers

*1:subPM…サブプロジェクトマネージャーの略

*2:各種承認など、PMとして責任を負うべき業務

2023 AWS活動の振り返り

この記事は弥生 Advent Calender 2023の5日目の記事です。

情報システム部でAWS周りの運用保守をしている「ねぎ」です、こんにちは!

2023年も終わりが近いので、この1年間AWSに関する取り組みについて振り返りをしてみたいと思います。

1月 AWS Support App in Slack

Slackを使ってサポートケース起票や、返信、クローズが出来るようになったというアップデートを早速試してみました。

日本語がサポートされるようになったため、英語が苦手でも使いやすくなったなと思いました。

この機能を使ってみて「いいな」と思ったのが、他の人が起票したものも通知が来るので、「あー、こういうので悩んでいるのか、ちょっと(起票した人に)確認してみようかな」といったアクションが取りやすくなったのが一番いいかなと思った機能でした。

2月 Slack通知時にアカウント名を表示させてみた

地味な改善でしたが、今年一番の改善点な気もします。

「アカウントIDだけだとわからん」という声が多くなってきた時に、こちらの対応を入れてみました。

その後は各チーム好評をいただいている、地味アップデートだと思います。

3月 AWS 専用線アクセス体験ラボ ハンズオントレーニング

新たに構築していたAWS環境にもTransit Gatewayを使った専用線を構築しよう、という話になってハンズオンを受講させていただきました。

弊社で利用している環境と近い環境でハンズオンが受けれたので、その後構築した専用線もスムーズに導入することが出来てとてもタメになりました。

4月 AWSのネットワーク構築時に役立つ機能やツール

先月受講したハンズオンを糧に、この月に専用線を導入していました。

導入時にオンプレミス環境とAWS間でうまく通信出来てないな、という部分を「Reachability Analyzer」を使ってどこまで到達しているのか、調査していました。

ネットワークを可視化出来るようなツールはとても重宝しています。

5月 セキュリティインシデント疑似体験 調査ワークショップに参加

AWSさん主催のワークショップに参加させてもらい、ゲーム感覚で楽しく学ぶことが出来ました。

※実際に脆弱性を突いたセキュリティインシデント例を元にワークショップが組まれていて勉強になりました

6月 ControlTowerランディングゾーンのバージョンアップを実施

中々対応が後手になってしまっていたランディングゾーンのバージョンアップを実施していました。

CloudTrailの暗号化対応についても、ついに対応することが出来ました。

バージョンアップは今後も頑張って追随していきたいと思います。

7月 AWS re:Inforce 2023 reCapイベント参加で得たもの

reCapイベントに参加して、「TEAM」というソリューションを知りました。

このソリューションの考え方をベースにして、社内でもユーザ権限の承認ワークフローを作ることになりました。

8月 AWS各通知の構成変更に取り組んでみた

改善活動ネタです。AWSからの各種通知を各チームのSlackに通知するための仕組みを整えました。

これによって私が今まで一つのSlackチャンネルへの通知していた内容を、各チームのSlackチャンネルへリマインドしていた作業がなくなりました。

1日1時間程度の工数削減に繋がり、楽になりました。

9月 ちょっぴりDiveDeep 2023年8月回に登壇してみた

AWSさん主催の「ちょっぴりDiveDeep」に登壇してきました。

2023年はこういった登壇にも初めてチャレンジ出来た、良い1年だったなと振り返りながら思いました。

10月 直近1年の成果まとめ

直近1年間のAWS活動の成果を社内にも発表した月でした。

直近1年間では

  • AWS Security Hubのスコアが20数ポイントも1年間で上昇することが出来た

  • オンプレDBをAWSへ移行第一弾完了

  • 専用線環境を構築

などの成果が出せました。

11月 コスト削減活動

コスト削減活動の一環で、Savings Plan を購入しました。

Savings Plan購入後の平均カバレッジ割合を今後も注視して、必要であればさらなるコスト削減のために追加購入も検討していきたいと思います。

あとがき

振り返ってみると、数ヵ月程度かけたものもあれば、すぐに実現出来たものなど、色々なチャレンジを行った1年でした。

2024年は以下の3本柱を基本に色々な活動をしていきたいと思います。

  1. セキュリティ・ガバナンス強化

  2. コスト削減施策

  3. 自動化・工数削減

一緒に働く仲間を募集しています

herp.careers

JaSST'23 2nd TokaiでLT登壇します

この記事は弥生 Advent Calendar 2023の4日目の記事です。
こんにちは、カトです。弥生でQAエンジニアをしています。
12月15日(金)開催のJaSST'23 2nd Tokaiにて、LT登壇をします。
このブログは、告知です。

JaSST'23 2nd Tokai とは

開催要項

ソフトウェアテストシンポジウム東海実行委員会によるイベントで、'23は、2月に続き2回目の開催です。

開催要項ページは以下です。
jasst.jp 今回は、「みんなで作ろう、令和時代の製品品質」をテーマに、オンラインで開催します。

ソフトウェアテストのイベントではありますが、テストや品質を生業にしている人以外にも興味を持てるイベントだと思います。

発表のきっかけ

2023年、私は弥生以外が主催するイベントでの登壇を2回しています。
1回目は、1月 JaSST Online Edelweiss、2回目は、3月 『教えて、先輩ユーザー!』GIHOZ活用事例共有会 です。
いずれも主催者とつながりがあり、声をかけていただいて登壇する機会を得ました。

今回は自己応募です。私にとって、はじめてのチャレンジでした。

このチャレンジをするに至った一つ目のきっかけは、スクラムフェスにプロポーザルを出した弥生エンジニア「たろけん」こと髙瀬さんを間近に見たことでした。
「自身が入社してからやったことをまとめてアウトプットしてさらに加速していこう」というチャレンジが、キラキラと輝いて見えました。
たろけんさん本人からアウトプットしてみたことに関する話は後日公開予定とのことなので、弥生 アドベントカレンダー2023 のリンクからぜひたどってみてください。
たろけんさんのチャレンジが周りの活気にもなり、どんどん巻き込んでいく勢いのある姿を見ているうちに、私も何かできることをやってみたいと思うようになりました。

二つ目のきっかけは、たろけんさんを応援するために参加したスクラムフェス大阪で視聴した発表でした。
「書いてみたい」のその先へ:経験がプロポーザルとして芽吹くまで というタイトルの発表です。
youtu.be たろけんさんを見ているうちに何か動き出したいと思ったものの、私のやっていることなんて当たり前の普通のことばかりだろうなと思っていたのですが、「あなたがやることに意味がある」という強いメッセージが刺さり、私の当たり前を話してみようと一歩を踏み出しました。

今の私が話せることは、担当しているスマート証憑管理での活動です。
同じサービスを担当していても、それぞれのロールで見えている景色は違うかもしれません。
QAエンジニアの私から見えていた、令和にはじまったチーム・サービスのお話しを5分間LTで勢いでお話しする予定です。

参加申し込み

jasst.jp

お申込みは、2023年12月13日(水)23:59までとのことです。
ぜひ参加をご検討ください。
私以外のLTが素敵な方々です。
招待講演、基調講演、その他のセッション全部がとっても豪華です。

おまけ

カトの紹介note

インタビューしてもらいました。
note.yayoi-kk.co.jp

2023年発表資料

お誘いいただいたり、弥生が主催している社外勉強会もくテクで発表した資料を載せておきます。
もっとうまく説明できる流れがあったのではないか、話し方失敗したのではないか、と思うこともありますが、その時の思いを全部出しきっています。
1月 JaSST Online Edelweiss
speakerdeck.com

3月 『教えて、先輩ユーザー!』GIHOZ活用事例共有会
speakerdeck.com

4月 もくテク 弥生QAエンジニアと品質を考える会 ~カレーづくしの考察集~
speakerdeck.com


明日12月5日の弥生 Advent Calendar 2023担当は、「ねぎ」さんです。
継続的に開発者ブログや登壇でアウトプットし続けていて、私が尊敬している人の一人です。
「ねぎ」さんによる、2023年活動のふりかえり記事、お楽しみに。


弥生では一緒に働く仲間を募集しています。一緒に、進化するチームで働きませんか?

herp.careers

Android アプリエンジニアへのキャリアチェンジ(オンボーディング編)

この記事は弥生 Advent Calendar 2023の3日目の記事です。

こんにちは。弥生でエンジニアをしている、たけです。
(前日のブログでカトさんから好きな勘定科目を聞かれた気がしますが、「売掛金」です。笑)

わたしは中途入社してから約3年間、Windows デスクトップアプリの開発に携わっていました。
あるときモバイルアプリの開発チームでエンジニアを社内募集していることを聞いて興味を持ち、今年5月から Android アプリのエンジニアとしてのキャリアをスタートさせました。

今回のブログではキャリアチェンジしたばかりの頃のこと、特にオンボーディングについて書きたいと思います!

異動までの期間にやったこと

モバイルチームに参加することが決まってから、実際に異動するまで少し時間があったので、その期間にウォーミングアップ的な勉強を行いました。

それまでは言語としてはほとんど C++ しか触ったことがなかったので、本や動画を参考にしながら Android アプリの開発で使われている Kotlin の勉強をしました。
また、モバイルチームのメンバーにサポートしてもらいながら、Android アプリを作るトレーニングも行いました。
ただアプリを作るだけではなく、GitHub にどういう情報を残したらよいかなど、チームで開発するための基本的な考え方も少しずつ教えてもらいました。

オフラインオンボーディング

そして今年2023年の5月、正式にモバイルチームに加入しました。
異動してまもなく、弥生の本社がある秋葉原で3日間の集中オフラインオンボーディングを行ってもらいました。

モバイルチームにはさまざまな地域でリモートワークをしているメンバーが所属しています。
わたしのオンボーディングをしてくれた方も遠方から来て、貴重な時間を過ごすことができました!

スケジュール

一言でいうと、オフラインオンボーディングは「モバイルチームの業務とAndroidアプリの開発について、あらゆる知識を身に付ける3日間」でした(一言じゃない…)。
スケジュールはこんな感じです。

オフラインオンボーディングのスケジュール

上記のようにオンボーディングの3日間では開発スキルや仕事の進め方・考え方などを幅広く学びました。
短期間で新しいことをたくさん学び、正直に言うとけっこうハードでした…!
わたしだけではなく、教えてくれた方もとても大変だったと思います。

よかったこと

そんな超ハードなオフラインオンボーディングだったのですが、実際に業務をはじめて、じわじわとよい効果を感じています!

① 自己学習がしやすくなった

未経験で何かを始めようとしたときに、聞いたことがない言葉がたくさん出てきて、何から学べばよいかわからなくなることがありがちではないかと思います。

今回のオンボーディングでは、短い期間でたくさんの知らなかった言葉に触れることができました。
それによって、「なんか聞いたことがあるな」とか、「なんとなくだけどわかる」というレベルまで知識を引き上げてもらえ、自己学習がしやすくなったと感じます。

これに関しては、オンボーディングが始まるときや終わった後に「一度教えたことでも、また質問していい」と言ってもらえたこともありがたかったです。
そう言ってもらえたことで、「覚えきれなかったらどうしよう」という不安に押し潰されることもなく、ポジティブに勉強していくことができました。

② 自分自身で判断するための軸を作ることができた

また、オンボーディングでは「どうやるか」だけではなく、「なぜそれをやるのか」を丁寧に説明してもらえました。
そのおかげで形式的なことだけではなく、本質的なことを理解できるようになり、自分自身で判断するための軸を作ることができたように思います。

実はオンボーディングから1ヶ月後くらいにほぼ一人で作業する期間があったのですが、想定していなかった問題が起きてもなんとか切り抜け、予定していたタスクをすべてやりきることができました。
まだ判断に迷うことは多いですが、オンボーディングによって最低限のサバイブに必要な部分は身に付けることができたのかな、と思っています。

③ 手元を見て技を学ぶことができた

そして、オフラインオンボーディングでは、手元を見たり、見せてもらったりできたこともよかったなと思っています。
実は開発マシンの Mac も、IDE の Android Studio も初めて触ったのですが、ショートカットやよく使う機能を気軽に教えてもらえて、その後の作業効率がぐんと上がったと感じています。

おわりに

できないことはまだまだたくさんありますが、こうしてやさしくてアツいメンバーに支えられ、楽しく開発をさせてもらっています。
Android アプリエンジニアになって学んだことやモバイルチームのことについて、今後もまた開発者ブログに書きたいです!

最後に少し宣伝をさせてください。
12月21日(木)に、もくテクという弥生のオンラインイベントが開催されます。 テーマは「読んでよかった技術書・ビジネス書LT」で、そのイベントで Android アプリの開発の勉強で参考にした本についてお話しします。
Android アプリの開発だけではなく、さまざまな分野の本について弥生のメンバーがお話しする予定です!
お時間があればご参加いただけると嬉しいです。

mokuteku.connpass.com


弥生では一緒に働く仲間を募集しています。

herp.careers

チームで「心理的安全性ゲーム」やってみました

この記事は弥生 Advent Calendar 2023の2日目の記事です。
好きな勘定科目が「雑費」の津輕さんからバトンを受け取りました。
12月2日このブログが公開されるタイミング、 津輕さんはre:Invent 2023からの帰路でしょう。
快適な空の旅を!

こんにちは、弥生でQAエンジニアをしている、カトです。好きな勘定科目は「未払金」です。
津輕さん、「自己紹介欄に好きな勘定科目を加えようという活動を一人でやっている」なんて言わないで。 私もやってます。 speakerdeck.com 2023年4月もくテクの資料、14ページ目の自己紹介で好きな勘定科目を書いています。

今日は、チームでやってみた心理的安全性ゲームのお話しです。

最初のきっかけ

時は2019年。
私は、「1on1でメンバーに心を開いてもらうにはどうしたらいい?」「リーダーは傾聴することが大事とは言うけれど、傾聴ってどうやってやればいいの?」「遠慮しないチームはどうやって作る?」ということを考えていました。
心理的安全性が高い組織は「知らないということを言い出せる」「質問することが周りを邪魔しているのではないかと不安になってしまわない」という内容を見つけ、「行動することが安全だと思えるチーム」はチャレンジができて、愉しく仕事ができるだろうなと感じました。

「心理的安全性を高めたい」


と思ったのですが、具体的にどのようなアクションをとればよいのかわからず、私は少し困っていました。

そんな時、connpassで「心理的安全性ゲーム体験会」を見つけ、私は迷わず参加しました。
初対面の人たちと心理的安全性ゲームを実施し、「ため息をつきながら言われたら、対応してくれても素直に喜べない」や「応援してくれる人がいるとがんばろうと思う」といった感想を持ちました。
どんなチームになったらいいのかを考えたり、同じ発言内容でも、その人のロールやキャラクターによって、状況が変わることもあると感じていました。

「このゲームは、ぜひチームでやってみたい」と考えていましたが、検討中に2020年突入。
弥生はリモートワークがはじまり、チーム全員でカードを中心に集まることがしにくい状況になってしまいました。

2回目のきっかけ

私が対応しているプロジェクトが開発手法にスクラム開発を取り入れ、私自身も認定スクラムマスターを取得しました。 tech-blog.yayoi-kk.co.jp こんなブログを書きました。こちらもぜひご覧ください。

スクラム開発って愉しいな、いろんな知見を得たいなと考えた私は、2023年9月、Agile party 2023に参加しました。

Agile partyのセッションに、『もっと自由にふりかえりを!』というタイトルのセッションがありました。
「チームがふりかえりをうまくやるためには、心理的安全性が必要」という話題があり、ふりかえりの手法やコツだけを追い求めても、発言しにくいチームだとうまくいかないなと納得しました。

「心理的安全性を高めたい」


と思ったのは、4年ぶり2度目です。
リモートワークだし、みんな業務に追われているし、どうやって何をすればよい?と考え始めたところ、10月に社員総会で全員が出社する日があることに気がつきました。
これは絶好のチャンス!
ということで、さっそくカードゲームをやってみませんか?とチームに問いかけました。

「心理的安全性ゲーム」やってみた

いよいよ、社員総会。チームのほとんどが朝からオフィスに出社する日です。

弥生はフレックス制度を導入しています。
普段、朝はやい時間から業務に取り組んでいるメンバーがいるので、はやい時間から出社する人がいるはず……と思い、はやめに会議室に到着しました。

誰も来ない……

画像はイメージです。弥生の会議室は体育館風ではありません。

みんな、心理的安全性ゲームに興味ない?それとも、カトに興味ない?
待っていると、インフラチームのリーダーが会議室を覗きにきました。
「インフラチーム、誰も来ないんだよね」「一緒じゃん」とひとしきり盛り上がりながら、みんなを待ちつつ、ゲームのセッティングをしていきます。
ゲームのセッティングが終わるころ、ようやくパラパラと人が集まり始めました。よかった。

5人集まったところで、1チーム目のゲームを開始しました。
普段同じチームで働いているメンバーなので、「状況」カードに具体性を持たせて発言をしていきます。
『10時から○○社とオンラインで打ち合わせだったの忘れてて、すっぽかしちゃた。どうしよう。』という状況に対し、メンバーは、『大丈夫だよ、一緒に謝ろう』、『気にしなくて大丈夫、失敗は誰にでもあるよ』、『どうしたらいいか、一緒に考えよう』、『(無視)』と事前に配ったカードから発言をしていきます。
このチーム、そこそこあたたかい状況ではないか?と思いながら、ゲームを進めていきます。

同じチームなので、普段の状況で共有できていることが多く、その状況がどのくらいのトラブル度合なのか、どういった関係性の人との状況なのかが手に取るようにわかります。

本当は助けたい、フォローしたいと思っても、手持ちのカードに助けられるカードがないと、冷たい返答しかできないこともあります。

『今日みんな出社遅くない?変じゃない?』という状況カードに対してのリアクション
こんなリアクションのチームどう?どうなっていくと思う?あてはまるところにキャンディーを置いていく
トラブルの状況出しが一巡したところで、感想やコメントを書き出していき、カードをじっくり見返します。
『この場の半数があったかいコメントしてくれたら、次も相談しようと思える』、『ポジティブな内容でも「目をそらして」とか「ため息をつきながら」だと本心じゃなさそう』、『大丈夫って言われても大丈夫じゃないこともあるかも』といろんな感想がでてきました。
そして、この後、それぞれが発言として使いたいカードを選び、2巡目を実施しました。

感想

ゲームを進めるにあたり、ファシリテーターとしてゲームの方向性をうまく伝えられなかった部分もあり、「結局このゲームなんだったの?」と感じながら終わったメンバーも正直いたのではないかとは思っています。
それでも、せっかくチームのほとんどのメンバーが出社するタイミングだったので、同じことに取り組むことでチームメンバーのことを知ることができた日になりました。
積極的にゲームを動かそうとする人、がんばって演技している人、お菓子を配ったり場を和ませたりする人、散らかっている場所をさっと片付けてくれる人……。
業務遂行のうえで絶対に知っていなければいけない相手の情報ではないかもしれませんが、お互いのキャラクターを知ることが、心理的安全性を高める活動の第一歩になっているかもしれません。
お客さまに価値のある製品を届け続けるために、プロダクトの品質を考えることはもちろん、プロジェクトの品質も考えて、いろんな試みをしてみたいと感じた出社日になりました。

チームに危機が訪れても、自由に発言して笑顔でみんなで乗り切りたい

これからのお話し

私たちのチームは日々進化をしています。
スクラムのチーム名を決めたり、勉強会を開催する動きが出てきたり、改善したいことがどんどんあがってきたりしています。

「勉強会やりたい」に対するチームの雰囲気(イメージ)。「参加できるかどうか考えさせて」と発言したのは私

このチーム愉しいな、新しい世界が広がるかもしれないなと感じながら仕事ができています。
チームの進化の過程や出来事は、また次の機会に。
明日12月3日の弥生 Advent Calendar 2023担当は、たけさんです。
同郷だったり、もくテク運営を一緒にやったり、共通点はあるけれど、私はたけさんと好きな勘定科目を語り合ったことはありません。
たけさんの好きな勘定科目は何だろう?


弥生では一緒に働く仲間を募集しています。一緒に、進化するチームで働きませんか?

herp.careers