はんなりと、ゆるやかに

アジャイル、スクラムが好きなITエンジニアが日々から学んだことをアウトプット

Tech Lead Night vol.0 - 各社のテックリードが、気になるテーマを徹底討論! - に参加

Tech Lead Night vol.0 - 各社のテックリードが、気になるテーマを徹底討論! - に参加しました。

legalforce.connpass.com

開催概要のとおり、テックリードというキーワードについて幅広くお話が伺えました。気になった部分についてまとめていきます。

テックリードの役割は企業によって異なる

「テックリードとエンジニアリングマネージャーの違い」というテーマでは「テックリード」という役割を設けていない企業もあり三者三様でした。共通点は「技術でチームやプロジェクトをリードする」という部分です。技術選定や技術に関わるリスクヘッジ、品質の担保などキーワードが上がっていましたが、細かいポイントは企業によって異なりそうです。また、人やタスクの管理は別のポジョンの方が担っていることが多そうでした。

他の方々はテックリードはどう考えているのか調べてみました。
テックリードという役割 | by Shimpei Takamatsu | Medium
良いテックリード、悪いテックリード - 小さなごちそう
「自らを実験台として新たなキャリアを切り拓け」 及川卓也氏が贈るアラサーエンジニア進化論 - エンジニアtype | 転職type
Tech Lead(TL/テックリード)の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
テックリードになって気をつけていること - Qiita

まとめるとテックリードとは以下のような人物かなっと思いました。

  • 技術的知見とドメイン知識が豊富
  • 技術でチームのアウトプットを最大化する
  • プロダクトマネージャー、デザイナーと対話し、技術面から意見する
  • プロダクトのリリースに対して献身的

あえて役割を分担しないという考え方もある

テックリードとエンジニアリングマネージャーという境界を引くことで、お互いの範囲外に落ちたタスクを拾う人が減ると困りますよねという発言もあり考えさせられました。なんのためにテックリードという役割を設定するのか、どういう期待があるのか、そのあたりを明示しないと悪影響もありそうです。

以下のブログも近いことを言っていて、庭という概念は良いですね。タスクが落ちるという表現だと、野球の守備範囲という概念でも表現できそうです。
チーム開発で活躍するために、自分の庭を作れると良い - hitode909の日記

思想を伝えてエンジニアの組織文化を作る

文化を広めるには色々なものに宿る思想や考えを発信し、伝えた方が良い。「なぜ」が共有されることで文化が醸成される。

ビジョンを伝えないと人は動かない」という記事でも書きましたが、Howだけ伝えられても人は納得して行動しづらいですね。その状態だと文化もできません。経験豊富なベテランの中では当たり前になっていることも、他のメンバーは共通の暗黙知がなく、ルールだけが存在する状態になりかねません。当たり前のこともWhyから伝えることが大切ですね。

まとめ

  • テックリードの役割は自社で定義したほうが良さそう
  • ムリに仕事を役割に分けると、落とすタスクが出てしまう
  • 文化を醸成するにはWhyを伝え続ける

運営のみなさん、登壇者のみなさん、参加者のみなさん、ありがとうございました。

GitHub Actions を スケジュールで実行する

ペースは遅いですが、GitHub Actionsについて調べています。今回はスケジュールで実行する方法をまとめます。前回の内容はこちらです。
iucstscui.hatenablog.com

on コマンドで schedule を定義

on:
  schedule:
    - cron:  '*/5 * * * *'

on コマンドでトリガーを指定します。on コマンドに対して schedule と書くことでスケジュールをトリガーに実行されるようになります。スケジュールの指定は cron で記載します。cron は Windows ユーザーには馴染みの少ないコマンドですね。Unix系OSでコマンドの定時実行のスケジュール管理を行うために用いられるコマンドです。

*/5 * * * * は スペース区切りで"分 時 日 月 曜日" を表しており、この例だと5分おきに実行します。指定が心配な場合は以下のサイトで確認することもできます。
crontab.guru

注意点はデフォルトブランチでしか実行されないことです。デフォルトブランチ以外に設定を書いてもGitHubActionsは実行されません。

Visual Studio Code の Remote Repositories が GitHubのコードを見るのに便利

以前、GitHubのコードをブラウザのまま、Visual Studio Code(VS Code) の 見た目で読む方法を紹介しました。
iucstscui.hatenablog.com

これと同じぐらい手軽に GitHubのコードを VS Code で見る拡張機能が version 1.57 からリリースされました。

marketplace.visualstudio.com

インストール方法

VS CodeのExtensionsでRemote Repositoriesを検索すると見つかりますのでインストールします。
f:id:iucstscui:20210704214608p:plain

使い方

「Ctrl」+「Shift」+「P」でCommand Palleteを開き、Remote Repositories: Open Repository を選択します。
f:id:iucstscui:20210704215105p:plain

初回使用時はGitHubとの連携が必要になるため登録します。
f:id:iucstscui:20210704215203p:plain

Open Remote Repository で 任意のリポジトリを選択すると Visual Studio Code で見ることが出来ます。clone する必要もありません!
f:id:iucstscui:20210704215502p:plain
f:id:iucstscui:20210704215516p:plain

Organizationから指定することで、他のリポジトリも見ることが出来ます。
f:id:iucstscui:20210704215544p:plain
f:id:iucstscui:20210704215657p:plain

まとめ

  • ちょっとコード見たいときはRemote Repositories が便利

LINEのエンジニア組織を支えるチームの取り組みと課題 に参加しました

line.connpass.com

LINEのDeveloper Success チームの取り組みと抱える課題 に参加しました。エンジニア組織づくりに興味を持っていましたし、自社の技術イベントを広めるためのヒントも見つかれば良いなっと思って参加しました。詳しいことは動画のアーカイブが残っていますのでそちらを見ていただいて、このブログでは僕がピン!ときたトピックをピックアップします。

イベントは主催者側から発表者に働きかける

「LINE Developer Meetup」は頻繁に開催されているので、エンジニアから発表したいという声が多いんだろうと思っていましたが、必ずしもそうではないということが分かりました。「別の課題(採用など)を解決するために情報発信したい」というニーズに合わせて、主催者側が働きかけて進めているそうです。

イベントの数の多さは主催者側の努力の賜物なんですね。Developer Success チームという専門部署がある強みだなっとも思いました。

縦のつながりと、横のつながりの社内イベント

「dev open talk」が役員やリーダーとのopenの交流、Tech Talkが組織を横断した社内イベントを開催されていました。縦のつながりを作るイベントを考えたことがなかったので、興味深かったです。縦、横に関わらずエンジニアとエンジニア以外のつながりを作るイベントを企画すると新しい化学反応が起こって商品づくりのヒントが生まれるかもって思いました。

これは、ぜひやってみたい。

KPI はアクションKPIが多い

ブランディングなど効果が見えずらいものが多いので、ブログの本数などをKPIと置かれているそうです。

ブログを書いてもらう仕組み

ガイドを作って書きやすくしたり、各部門にヒアリングして書くネタを見つけるようにしているが苦労しているとのことです。その話の流れエムスリーさんのブログに関するブログ記事が分かりやすいと紹介があり、見つけましたのでリンクを張っておきます。
www.m3tech.blog

自分のブログ書く時の参考にもなる良い資料でした。

オンラインイベント

オンラインになったことで参加者は増えたがリアルタイムで参加する意義が失われがちな部分が難しいと話されていました。
僕は参加者としてイベントに参加することが多いのですが、同じイメージを持っています。オンラインになったことで、遠方のイベントに参加できるようになり、今まで参加できなかったイベントにお邪魔するようになりました。これは大きなメリットですね。ただ、他の参加者や登壇者の方々との交流がほぼゼロになったことは物足りなさを感じます。

イベントって学びだけじゃなく、交流も求めていたんだなぁって改めて思いました。

まとめ

  • エンジニアとエンジニア以外の社内イベントを企画、開催してみようと思います
  • 社内の方々とコミュニケーションを取って、自社イベントで話してくださる方を増やそうと思います

運営の皆さんありがとうございました!

ユーザビリティテスト実施前に! / UXリサーチの道具箱IIを読んだ。

UXリサーチの道具箱II ―ユーザビリティテスト実践ガイドブック―を読みました。実践ガイドブックという名のとおり具体的な内容でした。

ユーザビリティテストに必要なことがわかる

ユーザビリティテストを簡単に説明すると、開発中のプロダクトをユーザに触ってもらって改善のヒントを得る手法です。

簡単に説明できますが、実践は難しいです。ユーザはどうやって呼ぶのか?謝礼は?実施方法は?実施したあとの分析方法は?などなど知るべきことがたくさんあります。

そして、本書はそれを1から10まで教えてくれます。目次はこんな感じです。

  • Chapter1 ユーザビリティテスト概論
  • Chapter2 求人ガイド
  • Chapter3 設計ガイド
  • Chapter4 実査ガイド
  • Chapter5 分析ガイド
  • Chapter6 UTちょい足しレシピ集
  • 附録 UTタスク事例集

個人的には「求人ガイド」でユーザのリクルート方法が書かれている点が特に実践的だと思いました。ヒアリング方法、分析方法が学べても、ユーザを集められないと何もできませんもんね。

本書を読んで特に気になった部分をまとめていきます。

コストだけでなく成果の大きさも考える

「求人ガイド」の項目はテスト計画やリクルートについて学べます。その中でコストについてもまとめられていて、謝礼やリクルート費用、参加者の工数について書かれています。具体的な金額も書かれています。

その中で「気をつけないとこの罠に嵌ってしまいそうだなー」ということが書かれていてました。それは、工数を削減するために最少人数で進めて、それ以外の人はレポートを読むだけにしないことです。誰かがまとめたレポートはその人の主観が入ります。レポートではなく、一緒に体験して自分なりの考えを持つことは大切ですね。

ドタキャンされた場合にも対応

カバー範囲が広い!っと感じた部分はドタキャンされた場合の対応方法も書かれている点です。

ユーザーストーリーがタスク設計に役立つ

ユーザビリティテストは、ユーザに作業課題(〇〇を予約してくださいなど)を実行してもらい、それを観察します。そして、作業課題をタスクと呼びます。「設計ガイド」では、タスクの設計方法とユーザビリティテストの始まりから終わりまでのタイムスケジュールが学べます。

本章はタスクを決める際の原則についてまとめられていて、どれも納得できる原則でした。個人的にはユーザストーリー単位でタスクを設計するのが良さそうだと思いました。

具体的な実査ガイド

「実査ガイド」は受付からエンディングまでの流れを実践さながらに書かれています。自分たちでユーザビリティテストをする前に読んでおくと準備のモレなど気づきがあると思います。

観察は事実を書く

「分析ガイド」に書かれている内容で早速役立った内容があります。「事実を書く」「ユーザ視点で書く」です。具体的な例を本書から引用します。

「戻るボタンがない」というのはユーザの視点ではありません。ユーザは戻るボタンを使いたいのではありません。単に「前の画面に戻りたい」だけです。つまり「(ユーザは) 前の画面に戻れなかった」と書くべきです。

私も開発で第三者が操作している様子を観察することがあります。そのとき、個人的に「戻るボタン」を付けた方が良いと思っていると、「戻るボタンがない」のように、自分の考えを含めたメモしたことがありました。観察はあくまで観察。意見を混ぜずに事実を書くべきだと気づきました。

まとめ

  • ユーザビリティテストするときの参考になる書籍
  • 具体的に書かれているため、実施している人は自分たちとの差を見つけやすそう
  • 観察するときは事実と意見をわける

Notion で手軽にメモを取るなら Fast Notion がおすすめ

Fast Notion が使いやすいので紹介です。

公式サイトはこちらです。

以前、僕のNotionの使い方を公開しました。今でも使っているのですが、スマホでちょっとしたメモを書くには少し使いづらい。。。と感じていました。

なんとかならないかなっと探して見つかったアプリがFast Notionです。

初期設定

初期設定は開発者の方が手順を書いてくれてますので、そちらを参考にしてください。アプリをダウンロードした後、少しだけPCで操作が必要です。

便利な点 その1 改行できる

PCで操作する場合、「Shift+Enter」で改行、「Enter」で新しいブロック作成ができます。スマホも同じように使いたいのですが、使い分ける方法がありません。公式のNotionアプリでは改行ができず、全てブロック作成になってしまいます。
その点、Fast Notionは改行し投稿すれば、改行が反映されます。投稿の単位がブロックになります。

便利な点 その2 メモが手軽

ちょっとしたメモにNotionは少々大げさで、Google Keepを使っていました。Fast Notion はアプリを起動してさっとメモ取れる操作が便利です。そもそも、さっとメモも取るに特化したアプリですので、当たり前のように使いやすいです。

まとめ

  • Fast Notion を使えばNotionがもっと便利になる
  • 初期設定は手順書を見て焦らず設定

THE COACHの「"人を活かす"コーチングとは」に参加した

第1回「"人を活かす"コーチングとは」〜対メンバー編〜 というイベントに参加しました。スクラムマスターに興味を持つと、コーチングというキーワードが必ず出てきますね。興味のある分野です。

thecoach.jp

THE COACH Academyはオンラインのコーチングスクールです。今回はその卒業生が語る対談イベントでした。事前に用意された質問や参加者からの質問に答えるパネルディスカッション形式で進んでいきました。進行もスムーズでお話も興味深く、あっという間の1時間30分でした。イベントに参加してどう思ったかを中心にまとめていきたいと思います。

コーチングを知るには、自分と向き合うこと

THE COACH Academy は 基礎、応用、プロのコースがあり、プロコースに近づくにつれ、内省(自分と向き合う)が多くなるそうです。そこでは、できれば向き合いたくない自分と向き合うことが求められ、そこで得た気づきがコーチングするための「器」を育むようです。登壇された3名とも、その時間はタフな時間だったが、必要な時間だったとお話されていました。

登壇者のお一人がプロコース受講中にあった具体例を話されていました。とあることで悩み、目を背けて逃げようとしているときにTHE COACH Academy の仲間と対話し自分の視野の狭さに気づかされて行動を起こせたという話をされていて、コーチングの力を感じられました。

コーチングは相手の気持ちと向き合います。ときにはそれが負担になることもあります。だからこそ、自分と向き合い、向き合うことのストレスと効果を自分で実感することが大切なんですね。その実感がないと、相手が向き合うことで辛そうにしてるから問いを投げかけるのやめにしようってなりそうだと思いました。乗り越えた先に良い未来が待っていると信じられないと難しいそう。

自己開示の強さ

自身の悩みとコーチングにより変わったというエピソードは、ジーンしました。自己開示するとそれを聞いた側は心を動かされますし、信頼が生まれると感じました。信頼してもらうには、まず自分が相手を信頼して自己開示することが大切ですね。

コーチとしての成長は実践で伸ばす

本やネットで勉強してから、自信を持って THE COACH Academy に参加したが、うまく出来ないことに気づかされたというお話がありました。本やネットで学ぶことも大切ですが、それだけではなく、実践とフィードバックが大切なんでしょうね。

コーチはクライアントの暗黙知形式知にする

こばかなさんからコーチングの簡単な説明がありました。その話を聞いて思ったことは、暗黙知形式知にする手助けがコーチングかもということです。

コーチを受ける側をクライアントと呼ぶそうですが、そのクライアントが「ほんとうはどうありたいか」を一緒に見つけていくことがコーチングです。「周りの目」、「思い込み」などから、抑え込んでいる感情を一緒に見つけてあげるのです。

人の可能性を信じる

過去にコーチングの本を読んだり、勉強会に参加しています。
iucstscui.hatenablog.com
iucstscui.hatenablog.com

すべてに共通することは人の可能性を信じるということです。コーチングは人の可能性を信じ、その人のほんとうにやりたいことを見つけ寄り添ってあげることだなと改めて思いました。

まとめ

今回のイベントで気づいたこと

  • 人と向き合うために、自分とも向き合う大切さ
  • 相手の〈ほんとうにありたい姿〉を一緒に見つける
  • 自己開示の力
  • 人の可能性を信じる

登壇された3名どなたも形式的な言葉じゃなく、自分の言葉として話されていました。それは、とことん自分と向き合ってきた結果なんだろうなと思いました。

登壇の皆さん、進行のこばかなさん、運営の皆さん、ありがとうございました!