はんなりと、ゆるやかに

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

Visual Studio Code 「Ctrl+マウスホイール」で拡大縮小する設定

Visual Studio Code の初期設定では「Ctrl+マウスホイール」で拡大、縮小されません。不便だと思っていたら簡単な設定で解決できたのでまとめておきます。

設定方法

「File > Preferences > Settings 」から設定画面を表示します。
f:id:iucstscui:20210118225609p:plain

設定画面から Mouse Wheel Zoom にチェックを付けます。
f:id:iucstscui:20210118225823p:plain

完了です。これで、「Ctrl+マウスホイール」で拡大、縮小できるようになります。なぜ、今まで調べなかったのだろうというぐらい簡単な内容でした。

まとめ

  • 簡単な設定で「Ctrl+マウスホイール」による拡大縮小が可能になります

Visual Studio Code スニペットで簡単日付入力

Visual Studio Code(VSCode)で 簡単に今日の日付を入力する方法を調べて、スニペットを使った方法が分かりましたのでまとめておきます。

スニペット

スニペットは繰り返し入力するパターンが登録できるテンプレートです。スニペットを登録したあとは入力補完を使いながら便利に入力できます。

スニペットの登録方法

「File > Preferences > User Snippets 」から スニペットが編集できます。
f:id:iucstscui:20210112231905p:plain

編集したいスニペットを選択します。新しいスニペットファイルを作る場合は「New Global Snippets file」を選択して任意のファイル名を入力します。
f:id:iucstscui:20210112232437p:plain

新しく作った場合はスニペットの説明と入力例のコメントが書かれた新規ファイルが表示されます。
f:id:iucstscui:20210112232739p:plain

日付スニペットの登録方法

スニペットは変数が用意されていて$変数名 と記述すると変数に応じた入力がされます。使える変数は公式ページに掲載されています。
code.visualstudio.com

今回は以下の変数を使って「2021-01-12(Tue)」のようなスニペットを作ります。

  • CURRENT_YEAR(年)
  • CURRENT_MONTH(月)
  • CURRENT_DATE(日)
  • CURRENT_DAY_NAME_SHORT (曜日)

作ったスニペットは以下です。

{
    "今日の日付": {
        "prefix": ["date", "current-date", "今日"],
        "body": ["$CURRENT_YEAR-$CURRENT_MONTH-$CURRENT_DATE($CURRENT_DAY_NAME_SHORT)"],
        "description": "今日の日付です。"
    }
}

今日の日付スニペットの名前です。入力補完時に表示されます。
prefix は入力補完するキーワードです。「date」、「current-date」、「今日」のいずれかを入力すると入力補完候補として表示されます。「今日」のような日本語の場合は確定後にTabキーを押すと変換されます。
bodyは入力される内容です。「変数」と「-」「()」の記号を使って入力する本文を入力しています。
descriptionスニペットのオプションの説明です。入力補完時の説明に表示されます。

エディターで「date」と入力すると入力候補に「今日の日付」が表示されます。
f:id:iucstscui:20210112235645p:plain

また、Ctrl+[Space]でも候補が表示されます。
f:id:iucstscui:20210112234437p:plain

まとめ

「言葉にできるは武器になる。」を読んで、「内なる言葉」と真剣に向き合うことに決めた

今年の抱負に「言語化を得意になる」と掲げましたので、それに近づくための書籍「言葉にできるは武器になる。」を読みました。

意見や想いを伝えるための「考えを深める思考法」、「伝わる言葉にするプロセス」が学べる書籍です。ブログ、プレゼン、ビジョンなど何かを伝えて周りにポジティブな影響を与えたい!と思った方は読んでみるとヒントが見つかりますよ。

自分は「何を伝えたいのか」にとことん向き合う

【1章「内なる言葉」と向き合う】、【2章 正しく考えを深める「思考サイクル」】は「内なる言葉」の大切さと深め方について書かれています。内なる言葉とは何でしょうか?それは、本書で以下のように紹介されています。

この「内なる言葉」とは、人が物事を考える時に頭の中で使っている言葉であり、考えを進める、広げる、深める、といったあらゆる側面で機能する。

考えたり、悩んだりしていると頭の中で色々な言葉が連想ゲームのように浮かんでは消えるを繰り返します。「今からお菓子を食べよう」「いや、でももう寝る前だし」「少しなら良いかな」「今日は仕事も頑張ったし」「ご褒美ご褒美」「でも、健康に良くないしなぁ」「甘さ控えめのお菓子ならいいかな」・・・こんな感じで頭の中は言葉であふれています

そう、あふれているから良くないのです。

頭の中だけで考えていると思考があっちいったりこっちいったり、たまにいったまま戻ってこれないこともありますよね。この状態は「考えたつもり」で考えられてないのです。

じゃあ、どうすれば良いの?

という問いに答えてくれるのが2章の正しく考えを深める「思考サイクル」です。

考えを頭の中から外に書き出す

本書では考えているときに浮かんだ言葉をすべて紙書き出しましょうと提案しています。先ほどのお菓子の例なら「今からお菓子を食べよう」~「甘さ控えめのお菓子ならいいかな」をすべて書き出します。

さっそく、この本の書評を書くときに試してみました。本を読んで思ったことを幅広く書き出してみたんです。すると、わかるんです。思ってたより考えてない。本を読みながら色々考えていたはずなのに、書き出してみるとあまり数は出ない。色々考えていたのは同じようなことを考えていただけだったと気付けました。

でも、ここで落ち込む必要はなくてここからさらに考えを深める思考法としてT字型思考法が紹介されています。詳細は本書を読んでいただければと思います。

本書を一読して良い本に出合えた!と思えた部分が、この考えを深める「思考サイクル」です。今年の目標にしている言語化のために深く広く考える癖付けが重要だと思っています。例えば「エモい」の一言で片づけず何がエモいのか、どうエモいのか、エモいとどうなるのか、と思考を深めたり広げることで伝わる言葉に置き換えられます。

言葉に自分らしさをのせる

【3章 プロが行う「言葉にするプロセス」】は自分と向き合って深まった自分の意見を言葉に変換するプロセスが紹介されています。大きく2つのプロセスが紹介されていて「日本語の「型」を知る」と「言葉を生み出す「心構え」を持つ」です。2つのプロセスで今までよりも伝わる文章になると感じました。そこの詳細は本書に任せて、このプロセスを使って「自分を言葉にのせる」ことが大切だと思いました。

本書でも書かれていましたが、ただきれいだけの言葉は響きにくいです。自分の経験や知識がのった言葉だからこそ響くのです。そのために「内なる言葉」と向き合うことが大切だと感じました。

まとめ

  • 言葉にできるは武器になる。を読みました。
  • 「内なる言葉」と向き合うことが伝わる言葉を表現するうえで大切
  • 自分の経験や知識で自分ならでは言葉も大切

2021年の抱負

新しい年がはじまりました🎍🐄
「一年の計は元旦にあり」なんて言ったりもしますので、今年の抱負です。頑張るぞ!

図解を得意になる

物事や考えを整理整頓するの苦手なんですよ。嫌いじゃないんですけどね。苦手。

苦手苦手とも言ってても変わらないので宣言してこの1年で得意になろうと思います。図解が得意になれば整理整頓スキルも高くなると思いますので、図解のパターンを知り、使うことでレベルアップしていきます。

ブログも図を多用していきます!

システム思考を得意になる

「SCRUMMASTER THE BOOK」もシステム思考について言及されていました。俯瞰して色々なことをシステムとして捉えられれば、良い課題が見つけられそうです。

「図解を得意になる」と合わせて武器🗡にできれば大きな強みになれそうなんですよね。

言語化を得意になる

今年の後半に「アオアシ」を読んで「言語化が大切だーーー!」となってます。すぐに影響されるんです。

alu.jp

このコマはプレーした内容を細かく説明しているシーンです。言語化により感覚でプレーした内容を考えて整理できます。言語化できるとふりかえりにも活用できますし、考える癖がつきます。

このブログも言語化の1つですね。さらに特訓の場所を増やすためにTwitterの投稿も増やしたいなーと思ってます。

健康

去年は5月ぐらいまでは継続してランニングできました。その後は暑かったり、寒かったり、とか言い訳をして止まってしまいました。今年こそ継続します!

計画立てて生活する

去年の抱負にも計画を入れていたのですが出来てませんでした。今年こそ!

まとめ

  • 図解、システム思考、言語化により課題の抽出や改善の質を高くする
  • 計画立ててやるべきことに力をかける
  • 決めたことはやりきる

「顧客志向」が「楽しい環境」を作る / 10Xとみてねが語る、顧客志向な開発カルチャーの作り方・育て方に参加した

10Xとみてねが語る、顧客志向な開発カルチャーの作り方・育て方」に参加しました。サブタイトル「「エンジニアが楽しい」環境をどう実現するか?技術トップがホンネで語ります!」も良いですね。

「顧客志向な開発カルチャー」と「エンジニアが楽しい環境」の両立を目指して日々開発に勤しんでいる僕としても興味深いテーマでした。

また、10Xさんは「Free Agenda」のPodcastで、みてねさんはアプリの利用者として普段からお世話になっているので、そんな企業の方々のお話が聞けるのも楽しみでした。

connpass.com

今回の配信はアーカイブ、公開されていますので、ご興味のある方は御覧いただけます。ありがたい。
www.youtube.com

今回のイベントは株式会社ミクシィの酒井さんと株式会社10Xの石川さんが自社の開発組織の説明をした後、参加者からの質問にパネルディスカッションで答える流れでした。詳細は動画に任せるとして、本記事はお話を聞いて僕が特に「おぉーー」と思った点に絞ってまとめていきます。

内容のハイライト

みてね さんの開発

  • サービスのミッションとは別に開発グループ向けにミッションがある
  • 自身の領域に閉じず、あらゆる物事に前のめりなチーム
  • エンジニアが責任感を持って、チャレンジしていく
  • 顧客にも、技術にも、好奇心を継続させる
  • 組織作りは理論だけじゃなく、課題から取り組んでいる

10X さんの開発

  • 状況に応じて何でもやる
  • Why/WhatまではPMが決めるが、Howはエンジニアに任せている
  • ビジネスチームがユーザーの声を集めて、言語化してエンジニアに伝える
  • 課題に対してビジネス1名、エンジニア2名の少数チームで開発している

パネルディスカッション

  • エンジニアが顧客を知る機会はどのような場があるのでしょうか?
    • 酒井さん
      • ユーザーインタビューに同席
      • カスタマーレビューを見たりリアクションしたり
      • 社内ユーザーにヒアリング
    • 石川さん
      • 専用チームからインタビュー動画やレポートがアップされる
      • エンジニアも現地に出向いて仕事を知る
  • 技術よりな関心の強いエンジニアに顧客志向な開発カルチャーを浸透させるには?
    • 酒井さん
      • ユーザーの声やアプリレビューの声に対して責任を持ってどう関わるか考えてもらう
      • 個々というよりチームとして顧客志向を目指す
    • 石川さん
      • メンバー全員が日ごろから顧客の声を聞くことが普通になっている
      • エンジニア力を高めるために顧客志向が第一じゃないメンバーも必要になる
      • チームへの貢献によりチーム全体が顧客志向になっている状態が良い
  • エンジニアチームが「プロダクトによる顧客の喜びやその手ごたえ」を感じながら楽しく働くために取り組んだこと
    • 酒井さん
      • わいわいの楽しさじゃなく、顧客の課題を解決してプロダクトを良くすることが楽しくなる
      • 人を褒める文化を作っていく
    • 石川さん
      • 大きく任せることを意識している
      • 自分で考えて、自分でリリースして、良いフィードバックがあれば嬉しい

他にも色々な質問があり、時間オーバーするぐらい盛り上がっていました。

学んだこと

今回のイベントで「顧客志向な開発カルチャー」と「エンジニアが楽しい環境」の両立を目指すために大切なことが見えてきました。

「顧客志向」が「楽しい環境」を作る

f:id:iucstscui:20201224004451p:plain

「顧客志向」と「楽しい環境」は関係性がありそうです。自分の開発したプロダクトで誰かの役に立ちたい。そういう志でエンジニアを目指した方は多いと思います。顧客の声を聞き、開発し、さらに顧客からフィードバックをもらうサイクルが回っていれば顧客志向で楽しい環境になりそうです。

そのためには、何ができるでしょうね。スクラムを採用していればスプリントレビューのタイミングで顧客の声を共有し話し合えたら良いなと思います。そんなとき、POだけじゃなくエンジニアから「こういう機能、どうですか?」とか話せると最高だな。

チームで顧客志向になる

f:id:iucstscui:20201224233348p:plain
かといって、1人ひとり全員が顧客志向は難しいです。エンジニアの個性もあるでしょうし、顧客の声が表れにくい開発もあります。バックエンドの改善やセキュリティ周りなど。こういった開発も貢献が感じられて、結果チーム全体として顧客志向になれると良い。

そのためには何ができるでしょうね。貢献と効果が目に見える形で表されて、良いこと悪いこと含めてフィードバックできると良さそうかなって思いました。良いことはすこし大げさにみんなで褒める!

Who/Why/Whatまで決めてHowからは一緒に進める

f:id:iucstscui:20201225001139p:plain
「POに言われたから作った」ではなく、自分が開発したと胸はって言えるよう「一緒に作った」感覚が欲しいですね。みてねさんも、10Xさんも、細かなタスクじゃなくて大きな仕様を渡して作り方はエンジニアに任せていました。

そのためには何ができるでしょうね。Howは決めずWhy、Whatまで決まったらエンジニアと共に考えるだと思いました。そして、考えるときは共通認識がブレないようにユーザーストーリーを使うと良いでしょう。「[Who]として[What]がしたい。なぜなら[Why]だからだ」の[●●]が埋まった段階で相談して、「じゃあ、こうすれば」「それも良いね。さらに、こうすれば。」「じゃあ、この機能は後回しでも良さそう」と会話の中でHowを決めていく。一体感が生まれ、コミュニケーションの中で予想を超えるHowも見つかると思います。

また、ユーザーストーリーを使えば[Who]が明確になるので自然と顧客に意識が向きます。

まとめ

  • 「10Xとみてねが語る、顧客志向な開発カルチャーの作り方・育て方」に参加
  • 「顧客志向」と「楽しい環境」は関係性があり、「顧客志向」だから「楽しい」状態が良さそう
  • チームで顧客志向になる
  • Who/Why/Whatまで決めてHowからは一緒に進める

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

2020年のブログふりかえり

今年も僅かになりました。年末といえばふりかえり。来年も楽しく過ごすために今年1年をふりかえりましょう。

今年の目標に対するふりかえり

年始に目標を設定したので、それに対するふりかえりです。

インプット、アウトプットを継続する。開発スキルをあげる。

今年もほぼ毎週ブログを書き続けることが出来ました。2年以上このペースを続けられて習慣になったなーと実感しています。

今年のブログ活動で一番大きかった出来事は2020/03〜2020/05の3か月間、カックさん(@kakakakakku / id:kakku22)にブログメンタリングしていただいたことです。この期間は新しい技術にも挑戦しましたし、ブログメンタリング以降の行動が積極的になったなーと自覚します。ブログのPV数も昨年の「約9000」から「約31000」と飛躍的に伸びました。定性的にも定量的にも伸びた年です。

この期間でブログと私は大きく成長しました。
カックさんに感謝です。

学習を促す環境をデザインできるようになる。

社内向けのイベントを多数立ち上げたり、学んだことをメンバーに共有する習慣が付きました。

健康

コロナ堝で運動不足にならないように、YouTubeで筋トレやヨガを始めてお腹周りが引き締まってきました!

計画を立てて進められるようになる

これは、まだまだ苦手。来年こそ計画立てて行動、ふりかえりの短いサイクルをまわしたいなぁ。

四半期ごとにふりかえる

今年を四半期にわけてふりかえっていきます。

⛄1-3月

2月にカックさんからブログメンタリング募集のアナウンスがありました。


この時点で1年以上は週一ブログ更新を続けていましたが、PV数の伸び悩みや自身の学びへの繋がりの薄さを感じていました。続けた割には伸びないな。。。という悩みを解消するために応募しました。

しかし、「ブログのライザップ」と呼ばれるブログメンタリング。

応募、悩みました。ブログメンタリングの紹介にあるノルマだったりペナルティを見ると軽い気持ちでは応募できません。でも、このままも嫌。ということで悩みに悩み申し込んだのです。ブログメンタリングの結果はブログにまとめています。

さっそく3月はブログメンタリング効果で今まで触れたことないCircleCIについての記事を3連投しました。

この期間でお気に入りの記事はこちらです。ブログ駆動で学んだ新しい技術です。

🌸4-6月

この期間はカックさんからのアドバイスもあり、 git に関する記事を増やしました。普段から使っているgitも知らないコマンドやオプションはたくさんあります。「知っているつもり」から「知っている」に変えるためにブログは良いきっかけになります。人に教えるようにブログを書くと、その技術について改めて調べます。そのたび新たな気づきがあり、理解が深まります。

6月はLTにもチャレンジしました。スクラムフェス大阪2020の「教えて!あなたの一歩を後押しした本」のセッションで本を紹介する企画に応募し、カイゼン・ジャーニーを紹介させて頂きました。

この期間でお気に入りの記事はこちらです。git を調べてこんなに便利な機能があるんだ!とブログを書くことで気づいた機能です。

🌞7-9月

9月は楽しみにしていた書籍「SCRUMMASTER THE BOOK」が発売されました。

スクラムマスターという役割は何をすべきなのか、どうすべきなのかが書かれた書籍です。ここに書かれている内容を体現できれば、理想的なリーダーになれそうですがまだまだ力足らずです。インプットしてもそれを、実践に投入する力が弱いんですよねー。

この期間は"対話"関連の本をまとめて読みました。特に「問いのデザイン」は実践にも活用できています。ブレストのミーティングを開催するときは設定する「問い」について考えるようになりました。前よりも活発に意見が出るようになったっと思っています。
人間関係は「箱」から出れば良くなる / 2日で人生が変わる「箱」の法則 を読んだ - はんなりと、ゆるやかに
効果的な問いでファシリテート上手になる / 問いのデザインを読んだ - はんなりと、ゆるやかに
仕事、子育て、プライベート、すべてを豊かにするためのコミュニケーション / NVC 人と人との関係にいのちを吹き込む法 - はんなりと、ゆるやかに

この期間でお気に入りの記事はこちらです。書評の中に日常と絡めた例や他で学んだ知識との関連をまとめられたり、本の要約だけじゃないオリジナリティがある書評になったと思っています。

🎄10-12月

新しく学んだことを調べてまとめて記事にすることが多いのですが、この期間は考えを整理しなおした記事が多かったです。それはNotionというツールを導入したことが大きいと思っていて、ふと浮かんだネタをNotionにさっとメモするようになりました。「タスクの重さと荷物の重さって似ている部分がありそう」という思い付きをメモにして記事にしたのが下記の記事です。

この期間でお気に入りの記事はこちらです。Notionを導入するとき色々な方の記事を参考にさせていただきました。その結果、今もNotionを活用して続けられています。自分の使い方もブログにまとめることで新たにNotionを始める方の参考になれば良いなと思って記事を書きました。過去の自分が知りたい情報をまとめたつもりで、読者の方を意識して書けた記事だと思います。

まとめ

  • 今年1年もブログを続けることができました
  • ブログメンタリングで大きく成長できました
  • ブログを書くことで成長の実感が出来はじめました
  • 来年は学んだことを実践に活かしていきたい

「ストーリーポイント」は「荷物運び」でたとえると分かりやすい

スクラムではプロダクトバックログアイテムを見積もるときに「ストーリーポイント」という単位を使います。

見積もりと言えば、「このタスクは2時間」「このタスクは7時間」といった時間🕒の絶対値で見積もることが多いと思います。「ストーリーポイント」は基準となるタスクから相対値で見積もります。

例えば、「ログイン画面を作る」をストーリーポイント「2」と決めて、「〇〇画面を作る」は開発部分少ないから「1」とか、「〇〇機能を追加する」は影響範囲が多いから「5」とかです。


ここで疑問がわいてきます。なぜ時間で見積もらず、まわりくどく「ストーリーポイント」で見積もるのか。どんな良いことがあるのか。


そこでピンっときたのが、ストーリーポイントを「荷物運び」でたとえてみる。です。

「荷物運び」と「ストーリーポイント」

f:id:iucstscui:20201210230449p:plain

ある地点からある地点まで大量の荷物を運ぶ必要が出てきました。この時、荷物の運ぶ時間を見積もることが時間見積もりです。荷物の重さを見積もることがストーリーポイントを使った見積もりです。

荷物を見積もろう

重さを見積もるのに「はかり」があれば正確に測れますが、過去の経験から見積もらないといけない場合、「これは10.235.kg」「これは2.173kg」と正確に見積もるのは困難ですよね。「これは10.235.kg、いや、10.245.kgか?、いや、・・・」なんてやっていると時間がもったいないですし、どうせ間違えます。また、直感で見積もっても時間かけても見積もっても、正確性に差が出ることは少ないです。こういうことを「収穫逓減の法則」と言います。

そこで見積もり時間短縮に有効な手段が相対見積もりです。基準となる荷物の重さを「2」と決めます。あとは簡単です。「これはちょっと重いから「3」。こっちは軽いから「1」」とぱっぱっぱっと見積もっていくのです。ただ、これも細かくし過ぎると見積もり時間がかかるので「1,2,3,5,8,13,21」のフィボナッチ数列を使われることが多いです。基準から遠い荷物はきっと正確な数値を出せないので選べる値も極端にします。

また、複数人で見積もる場合にもストーリポイントの利点がでます。
時間見積もりは同じ2キロの荷物でもAさんは1時間、Bさんは3時間、と能力によって見積もり結果に差が出ます。じゃあ、あいだ取って2時間にしようかってすると、どちらが作業しても見積もりミスになります。また、関係性によっては1時間で押し切られて、Bさんが作業したら大幅な見積もりミスになります。こんなときもストーリーポイントであれば荷物の重さを見積もるので個人能力で差が出ません

さらに、見積もりの差について話し合うことで作業の漏れや余計な作業をしようとしていることに気づけます。
Aさんが2kg、Bさんが10kgと大きく差が出た場合、「この荷物を運ぶときは合わせてこれもセットで運ばなきゃいけないんだよ。」「そうなの!?」って暗黙知を可視化できるのです。
f:id:iucstscui:20201210234639p:plain

全部運び終わるにどれぐらいかかるか予測しよう

時間で見積もった場合、1つひとつの見積もり時間を足せば「後50日で終わりそうだ。」と予想が立てられます。そして、1日目から遅れていくのです。

ストーリーポイントの場合、運ぶ重さは分かりましたが、どれくらいで運び終えられるかは分かりません。だから、とりあえず、運び始めます。1日目運んでみたら「10ストーリーポイント」運べることが分かりました。じゃあ、残りは「900ストーリーポイント」だから後90日で運べそうだとわかります。

ただ、時間で見積もった場合も1日目終わったあとにリスケをすれば良いので、結果は変わらないと思います。ただ、予想より2倍かかりそうって分かったら荷物1つ1つの見積もり時間を修正していく作業が発生しますし、上司やステークホルダーに「すみません、間に合いそうにないです。」と気が重い報告しなくちゃいけません。時間で見積もったら正確に見積もれたって気がしますが、そうでもないです
f:id:iucstscui:20201211003458p:plain

スクラムは時間固定で開発するから、ストーリーポイントの方が改善結果が分かりやすい

カイゼンマインド」を持ち、前よりもっと成長したいと思いながら開発していると思います。その場合、「成長したかどうか」を計測することが大切になります。

スクラムで開発する場合、1週間とか、2週間とか、固定の期間で繰り返し開発します。この固定期間で完了した数値をベロシティと呼びます。

開発期間は固定なので時間見積もりの場合、集計できる対象は荷物の数になります。荷物の数をベロシティにする場合、軽い荷物を13個運んだ日と重い荷物を1つ運んだ日でベロシティが異なります。何か改善しても次の日の運んだ荷物によってはベロシティが下がる可能性があります。「あれ?効果なかったかな?」っとなるのです。

ストーリーポイントの場合はその合計がベロシティです。ストーリーポイント「1」の軽い荷物を13個運んだ日と、ストーリーポイント「13」の重い荷物を1つ運んだ日で同じベロシティになります。(どちらも13)

たとえば筋肉がついて運べるスピードが上がった場合、1日のベロシティが「10」から「15」に変わって成長が見えます。また「荷台を購入する」という画期的なアイデアにより運べるスピードが格段に上がった場合も「10」から「30」と大きな成長が見えるのです。
f:id:iucstscui:20201211002425p:plain

まとめ

  • ストーリーポイントは荷物運びでたとえられる
  • 荷台は荷物を運ぶのに役立つ

参考にした記事

www.ryuzee.com
qiita.com