NotionでWebクリップには「Save to Notion」がおすすめ

NotionのWebクリップはChromeの拡張機能で追加できる「Save to Notion」が便利です。
chrome.google.com

Notion Web Clipper との違い

NotionのWebクリップは「Notion Web Clipper」というツールもあります。「Save to Notion」も「 Notion Web Clipper」もどちらもWebクリップのためのツールです。

操作方法

拡張機能を追加するとどちらもChromeから使えるようになります。(左がSave to Notion、右がNotion Web Clipper)

Notion Web Clipper をクリックした場合は下記のように追加するDatabaseを指定し「Save Page」をクリックするとWebクリップできます。

Save to Notionをクリックした場合、Databaseを指定する部分は同じですが、Webクリップする前にデータベースのFieldsも含めて設定できます。

また、特定のFieldsにデフォルトの値を設定することも可能です。上記図の「記事」はデフォルトで設定されています。

また、Webクリップした結果も違いがあります。Save to Notionはアイコンやアイキャッチ画像も埋め込まれています。

(上がSave to Notion)

僕の使い方

Save to Notionを使う前はNotion Web Clipper を使っていました。その時はWebクリップしたあと、Notionのページを開き、Fields の 「種類」に記事タグを設定し、「Tags」に一致するカテゴリ(アジャイル とか デザイン とか)を設定していました。
Save to Notion に変更してからは、デフォルトで「種類」に記事タグが設定されていて、カテゴリを設定するだけになりました。ちょっとした違いですが、後から設定するのと一緒に設定するのでは手軽さと漏れなさが違います。

Androidでの使い方

Notion Web Clipper はNotionアプリをインストールするとAndroidでも使えるようになります。Save to Notionはアプリがありませんので、Chrome拡張機能が使えるブラウザを使う必要があります。僕はKiwi Browserを使っています。Kiwi Browserはアドレスバーやタブを画面下に切り替えると便利です。

まとめ

• Notion のWebクリップはSave to Notionがおすすめ
• AndroidはChorme拡張機能が使えるブラウザを使うとスマホでも便利

プラクティスやフレームワークをふりかえる

日々、書籍や勉強会などで新しい情報を得てブログに書いてはいますが、数か月、数年たつと忘れてしまっていることがあります。また、学んだ時はピン！とこなかったことも、今の自分ならピン！とくることもあると思いました。
ということで今回は開発で使えるプラクティスやフレームワークをふりかえってみました。

むきなおり

カイゼン・ジャーニーやチーム・ジャーニーの書籍で登場したプラクティスです。過去から今を変える「ふりかえり」と違い、未来から今を変える方法です。前回読んだU理論の考えとも似ていると感じました。ありたい姿を思い描いて、現状とのギャップを出す。ギャップを課題に分割して計画だてて進める方法です。

「ふりかえり」と「むきなおり」、どちらかが良いというわけではないです。どちらも実行するのが良いと思っています。頻度は「ふりかえり」週1か2回、「むきなおり」４半期に1回ぐらいが良いかなと思ってます。

ファイブフィンガーによる合意形成

決めることに対する合意度合いを測るプラクティスです。決めたいことに対して全員で同時に指を出して意思を表明します。指の本数と意味合いは以下のとおりです。
1本：反対
2本：どちらかと言えば反対
3本：反対でも賛成でもない
4本：条件付きで賛成
5本：全面的に賛成
（0本を使う説明も聞いたことがあります）

全員5本を目指すことが目的ではなく、違いを見つけて対話し全員が納得して進めるのがコツです。

指の本数の意味を変えればふりかえりにも使えます。例えば、１週間をふりかえってどうだった？と言う質問に対して以下を用意すれば良いです。
1本：失敗だった
2本：乗り切れたけど、満足できていない
3本：可もなく不可もなく
4本：気になるところはあるが、良い感じ
5本：完璧

こちらも同じで、5が多いから良い、少ないから悪いではなく、そこから深堀するのが大切です。応用がきくプラクティスですね。

OODA

PDCAと比較されがちなフレームワークです。以下の頭文字をとってOODA（ウーダ）と呼びます。
Observe（観察）
Orient（状況判断、方向づけ）
Decide（意思決定）
Act（行動）

数年前、アジャイルでPDCAを早く回すんだ！って考えていたとき、とある勉強会でアジャイルはPDCAじゃなくOODAだよ。と教えてもらいました。また、More Effective Agile では速さを生み出すため、ループ以外のショートカットする考えもあることを知りました。

不確実性が高いプロダクト開発は「計画通り」よりも「価値が届けられる」が重視されるため、OODAで観察して作って観察を繰り返すんですね。

INVEST

ちょうどいいユーザーストーリーを表す指針のようなものです。
Independent：独立している
Negotiable：交渉可能である
Valuable：価値がある
Estimable：見積もり可能である
Sized Right（Small）：適切な大きさである
Testable：テスト可能である

MVP(Minumum Valuable Product)を考えるときのヒントにもなりますね。

成功循環モデル

成功循環モデルは「①関係の質」→「②思考の質」→「③行動の質」→「④結果の質」→「①関係の質」というサイクルがあり、はじめに「①関係の質」を良くすれば好循環なサイクルを生まれるといった考え方です。「④結果の質」から良くしようとすると、競争が激しくなったりして「①関係の質」が悪くなり、悪循環なサイクルを生まれるというものです。

ただ「①関係の質」だけを良くすればいいわけでもなく、最終の「④結果の質」が良くなるように「②思考の質」を良くするために目的を明確にしたり、「③行動の質」を良くするためにプロセスを整えたりすることも必要です。

さいごに

ふりかえることで、むきなおりとU理論が関連づいたり、OODAの考えがバージョンアップしていたり、新たな発見がありました。今後も定期的に学んだことを見返したいと思います。

思い込みを取り除け！ / U理論を読んだ

「U理論」ちょくちょく単語は耳にしますが、何か分からないものでした。 どういったものか知るために本書を手に取りました。具体的な部分もありますが、どちらかというと抽象的で、完全に理解するというよりも感覚的に身にまとっておくような内容だと思いました。

U理論［第二版］――過去や偏見にとらわれず、本当に必要な「変化」を生み出す技術

U理論はなんですか？

と質問されたら「思い込みを取り除いて、今まで見えてなかった将来や未来を見つけ、行動する」ためのフレームワークや考え方です。以下にフレームワークの概要をまとめました。1から7へと進んでいきます。

1. ダウンローディング（Downloading）…思い込みや習慣でモノゴトを捉えている状態。
2. 観る（Seeing）…思い込みや習慣による判断を保留して、モノゴトを観ている状態。
3. 感じ取る（Sensing）…自分はモノゴトに影響を与えていて、与えられているということに気付く状態。言い換えると、システム思考のフィードバックループの中に自分も組み込まれていることに気付いた状態。
4. プレゼンシング（Presencing）…「感じ取る」の状態を維持することで、「ダウンローディング」状態では見つけられなかった未来やアイデアが見えてくる状態。
5. 結晶化（Crystallizing）…プレゼンシング状態で見えた未来やアイデアの意図やビジョンを明確にしていく
6. プロトタイプ（Prototypying）…完成前に小規模な範囲で実験し、速いフィードバックと見直しを行うこと。
7. 実践・実体化（Performing）…実験の範囲を広げていく。広がるにつれプロトタイプでは得られなかったフィードバックを取れ入れていく

U理論で例をつくってみる

個人的に分かりやすい例えを考えてみました。

※注:スクラムを例にしますが、スクラムを批判している訳じゃないですよ。

ダウンローディング

プロジェクトの問題はすべてスクラムで解決できると思い込んでいるので、問題が見つかっても、「スクラムで開発すれば良い」「スクラムが回ってないので改善した方がいい」と、現場の状況をろくに観察せずに決めつけている状態です。良くない。

観る

スクラムという方法論はいったん置いておいて、問題の原因を分析し、絡み合っている因果関係を見つけようとしている状態です。スクラムという拘りがプロジェクトを混乱させている要因だと気付き始めます。

感じ取る

問題を分析し、因果関係がわかった。また、その問題に自分も加担していることに気づいた。部分最適ではなく、全体最適するために何ができるか考えている状態です。自身の課題に気づく、チームの課題に気づき、プロダクトの課題に気づいています。

プレゼンシング

スクラムが唯一の解決策だという思い込みを捨て、問題に向き合い、自身と向き合い、関係者と対話し、全体を把握できたため、新しい開発後の姿が見えてきた。

結晶化

プレゼンシングまでの気づきや変化から生まれた新しいアイデアの意図やビジョンをまとめた状態です。それは、今このプロジェクトに必要なアイデアです。

プロトタイプ

生煮えのアイデアを自チームで実験し始めました。すると、実践によって分かった課題が見つかり、アイデアを見直しながら進めています。

実践・実体化

アイデアを自チームで運用し、改善し続けた結果、効果的であることが分かってきました。アイデアを広げるため再現できる形にまとめ、他チームに展開したり、カンファレンスで発表し、新しい課題が見つかりました。引き続き、アイデアをブラッシュアップしている状態です。

小まとめ

ということで、思い込みやエゴにより狭めていた可能性を広げ、自身、チーム、組織など狭い範囲から広い範囲まで考えることで新しいアイデアを実現できるフレームワークです。

大事だと思った考えやキーワードなど

本書の中から大事だと思った考えやキーワードを紹介します。

未来から学ぶ

プレゼンシングの意味は、未来の最高の可能性を感じ、同調し、そこを起点に行動するということだ

過去からの学びも重要だと紹介しつつ、それだけでは不十分で未来からも学ぶことが大切だと書かれています。そして、未来からの学びを起こすプロセスがU理論です。「今までがこうだから」という理由で諦めていたこと、思考停止していたことを、保留して、理想の未来を考え、そこから逆算してアイデアを作るフレームワークだと理解しました。

全体を感じる

本書はシステム思考の考え方も登場します。フィードバックループを理解し全体を感じることで、目の前の問題も自分が引き起こしていることに気づくことが大切です。

境界を意識する

過去の私と未来の私、行動と内面(源)、私と他者、私と組織、チームと組織、会社と社会、色々な部分に境界があります。また、内面も以下のように境界があります。

1. 私の中の私〔I-in-me〕…境界内の私
2. それの中の私〔I-in-it〕…境界内にいることを認知した私
3. あなたの中の私〔I-in-you〕…境界の外から見た私
4. 今の中の私〔I-in-now〕…全体から見た私

これらの境界を意識することで、ダウンローディング状態であることに気づきやすいと感じました。とくに、「行動と内面(源)」です。なぜそのような行動をしたのか。しっかりと向き合うことで今まで見えなかった未来が見えるかもっと思いました。

人生が自分に何をすべきかを呼びかける 声に耳を傾けよ

上記にも書きましたが、U理論は内面を知ることが重要だと書かれています。内面を知るためにマインドフルネスなど具体的な手法も登場しています。その中でもやってみようっと思ったことは「毎日の4分ふりかえり」です。自分を客観視し振り返ることで、内面を知る機会になります。

対話重要

本書でも対話にまつわる話が出てきます。思い込みをなくして「知る」ということが非常に重要で、そのために対話が重要だと思いました。

対話に関する書籍でも、思い込みで決めつけない重要性が書かれていました。「他者と働く」では私とあなたの境界について書かれており、対話についても境界を意識することは大切です。
iucstscui.hatenablog.com
iucstscui.hatenablog.com

最後に

「思い込みを取り除いて、今まで見えてなかった将来や未来を見つけ、行動する」

簡単なようで、できないことだと思います。宗教用語が出てきたりしますが、ロジカルに新しいアイデア（未来）を見つける方法が書かれた本です。
抽象的なこともあり理解して実践するまでに時間がかかりそうですが、読み直したり、少しずつ意識して身につけたいと思います。

PullRequest が Open された時などに GitHubActions を実行する

GitHubActions で PullRequest への操作内容によってトリガーを切り替える方法を調べました。例えば、PullRequest が Open された時だけイベントを実行する方法です。結論から書くと、typesキーワードを記述することで可能です。

docs.github.com

GitHubActions の on は イベントごとにアクティビティタイプが指定できる

たとえば、PullRequest イベントは「assigned、unassigned、labeled・・・removed」の15個のアクティビティタイプが指定できる。PullRequest が作られたときにワークフローを実行したい場合は「opened」を指定する。

サンプル

name: TriggerTest

on:
  pull_request:
    types: [opened, reopened]
  pull_request_review:
    types: [edited]

jobs:
  test:
    runs-on: windows-2019
    steps:
      - name: PullRequest Type
        run: write-host "PullRequest Type"
        shell: pwsh

このサンプルはPullRequest が作成または再オープンされる場合、もしくはPullRequestのレビューのコメントが修正された場合にワークフローが実行されます。typesキーワードを変えることで、実行するトリガーを切り替えることもできます。submittedを指定すれば、PullRequestレビューが完了したタイミングでワークフローが実行されます。

GitHub CLI で GitHub Actions を コントロールする

前回、GitHub CLI を使ってみた - はんなりと、ゆるやかに の記事で初めて GitHub CLI を使ってみました。今回はGitHub CLI を使ってGitHub Actions をコントロールしてみたいと思います。

リポジトリはこちらを使っていきます。
なお、GitHub CLIのバージョンは「v2.0.0」を使っています。
また、サンプルコマンドはワークフローID(12307731)を指定していますが、ワークフロー名(powershell.yml)でも同じ結果です。

ワークフロー の一覧を知る

gh workflow list を実行すると一覧が取得できます。-a というオプションがあり、ワークフロー が有効か無効かによって結果が異なります。以下の結果を見てください。PowerShellTest というワークフローが一つあるため、gh workflow list を実行するとPowerShellTest が取得できています。しかし、そのワークフローをdisable にするとgh workflow list では取得できません。gh workflow list -aを実行することで取得できます。

> gh workflow list
PowerShellTest  active  12307731

> gh workflow list -a
PowerShellTest  active  12307731

> gh workflow disable 12307731
Disabled PowerShellTest

> gh workflow list

> gh workflow list -a
PowerShellTest  disabled_manually  12307731

ワークフロー を実行する

gh workflow run を実行するとワークフローが実行できます。ここで、1点注意があります。実行するワークフローのonトリガーにworkflow_dispatch が設定されていないと実行されません。設定されていない場合は「could not create workflow dispatch event: HTTP 422: Workflow does not have 'workflow_dispatch' trigger」というエラーが発生します。workflow_dispatch をお忘れなく設定してください。
gh workflow run を実行した結果はgh run list --workflow= で確認できます。

> gh workflow run 12307731
✓ Created workflow_dispatch event for powershell.yml at master

> gh run list --workflow=12307731
STATUS   N  AME                                                    WORKFLOW        BRANCH  EVENT              ID          ELAPSED  AGE
-  on に　workflow_dispatch を追加                     PowerShellTest     master              workflow_dispatch  1213868779  9s       0m

ワークフローの詳細を知る

gh workflow view を実行すると指定ワークフローの詳細が確認できます。オプションなしの場合は直近の実行したJobが表示され、-y をつけるとyamlファイルが確認できます。

> gh workflow view 12307731
PowerShellTest - powershell.yml
ID: 12307731

Total runs 6
Recent runs
✓  Jobの名前が分かりにくかったので修正                     PowerShellTest  master  push  1143428361
✓  pwsh から ps1 ファイルを実行するとどうなるのか確認する  PowerShellTest  master  push  1143418024
・・・省略・・・

> gh workflow view 12307731  -y
PowerShellTest - powershell.yml
ID: 12307731

name: PowerShellTest

on:
  push:
  workflow_dispatch:

jobs:
  first_job:
    runs-on: windows-2019
    steps:
      - name: Checkout
        uses: actions/checkout@v2
・・・省略・・・

まとめ

• GitHub CLI で GitHub Actions は簡単にコントロールできます
• gh workflow runするときは、on に workflow_dispatchの設定が必要です

参考資料

cli.github.com
docs.github.com

GitHub CLI を使ってみた

GitHub CLI 2.0 がリリースされたという記事を見ましたが、GitHub CLIとはなんだ？という状態だったので使ってみました。

cli.github.com

GitHub CLI は GitHub をコマンドラインから操作できる

GitHub CLI は GitHub をコマンドラインから操作できるツールです。インストールは上記リンクからダウンロードしインストールすれば使えます。インストール後はghというコマンドが使えるようになります。

使えるコマンドは以下のマニュアルを見ると良さそうです。
gh alias | GitHub CLI

今回はGitHub CLI を使ってみたというブログです。issue を作ってみたいと思います。

まずはログイン

さっそく、issue を作ってみるとエラーがでます。

> gh issue create --title "new issue"

Welcome to GitHub CLI!
To authenticate, please run `gh auth login`.

ようこそ！とは言ってくれますが、あなたはどなたですか？とログインを求められました。
要求されたコマンドを入力してログインしましょう。

> gh auth login

? What account do you want to log into? GitHub.com
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser

接続するサーバー、接続する方法、GitHubの認証情報でGitを認証するか、認証は何で実施するか、が聞かれます。それぞれ必要な方、好きな方を選ぶと良いと思います。最後の質問はブラウザを選択しました。ブラウザを選択するとブラウザが起動され、GitHubのログインが求められます。その後、以下のような認証コードを入力する画面が表示されるため、コマンドラインに表示されているコードを入力すれば完了です。

issue を作る

あらためて、issueを作成しました。Bodyを入力するかどうか聞かれます。e を入力するとメモ帳が起動するので、Bodyとなるメッセージを書いて完了です。

> gh issue create --title "new issue"

Creating issue in iucstscui/GitCloneDepthTest
? Body [(e) to launch notepad, enter to skip]

まとめ

ログイン方法は少し調べましたが、インストールからissue作成までそれほど時間は使いませんでした。次からはコマンドを調べてみようと思います。

「0秒リーダーシップ」を読んで、リーダーシップを発揮する要素を知った

メンバー全員がリーダーシップを発揮できるチームは強い。じゃあ、どうやってそのようなチームを作るのか。それを知るために、0秒リーダーシップを読みました。

０秒リーダーシップ

目次

プロローグ　働き方が変わった　～誰もがリーダーシップを求められる時代～
第１章　だれでもリーダーシップ
第２章　イノベーティブシンキング
第３章　プロトタイプシンキング
第４章　デジタルリーダーシップ　　
第５章　ラーニングアジリティ
第６章　コミュニティリーダーシップ
第７章　コンプレクシティリーダーシップ
第８章　エモーショナルインテリジェンス
第９章　マインドフルリーダーシップ
第10章　リーダーシッププレゼンス

第１章では、リーダーシップは肩書に関係なく全員が発揮できるスキルだと説明があり、以降の章ではリーダーシップに求められる考え方や行動がまとめられています。

リーダーシップはすでに全員が発揮している

本書を読んで思ったことは、リーダーシップはすでに全員が発揮しているということです。
リーダーシップは「ゴールに向かって前進すること」だと定義すると、誰しも何らかのゴールに向かって前進していますよね。そう考えるとリーダーシップを発揮していると考えられます。
でも、あの人はリーダーシップを発揮していないと感じることないですか。それは、あの人と自分の期待しているゴールが違うだけじゃないかと思いました。

だから、もしあの人に自分が思うリーダーシップを発揮して欲しいと思うならゴールについて認識をあわせることがスタートじゃないかと思いました。

リーダーシップとは

本書では複数の切り口で「リーダーシップ」とはこういうことだよっと教えてくれます。
本書の「リーダーシップとは」を私が3つにまとめると以下になります。

• 成果やゴールを目指して行動できる
• 他の人のお手本になる
• リーダーシップは「リーダー」という役割の人だけが発揮するものではなく、全員が発揮するかどうか選べる

この中でも「成果やゴールを目指して行動できる」が重要だと思いました。成果やゴールの目標が高ければ周囲を巻き込む必要が出るでしょうし、その姿は他の人のお手本にもなると思います。

学び、変わり続ける

第５章ラーニングアジリティでリーダーシップと学びについて書かれています。

リーダーシップを発揮するには、つねに学び、学んだことをすぐに応用できる機敏な動きが欠かせません。

じゃあ、どうやって学ぶのか、どうやって応用するのかということですが。
学ぶの3つのポイントは①他人から学ぶ、②経験から学ぶ、③振り返りから学ぶ、でした。そして、その学びを素早く別の場面で活用することがラーニングアジリティで、成長の一歩ということです。

本章を読んで、謙虚は成長するうえで大事だと改めて思いました。「①他人から学ぶ」で他人から学ぶには謙虚な姿勢が必要だと書かれていました。他人から学ぶこともですし、過去から学ぶことも謙虚な気持ちがなければ変わろうと思わなさそうですね。謙虚大事。

また、あとがきに、Learn, Relearn, Unlearn という言葉と共に学ぶ大切さが書かれており、改めて「学ぶ」を続けようと思いました。

EQを高める

第８章　エモーショナルインテリジェンス　では、リーダーシップを発揮するために欠かせない感情のコントロールについて書かれています。自分の感情、他人よ感情、チームの感情、それらを感じとり、建設的なコミュニケーションができるようにコントロールしなければなりません。

難しいですよね。でも、大事なこともわかる。まずは、意識すること、興味を持つこと、が大事だと思いました。自分に対しても感情面をふりかえってみる、相手に対しても、興味を持って色んなことを聞いてみる。まずは毎日、ふりかえりを続けてみて、自分のことを意識する習慣をつけてみようと思いました。

リーダーらしさ

第10章　リーダーシッププレゼンスはリーダーとして認められる行動や伝え方がまとめられています。
少し脱線して、FREE AGENDAというPodcastのリーダーシップって触れるの？という回で「リーダーシップはマインドとスキルはセットで必要」「リーダーシップは周囲にポジティブな影響を与えられる人」だと話されていましました。
話を戻して、この章でも書かれているように、「リーダーとして認められる」には行動も大切な要素だと思いました。

行動と伝え方は伸ばす必要がある。

まとめ

• リーダーシップは全員が発揮するもの
• リーダーらしさは考え方と行動がセット
• 必要な要素は10個あり、どれも伸ばしたほうがいいため、謙虚な気持ちで学び続けたい