はんなりと、ゆるやかに

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

現在のブランチ名が取得できる git rev-parse を調べた

git rev-parse --abbrev-ref @ というコマンドを見かけて、「rev-parse?」「--abbrev-ref?」とちんぷんかんぷんだったのでrev-parse コマンドについて調べました。ちなみに、git rev-parse --abbrev-ref @ を実行すると、現在のブランチ名が取得できます。同じようなことはgit branch --containsでもできますが、取得できるブランチ名の先頭に「*」が付くのでブランチ名だけが欲しい場合は前者を使った方が良いですね。

git rev-parse は他に何が出来るかを調べました。

git-scm.com

git rev-parse --abbrev-ref @

現在のブランチ名が取得できます。これは便利です。

$ git rev-parse --abbrev-ref @
testBranch

ブランチ名を指定すれば、同じブランチ名が取得できますが、どんな時に使うかはわかりません。

$ git rev-parse --abbrev-ref master
master

git rev-parse @

ブランチが指すコミットのハッシュ値が取得できます。

$ git rev-parse @
71d...(省略)...cb6

$ git rev-parse master
d4d...(省略)...46c

git rev-parse --show-cdup

カレントディレクトリから最上位ディレクトリまでの相対パスが取得できます。サンプルは test1/test2/ のディレクトリから実行した場合です。

$ git rev-parse --show-cdup
../../

git rev-parse --show-prefix

--show-cdup と逆で最上位ディレクトリからカレントディレクトリまでのパスが取得できます。

$ git rev-parse --show-prefix
test1/test2/

git rev-parse --is-inside-work-tree

カレントディレクトリがgitリポジトリかどうか判定されます。

$ git rev-parse --is-inside-work-tree
true

「ユニコーン企業のひみつ」を読んで、働き方を考えた

ユニコーン企業のひみつを読みました。本書はSpotifyモデルで有名なSpotifyがどういった思想でどういった開発をしているのか教えてくれる本です。

本書を読んで感じたこと、取り組もうと思ったことを中心にまとめていきます。

Spotifyをユニークな開発組織として知ったきっかけはSpotifyモデル

Spotifyは音楽やポッドキャストを楽しめるストリーミングサービスで、僕も使っています。Spotifyはサービスとしても良いサービスなのですが、それとは別にSpotifyモデルと呼ばれる開発手法としても有名です。僕もこの開発手法を知り、Spotifyを音楽サービスの会社ではなく、ユニークな開発組織として意識するようになりました。
Spotifyモデルは以下の記事が詳しいです。
lean-trenches.com

また、2020年にSpotifySpotifyモデルを使っていないという記事が注目されたことから多くの方が参考にされる手法だと分かります。本書のあとがきにも今のSpotifyモデルと今のSpotifyとの違いが説明されています。同じモデルを使い続けるのはアジャイルな感じがしないので、有名になった当時のSpotifyモデルが使われていないことは正しい進化だと思います。
agile.quora.com

権限と信頼

本書を読んで一番印象に残ったことは信頼して権限をチームに渡すことです。Spotifyモデルではスクワッドと呼ばれる職能横断の少数のチームで開発されます。スクラムでいうスクラムチームに似ています。カンパニーベットと呼ばれる抽象度の高い会社としての重要事項(たとえば、「モバイルに注力する」)は示されますが、具体的な方法や実現手段はスクワッドで考え決定します。あらゆる情報はオープンにされ、色々なことがチームで決められる仕組みや制度が整えられていました。

「信頼されている」という感覚はモチベーションに大きく影響を与えますね。そして、権限があればスピードも向上します。信頼と権限は開発を進めるうえで大切なことだと改めて思いました。権限が大事だからといって「よしよし、権限委譲が大事なんだな。すべて任せる!」っとなると混乱すると思いますので、デリゲーションポーカーなどを使って期待値と現状をすり合わせて進めるのが良さそうですね。

マネしてはダメ

10章では本書で学んだことの活用方法について書かれています。その中に以下の一文があります。

世界有数の企業の取り組みの研究を続けて、自分たちの役に立ちそうだと思えるものなら何でも試してみることを、私個人としては強くおすすめるする。
~中略~
他所でやっているからといって、そのままコピーしてはだめだ。

完全、同意です。

Spotifyモデルは良さそうだ!さっそく、明日から体制を変えよう」は良くないですね。チームや組織が混乱するだけです。これはSpotifyモデルに限らず、「スクラム」「アジャイル」などどれでも同じです。学び続けることは大切だと思いますし、好奇心があるのは強みです。だからといって今の会社、組織、チームの状況を無視して当てはめると明るい未来は待っていません。僕も経験済みで、こんな発表をしています(笑)
iucstscui.hatenablog.com


何か新しく魅力的な手法を見つけると、今の問題をすべて解決する手法だと勘違いしてしまいます。でも、そんな銀の弾丸は残念ながらありません。「スクラム」のようなフレームワークの形になるとマネしやすく広まりやすいですが、状況に合わせて取り入れ方を工夫しないとうまくいきません。

スクラムフェス大阪2020のふかやみわさんのお話で「やりやすそうな仕掛けは何か間違っている」という言葉があり、ハッとしました!色々なフレームワークはヒントにはなりますが、答えにはならないのです。

「手伝おうか?」

6.6章のタイトルです。次の僕のステップはこれだと思いました。まだまだ自チームのことだけを考えがちです。局所的にはチームという単位で区切られていますが、視野を広げれば同じチームです。視野を広げて自チームで得た情報を外に公開したり、他チームが困っていそうな雰囲気を感じたら声をかけたり、していこうとおもいました。

「手伝う」というよりも、そもそも「それも含めて自分の仕事」と捉えて開発していきたいと思いました。

訳者のあとがき を実現したい

訳者のあとがきに「毎朝、仕事に行きたくなるような、全力を尽くしたくなるような・・・」という一文があります。

scrapbox.io

こちらも完全に同意です。僕も含めて一緒に働くメンバーが毎日充実して楽しく過ごせる環境を作っていきたいと思います。

まとめ

  • Spotifyの働き方や文化を知れる一冊です
  • とても読みやすい本です
  • Spotifyモデル はマネをするのではなく、自分たちの環境に合わせて適応させた方が良いです
  • 毎日、楽しく働きたい

その他、参考記事

スクラムフェス大阪2020 の参加記事書いてます
iucstscui.hatenablog.com

本書でも「学習」が大切だと取り扱われています。僕も「顧客に寄り添いながら継続的に学習している状態がアジャイルじゃないかな」と思っています。
iucstscui.hatenablog.com

システム思考のレベルアップが出来る本 / 世界はシステムで動くを読んだ

世界はシステムで動いている。

問題が起こるたびに再発防止策を考えているのに同じ問題が起こってしまう。良くしようと思って考えた施策が悪い影響を及ぼした。問題は起こっているけど、原因が見つからない。

今を良くしようと考えているのに上手くいかないことありますよね。その原因は出来事に注目して、問題が発生する構造を理解できていないからです。

今回読んだ本「世界はシステムで動く」はシステム思考という考え方を活用して、出来事が起こった構造を見つけて効果的な改善点(レバレッジポイント)の見つけた方を学べる書籍です。

システムとはなにか

システムは「要素」「 相互のつながり」「 目的」 の3種類で表現される構造のことです。たとえば、自転車のシステムならこうです。
f:id:iucstscui:20210430171507p:plain
体力と筋力の力をインプットとして自転車の性能に伝えられ動力に変わります。その力が速度へ変換されるのです。

ポイントは何を要素として洗い出すかです。この図を書くときも悩みました。洗い出す要素が多すぎても少なすぎても良くないでしょう。もっと詳細にもっと広く洗い出すこともできるので、事前に分析する範囲を決めることが重要だと思いました。

この図、「要素」「相互のつながり」はありますが、「目的」はありません。しかし、システムにおいて目的は重要です。(目的は図に表現しないと思ってますが合っているのかな。。。)

自転車で速度を出す目的が目的地に着くことなのか、自転車レースで優勝することなのかによってレバレッジポイントが変わります。「目的地に着く」ことが目的であれば、「体力」「筋力」にプラスして「電力」を追加し、電動自転車として速度を出す改善案が浮かびます。目的が「自転車レースで優勝」の場合は電力を追加するわけにはいきませんので、「体力」「筋力」を高める改善案を考えるわけです。

こんな感じで分析したいシステムを捉えることで改善案が見つかります。

ストックとフロー

上記の図の中で四角で囲った減ったり増えたりする要素はストックと呼ばれ、ストック同士をつなぐ矢印がフローです。何度かシステム思考を使って分析しようとしましたが、何かしっくりこないことがありました。今思うとストックとフローを意識できていなかったため、矢印のつながりが曖昧になっていたように思います。

ストックに入るフローをインフロー、ストックから出るフローをアウトフローと呼び、改善案を考える時はどちらも対象になります。

フィードバックループ

システム思考で図を書くときには2種類のフィードバックループを見つけます。

たとえば、バランス型フィードバックループは以下の形です。
f:id:iucstscui:20210430171810p:plain
目標速度を保つために、体力を使って加速するループです。このような形でシステムを考えるといたるところでループが見つかります。スケジュールを立てて開発を進める時もスケジュールを間に合わせようというバランス型フィードバックループがありますよね。改善案を考える時は悪影響を及ぼしているループを見つけるんですね。

システムは生き物

システムには3つの特徴があると書かれていました。

  • レジリエンス:環境が変わってももとに戻ろうとする力
  • 自己組織化:システム自体がシステムを変える力
  • ヒエラルキー:システムの中のサブシステム

この特徴について読んでシステム自体が意思を持った生き物のように感じました。この感覚を持てたことは大きい。人を変えることは難しいように、システムを変えることも同じように難しいです。

パターンがある

変えることは難しいと言いつつも、本書には問題のパターンと介入するポイントに関するヒントが「第5章 システム の 落とし穴…… と チャンス」「第6章 レバレッジ・ポイント システムの中で介入すべき 場所」に書かれています。システムを分析したあとは5章、6章を辞書のように使っていこうと思います。

6章に書かれていた「パラダイムを超越する」は最近もやもやしていたことが繋がった感覚がありました。(パラダイム=前提)が変わるような考えを受け入れる状態を保ち続けることが変化に強くなる要素だと思いました。

システム思考はあらゆる場面、範囲で使える

範囲の大小に限らずシステム思考の考え方は有効でしょう。しかし、使いこなすには経験が必要です。小さな部分から使ってみます。

子どもとScratchでペンギンゲームを作った

2020年度4月から小学校でも「ブログラミング教育」が始まったそうです。小さい頃からプログラミングに触れておくと、プログラミングの授業が始まっても不安が減りますね。

今回は子どもとドットインストールを見ながらペンギンゲームを作りました。子ども向けのレッスンというわけではありませんが、子どもでも集中して楽しく取り組める内容でした。僕はドットインストールの再生だけして、「Scratch」の操作は子ども1人で行えました。※もともと、子どもは「Scratch」に触れたことがあるレベルです。

作ったゲームはこちらです。右から大小の氷が流れてくるので、スペースキーを押してジャンプしながらよけてハイスコアを競うゲームです。
f:id:iucstscui:20210422235504g:plain

ドットインストールのページはこちらです。
dotinstall.com

レッスンが細かく分かれているのでリズムよく進む

ペンギンゲームのレッスンは1~3分の動画が全23回分あります。1回の動画が短いため「動画を見る→「Scratch」を書く→動画を見る→「Scratch」を書く・・・」とリズムよく進められます。また、動画が短いので子どもの集中力も途切れなかったです。横で見ていた下の子どもは「すぐにおわるやーん」っと笑ってましたが。

作るものがおもしろい

ゲームを作れるということ自体が子どもの興味を引きます。作ったあとも弟と作ったゲームで遊んだり、作ったゲームをさらにオリジナリティを加えて楽しんでいました。

簡単すぎない作り

ジャンプのコードを書くレッスンで感心しました。y座標をただ移動させるだけではなく、自然なジャンプになるように、頂点に向かって徐々に速度を遅くし、頂点から地面は徐々に早くなるように説明されます。ただ作るだけでではなくゲームとして成り立つ工夫がされていました。
f:id:iucstscui:20210423004211p:plain

まとめ

プログラミングを始める時は「何を作るか」を決めることが第一関門です。単純に足し算するようなプログラムを書いても面白くはないですよね。ゲームを作ることで、楽しく学べ、作った後も遊べるのでお勧めのレッスンです。

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

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