「アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き」を読んで

書籍

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

この本を選んだ理由

  • 自分のチームでは月イチで振り返り(KPT)を行っているがマンネリを感じており、より効果的な振り返りができるようになりたいから。

所感

レトロスペクティブの構成は5つのアクティビティがある

  • ①場を設定する、②データを収集する、③アイデアを出す、④何をすべきかを決定する、⑤レトロスペクティブを終了する
  • この構成は1時間でも3日間でも可能
    • ①や⑤をやっていないのでまずは自分のチームからやっていきたい。

レトロスペクティブの目標を後押しするアクティビティを選択する

  • 教育のあり方を評価するARCSは選択する上で有効な基準
    • Attention(注目)、Relevance(関連)、Confident(自信)、Satisfaction(満足)
  • 時間が経ってアクティビティに興味を失ったり飽きたりしたら新しいアクティビティを見つけ興味を持たせることが必要。
    • わかるー。既に飽き気味でこの本を読んでる。引き出し増やしチームに提案してみる。

「あなたが言葉」ではなく「わたしが言葉」を使うとよい

  • 「あなたが言葉」だと責任の問い詰め、一方的な決めつけになるので注意しないといけない。「わたしが言葉」であれば気づきや経験に重点が置かれ決めつけをしたりしない。
    • 2人チームだとわたし言葉でも裏を返せばあなた言葉に取られる可能性が高いよなぁ。気をつけて発言しないとアカンなぁ。

場を設定するアクティビティにESVPというものがある。

  • ESVPとはExplorer(探検家)、Shopper(買物客)、Vacationer(行楽客)、Prisoner(囚人)の頭文字を取ったもの。
    • 振り返りを始める前に囚人がいることがわかること自体がスゴく有用だと感じた。いたらいたで自分は戸惑いそうだが。。。
    • スゴく面白そうでやってみたい。ただ、2人だと誰がどの属性か分かっちゃうのはアカン。規模が大きくなったらやってみたい。

データ収集時に色分けやカラードットを使う

  • 付箋の色分けはカラードットを使って感情/イベント/職務/テーマを分けると分かりやすい。
    • ただ見た目にこだわり過ぎず重要なテーマに対して色分けすべき。

無口な人が多いチームなどでも「555」を使うとチーム全体からデータ収集ができる

  • 誰もが振り返りで話せる訳ではないので、無口なメンバーがいる場合やしゃべりすぎるメンバーがいる場合でも有意義な方法だと感じた。
  • 引き出しとして持っておきたい。

達成したい目標をサポートする要因と抑制する要因を認識し、効果的なアクションを決める方法として「フォースフィールドアナリシス」がある

  • チームだけでは解決できない目標に対してどういうアクションを取るべきか2つの要因(サポート/抑制)から分析する手法
    • 達成したいことがあってもチームだけでは解決できないから辞めておこう。。。と考えることさえ避けることがある。費用対効果をしっかりと見極めるためにもこの方法は有用だと思う。

課題/アイデア/提案の優先順位をつけるために「ドットによる優先付け」をする

  • 1人複数のドットを持ち対象のアイテム(課題/アイデア/提案)に投票する。1人に10ドット持たせたり、アイテムの1/2-1/3持たせたりと投票の仕方は様々。
  • 質問の仕方としてインパクトや重要度を意識しなくても良い。チームで実現できることが重要で取り組みたいことをフォーカスしても良い。
    • これは良い。ペイオフマトリクス使っていたが、軽い案件が落ちるし、重たい案件への挑戦が増えて疲弊してしまう。次の振り返りでは何を取り組みたいか?という問でドット投票してみる。

SMARTな性質をもつ目標であれば達成できる可能性が高い

  • Specific(明確な)、Measurable(計測可能な)、Attainable(達成可能な)、Relevant(適切な)、Timely(タイムリーな)の頭文字をとってSMART。
    • 次のアクションを決める際でも同じだなぁ。また、Timelyが入ってることが面白い。鮮度ということだろう。

イテレーション毎のレトロスペクティブではアクティビティを変えると良い

  • 毎度おなじみのアクティビティだと飽きるので、「短い話題」のバリエーションを使って議論の観点を変更すると良い
    • KPT、喜/怒/哀、上手くいったこと/次回はやり方を変えたいことなど。
      • わかるー!!飽きが来てる。飽きない工夫は必要だという後押しはありがたい。

レトロスペクティブを終了するアクティビティでは気持ちを上げることが大事

  • プラス/デルタ、感謝など振り返りで疲れているので、ポジティブなフィードバックや感謝の気持ちを伝えることが重要
    • 今のチームは出来ていると思う。専用のアクティビティまで用意する必要はないと思うが、引き続き意識してポジティブフィードバックをしていきたい。

規模を大きくしたレトロスペクティブもあるがチームレベルとは進め方が異なる

  • リリースやプロジェクトレベルはチームレトロスペクティブと異なる視点での改善ができる為有用
  • ただ、イテレーション単位でレトロスペクティブをしているチームであれば慣れているが、リリースやプロジェクトレベルだとレトロスペクティブに不慣れな人が多い
    • 参加者のバックグラウンドや人数の多さなどチーム単位に比べ気をつけることが多いようだ。上司に読ませたい。

今後

  • まずは自分のチームにて飽きが来ないようにアクティビティを少し変えてみる。
  • カラードットや付箋紙の色分けなど、見た目だけでグルーピングすることで議論にフォーカスを与えられるので、使っていきたい。
  • チームだけではなく、更に上位の組織にて振り返りが出来ないか上司に提案する。
  • 二人は匿名性がないので、使えない/使いづらいアクティビティが多いと感じた。
    • つまり、匿名性が高くないと効果的な振り返りがし辛いというところだろう。心理的安全性を作る方法を2人の場合でも考えていきたい。

「なぜ、あなたの話はつまらないのか?」を読んで

書籍

なぜ、あなたの話はつまらないのか?

なぜ、あなたの話はつまらないのか?

この本を選んだ理由

  • 雑談力が乏しいと感じており、面白い話が出来るようになりたいと感じているから。

所感

つまらない話のパターンは4つある

  • ①内輪受け話、②自己中心的な話、③ダラダラ時系列話、④結論ポロリ話の4パターン。
    • ①や②は話がち。特に①は話し相手のコンテキストが揃ってないといけないので、話題を考えるときは意識していきたい。

おもしろい話をするには正しい順序立てがある

  • ①おもしろく伝えるために必要な要素をチョイスする、②チョイスした要素をよりおもしろく伝えるために順序立てが必要。
  • ②はざっくりいうと「フリ⇒オチ」があるかないかということ。
    • 話のプロ(お笑い芸人や噺家など)はこのチョイスと順序が上手なのだろう。

面白い話の重要なポイント=共感であり、聞き手が共感して初めて初めて面白い話となる

  • 1対1であればまだしも、不特定多数に対して共感できるポイントを見つけるのは難しいの。
    • そういう時のヒントとして「共感のピラミッド」があるとのこと。
共感のピラミッドとは、三角形の下から上に「家族」「学校」「食・住」「恋愛・仕事」「芸能」と並べた図。
下にいくほど共感を得やすく、初対面の人には下から上にスライドさせていき相手の関心を探ることもできる。

「フリ⇒オチ」にもテクニックがある

  • フリからオチまでが長い場合は「アバン」を使うとよい。
    • 「アバン」とはフランス語と英語の造語「アバンタイトル」を略したもので、番組が始まる直前に流れる見どころVTRのこと。
    • 関心を引くことができるとのことなので、これは良いなぁ。
  • エスチョン法を使うと聞き手が今まで他人事だった内容が自分事になり、注意を引くことができる。
    • ほんまでっかTVでいうタイトルの所。なるほど確かに注意を引く。スピーチする際のテクニックとして参考になる。

毒舌は「相手に愛を持つ」「名指ししない」ことが大事

  • 毒舌で有名な人を例に挙げて説明していたが、ポジティブ+ネガティブであだ名を付けたり、直接名指ししないというのは言われて気づいた。
    • 毒を吐いて笑いを取るには相手への尊敬や愛情がないといけない。当たり前のことをちゃんと出来ていないと毒舌はできないということを改めて認識した。

今後

  • 話し方のテクニックは学ぶ所はあったが、結局のところ話を受ける側のことをどれだけ思いやったり気遣いができたりできるのか?が面白い話の本質だと感じた。
  • 今後は話を受ける側が今の話を聞いて何を感じるか?をより意識して話をしていきたい。

その他

  • Kindleのエクスポート機能はブログをまとめるときに便利。
    • ハイライトした箇所が引っこ抜ける。Kindle本で買いたくなってしまう。

「プログラマの数学第2版」を読んで

書籍

プログラマの数学第2版

プログラマの数学第2版

この本を選んだ理由

  • プログラミングに役立つ「数学的な考え方」を身につけよう。というイントロに興味を持ったから。
  • 通勤中に読む上で写経をする必要がなく、リラックスして読める本を探していたから。

所感

「初歩的な」プログラミングに役立つ数学的な考え方が身につく

  • If文、For文、While文など初めてプログラムを学ぼうとする人が事前に読むと理解がスムーズになる本だと思う。
    • 高専で初めてプログラムを学んだ時2年くらいは暗闇を彷徨っていたが、その時この本を渡されていたら少しは早く暗闇から脱出できていたと思う。
  • ただし、基礎が分かっていても言語化する難しさを感じている人は一読する価値はあると思った。
    • プログラムするならこう書くべき!と思っていことが、とても上手に言語化されている。

日常生活のゼロを意識する

  • 本には「薬を3日飲んで1日休むを繰り返すには飲む日か飲まない日かを判断しないといけない。ただ、効果のない薬を用意してルールを毎日飲むというように単純化できる。」という例題があった。
    • この発想はプログラムだけではなく、複雑になりすぎているプロセスについて単純化する際の切り口として日常業務にも使えるなぁ。

-周期性や偶奇性(パリティ)を見抜く

  • 手に負えない数でも周期性を見抜けば取り扱うことができるし、偶奇性を使うことで試行錯誤の回数を減らせる。
    • 物事を詳しく調べる際は正確に把握しようとするが、的確な分類をするほうが役に立つという良い例。
    • 的確な分類。ここが仕事においても肝だと思う。

雑談ネタで使えそうな内容が多い

  • ローマ数字は位取り記数法ではない
    • 今まで気にもしてなかったけど確かにそうだ!ローマ数字だと桁が増え過ぎたら辛い。
  • 植木算
    • 0のことを忘れるな!という有名な問題。0を入れ忘れるあるあるネタを植木算ということは知らなかった。
  • 対角線論法
    • どこで使えるか知らないけど、なるほどなぁー。と思った。

今後

  • 基礎的な本でも新たな気付きを得られる。基礎的な本を読むのも良い!興味持ったらまずは読んでみようと思う。
  • (30過ぎて今更ですが…)本って良いですね。他者がいくら伝えても意味がない。進んで読む気持ちを持たせる工夫が必要だと感じた。

「WebAPIアプリケーション「超」入門 FirebaseとAPIによるWeb会議システム制作」を読んで

内容

f:id:fatherofikura0107:20190322075420j:plain

このテーマを選んだ理由

  • Firebaseを触ってみたかったから

所感

初めてFirebaseやWebAPIを使う人には雰囲気を体験できる良い教材

  • タイトルにある「超」入門の通り。めちゃ駆け足。どうやって使えば良いかはなんとなーく分かるくらい。
    • ただ、開発環境のセットアップやコードの解説などはそこまで細かく記載していないので、Web開発全くしたことない人だと躓くかもと思った。
  • Realtime Databaseの凄さが良く分かる。
    • 少ないコード行数(100行程度)でRealtimeチャットが作れるなんてどうかしてる。

所々誤字がある

  • 3-3のサンプルコードが3-2と同じ。
  • FirebaseのDeployなのにinitコマンド書いてあった。
    • こちらのサイトを参考にdeployした。ファイルの中身も記載があり大変助かった。

その他

  • XAMPPあると簡単にWebサーバ建てれるので便利だが、MACだとそもそもPythonなどの開発環境入っているのでそれで代用できるっぽい。いいなぁ。
    • Apacheの設定で躓いた。が、別の勉強にて何度か設定しているので躓いても起き上がるまでが早くなった。
  • 会社で朝活している関係上、声出せないので音声認識は諦め。今後のテーマ選びは考えようと思った。
  • Realtime DatabaseとCloud Firestoreの違いはなんだろう。
    • 公式ドキュメントに書いてあった。
    • どちらもNoSQLベース。昔からあるのがRealtime Databaseのようだ。
  • @iwashi86さんがやっているSkyWay初めて触った。こんな簡単にビデオ会議のシステム作れるんだ…。裏側どうなってるんだろう…。

今後

  • Firebaseにより興味が出た。DatabaseとHostingだけだっとのでその他の機能も使ってみたい。

「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」を読んで

書籍

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

この本を選んだ理由

  • モビングについて単純に興味がある。
  • 自チームはペアでの作業を行っており、モビングからも良い知見が得られるのでは…と思ったから。

所感

※かっこ書きは本の中の章番号。

良かった点

  • モブプロとペアプロとの違い(1.2)が書いてある。
    • ペアプロだと意見が食い違うと膠着するが、モブプロはチームなので個人を否定された感が少ない。(1.2.1)
      • 今はペアで動いているため意見の対立=個人否定になりかねない。この部分を解消できるのはモブプロの大きな意味に感じる。
    • モブプロはペアより中断しにくい。ペアだと片一方が病気、会議、電話で中断すると作業が止まる。(1.2.2)
      • 休みがちな方とペア組んでいるので分かる...凄くよく分かる…。
    • モブプロ効果測定は難しいので、コンフリクト解決、欠陥数、学習度、チームメンバーの改善効果の所感を利用すると良い。(1.3.2)
      • 確かに効果測定はどうやるのだろうか?と感じていた。モブプロやる前に測っておくべきだなぁ。得られた成功を記録しておくと上長への説明に役立つらしい。ふむふむ。
  • モビングの軌道修正方法がかかれている(4)
    • エキスパートがいる場合のモビングはタイピストではなく、モブのコーチとして知識の穴を埋める形で参加してもらうと良い(4.1.3)
    • 手探りなモビングの場合は、タイムボックスを決めて個人で探求する方法(4.2.3.1)や強いモビング(=進行役を設けアイディアは進行役に委ね、進行役からのみタイピストに依頼する)を使いバラバラの意見をまとめる(4.2.3.2)
    • 些細な仕事のモビングの場合は、無理に皆で同じ仕事をする必要はない。振り返りや体制を整えたりすればよい。(4.3.3)
      • メリハリって大事だなぁ。引き出しとして覚えておきたい。
  • モブプロの核心であるフロー効率について書かれている。(7)
    • フロー効率を表すのに高速道路の例を用いている(7.1.1)
      • 全ての車が一定スピードではないので、どこかで急ブレーキすると後ろ全体に影響を与え、いつ目的地に到着するか予測することが難しい。一方、フロー効率重視だと車間距離に余裕があり、目的地到着の予測がつきやすい。(7.1.1.1)
        • これはなるほどと思った。フロー効率の良さは目的地到着の誤差が少ないという点なのか!
    • 仕事を早く始めることが目標ではなく早く終わらせることが目標。(7.3)
      • ここがモブプロの本質のような気がする。未完成では意味がないことを皆理解すべき。
  • モブプロ実施で漠然と遅くなったと感じるのであればエンドツーエンドで考えてみるとよい。(8.2.1)
    • コードの部分だけみてもしょうがない。もっと広い視点でみれば早くなっている。モビング/ペアリングの効果を聴かれた際はこの点を意識して回答したい。

その他

  • 無駄とは何か?業務全体の効率化を考えていくとモビングという手法に落ち着いたのかなぁと個人的には思った。
  • チーム/組織として働く上で人との繋がりは大事であることを本を読むたびに感じている。

Laravelで作ったアプリをHerokuにデプロイする(DBはMySQL)(実施期間:14日)

内容

はまったところ

  • HerokuにてCreditCard登録しようとしたが「risk_threshold」のErrorが出て登録できず。Cardを変えたら登録できた。
  • Error R13 (Attach error) -> Failed to attach to processが出た。
    • こちらの記事を見たら同じ内容で、run⇒run:detachedに変更したら上手くいった。Log見ても問題なさそう。
  • Heroku上のDBを見たいと思いMySQL Workbenchを使ってLocalから繋げようとしたがなかなか繋がらず悪戦苦闘
    • こちらの記事を見てやってみた
      • 「Can’t connect to MySQL server on SERVER'(10060)」が出た。
      • コマンド(mysql)で接続しようとしたら、ERROR 2003 (HY000): Can't connect to MySQL…となった。
      • 家から試したらMySQL Workbenchでつながった。
        • こりゃ環境がアカン。会社のセキュリティソフトで弾かれてる可能性高し。会社での確認は諦めよう。

所感

  • 本質ではないネットワークトラブルで躓き時間がかかった。
    • 家で試すまでに10日くらい悩んだ。もっと早く気付けばよかったが、それもまた勉強…。
    • 今度からはネットワーク絡みでのトラブルは機転が利くようになったし、調べ方も勉強になった。

「カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで」を読んで

書籍

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

この本を選んだ理由

  • チーム作り/組織作りに興味があり、まずは自分から改善が始められる部分があれば…と思ったから。

所感

良かった点

  • 心に刺さるフレーズ、すぐに実践したいとプラクティスが詰まっていた。
    • 「許可を求めるなら謝罪せよ。許可がおりるまで待ってモチベーションを下げるくらいなら、結果がついてこないときに謝ったらよい。」
      • 上長に許可を取ろうとしたがネガティブな発言をされモチベーションを下げた経験はある。確かにその通りで結果がついてこなかったときに謝れば良い。このマインドで仕事をしようと思ったし、上に立つときは謝罪する相手が許可を求めなかった理由も考えるようにしたい。
    • 「新たな一歩を踏み出すのに遅すぎるということはない。行動を始めるべきだと気づいたそのときが、その人にとって最速のタイミング。」
      • 仕事に関わらず、何か新しいことをやってみようと思っても、「今更遅いよなぁ…やめておこうかなぁ。」と思うことがよくあった。自分のやりたいという想いを大切にし、素直にアクションにつなげられるようにしたい。そして、周りの人が一歩踏み出すのを躊躇しているときは一押ししてあげたい。
    • ダニエル・キムが考えた成功の循環モデル。結果の質を向上させることからスタートすると、一時的な結果は出るかもしれないが、長期的な結果を出すのは難しい。関係の質から改善することが成長し続ける近道。
      • 仕事で「関係の質」を軽んじているように感じる。今チームで動いているが、上からは結果を求められるが、関係の質を強化することを取り組んでいきたい。
    • 会社標準でプロジェクトに直結しないスキルマップではプロジェクトの成果に繋がらない。繋がる項目であることに意味がある。
      • 確かにその通り。今の組織はスキルマップがあるが、あまり意味がないと感じていた。プロジェクトから吸い上げたものではないので意味がなく、形骸化してる感がある。
    • チームビルディングの三種の神器インセプションデッキ」「ドラッカー風エクササイズ」「星取表」
      • これは良い。新しいチームのときは実施してみたい。
    • リーダーズインテグレーションというチームの信頼関係を高めるワークがあることを知った。
    • SL理論(Situational Leadership)。メンバーの成長に応じてリーダーシップスタイルを変えていく。
      • 確かにリーダーシップもメンバーの状況次第で変える必要がある。今上手くいっているからといってそのままで良いわけではない。正しく現状を把握し振る舞えるようにしたい。
  • 現状の仕事、会社、組織に嫌気がさした時に読み返せばまた頑張る気持ちが出る本。
    • 職場の課題図書にしてほしいと思うくらい良い本。悩める後輩がいたらこの本を読んでもらって熱く語り合い、ともに頑張っていきたい。

その他

  • 最近読んだ本で間違いなくナンバーワン!!
    • 長々感じたことを↑に書いたがそれ以外にも書きたりないくらい学びが多かった。