はんなりと、ゆるやかに

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

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

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

目次

プロローグ 働き方が変わった ~誰もがリーダーシップを求められる時代~
第1章 だれでもリーダーシップ
第2章 イノベーティブシンキング
第3章 プロトタイプシンキング
第4章 デジタルリーダーシップ  
第5章 ラーニングアジリティ
第6章 コミュニティリーダーシップ
第7章 コンプレクシティリーダーシップ
第8章 エモーショナルインテリジェンス
第9章 マインドフルリーダーシップ
第10章 リーダーシッププレゼンス

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

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

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

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

リーダーシップとは

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

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

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

学び、変わり続ける

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

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

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

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

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

EQを高める

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

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

リーダーらしさ

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

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

まとめ

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

GitHub ActionsでPowerShellを実行する

GitHub ActionsでPowerShellを実行する方法を調べて、サンプルコード書いたのでまとめておきます。ワークフローから直接実行するパターンと、ps1ファイルを実行するパターンがあります。今回まとめてみて分かったことは、書き方によって実行されるPowerShellのEditionやVersionが異なることです。

コードはこちら

github.com

GitHub Actionsのワークフローはこちら

name: PowerShellTest

on: push

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

      - name: Display hello world pwsh
        run: |
          write-host "hello world pwsh"
          $PSVersionTable
        shell: pwsh

      - name: Display hello world powershell
        run: |
          write-host "hello world pwsh"
          $PSVersionTable
        shell: powershell

      - name: run ps1File cmd
        run: powershell -NoProfile -ExecutionPolicy Unrestricted ./helloworld.ps1
        shell: cmd

      - name: run ps1File pwsh
        run: powershell -NoProfile -ExecutionPolicy Unrestricted ./helloworld.ps1
        shell: pwsh

ワークフローから直接実行する方法

ワークフローのこの部分がPowerShellを実行している部分です。

     - name: Display hello world pwsh
        run: |
          write-host "hello world pwsh"
          $PSVersionTable
        shell: pwsh

shell: pwsh と指定するとPowerShell Coreとして実行されます。実行結果を見てもPowerShell Coreとして実行されていることがわかります。

Run write-host "hello world pwsh"
  write-host "hello world pwsh"
  $PSVersionTable
  shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'"
hello world pwsh

Name                           Value
----                           -----
PSVersion                      7.1.3
PSEdition                      Core
~省略~

shell の指定を powershell と書くと、Windows PowerShell として実行される

上で紹介した構文との違いはshell: powershellだけです。

      - name: Display hello world powershell
        run: |
          write-host "hello world pwsh"
          $PSVersionTable
        shell: powershell

この違いで実行されるPowerShellのEditionがDesktopに変わっていることがわかります。PowerShell 7.0以上で追加された機能を使う場合は、pwshを指定したほうが良いです。

Run write-host "hello world pwsh"
  write-host "hello world pwsh"
  $PSVersionTable
  shell: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.EXE -command ". '{0}'"
hello world pwsh

Name                           Value                                                                                   
----                           -----                                                                                   
PSVersion                      5.1.17763.1971                                                                          
PSEdition                      Desktop     
~省略~

ps1 ファイルを実行する

ps1 ファイルを実行するのは以下の部分です。

      - name: Checkout
        uses: actions/checkout@v2
~省略~
      - name: run ps1File cmd
        run: powershell -NoProfile -ExecutionPolicy Unrestricted ./helloworld.ps1
        shell: cmd

shell: cmdshell: pwshから ps1ファイルを実行すればOKです。注意点はチェックアウトを忘れずにです。サンプルコードを書いているときに「なぜか実行されない」と思っていたらそもそもファイルがなかったという凡ミスをしたので、注意してください。また、shell: cmdshell: pwsh どちらで実行してもPowerShellのEditionはDesktopとして実行されました。

まとめ

  • GitHub Actions で PowerShell を実行する方法がわかった
    • ワークフローから直接実行、ps1ファイルを実行、どちらも可能
  • 構文の書き方の違いで実行されるPowerShellのバージョンが変わるため注意が必要
    • 特別な理由がない限り、shell: pwsh で実行したほうが良い

参考2

GitHub Actionとは?については過去に書いています。
iucstscui.hatenablog.com

ふりかえりについて考えてみた

なぜ、ふりかえりをやっているのか。

雑談の中で聞かれることがたまたま重なって、説明はするものの自分の考えをうまく言葉にできず、一度まとめてみよう。と思ったのがこの記事です。ちなみに、対象はチームのふりかえりです。

ふりかえりとは

私が思うふりかえりは「これまで」を「これから」に活かすことです。

「これからに活かす」は幅広く考えていて、具体的なアクション以外にも、「Aさんはこういうことで悩んでいたんだ」っといったメンバーを知ることも含まれています。知ることで「これから」の行動に少なからず活かされると考えているんです。

昔、勉強会かカンファレンスで、「ふりかえりでTryが出なくても良いんだよ」と仰ってる方がいて、当時は理解できずモヤッとしてたんですが、今なら大いに賛成できます。Tryを出すことがふりかえりのゴールではなくて、「これから」を良くすることが大切なんです。

頻度は最長でも月1回

ふりかえりの頻度は月1回以内が良いと思います。前回のふりかえりから次回のふりかえりの期間が長いと、色々忘れてしまいますよね。また、次のふりかえりまで問題が放置されたり気づかなかったりするので短いほうが良いと思います。

効果1:前よりも良くなる

ふりかえりをすると前よりも良くなります。起こった問題を話し合って、改善策を考えて実行すると、改善前と比べて良くなります。分かりやすい効果ですね。

効果2:チームメンバーのことを知れる

ふりかえりをするとチームメンバーの意見が聞けるので、一人ひとりの考え方や価値観を知ることができます。同じ経験から違うことを感じ、それを共有しあえるっておもしろくないですか。お互いを知ることはチームビルディングとしても効果的です。

効果3:考えるきっかけ

究極、開発の中で常にふりかえりのようなこと(全員が頻繁に考え方を共有したり、問題を見つけて共有して改善したり、強みを見つけて共有して改善し続けること)ができた方が良いと思います。そうであれば、ふりかえりという場がなくても良さそうです。しかし、さすがに難しい。忙しい状況になると目の前のタスクに集中して他が考えられなくなります。そして、だいたい常に忙しい。

忙しいという状況の中でも「これまで」を「これから」に活かすにはふりかえりという場を作ることが大切です。忙しくて面倒でもふりかえりが始まれば「これまで」を考えます。そこで忙しさについて考え、改善策が見つかり、緩和されるかも知れません。

ふりかえりは忙しいからできないというケースは多いと思いますが、考えるきっかけをつくため、忙しいからこそ、ふりかえりを実施してみてください。

RULER モデルが気になる

More Effective Agile を読んでRULER モデル を知りました。RULER モデルはMore Effective Agile で他者と良好なコミュニケーションをとるためのスキルとして紹介されていました。書籍では概念に触れる程度でしたが、気になり追加で調べてみました。

RULER とはなにか

RULERとは感情に関わるスキルを伸ばす教育プログラムで以下の5つのスキルの頭文字をとったものです。

Recognizing: 自身と他者の感情を認識する
Understanding: 感情の原因と結果を理解する
Labeling: 感情を正確に表す言葉を選ぶ
Expressing: 感情を適切に表現する
Regulating: 感情を効果的にコントロールする

SELへの体系的なアプローチとして教育現場で使われることが想定されていて、4つのツールがありそれを活用して進めていくようです。

参考
RULER — Yale Center for Emotional Intelligence
心の知能指数【EQ】を養う5つのスキル「R.U.L.E.R.」とは? | ココロジー
RULER イェール大学の教育者向け感情教育 - 日々是Is'+ (アイズプラス)

調べているとわからない単語が2つ出てきました。EIとSELです。

EIとはなにか

EIは感情的知性(Emotional intelligence)のことで、自身と他者の感情を認識し、自分の感情を制御する能力です。似た言葉でEQはEIを測る指標です。

さてこのEI、PMBOKにも登場しているようで、ソフトウェア開発と無関係ではなさそうです。プロジェクトマネジメントする人は感情をコントロールして、チームのモチベーションを上げるとともに安定をもたらさなければなりませんね。

参考
感情的知性(EI)とは何か?EIとEQの違いを含めて解説 | Promapedia
EI(感情的知性)とは?EIを伸ばすメリットと活用法

SELとはなにか

SELとは「Social and Emotional Learning」の略で、アメリカの教育現場でトレンドになっているらしく、EIを高める学習のために使われています。

SELとは、他の人々とうまくやっていったり、自分や相手の感情を理解することによって、社会の中で適切に行動できるための知識やスキルを学習していくことを指します。

また、派生した考え方としてSEL-8があります。日本の教育事情に合わせた学習プログラムです。

8つの社会的能力を育てる
①自己への気づき,②他者への気づき,③自己のコントロール,④対人関係,⑤責任ある意思決定,⑥生活上の問題防止のスキル,⑦人生の重要事態に対処する能力,⑧積極的・貢献的な奉仕活動,という8つの能力を育みます。

参考
社会性と感情の学習「SEL(対人関係能力育成)」とは - Educedia(エデュケディア)
SELとは|学びプロダクション 株式会社roku you
エビデンスに基づいた 安全な生活環境づくり「エビサポ」 : 対人関係能力育成プログラム SEL-8S

まとめ

  • EIは共感力や感情のコントロール能力のこと
  • SELやRULERはEIを高めるための学習プログラム
  • 「1.観察、2.感情、3.ニーズ、4.要求」というプロセスでコミュニケーションをとるNVCも合わせて理解すると良さそう
  • 「準備 、観察、解釈、介入」という対話のプロセスも参考になりそう

さいごに

チームで働くとコミュニケーションが必ず発生します。すべての意見が一致するわけはないので、ネガティブな感情も発生します。そのとき、前向きに話せるようにEIを高めることは重要でしょう。個人ではなく、チーム全員のEIを高める施策として、SELやRULERは参考になりそうだと思ったので、良い本を探して読んでみようと思います。

More Effective Agile は 実践的でいい。

More Effective Agile を読みました。CODE COMPLETE の著者であるスティーブマコネル氏が実践的なアジャイルについてまとめた良書です。

どんな本?

目次

Part1 はじめに:より効果的なアジャイル
Part2 より効果的なチーム
Part3 より効果的な作業
Part4 より効果的な組織
Part5 おわりに

概要

Part1ではアジャイルが有効である点についてまとめられています。アジャイルとシーケンシャル開発を対比させ、相違点と共通点について記述し、その優位性を明らかにしています。さらに、Cynefinフレームワークを用いて、アジャイルが活躍するプロジェクトの領域について学べます。どういうときにアジャイルが役立つのか?(多くの場合に役立つのですが)、アジャイルが役立つのはなぜなのか?という疑問が解けるPartです。

Part2〜はチーム、開発、組織でアジャイルを実践するためのプラクティス活用方法が紹介されています。それぞれのプラクティスの説明に当てはまるのですが、「アジャイルはこうあるべき」ではなく、実践するために「アジャイルをどう使うか」という観点で書かれています。それは以下の引用の一文でも感じてもらえると思います。

アジャイルに熱心な人は、このアプローチを「アジャイルとは言えない」と訴えるだろう。だがこの場合も、アジャイルであることが目的ではない。ここでの目的は、ビジネスを最も効率的に支援するために、利用できるソフトウェア開発プラクティスは利用する。ということにある。

アジャイルスクラムを実践すると、教科書どおりにできないことが出てきます。そんなとき、現場の状況を無視して無理矢理アジャイルの型の当てはめていくことは得策でないと考えています。そのため、上記の引用は共感できます。とは言え、守破離の守ができないうちからアジャイルの型を崩すことも得策でないと考えています。自分の中で矛盾した考えがあります。
そのような、矛盾を抱えつつ、学び、チャレンジし、ベストを探し続ける姿こそがアジャイルな道だと思います。そして、本書はその道を進むために背中を押してくれたり、進む道を示してくれるのです。

本書を読んで、特に共感したり新しい発見があった個所についてピックアップしていきます。

フィードバックループをタイトにしていく

アジャイルのメリットの一つはフィードバックループが早いことだと複数の章で書かれています。良くなることを端的にまとめると以下の通りです。

  1. 不具合の検出が早くなり、修正コストも下がり、コード品質向上につながる
  2. ビジネス価値を早く提供でき、判断できる

スクラムはフィードバックの仕組みが整っていますね。1スプリントごとにレビューを実施し、フィードバックを得ます。また、同じペースでふりかえりも用意されています。スプリントレビュー、デイリースクラムもフィードバックの場です。仕組みとしてフィードバックの場が用意されているため、効果が出やすく、多くの企業で使われているんだと思います。

フィードバックと聞いて思い出すことはシステム思考です。変化を起こすためにはフィードバックを設計することが大切です。目標と現状のギャップを把握できる仕組みを整えることが変化を起こす第一歩です。

持続可能な開発の多様性

アジャイルソフトウェアの12の原則に以下の原則があります。

アジャイル・プロセスは持続可能な開発を促進します。

XPには「週40時間労働」という原則もあり、「持続可能な開発」については働く時間について言及されることが多いと思います。働き過ぎは制御すべきですが、「持続可能な開発」はペースだけなのか?開発に取り組むモチベーションも大きな要素ではないのか?と考えていました。開発している機能が「なぜ必要なのか」という「Why」の部分に納得・共感できるかどうかも影響すると思っていました。

本書の「6.1 基本原則:自律、熟達、目的によるチームの動機付け」に以下のような記述があり、「やっぱり!」と思いました。

生産性に関するほとんどの調査では、生産性を他の何よりも大きく左右するのはモティベーションであることが確認されている。

内発的モチベーションを高める要因は自律、熟達、目的、があげられていました。それぞれを簡単に紹介しましょう。

  1. 自律は自分の仕事を自分で管理する能力
  2. 熟達は学習と改善を強く願うこと
  3. 目的は取り組んでいる問題の重要性を理解すること

本書ではそれぞれの要因を良くする方法、阻害する方法についてまとめられていました。アジャイルというか、良いプロダクトを作り続けようとすると、個人やチームの成長は不可欠です。本書の内容をもとに仕組みや振る舞いを見直そうと思いました。

また、本書の「9.6 バーンアウトを回避する作業構造」という項目で「人によって働くペースは違う。週50時間を超える週と週30時間に抑える週を組み合わせる働き方が良い人もいる」と言及されていました。
同じように私も(働き過ぎはコントロールすべきですが)人によって働きやすいペースがあると思っていました。

予測可能性を必要とするアジャイル

プロジェクトの課題や失敗の主要な原因は要求のまずさにあったと書かれています。アジャイルプロジェクトとシーケンシャルプロジェクトの要求の違いは要求作業のタイミングです。前半に要求作業をほぼ終わらせて、後半に要求作業をしないのがシーケンシャルです。前半も後半も同じペースで要求作業をするのがアジャイルです。シーケンシャルとアジャイルの違いを表す大きな要素ですね。

さらに、予測可能性を必要とするアジャイルの進め方について説明がありました。従来のアジャイルよりも前半に要求作業の大きな山を作ってから後半も要求作業を続けるということです。
この点について、個人的に驚きがありました。アジャイルといえば従来のアジャイルのイメージしか持ってなくて、「予測可能性の必要のあるプロジェクト」もアジャイルなのだと驚いたのです。狭い範囲をアジャイルと考えていたと気づきました。

また、他の章でも「アジャイルの境界」がどこにあるのかを理解しておく必要があると書かれており、アジャイルかシーケンシャルかというゼロかイチでは、プロジェクトの中でもアジャイルが有効な場所を見定めて柔軟に考えたいと思いました。

本書を使ってふりかえる

本書は各章に推奨リーダーシップアクションと言う項目があり、自身を振り返るためのチェックリストがあります。ひとつひとつ向き合ってみようと思います。
また、28の基本原則のまとめに関しても今のチームと照らし合わせて変化を起こせる部分から変わっていこうと思います。

まとめ

  • 理想的なアジャイルではなく、現実的なアジャイルが学べる本
  • どのプラクティスも大切だと思えた
  • 人、技術、チーム、組織、幅広くカバーされている
  • Don’t just do agile. Be agile.

Tech Lead Night vol.0 - 各社のテックリードが、気になるテーマを徹底討論! - に参加

Tech Lead Night vol.0 - 各社のテックリードが、気になるテーマを徹底討論! - に参加しました。

legalforce.connpass.com

開催概要のとおり、テックリードというキーワードについて幅広くお話が伺えました。気になった部分についてまとめていきます。

テックリードの役割は企業によって異なる

「テックリードとエンジニアリングマネージャーの違い」というテーマでは「テックリード」という役割を設けていない企業もあり三者三様でした。共通点は「技術でチームやプロジェクトをリードする」という部分です。技術選定や技術に関わるリスクヘッジ、品質の担保などキーワードが上がっていましたが、細かいポイントは企業によって異なりそうです。また、人やタスクの管理は別のポジョンの方が担っていることが多そうでした。

他の方々はテックリードはどう考えているのか調べてみました。
テックリードという役割 | by Shimpei Takamatsu | Medium
良いテックリード、悪いテックリード - 小さなごちそう
「自らを実験台として新たなキャリアを切り拓け」 及川卓也氏が贈るアラサーエンジニア進化論 - エンジニアtype | 転職type
Tech Lead(TL/テックリード)の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
テックリードになって気をつけていること - Qiita

まとめるとテックリードとは以下のような人物かなっと思いました。

  • 技術的知見とドメイン知識が豊富
  • 技術でチームのアウトプットを最大化する
  • プロダクトマネージャー、デザイナーと対話し、技術面から意見する
  • プロダクトのリリースに対して献身的

あえて役割を分担しないという考え方もある

テックリードとエンジニアリングマネージャーという境界を引くことで、お互いの範囲外に落ちたタスクを拾う人が減ると困りますよねという発言もあり考えさせられました。なんのためにテックリードという役割を設定するのか、どういう期待があるのか、そのあたりを明示しないと悪影響もありそうです。

以下のブログも近いことを言っていて、庭という概念は良いですね。タスクが落ちるという表現だと、野球の守備範囲という概念でも表現できそうです。
チーム開発で活躍するために、自分の庭を作れると良い - hitode909の日記

思想を伝えてエンジニアの組織文化を作る

文化を広めるには色々なものに宿る思想や考えを発信し、伝えた方が良い。「なぜ」が共有されることで文化が醸成される。

ビジョンを伝えないと人は動かない」という記事でも書きましたが、Howだけ伝えられても人は納得して行動しづらいですね。その状態だと文化もできません。経験豊富なベテランの中では当たり前になっていることも、他のメンバーは共通の暗黙知がなく、ルールだけが存在する状態になりかねません。当たり前のこともWhyから伝えることが大切ですね。

まとめ

  • テックリードの役割は自社で定義したほうが良さそう
  • ムリに仕事を役割に分けると、落とすタスクが出てしまう
  • 文化を醸成するにはWhyを伝え続ける

運営のみなさん、登壇者のみなさん、参加者のみなさん、ありがとうございました。

GitHub Actions を スケジュールで実行する

ペースは遅いですが、GitHub Actionsについて調べています。今回はスケジュールで実行する方法をまとめます。前回の内容はこちらです。
iucstscui.hatenablog.com

on コマンドで schedule を定義

on:
  schedule:
    - cron:  '*/5 * * * *'

on コマンドでトリガーを指定します。on コマンドに対して schedule と書くことでスケジュールをトリガーに実行されるようになります。スケジュールの指定は cron で記載します。cron は Windows ユーザーには馴染みの少ないコマンドですね。Unix系OSでコマンドの定時実行のスケジュール管理を行うために用いられるコマンドです。

*/5 * * * * は スペース区切りで"分 時 日 月 曜日" を表しており、この例だと5分おきに実行します。指定が心配な場合は以下のサイトで確認することもできます。
crontab.guru

注意点はデフォルトブランチでしか実行されないことです。デフォルトブランチ以外に設定を書いてもGitHubActionsは実行されません。