╭(・ㅂ・)و hilog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

「アジャイルレトロスペクティブズ」を読んだ

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

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

前から気になっていて、まだ読めていなかったアジャイルレトロスペクティブズ退職する際に書いたブログに貼ってったおねだりリストから送ってもらったので読んでみた。

振り返りをする会

今、振り返りをする際に会を始める前に何かをしているわけではない。
会が始まるとすぐにチームメンバが書いたKPTを読んでいるが、実際は以下のように会をすすめるみたい。
振り返りをするのはもちろん大事だけどまずは場を整えるのが大事と。

  1. 場を設定する
  2. データを収集する
  3. アイディアを出す
  4. 何をすべきかを決定する
  5. レトロスペクティブを終了する

振り返り手法

それぞれのタイミングによって使える振り返り手法が多数紹介されている。全部で30種類。
自分がやったことあるものは5、6種類だった。特に振り返りの場だとKPTだけやり続けていた。

  • 場を設定するアクティビティ: 4種
  • データを収集するアクティビティ: 8種
  • アイディアを出すアクティビティ: 9種
  • 何をすべきかを決定するアクティビティ: 4種
  • レトロスペクティブを終了するアクティビティ: 5種

どれもこれも目的と結果が別々にある。どれかをやるのではなく、自分たちが困っていることに対して必要なものを適宜選んでやっていくのが良さそう。

まとめ

最近チーム開発の本を読んでいて本書にも書いてあったが、チームとしての目的・やるべきことが明確になっていること、またチームメンバで同意が取れていることが重要な気がしている。
その目的に対して、自分たちの立ち位置がずれていないか、おかしなことをしていないかを定期的にみんなで調べることが必要なのだと思う。

振り返りをする前に、自分たちが何をするものなのか?なぜいるのかをみんなでちゃんと話し合うのが大事なのかなーと思った。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

世界最高のチーム グーグル流「最少の人数」で「最大の成果」を生み出す方法

世界最高のチーム グーグル流「最少の人数」で「最大の成果」を生み出す方法

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

これだけ! KPT

これだけ! KPT

「Team Geek」を読んだ

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

個人ではなくチームで、チーム内だけではなくチーム外への働きかけや向き合い方が書いてあった。

ニハトモアレHRT

  • 謙虚(Humility)
    自分は全知全能ではないし、完璧ではない。常に自分を改善していく。
  • 尊敬(Respect)
    一緒に働く人を思いやり、その能力や功績を評価する。
  • 信頼(Trust)
    自分以外の人は有能であり、正しいことをすると信じる。

あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ
出典 : Team Geek (P. 15)

と、書かれるほど本書の中ではこの3つを原則として説明がされている。

自分自身の行動

この原則が守れるとどんなことができるのかの例がいくつか、書いてあるがその中で僕が気に入ったのは、 不完全なソフトウェアを見せても良いという謙虚さ、ユーザがその対応を称賛し、迅速な改善を望んでいるという信頼があれば、早い段階で失敗・学習・反復することができるということだ。

Googleの社是の一つに

失敗は選択肢の1つ

というものがあるらしい。失敗するような改善やリスクを取ることを尊敬して行動すれば、失敗も隠されないしみんなが試すことを積極的になってくれる。そして、失敗した後にそのままにするのではなくポストモーテムを残すことで、学習した結果何を学び、何を変更すべきかが共有できる。これはSRE本でも書かれていたことだ。ポストモーテムには以下の内容を含むと良いとのこと。

  1. 概要
  2. イベントのタイムライン
  3. イベントの根本原因
  4. 影響と損害の評価
  5. すぐに問題を解決するための行動一式
  6. 再発を防止するための行動一式
  7. 学習した教訓

チームとしての行動

チームとして働くためには、チームの文化を作ることが大切。
文化を作るためには、みんなの認識を合わせる必要がある。そのためにミッションステートメントを書くことをすすめている。決めるべきは、

  • メールやチャット、ミーティングなど話し合いをする際のマナー
  • バグ修正、テスト、リリースなどのルールを決め
  • すべての履歴を文書として残す
  • 合意ベースの決定をする
    • 合意できなかった際の衝突解消プロセスも決めておく

文化ができれば、文化に沿った行動を求めることも、合ってないから直してほしいと言うこともできる。まずは、誰が見ても自分たちがなにを守るべきかがわかるようにすべきだと思った。

有害な人

ソフトウェア開発でもっとも難しいのは人間だからこそチームの中にしろ外にしろ有害な人はいる。本書の中では最終的にどうしようもなければ有害な人は追い出して良いと書いてある。
人を追い出すのではなく、振る舞いを追い出すことを試みて、それでもダメだったら最終手段として追い出しをするしかないと書いてある。

有害な人の例としては

  • 他人の時間を尊重しない人
  • エゴが強い人
  • 何かを要求する人
  • 未熟なコミュニケーションをする人
  • パラノイアな人
  • 完璧主義の人

が挙げられている。自分がいくつか当てはまる気がものすごいし、胸が痛くなりながら読んだ。徐々に直していかないとな。

チーム外

いかにうまくチーム内では上手く回って開発が上手にできていても、最終的にユーザが使ってくれなければ開発する意味がそもそもない。
以下の事に気をつけることによってユーザを忘れずにいることができる。

  1. ユーザはソフトウェアの存在に気がついているか?

    • ソフトウェアがどのように見えるか気を配る
      • 第一印象に気をつける
      • 小さく約束して、大きく届ける
  2. ユーザの期待に応えられているか?

    • 簡単で、早く、使いやすく、止まらないようにする
      • ハードルを下げる
      • 利用を計測する
      • 怠けない
  3. ユーザとうまくやりとりができているか?

    • ユーザとの友好的で長期的な関係を築く
      • 見下さない
      • 我慢する
      • 信頼と歓びを創る

まとめ

自分の行動からチームの作り方や社内政治について、更には、チーム外の人達との立ち回りとチームで開発をして価値を提供していくためのすべてが実体験を交えながら説明されている。
僕には、HRTが足りてないなと何回も心を痛めながら最後まで読み切った。
今後チームメンバーにしろユーザにしろHRTを取り入れた行動を心がけていきたいなと思う。

読書会すると面白そうな本だな…

世界最高のチーム グーグル流「最少の人数」で「最大の成果」を生み出す方法

世界最高のチーム グーグル流「最少の人数」で「最大の成果」を生み出す方法

ピープルウエア 第3版

ピープルウエア 第3版

人月の神話【新装版】

人月の神話【新装版】

Being Geek ―ギークであり続けるためのキャリア戦略

Being Geek ―ギークであり続けるためのキャリア戦略

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

#scrumosaka でPAしてきた

www.scrumosaka.org

大阪で面白いイベントに参加してきた。
スタッフをしていたわけでもスピーカをしてきたわけでもない。タイトルの通りPAとしてお仕事をしてきた。

キーノートスピーカの及部さんきょんさんから手伝いが必要との連絡をもらい、PAとしての仕事をいただきました。他にもスタッフは4名いて、スピーカも合わせて計7名のチームで活動していました。

スピーカの2人のスライドやコンサート作りの一部始終を見ることができてとても良い経験が得れた。
みなさんが少しでも楽しめていれば良かったなと思います。

担当部分

準備

  • オープニング、エンディング部分の写真、ビデオ撮影 at デブサミ
  • 発表資料、発表進行の打ち合わせ

コンサート

  • 前説
  • 照明操作
  • 音量調整
  • PC操作(ムービー、PC切り替え)

前説の様子は以下になります。写真に写っている右側が僕になります。

まとめ

前日のリハーサルで僕の担当分が増えたり、なぜかイベントの一部の照明などにも関わることになったがとても面白いイベント参加になった。イベントの作り方や、ストーリの作り方、人への魅せ方など自分が全然できないことをどうやって実際に考えてやっているのかを見ることができてとても有意義だった。

もっと改善できたところもあるだろうけど、あれがあの時のベストだったと思う。よく頑張った自分。
何かイベントでPAとしての仕事が必要な時はお声がけお待ちしております m( )m

最後に

なんだか最後の新幹線でふっと思った感想はこれだった。

201902 振り返り

今月は大きいイベントに2つ参加できた。Developers Sumii 2019Scrum Fest Osaka 2019デブサミは少ない数だったが、話を聞けて楽しかった。スクラムフェスト大阪では、キーノートの音響と照明をやった他には、裏でスピーカの人と話をしている時間が長かったな。

べんきょうかい

例年通り参加できた。
ここ最近個人スポンサーを申し込んで参加しているが、来年も参加するなら個人スポンサーだな。

ほん

新幹線に乗ることがあったのに本が減らなかった。
最近はチームを作るため、チームを良くするためにはという本をよく読んでいる。
漫画は順調に読み進めているが、買って読んでるだけなので積ん読は減らないな。

えいが

懐かしいアニメ映画を何本も観れて楽しかった。
七つの会議は面白かったが、一緒に観に行った人と帰り話をしたが、そこまで頑張らなくてもと思ってしまった。業種の違いかな。

その他

スクラムフェスト大阪に参加してきた。キーノートを手伝えて良い経験を得れた。
忘れないうちにブログを書かなくては。

ブログ

勉強になる本が多い。もっと勉強しなくては。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

「あなたのチームは、機能してますか?」を読んだ

あなたのチームは、機能してますか?

あなたのチームは、機能してますか?

機能していないチームには5つの問題がある。
それぞれの問題を、実際に機能不全になっているチームを改善していく物語仕立てで説明している。
5つの問題は以下。

信頼の欠如

チームのメンバーが理解し合い、互いに心を開けない。
チームを築くためにどうしても欠かせない要素。

衝突への恐怖

腹を割って前向きに考えをぶつけ合おうとしない。
自分の意見や正直な不安を隠してしまう。

責任感の不足

決定したことをきちんと支持できない。
曖昧な態度をとってしまう。

説明責任の回避

やると約束したことについて、水準の高い仕事をして、行動をとるよう、互いに説明責任を求める。

結果への無関心

チームのメンバが個人として認められ、注目されることを求めて、結果を犠牲にすること。
個人でいくら優れていても、チームとして結果が出なければ意味がない。

これらがピラミッドのように積み重なって機能不全なチームが出来上がっていく。
この本の中では、これらの問題についての詳しい解説と一部の解決方法が説明されている。

まとめ

機能不全なチームになる、一番の問題はピラミッドの最底辺である、信頼の欠如である。
信頼できるメンバで働いていれば同じ結果に向かって、衝突と同意を繰り返しながら責任持って機能するチームになれるということだろう。

やはり、信頼できるメンバになるということが大事ということか。

なぜあなたのチームは力を出しきれないのか

なぜあなたのチームは力を出しきれないのか

意思決定5つの誘惑―経営者はこうして失敗する

意思決定5つの誘惑―経営者はこうして失敗する

「世界最高のチーム」を読んだ

世界最高のチーム グーグル流「最少の人数」で「最大の成果」を生み出す方法

世界最高のチーム グーグル流「最少の人数」で「最大の成果」を生み出す方法

Googleがチーム作りで大事にしていることが、250ページ以下の読みやすい内容でまとめられている。

心理的安全性

この言葉をよく聞くようになったが、ふわっとしていてなんだかよく分からない。この本では、「自分らしさを発揮しながらチームに参画できる」と書いてある。例を見ると、自分の話を隠すことなくできるし、責めることがないように思える。
こういった信頼や尊重などはいかに同じ時間を過ごしたかで構築されるのではないかと思う。作業をみんなで一緒にやったり会話をする時間を作ったりすることで、チームなんだとみんなが思えるようにしていくことが大事なのだと思った。

思考の多様性

個人ではなくチームで働くことで集合知が集まる。そのためには、幅広い考えを持つ人が集まった方が多様性が高くなると思う。
チームメンバを信頼していれば、どんな意見でも言えるし挑戦ができるようになる。多様性が高くなれば平均は下がるかもしれないが、飛び抜けた質のものが出来上がる可能性は高くなる。自分とは違う意見も受け入れることができるようなチームを作ることが必要みたい。

アンラーン

技術は次々新しいものがでてくる。その勉強はしなければいけないが、その際に自分の知っている知識、方法が古いと思ったら学び直す必要がある。
追加するのではなく一度忘れて新しく覚えることをする必要がある。そのためには、振り返りの繰り返しと学び続けることを忘れてはいけない。

まとめ

チームで働くためには、相手を信頼・尊重していることが前提である。
その前提がある上で、話し合いやオペレーションをし、振り返りをしての繰り返しを行うことが大事だと思った。 ひとまずは、

  • 話をする場の作成
  • 試してみることが正しいという文化の定着
  • やっていることの共有の仕方を考える
  • ゴール意識の共有
  • オーバコミュニケーションの仕組み化

あたりができるようになれると良いな。

起業家 (幻冬舎文庫)

起業家 (幻冬舎文庫)

経営は何をすべきか

経営は何をすべきか

「モブプログラミング・ベストプラクティス」を頂いた

f:id:hihihiroro:20190219030327j:plain
モブプログラミング・ベストプラクティス

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

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

解説を書かれている及部さんから頂いたので、発売日前だが読んでしまった。

170ページくらいの本の中に、これでもかという程モブプログラミングの説明・魅力・問題、それに対する対処法が詰まっていた。

章構成は以下。

  1. なぜモブプログラミングなのか
  2. モビングの始め方
  3. モビングと人
  4. モビングの軌道修正
  5. 定期的なモビングのための仕事場の改造
  6. モビングを定着させるためのチームへの働きかけ
  7. フロー重視の考え方
  8. モビング定着後の長期的な展望

モブプログラミングをはじめるタイミング、はじめた後チームメンバや上司に説明をする際、チームに定着させようとしている時、定着した後に起きやすい問題。
上記のようにモブプログラミングに関わるどんな人に対しても役立つ内容だった。

僕が読んで役に立ちそうと思ったのは、

  • モブプログラミングの説明
  • 試行から取り入れるまでの流れ
  • チームとして取り組むこと

かな。
これで、モブプラグラミングをする理由、効率が…と言われた際に焦らず返答ができると思った。

最近、お試しとして業務とは関係ないお題でモブプラミングをしてみたが、まだ業務に導入できていない。
試してみた後に振り返りしていないなと思った。一緒にやった人がどう思っているか聞いていなかった。シンキングハット法面白そうだから今度やってみよう。

また、途中途中にあるコラムと解説もとても面白く読める。あー、それあるな。わかるわかると思いながら2時間かからないくらいの時間でさくっと読み終えれた。

これからモブプログラミングやってみようと思っている人も、やってみたけど続かないなと悩んでる人も、やってたけどなんかなと思ってる人も、周りがやりたいって言ってるけど何それって人も読みやすくわかりやすい本なのでオススメです。

その他

途中途中にリソース効率とフロー効率の話が出てくるが僕はこの単語を聞くと、黒田さんのスライドで勉強したなといつも思う。

www.slideshare.net

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

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

ザ・ゴール ― 企業の究極の目的とは何か

ザ・ゴール ― 企業の究極の目的とは何か

ザ・ゴール コミック版

ザ・ゴール コミック版