はんなりと、ゆるやかに

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

考え上手になるヒントが見つかる / 「考える」考えかたを読んだ

解決策を「考える」、目標を「考える」、カメラの購入を「考える」。生活は考えることの連続です。でも、考えることは苦手という人は少なくないでしょう。僕もその一人です。日常のちょっとしたこと、仕事で難しい決断をするとき、あらゆる場面で参考になる「考える」が学べる書籍『「考える」考えかた』を読みました。

本書で「考えるとは発散と収束を行うこと」と定義されています。たとえば、カメラを購入しようと思ったときカメラに関するいろいろな情報を集めます。「値段、機能、重さなどなど・・・」これが発散です。その集めた情報から自分の用途にぴったりのカメラを比較して選ぶのです。これが収束です。課題を特定するときも発散と収束を、解決策を決める時も発散と収束をしましょうっと書かれていました。本書は現状を把握するための考え方、課題を見つけるための考え方、解決策を決めるための考え方、それぞれのフェーズに分けた考え方について学べる書籍です。

目次

第1章 そもそも「考える」って何だろう?
第2章 考える枠を決める
第3章 課題を特定する
第4章 解法を特定する
第5章 チームで「考える」ために気をつけること
第6章 「考える」実践例

具体的な理想を描く

「今からチームを良くするアイデアを出そう!」っという目標がアンチパターンとして取り上げられていました。そのままやった事があるので、グサリと来る例でした。さて、何がダメなのでしょうか。それは、理想が具体的でないからです。本書の言葉では「考える枠を決める」と書かれています。チームで何を決める時、抽象度が高い理想だとAさんとBさんで見ている理想が異なる可能性があります。その状態で事実を洗い出したり、解決策を洗い出してもブレが生じてまとまりませんね。

本書では具体的にするフレームワークが複数紹介されています。その一つはSMARTです。SMARTは目標を立てるフレームワークとして有名で、調べると色々な記事が見つかります。Specific(具体的)、Measurable(達成を判断できる)、ActionOriented(アクションに落とせる)、Relevant(意義が明確)、TimeLimited(期限が明確)の頭文字です。ふりかえりでActionを決める時に使われたりもしますね。

今の状態を把握して課題を見つける

「As is / To be」「GROWモデル」など理想と現状のギャップから課題を見つけるフレームワークがありますね。具体的な理想と現状がわかれば的確な課題が見つけられます。

第3章 課題を特定する では現状を洗い出して課題を見つける方法が学べます。ここで発散と収束を使います。事実だけでなく感情も集めてみたり、過去、未来という時間軸でも集めてみます。発散させるとき収束させるときに使えるフレームワーク(SWOT分析や因果関係図などなど)が紹介されています。この中で今注目している技術は因果関係図です。SCRUMMASTER THE BOOKでもシステム思考が紹介されており、身に着けたい技術です。

最良の解決策を見つける

第4章 解法を特定する では第3章までで見つかった課題に対して「重要度×緊急度のマトリックス」や「マンダラチャートを使ったアイデア出し」など、解決策を見つけ収束させるフレームワークが複数紹介されています。どのフレームワークを使うかはファシリテータの腕の見せ所ですね。引き出しを多く持って適切なフレームワークを提案できるようになりたいです。

著者の勉強会で発表されたスライド

著者が発表されたスライドもリンクを張っておきます。

まとめ

「考える」ということについてコンパクトにまとめられた書籍なので「考える」が苦手な方にはお勧めの書籍です。紹介されているフレームワークには知っているものもあったので、知識としてあるだけで使いこなせてないなーっと実感しました。

書籍では「具体的」が重要であると気付けました。冒頭で書いた「カメラを購入する」も具体的ではないですね。「どこで、どういうとき、どれぐらい、何を撮る」といったように具体的にすることで間違った選択をせずに済みそうです。「具体的」は個人のときもチームのときも意識していきたいです。

関連

課題を見つけたり、解決策を考える際に「問いのデザイン」は役立ちそうです。
iucstscui.hatenablog.com

参考

「SMART」
globis.jp

「As is / To be」
ruimaeda.com

「GROWモデル」
www.kikakulabo.com

「マンダラチャート」
iucstscui.hatenablog.com

アジャイルプラクティス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

まとめ