はんなりと、ゆるやかに

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

アジャイルプラクティスLT会 <Agile Practices Subway Tour>#1 XP編 に参加した

アジャイルラクティスLT会 #1 XP編 に参加しました。

agiledevs.connpass.com

Subway Map to Agile Practices に書かれているXPのプラクティスの中から4名の方がLTをされました。

発表のハイライト

コードの共同所有

  • コードの共同所有とは?→チーム全員がすべてのコードに責任を持ち修正できる状態
  • 誰でも修正出来ることでリードタイムを短くなる
  • 誰もがコードに責任を持ちコードレビューすることで品質が高くなる
  • でも、コードレビュー大変
  • ペアプロを活用して効率をあげよう
  • しかし、ペアプロの導入も簡単ではない

Product ManagerとXPが交差するユーザーストーリー

  • ユーザーストーリとはBizDevOpsがユーザー視点で共通認識を持てるようになるもの
  • 要望を出す側はシステムが分からない、システムを作る側は要望の背景が分からない
  • Whyはユーザー視点の価値を書く「(Value)という価値があるからだ」
  • 議論が仕様から価値に変わる

1週間ですら見積もれなかったからイテレーションを1日にしてみた

  • 作業が複雑で1週間の計画が立てられない
  • イテレーションを1日した結果、方向転換がしやすくなった
  • プラクティスに縛られず、環境に対応しよう

ベロシティを上手く使って技術的負債を計画的に解消する

  • 技術的負債返済用のバックログアイテムを作る
  • 毎スプリントに技術的負債返済用のストーリーポイントを天引する
  • 大きなアイテムは分割する

学んだことや共感したこと

Subway Map to Agile Practices を知れた

何度か見た記憶はあるのですが、改めてじっくりと内容を確認できました。路線図で表現されていて、XPとProduct Management の交わる部分やスクラムと交わる部分など、発見があります。

ペアプロの力

僕たちのチームでもペアプロの頻度が増えてきています。実施方法は必要に応じてという感じで、デイリースクラムでペアプロしましょうかーっとなるケースが多いです。今回のお話では「コードの共同所有」という視点からのペアプロでしたが、実装に悩んだ時も1人で悩むよりは、2人で悩むほうが心強い。また、話すことで整理できるので悩んでいることを説明するだけで、「あ、そっか。分かった」ってなることも多々。

ユーザーストーリのWhyはValue

ユーザーストーリは「(Who)として(What)をしたい。なぜなら(Why)だ」と説明されることが大半だと思いますし、僕もそう思っていました。そのWhyの部分を「(Value)という価値があるからだ」にすることを知れたのは大きな収穫です。開発する機能の背景を知るためにユーザーストーリを取り入れていこうと思っていたので、参考になりました。

プラクティスには縛られない

「スクラムで開発しよう」とすると縛られがちで、僕もそうでした。今は状況を見ながら開発方法を変えていこうという風に考えられるようになってきました。

緊急度 低×需要度 高 を計画する

f:id:iucstscui:20210224231327p:plain
緊急度と重要度のマトリクスでよく言われますが、緊急度 低×需要度 高 の作業を実行できるかどうかが大切です。分かっているけど、出来ないことがありますよね。プロダクトバックログアイテムに入れて、完成の定義も決めて計画したいと思います。

さいごに

いろんなプラクティスを理解して、状況に合わせて使い分けることが大切だと思いました。
登壇、運営のみなさん、ありがとうございました!

ブラウザ上でGitHubのコードを見るときに便利な方法「1s」

cloneするほどではないけど、GitHubのコードを確認したいときに使える便利方法「1s」を知りました。ブラウザ上のGitHubのコードがVisual Studio Code(VSCode)の見た目と操作方法に変わります。しかも、インストール不要。

github.com

操作方法

1.GitHubリポジトリに移動します。
サンプルとしてgitのページに移動してみましょう。

f:id:iucstscui:20210212223325p:plain

2.アドレスをhttps://github1s.com/に変えます。
https://github.com/git/gitgithub.com に「1s」を追加してhttps://github1s.com/git/gitにします。すると、VSCodeの見た目に変わります。
f:id:iucstscui:20210212223712p:plain

メリット

画面左に出るエクスプローラーが便利

GitHubでコードを読んでいるとき、別のコードを見るためにブラウザの戻るボタン使ったり、一度トップページに戻ってからファイルを探したりと不便でしたが、画面左側にEXPLORERが表示されているのでファイルの移動がスムーズです。

ファイルのタブ表示もできる

GitHubでコードを読んでいるとき、コードを開いたまま別のコードを見たいときありますよね。また、そういうときはコードの意味を調べながら読むのでタブが増えすぎて管理できなくなります。
f:id:iucstscui:20210212224553p:plain

「1s」を使うとブラウザのタブとは別にVSCodeのタブとして管理できるので、コードのタブと調べているタブが混ざらず、管理しやすくなります。
f:id:iucstscui:20210212224822p:plain

VSCodeのショートカットも使える

Ctrl+Shift+F で検索できたり、Ctrl + Alt + 矢印 で 画面を分割できたり、コードを読む効率が向上します。

f:id:iucstscui:20210212225958p:plain

まとめ

  • GitHubのアドレスに「1s」をつけるとちょっとしたコードリーディングの速度が向上する
  • インストールが不要で便利

Visual Studio Code で文字化けせずにSJISファイルを開く

Visual Studio Code の初期設定ではSJISファイルを開くと文字化けします。エンコードを指定して開きなおせば解決しますが面倒。そんな面倒から解放される設定があったのでまとめておきます。

f:id:iucstscui:20210201214756p:plain
文字化けしたSJISファイル

設定方法

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

「files.autoGuessEncoding」を検索してチェックを付けて完成です。
f:id:iucstscui:20210201220304p:plain

これで、SJISファイルを開いても文字化けせずに表示されます。
f:id:iucstscui:20210201215241p:plain

まとめ

簡単な設定で「S-JIS」の自動判別して表示が可能になります。

Visual Studio Code markdownファイルでサジェスト機能(予測変換)をONする

以前、Visual Studio Code(VSCode)で 今日の日付をスニペットを使って入力する方法をまとめました。
iucstscui.hatenablog.com

前回の記事のとおりであれば、こんな感じで予測変換(サジェスト機能)が出ていました。
f:id:iucstscui:20210112234227p:plain

markdownのファイルでも同じように使おうっと思っても予測変換(サジェスト機能)が出ませんでした。。。
f:id:iucstscui:20210125223142p:plain

調べてみると、markdownはサジェスト機能がOFFになっていて、ONにしないと出ないことが分かりました。

設定方法

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

設定画面で 「Configure settings to be overridden for [markdown] language.」と検索し、「Edit in settings.json」をクリックすると設定ファイルが開きます。
f:id:iucstscui:20210125223611p:plain

markdownの項目に設定が書かれた状態で開かれました。ここに書かれている「editor.quickSuggestions」をtrueにすれば設定完了です。「editor.quickSuggestions」がない場合は行を追加してください。

    "[markdown]": {
        "editor.quickSuggestions": true
    },

完成です。これでmarkdownでも予測変換(サジェスト機能)が使えるようになりました。サジェスト機能がなくても「Ctrl+space」でスニペットが使えるので設定はお好みです。
f:id:iucstscui:20210125224652p:plain

まとめ

  • ファイルの種類ごとに設定がかける
  • markdownのサジェスト機能はデフォルトOFF

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つのプロセスで今までよりも伝わる文章になると感じました。そこの詳細は本書に任せて、このプロセスを使って「自分を言葉にのせる」ことが大切だと思いました。

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

まとめ

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