はんなりと、ゆるやかに

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

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 が使いやすいので紹介です。

公式サイトはこちらです。
fast-notion.com

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

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

初期設定

初期設定は開発者の方が手順を書いてくれてますので、そちらを参考にしてください。アプリをダウンロードした後、少しだけPCで操作が必要です。Fast Notion 初期設定方法(トークン・投稿先 URL の習得方法) | 35D BLOG
(2022/02/10)FastNotionの初期設定手順が簡単になってます。公式ページを確認してください。
fast-notion.com

便利な点 その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名どなたも形式的な言葉じゃなく、自分の言葉として話されていました。それは、とことん自分と向き合ってきた結果なんだろうなと思いました。

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

スクラムとSECIモデルの関連を考えた

f:id:iucstscui:20210604182225p:plain
スクラムについて調べると「SECIモデル」というキーワードに触れることがあります。SECIモデルとはスクラムの生みの親と言われている 野中 郁次郎さん が提唱した、ナレッジ・マネジメントの枠組みのことです。そのため、SECIモデルとスクラムは関係性があると言えますね。今回はSECIモデルにスクラムを当てはめてみるとどうなるか という点について考えてみようと思います。

SECIモデルとは

以下の記事が分かりやすいです。
SECIモデル(せきもでる):情報システム用語事典 - ITmedia エンタープライズ
【野中郁次郎氏対談】第1章 組織で「知」を生み出すための起点は、「共感」をベースにした「対話」 | Hello, Coaching!
テレワーク環境でのコミュニケーションとナレッジマネジメント〜SECIモデルから考える〜|ほったりょうと|note

SECIモデルは暗黙知から形式知形式知から暗黙知というサイクルを繰り返すことで「知」を進化させていくフレームワークです。4つのフェーズに分かれます。
共同化(Socialization)暗黙知を共有するプロセスです。「共感」によって個人と個人の知識を結びつけます。
表出化(Externalization)暗黙知形式知にするプロセスです。多くの人に伝えられる情報になります。
連結化(Combination)形式知同士を結合し、新たな形式知を生み出すプロセスです。
内面化(Internalization)形式知を実践し経験により暗黙知を得るプロセスです。

この4つのフェーズを「共同化→表出化→連結化→内面化→共同化→・・・ 」の順に回しながら「知」を進化させていくのです。

スクラムとSECIモデル

さて、このブログのメインです。スクラムの「デイリースクラム」や「プロダクトバックログ」とSECIモデルはどういった関連があるのか考察してみました。

スプリント

1ヵ月以内のサイクルで他のスクラムイベントを進めていく「スプリント」はSECIモデルをまわすことにつながると思います。スプリントを繰り返しながら、暗黙知形式知暗黙知 を進めて「知」を進化させていくのです。

スプリントプランニング

「プロダクトバックログ」という形式知から「スプリントバックログ」という形式知を生み出す「スプリントプランニング」は「連結化」に当たると思います。
また、「スプリントプランニング」はプロダクトバックログアイテムについて「価値は何か?」「どうやって作るのか?」という対話を行います。「プロダクトバックログ」で形式知になっていなかった暗黙知を引き出すこともするため「表出化」にも当たります。

デイリースクラム

1日分の作業を共有し、スプリントゴールに向けて適応していく「デイリースクラム」は暗黙知の共有にあたる「共同化」に当たると思います。起こった事象に共感し、チームの「知」を育てていくのです。

スプリントレビュー

スプリントの成果を確認し、プロダクトバックログを更新する「スプリントレビュー」は「連結化」に当たると思います。すでに完成している成果(形式知)からプロダクトバックログ(形式知)を生み出すのです。

スプリントレトロスペクティブ

今回のスプリントの暗黙知を共有し、次スプリントに向けて改善を決定する「スプリントレトロスペクティブ」は「共同化」に当たると思います。実績と感情を共有することで「共同化」が進み、共感し具体的なアクションに繋がるのです。

プロダクトバックログ・スプリントバックログ

プロダクトの改善に必要な一覧である「プロダクトバックログ・スプリントバックログ」は「形式知」の塊です。スクラムチーム全員の形式知となり、この「知」をベースに開発するのです。

インクリメント

開発し作成される「インクリメント」は「形式知」です。「形式知」はドキュメントというイメージもありますが、動くソフトウェアはそれ以上に価値のある形式知だと思います。

まとめ

スクラムでSECIモデルのサイクルを実践できる
  • 「スプリントプランニング」は「表出化」と「連結化
  • 「デイリースクラム」は「共同化
  • 「 スプリントレビュー」は「連結化
  • 「スプリントレトロスペクティブ」は「共同化
  • 「スプリント中の開発」は「内面化
  • 「プロダクトバックログ・スプリントバックログ・インクリメント」は「形式知

図にするとこんな感じです。冒頭に貼った図と同じです。
f:id:iucstscui:20210604182225p:plain

暗黙知も大切

暗黙知形式知にした方が良いとは思っていましたが、暗黙知をためた方が良いと考えたことがなかったです。SECIモデルはそのことを教えてくれます。このインタビュー記事(【野中郁次郎氏対談】第1章 組織で「知」を生み出すための起点は、「共感」をベースにした「対話」 | Hello, Coaching!)に「SECIモデルは、共感」から始まります。」という言葉があります。共同化フェーズで対話を通じて共感し知的なぶつかりあいを起こすことがイノベーションに繋がると書かれていました。スクラムの各イベントも暗黙知を持ちより、対話し、共感することが大切だと気付きました。

関連する過去記事

対話を学ぶときにお勧めしたい一冊です
iucstscui.hatenablog.com

スクラムについていろいろと記事を書いてます
iucstscui.hatenablog.com

文章力をあげるため 理科系の作文技術 を読んだ

わかりやすい文章を書きたい。伝わる文章を書きたい。誤解を与えない文章を書きたい。ブログだったり、仕事だったり、文章を書いていると願うことです。そんな期待に応える本が「理科系の作文技術」です。

理科系の作文技術 (中公新書 (624))

理科系の作文技術 (中公新書 (624))

1981年に発売された本が今も名著として読まれています。古さを感じる部分もありますが、それはほんの一部で今も普遍的に使える内容ばかりです。明快・簡潔な文章を書く技術を学びたい方にお勧めできる一冊です。

読み終えたあとの大量のメモの中から、
 ①大切にしたいと思ったこと
 ②すぐに使い始めたテクニック
をピックアップしてまとめていきます。気になったらぜひ本書を手にとって見てください。

心構えと技術が学べる

文章の目的と対象読者は明確になっていますか?〈目的〉は書くテーマが決まっているだけでなく、そのテーマについて伝えたいメッセージを決めることが大切だと書かれています。また、(i)対象読者は何を知りたいと思っているのか、(ii)本文を理解する前提知識はあるのか、によって書く内容が変わると書かれています。

「目的と読者を意識しましょう」は同意できますが、実践が難しいですよね。本書はその実践〈〉教えてくれる一冊です。たとえば、読者のために書くとは、序文で(i)本論に必要な予備知識、(ii)本論を読むべきかどうか判断する情報、を与えることを勧めています。本論では(i)概要から詳細の順序で書くこと(ii)読者が知りたい情報から書きはじめること、を勧めています。他にも多数の技術が書かれています。

このように、心構えとそれを実現する技術について書かれているので、技術を学ぶモチベーションが上がります。手段と目的はセットで説明することが大切だと改めて思いました。

事実と意見

事実と意見が混ざると不当な結論が導き出されることがあるため、仕事の文章では事実と意見を区別することが大切だと書かれています。事実は誰もが同じ結論になるもの、意見は人によって結論がかわるものです。たとえば、「汚い部屋」は事実のように思えますが意見です。同じ部屋を見て、汚いと思う人もいれば普通と思う人がいます。「おもちゃが50個以上落ちている」が事実です。事実と意見をわけることについては NVC(Nonviolent Communication=非暴力コミュニケーション)でも登場していました。言葉でも文章でも人に伝えるときは事実と意見を分けることが大切ですね。
iucstscui.hatenablog.com

すぐにマネできる技術が多数

この本で学んだことはさっそく仕事の文章に活用しています。すぐに活用をはじめた技術を少し紹介します。

並記の方法

本ブログの前半でも書いた

読み終えたあとの大量のメモの中から、
 ①大切にしたいと思ったこと
 ②すぐに使い始めたテクニック
をピックアップしてまとめていきます。

という書き方です。一つの文で AとB のように複数の事柄を並べて書くときは番号を打つという技術です。AとB それぞれが長くなる場合、読みにくい文になって困っていたのですが、この方法を知ってからは多用しています。
以下のように改行しなくても読みやすいです。

読み終えたあとの大量のメモの中から、①大切にしたいと思ったことと、②すぐに使い始めたテクニックをピックアップしてまとめていきます。

トピック・センテンス

パラグラフ(ある一つのトピックについて述べた文の集まり) にはパラグラフを要約した一文を先頭に書きましょう。これが、トピック・センテンス です。文章の構成として概要から詳細の順序で書いたほうが良いと紹介しました。それはパラグラフにも当てはまるということです。一行目でパラグラフの主張を頭にいれてから詳細を読むことで理解しやすくなるのです。また、「読者が知りたい情報から書きはじめる」という心構えとも関連します。

他にも多数の技術が紹介されています

私がメモした内容を抜粋すると下記です。
f:id:iucstscui:20210527003848p:plain

思いつくままメモ

「2.5 材料あつめ」の章で、主題を頭のどこかに置いておき、何かをきっかけに浮かんできたアイデアやキーワードをとにかくメモすることをお勧めしています。あとから読み返して使えなくてもいいから、とにかくメモせよと。あのとき思いついたアイデアなんだっけ?ということありますよね。「この問題とあの問題は似ているな」「この技術を応用すれば解決できるかも」「もしかしたら、関連がありそうだ」とか。とにかくメモしましょう。ブログのネタ出しにも使える方法ですね。

まとめ

  • 理科系の作文技術は今読んでも学びの多い書籍
  • 読む人を意識して書く
  • 意識だけでなく技術も多数書かれている。

伝わりやすい文章を学べました。日々の開発で文章を書くことが多いですし、ブログでも毎週書いています。少しでも読みやすく書けるように本書を参考にしたいと思います。