はんなりと、ゆるやかに

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

Visual Studio Code の Split in Group でエディターを分割

Visual Studio Code の version 1.61でSplit in Group という機能が追加されたので確認してみました。

code.visualstudio.com

使い方

タブを右クリックし、Split in Group をクリックします。
f:id:iucstscui:20211013225052p:plain

そのタブ内で分割できました。
f:id:iucstscui:20211013225125p:plain

同じグループ内の別タブに移動すると分割されていません。対象のタブのみ有効です。
f:id:iucstscui:20211013225151p:plain

戻すときはタブを右クリックし、Join in Group をクリックします。
f:id:iucstscui:20211013225240p:plain

今までとの違い

今まではグループを分けることで分割が出来ていました。その場合は各グループでタブ管理が求められます。Split in Groupはグループ内で分割できるため手軽に感じました。また、タブによって分割するしないが選べるため、①タブは分割して見比べたいけど、②タブは画面をいっぱい広く見たいという場合にも便利そうです。

グループで分割した図
f:id:iucstscui:20211013225319p:plain

まとめ

  • Split in Group は グループの分割とも似ている
  • グループ内で分割できるため、画面は広く使える

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)
f:id:iucstscui:20211007234713p:plain

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

Save to Notionをクリックした場合、Databaseを指定する部分は同じですが、Webクリップする前にデータベースのFieldsも含めて設定できます。
f:id:iucstscui:20211007235431p:plain
また、特定のFieldsにデフォルトの値を設定することも可能です。上記図の「記事」はデフォルトで設定されています。

また、Webクリップした結果も違いがあります。Save to Notionはアイコンやアイキャッチ画像も埋め込まれています。
f:id:iucstscui:20211008000837p:plain
(上が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回、「むきなおり」4半期に1回ぐらいが良いかなと思ってます。

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

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

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

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

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

OODA

f:id:iucstscui:20210930233529p:plain
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)を考えるときのヒントにもなりますね。

成功循環モデル

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

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

さいごに

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

思い込みを取り除け! / 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 CLIGitHub Actions は簡単にコントロールできます
  • gh workflow runするときは、onworkflow_dispatchの設定が必要です

GitHub CLI を使ってみた

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

cli.github.com

GitHub CLIGitHubコマンドラインから操作できる

GitHub CLIGitHubコマンドラインから操作できるツールです。インストールは上記リンクからダウンロードしインストールすれば使えます。インストール後は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のログインが求められます。その後、以下のような認証コードを入力する画面が表示されるため、コマンドラインに表示されているコードを入力すれば完了です。

f:id:iucstscui:20210903000329p:plain

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作成までそれほど時間は使いませんでした。次からはコマンドを調べてみようと思います。