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

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

marketplace.visualstudio.com

インストール方法

VS CodeのExtensionsでMarkmapを検索するとMarkmapが見つかりますのでインストールするだけです。

使い方

markdownのファイル(拡張子 .md)を開くと、右上にホウキのようなマークが出ます。

それをクリックするとマインドマップのプレビューが表示されます。

markdown記法ごとのマップ

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

見出し

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

見出しのサイズが小さければ(# が多ければ)階層も深くなります。

リスト

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

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

チェックボックス

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

チェックリストは箇条書きリストと同じ見た目になります。

引用

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

引用の数が階層として表現されます。

文字の装飾

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

太字が見づらいですが、装飾もできます。

コードの入力

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

「`」で囲った部分がハイライト表示されます。

折り畳み

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

折り畳みのマークはでますが、展開はされません。残念。

リンク

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

リンクも使えます。

画像の埋め込み

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

画像へのリンクを記述するだけでは何も出ません。

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

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

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

文字を増やせば画像も大きくなりました。

表

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

表を書けばそれっぽく表現されます。

参考

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
座学よりもワークショップがメインのイベントでした。表情、体の書き方、モノの捉え方について学ぶことが出来ました。

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

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

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

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

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

感想

文字だけではなく絵も使って表すことで誤解が減ることが分かりました。また、文字だけよりも見た目も華やかになりますので、積極的に使っていこうと思います。勉強会中に何度も絵を描きましたが、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タブで確認できます。

一覧の中から特定の実行結果を選ぶと詳細ログが確認できます。
成功のログ

失敗のログ

設定ファイルの説明

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-msbuild はmsbuild のコマンドを使えるようにするアクションです。
github.com

      - run: dotnet build
      - run: dotnet test

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

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

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

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

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

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

目的の目的

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

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

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

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

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

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

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

参考にしたサイトや本

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

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

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

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

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

今朝

上司「だから目的と目標がごっちゃなんだって」
私「すみません分かりません」
上「お前が勇者だとして魔王を倒す事が目的になってんだよ」
私「違うんですか？」
上「違うだろ。目的は魔王を倒す事によって得られる世界平和だろ！」
私「…！！すぐ作り直します」

この後めちゃくちゃ捗った。

— xeno (@xeno_37G_Player) 2018年5月8日

スクラムを図解した

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

スクラムの構造を図解

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

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

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

まとめ

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

参考

iucstscui.hatenablog.com

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

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

「考える」考えかた 個人にもチームにも効く思考プロセス (技術の泉シリーズ（NextPublishing）)

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

目次

第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