はんなりと、ゆるやかに

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

「偏愛マップ」と「みんなで記者会見」を混ぜてみた

f:id:iucstscui:20210415080722p:plain
偏愛マップ」と「みんなで記者会見」を混ぜたプラクティスをやってみたので感想です。プラクティスの名前は「偏愛 記者会見」とでもしましょう。ワイワイ盛り上がれました。

偏愛マップ」はこちらで紹介されています。
tamkaism.com
uxmilk.jp
みんなで記者会見」はこちらで紹介されています。
springaki.github.io

やり方

  1. 時間を決めて好きなものとにかく書き出す(偏愛マップを作る)※事前に作っても良い
  2. インタビューアー(聞き手)複数人とインタビューイー(話し手)1人を決める
  3. インタビューイーは書いたものを見せて質問を待つ
  4. インタビューアーは公開された偏愛マップについて質問する
  5. インタビューイーを交代する

感想

好きなことを話すので盛り上がる

インタビューアーは何を聞かれても好きなことです。好きなこと話すことは楽しいですよね。1つの質問から話も広がりやすく盛り上がっていきます。また、「分かることしか質問されない」と分かっているので緊張もほぐれます。

質問形式なので聞き手も前のめりになる

記者会見方式の良いところはインタビューイーから質問することです。質問するためにインタビューアーの偏愛マップをじっくり見ますし、気になったことを質問するので興味を持って聞けます。聞き手が前のめりなので話し手も楽しいです。

知らない一面を知れる

偏愛マップの良いところですね。長年一緒にいても知らないことはあります。こういった機会がないと知れないこともあるのでお互いを知るには良いプラクティスです。「え?なにこのキーワード!」というのが見つかりますよ。

進行も簡単

1つの話題が終わったあとは何を話すか迷う必要がありません偏愛マップに書かれた内容を質問すれば良いのです。また、質問と質問の切れ目に割り込めばインタビューアーの交代もスムーズです。

その他

好きなこと、得意なことを質問されると嬉しいことについて仕組みを考えた記事が面白いです。盛り上がる要因はこの記事と重なる部分もありますね。
dailyportalz.jp

Visual Studio Code を使ってマインドマップをマークダウン記法で書く

マインドマップmarkdown記法で書けるVisual Studio Code(VS Code)の拡張機能を試してみました。

marketplace.visualstudio.com

インストール方法

VS CodeのExtensionsでMarkmapを検索するとMarkmapが見つかりますのでインストールするだけです。
f:id:iucstscui:20210408225208p:plain

使い方

markdownのファイル(拡張子 .md)を開くと、右上にホウキのようなマークが出ます。
f:id:iucstscui:20210408230536p:plain
それをクリックするとマインドマップのプレビューが表示されます。
f:id:iucstscui:20210408230521p:plain

markdown記法ごとのマップ

v0.0.9 で確認しています。

見出し

# 見出し1-1
## 見出し2
### 見出し3-1
#### 見出し4
### 見出し3-2
##### 見出し5
###### 見出し6
# 見出し1-2

f:id:iucstscui:20210408231016p:plain
見出しのサイズが小さければ(# が多ければ)階層も深くなります。

リスト

# 見出し1
* リスト1-1
  * リスト2
    * リスト3
      * リスト4
        * リスト5
          * リスト6
            * リスト7
* リスト1-2
# 見出し2
1. リスト1-1
1. リスト2
1. リスト3  
    1. リスト3-1
1. リスト4

f:id:iucstscui:20210408232041p:plain
箇条書きリストも番号付きリストも対応されています。リストはネストすることで階層を表現できます。

チェックボックス

# 見出し1
- [ ] タスク1
- [x] タスク2

f:id:iucstscui:20210408233020p:plain
チェックリストは箇条書きリストと同じ見た目になります。

引用

# 見出し1
> 引用1-1
>> 引用2
>>> 引用3
> 引用1-2
>>>> 引用4

f:id:iucstscui:20210408233333p:plain
引用の数が階層として表現されます。

文字の装飾

# 見出し1
* ab *cd* ef
* ab **cd** ef
* ab ~~cd~~ ef

f:id:iucstscui:20210409231418p:plain
太字が見づらいですが、装飾もできます。

コードの入力

# 見出し1
* `コード`を書く

「`」で囲った部分がハイライト表示されます。
f:id:iucstscui:20210409230344p:plain

折り畳み

# <details><summary>abc</summary>def</details>

f:id:iucstscui:20210409231004p:plain
f:id:iucstscui:20210409231008p:plain
折り畳みのマークはでますが、展開はされません。残念。

リンク

# 見出し1
* [ブログ](https://iucstscui.hatenablog.com/)

f:id:iucstscui:20210409231816p:plain
リンクも使えます。

画像の埋め込み

# 見出し1
* ![Blog](https://3.bp.blogspot.com/-dknWIXCSs-w/WCqdlXLjszI/AAAAAAAA_j0/AygXNzLm3MclEb3x69Mr195tK84RUfKuACLcB/s800/blogger_man.png) 

f:id:iucstscui:20210409232856p:plain
画像へのリンクを記述するだけでは何も出ません。

# 見出し1
* ![Blog](https://3.bp.blogspot.com/-dknWIXCSs-w/WCqdlXLjszI/AAAAAAAA_j0/AygXNzLm3MclEb3x69Mr195tK84RUfKuACLcB/s800/blogger_man.png) blog

f:id:iucstscui:20210409233049p:plain
画像へのリンクのあと、文字を追加するとその文字分の幅に収まる形で画像が表示されます。

# 見出し1
* ![Blog](https://3.bp.blogspot.com/-dknWIXCSs-w/WCqdlXLjszI/AAAAAAAA_j0/AygXNzLm3MclEb3x69Mr195tK84RUfKuACLcB/s800/blogger_man.png) blogblogblogblog

f:id:iucstscui:20210409233129p:plain
文字を増やせば画像も大きくなりました。

| 左 | 中 | 右 |
|:-----------|------------:|:------------:|
| 左1 | 中1 | 右1 |
| 左2 | 中2 | 右2 |

f:id:iucstscui:20210409233741p:plain
表を書けばそれっぽく表現されます。

参考

qiita.com

「イシューからはじめよ」を読んで、良いイシューを見つけるスキルを学ぶ

「イシューからはじめよ」を読みました。僕には色々とやりたいことがあります。そのやりたいことをそのまま手段から入ってしまうので、「なんのために取り組むの?」と質問されたとき、「やりたいから!」と答えになっていない答えを返してしまいます。これでは、まわりを巻き込みながら進めることは困難です。

「こういう理想があります。今はこういう現状です。理想の状態にするにはこの課題を解決する必要があるんです!だから、この手段を使うのです!!!」

このように、課題を見つけ、その課題を解決する手段としてやりたいことを使えればよいのです。だから、必要性の高い課題を見つけることが重要なのです。

本書は必要性の高いイシューに取り組む重要性と特定方法が学べます。また、そのイシューの伝え方が学べます。

目次

  • 序章 この本の考え方―脱「犬の道」
  • 第1章 イシュードリブン―「解く」前に「見極める」
  • 第2章 仮説ドリブン(1)―イシューを分解し、ストーリーラインを組み立てる
  • 第3章 仮説ドリブン(2)―ストーリーを絵コンテにする
  • 第4章 アウトプットドリブン―実際の分析を進める
  • 第5章 メッセージドリブン―「伝えるもの」をまとめる
  • おわりに 「毎日の小さな成功」からはじめよう

必要性の高いイシューに取り組むと生産性が高くなる

解くべき問題を見極める。これが本書を通して伝えたいことだと思います。

問題の多くは解決する必要がありません。数少ない解決すべき問題を見つけ、同じ労力でも大きな成果を出しましょうと序章で説明されています。

  • 生産性は「成果(アウトプット) / 投下した労力・時間(インプット)」
  • 成果は「解の質✕イシュー度」
  • 解の質は「イシューに対する明確に答え」
  • イシュー度は「問題に答えを出す必要性の高さ」

スクラムだとふりかえりで見つかるTryやプロダクトバックログの順番に使える考え方ですね。それ以外でも年始や年度始まりで目標を立てる際にも使える考え方です。自分の立場でしか解けないイシューと向き合うのです。

イシューを見極める

「第1章」では必要性の高いイシューの特定、見極め方が学べます。特に「仮説を立てる」という考えを知れたのは良かったです。「ブログを書くとどうなるのか?」ではなく、「ブログを書くことで技術力が向上するのではないか?」と答えを知りたいことについて明確に問うことで、調べる範囲が絞れて無駄な作業を減らすことができるということです。

本書の中で良いイシューの3条件として紹介されている1つにも仮説が含まれています。

  • 良いイシューの3条件
    • 本質的な選択肢:イシューに答えが出たとき、今後の方向性に変化が起きるかどうか
    • 深い仮設がある:直観に反するか、新しい発見があるか(共通性、関係性、グルーピング、ルール)
    • 答えを出せるか:今の技術で答えが出せない課題は着手しない

仮説の立て方は「問いのデザイン」も参考になります。
iucstscui.hatenablog.com

情報収集

仮説を立てるにも材料が必要で、その材料の収集方法についても「第1章」に書かれています。そこで3つのコツが紹介されていて、その中でも「一次情報に触れる」は大切にしたいと思いました。人づてではなく、自分の五感を使って得た情報は大きいです。実際に作ったプロダクトを使っているユーザーを見ると、ちょっとした仕草が気になったりします。そして、それは誰かがまとめたレポートでは省かれる可能性があるため、一次情報に触れることは大切だと思います。

  • 一次情報に触れる
  • 基本情報をスキャンする
  • 集め過ぎない・知り過ぎない

イシューを分解し、ストーリーにまとめる

「第2章」はイシューを分解し、ストーリーにまとめる方法が学べます。ストーリー?っとなるかもしれませんが、「問いのデザイン」では「課題」を「関係者の間で「解決すべきだ」と前向きに合意された問題のこと」と定義されていて、関係者と合意するために納得できるストーリーが不可欠になるのです。

分解はMECE(ダブリなくモレなく)で意味のある切り口で分解する必要があり、そのためのフレームワークが紹介されています。3C分析やビジネスシステム、など切り方は色々ありますが、重要なことはMECEであるかどうかです。一人でMECEかどうか気づくことは厳しいと思いますので、相談しながら進めると良さそうです。

ストーリーラインは2つの型が紹介されていました。そのうちの「空・雨・傘」という手法は初めて知りましたが、僕の弱さを補う手法だと思い、知れて良かったです。「黒い雲が増えてきている」→「雨が降りそうだ」→「傘を持っていこう」の順に「前提の確認」→「課題の深堀」→「結論」の形に当てはめて説明する手法です。手段から入りがちな僕としては前提の考慮漏れなどに気づける型です。

ストーリーを図解する

「第3章」はストーリーラインを伝えるための図解について説明されています。
分析とは比較することと本書で説明されており、比較、構成、変化を表現する例や軸の考え方からデータの取り方まで学べます。

分析でぶつかる罠

「第4章」は分析を始めたときの心構えと起きやすいトラブルとその解決方法について学べます。データ集めが難しいときのフェルミ推定、回転率、スピードを上げるための60%の完成度を目指すなどです。

必要性の高いイシューに取り組むということは、今の当たり前を疑い、大きく変えようとする取り組みなので簡単には答えが出ないと思います。本章で書かれたヒントを活用して四苦八苦しながら前進するしかなさそうです。簡単な問いじゃないことは分かってます。

イシューを伝える

「第5章」はこれまでの分析した結果について整理整頓し伝えるコツが具体的に書かれています。具体的な方法が書かれているのですが、この章で大事だと思った部分は抽象的な以下です。

第一に聞き手・読み手と自分の知識ギャップを埋める。聞き終わったあと同じ問題意識を持ち、同じように納得し、同じように興奮してくれるのが理想。

ひとつ、聞き手は完全に無知だと思え
ひとつ、聞き手は高度の知性をもつと想定せよ
(デルブリュックの教え)

何か考えを発表したとき、発表者と受け手で温度差を感じることがあります。その謎は本書を読んで解けました。前提の理解度が違うからですね。発表者は時間をかけて検討したため、受け手の知らない情報(前提)があります。それを伝えずに結果だけ発表するため、伝わらず温度差が生まれるんですね。良いイシューを見つけられるようになっても、伝え方でミスすると行動に結びつかないと思いますので、本章も重要です。

まとめ

  • 取り掛かるよりも前に、良いイシューか検討する
  • イシューを見極めることで生産性が上がる
  • イシューは仮設として言語化する
  • イシューを伝えるときは前提から説明する
  • 今年のテーマでもある図解は引き続き学んでいく

関連ブロク

言語化するヒントになる書籍
iucstscui.hatenablog.com

仮説などを考える際のヒントになる書籍
iucstscui.hatenablog.com

「【オンライン開催】図解・ビジュアル化の基本講座~言葉を図解化する方法~」に参加しました

【オンライン開催】図解・ビジュアル化の基本講座~言葉を図解化する方法~ に参加しました。

uxdt.connpass.com
座学よりもワークショップがメインのイベントでした。表情、体の書き方、モノの捉え方について学ぶことが出来ました。

ビジュアル化は難しくない

マンガやアニメ、アート作品のような絵を描くことは難しいですが、伝わる絵はシンプルな形の組み合わせで表現できるため難しくありません。形を捉える訓練とシンプルな形を書く訓練で上手になると分かりました。

f:id:iucstscui:20210401000713j:plain
ワークショップで書いたスマホと鉛筆と時計です。主にはでできています。シンプルに捉えること自体の難しさはありますが、物を観察するとき□と○と△で表現するにはどうすれば良いか?を考えればコツは掴めるかなと思いました。
この、シンプルな形を書く訓練も大切です。ワークショップでも○を書く時間がありました。キレイな○を書くのは難しい。

形のないものを表すと違いが分かる

心理や概念など形がないものを伝えるときにビジュアル化は有効です。抽象的な言葉を使って会話していると、AさんとBさんで同じ単語を認識しながらも、違うイメージを持っているかも知れません。下の絵は「カリギュラ効果」を表現した絵です。他の参加の方々は違う表現をされていました。絵にすることでイメージの違いが明確になります。
※他の方のイラストは「 #UXDTワークショップ 」でTwitterを検索すると見つかります。

f:id:iucstscui:20210401001257j:plain

感想

文字だけではなく絵も使って表すことで誤解が減ることが分かりました。また、文字だけよりも見た目も華やかになりますので、積極的に使っていこうと思います。勉強会中に何度も絵を描きましたが、20秒とか5分以内とか短い時間で書きました。短い時間だからこそ、シンプルに表現し、わかりやすい絵になったと思います。凝るよりはシンプルで伝わりやすい絵を心掛けていきます。

GitHub Actions で ビルド→テストを実行する(Windows+C#+NUnit)

はじめに

GitHub Enterprise 3.0.0 で GitHub Enterprise にもGitHub Actions が搭載されました。これをきっかけに勉強を始めていきます。
docs.github.com

今回はGitHub Acionsで Windows + Visual Studio + C# + nunit でビルドからテストまで実行してみます。実行の手順と設定ファイルの説明をまとめます。

GitHub Actionsとは

GitHub Actions とは CI/CD を実現する機能です。CI/CDと言えば Jenkins や CircleCI が有名ですね。 Jenkins や CircleCI は別サービスですので新たに環境構築したり、登録する必要があります。GitHub Actions を使えばGitHub だけでCI/CDを実現できます。

github.co.jp

導入手順

1 リポジトリの用意

事前にGitHubのアカウントとリポジトリを用意しましょう。以下は今回の勉強用に作成したリポジトリです。
github.com

2 GitHub Actions 専用のYAMLファイルを用意

「.github/workflows/」 のフォルダを作成し、YAMLファイルを配置します。これで設定が完了です。内容は「ビルドしてテストを実行する」です。「ビルドしてテストを実行する」のような一連のプロセスはワークフローと呼びます。

name: MSBuild

on: push

jobs:
  build:
    runs-on: windows-2019
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Add msbuild to PATH
        uses: microsoft/setup-msbuild@v1.0.2

      - run: dotnet build
      - run: dotnet test

3 実行結果を確認する

上記の設定で push のたびにワークフローが実行されています。実行結果はActionsタブで確認できます。
f:id:iucstscui:20210327200728p:plain

一覧の中から特定の実行結果を選ぶと詳細ログが確認できます。
成功のログ
f:id:iucstscui:20210327201022p:plain
失敗のログ
f:id:iucstscui:20210327201113p:plain

設定ファイルの説明

on: push

設定するワークフローの開始トリガーを設定します。この設定は「push」をトリガーに実行されます。設定できる文字列は下記ページが参考になります。
docs.github.com

    runs-on: windows-2019

実行するOSを設定します。設定できるOSは下記ページが参考になります。
docs.github.com

      - name: Checkout
        uses: actions/checkout@v2

actions/checkout はワークフローからリポジトリにアクセスできるようにするアクションです。
github.com

      - name: Add msbuild to PATH
        uses: microsoft/setup-msbuild@v1.0.2

microsoft/setup-msbuildmsbuild のコマンドを使えるようにするアクションです。
github.com

      - run: dotnet build
      - run: dotnet test

run はOSのCLIを操作するコマンドです。dotnet build でビルドし、dotnet test でテストを実行しています。

目的設定について整理した

目的は「実現しようとしてめざす事柄。行動のねらい。めあて。」
目標は「そこに行き着くように、またそこから外れないように目印とするもの。」
goo辞書 - 国語・英語・四字熟語のオンライン辞書より

「目的」について考える機会があったので、調べた結果をまとめます。

目的と目標の違い。目標は目的にたどり着くためにある。

f:id:iucstscui:20210318235047p:plain

目的は「ありたい姿」です。目標は目的を達成するための手段を表現します。たとえば、「ブログを継続する」という目的があるとします。これに対する目標は「1ヶ月以内にブログネタのストックを20個つくる」や「毎週1記事以上、ブログを更新する」です。

目的の目的

f:id:iucstscui:20210319233603p:plain
先ほど「ブログを継続する」という目的をたてました。そもそも、なぜブログを継続するのでしょう。僕がブログを書く理由は「技術力を高めるため」です。ブログ駆動で新しいことを学んだり、整理するきっかけを作って技術力を高めたいと思っています。

目的はこのように連鎖しています。上位にいけばいくほど抽象的になっていきます。「技術力を高める」にもその上位目的がありますし、その上位目的にもさらに上位目的があります。「なぜ、それをするのか」を問うことで上位目的を見つけられます。

上位の目的がわかれば手段が増える

「技術力を高める」という目的の目標を考えてみましょう。「ブログを継続する」、「新しい言語にチャレンジする」、「勉強会に参加する」とブログを継続する以外の手段も考えられます。上位目的から考えることで他の手段に気づけます。その中からより効果の高い目標設定ができます。

どこまで上位を考えれば良いのか

ここで疑問がわきます。どこまで上位目的を考えたら良いのか。まず、今から取り組むタスクの目的は考えた方が良いです。「何のために、このタスクに取り組むのか?」が答えられると手段が増えますし、やらなくてよいことも明確にできます。さらに、以下の要素が含まれているかが重要そうです。含まれていない場合は「なぜ、この目的に取り組むのか」を考えた方が良いと思います。

  • 達成できる見込みはあるか
  • 達成したあとの状態が明るく想像できるか
  • 自分、もしくは誰かに価値を届けられるか
  • チャレンジングかどうか

参考にしたサイトや本

7.1.1 理想と現実 – ロジカルシンキングことはじめ

プロジェクトマネジメントを加速させる良質な目的設定の5C|Goodpatch Blog グッドパッチブログ

目的と目標の違い・目的と目標の例3つ-言葉の使い方を学ぶならMayonez

【習慣化のコツ①】最上位目的を明確に|shaun@山本武史|note

第3回 パーパス・ドリブンのコンセプチュアルプロジェクトマネジメント|Tetsuto Yoshikawa(m&t)|note

スクラムを図解した

今年は図解を練習する年にしています。今回はスクラムを図解してみました。
iucstscui.hatenablog.com
スクラムガイド2020を参考にしています。

スクラムの構造を図解

f:id:iucstscui:20210311223420p:plain
スクラムの構造はシンプルですね。スクラムチーム、スクラムイベント、スクラムの作成物の大きく3つの要素でできています。スクラムチームは役割が定義され、スクラムイベントはミーティング形態が定義され、作成物は作業や価値の表現方法が定義されています。

透明性、検査、適応との関連を図解

f:id:iucstscui:20210311224334p:plain
スクラムは3本柱、透明性、検査、適応が重要です。上記の要素と3本柱の関係を図に表しました。たとえば、スプリントレトロスペクティブ(ふりかえり)は各メンバーが感じる課題や問題点、良い点が見える化(検査)されます。悪かったところは良くなるように、良かったところはより良くなるように次回スプリントでどうするかを決定(適応)します。そのため、検査、適応が含まれているため、重なる部分に配置しました。

まとめ

  • ロジックツリー図とベン図を使った
  • ロジックツリー図は構造分析に使える
  • ベン図は集合の関連を表せる