Posted on

コーチング入門 オススメコーチング書籍3冊!!

これまで特別意識してこなかったコーチングについて意識する機会があったのでオススメしてもらった3冊を読みました。学びがあったこととその感覚の定着の為にメモしておきます。



背景

大学を卒業してソフトウェアエンジニアになり、いちエンジニアからチームリーダー、テックリード、マネージャー、スタートアップのCTOを経験してきました。その中でチームマネージメントや1on1などもやってきました。ただこれまでやってきたことは自分の経験であったり周囲との関わりで得たものをベースに自分なりに考えてやっていました。
そして今、新しい環境(スタートアップ)にジョインしたところ、今の環境には1on1(コーチング)を積極的に進めているエンジニアがいました。そしてそれはこれまで半ばやらされている感じでやっていた1on1とは印象が違いました。そこでもれなく自分もコーチングをしてもらうようになったわけですが、そのコミュニケーションの中でこれまでの自分の活動を振り返ってみると自分が今「コーチング」に興味があることが分かりました(年齢的なこともあると思います)。「マネージメント」と聞くとちょっと抵抗感があるけど「コーチング」と聞くと抵抗感がないという不思議さもあります。そんなこんなでオススメしてもらった書籍を読み、体系的に学びを得た上で、今後の活動に活かそうと思います。

1冊目 コーチング・マネジメント―人と組織のハイパフォーマンスをつくる

書評

2002年に出版された本なので今から約20年程前の本ですが、読んでいても時間の経過による内容のずれなどは全く気になりません。前半から後半にかけては、コーチングの基本・詳細と進んでいき最後の方にはコーチングを導入するにあたってのチェックリストがあるといった構成になっています。中でも一番の要点は、「コーチング・フロー」と「いかに聞くのか?」ということだと思います。「コーチング・フロー」は次のとおりです。

  1. 現状の明確化
  2. 望ましい状態の明確化
  3. ギャップを引き起こしている理由と背景の発見
  4. 行動計画を立てる
  5. フォロー

これだけ見ると当たり前のようですが、これを実際に実践する・させる為に「いかに聞くのか?」というスキルが求められます。本の中ではそのコミュニケーションへのアプローチの方法やコミュニケーションが如何に大事かが書かれています。やり方や捉え方によっては詰めているようにも感じられそうな程の質問攻めですがそこのバランスが重要なポイントになるかと思います。

2冊目 この1冊ですべてわかる 新版 コーチングの基本

書評

2009年に出版された書籍の新版(2019年)です。この本は「コーチング・マネジメント」より詳細に具体的にコーチングについて書かれています。後半では実例による説明もあります。目次がパッと見分かりやすかったので記載しておきます。

  • 1章 コーチングとは何か
  • 2章 コーチのもつべき視点
  • 3章 コーチングの3原則
  • 4章 コーチング・プロセス
  • 5章 コーチングのスキルと実践例
  • 6章 組織へのコーチング

本書でも4章で「コーチング・プロセス」とし「コーチング・マネジメント」の「コーチング・フロー」が書かれています。本書で特筆すべきは「コーチが持つべき3つの視点」として以下の3つ(PBPの視点)について言及されていることです。これらは三角形となりそれぞれ相互に作用しているようです。

  • Possesion(身につけるもの)
  • Behavior(行動)
  • Presence(考え方、信念)

全体的に図が多く具体的に書かれているので「コーチング・マネジメント」と合わせて読むとより理解が深まると思います。

3冊目 0秒リーダーシップ:「これからの世界」で圧倒的な成果を上げる仕事術

書評

2016年に出版された本で、上記2冊と違い著者が外国人です。著者は日本に長年いながらも、グーグルやモルガン・スタンレーで人材開発を務めていたとあって外国から見た日本という視点がおもしろい点です。上記2冊と違いコーチングではなく、リーダーシップはこうあるべきということが書かれています。グーグルの話や、マインドフルネス、禅などの話も出てきます。コーチングという文脈ではないので上記2冊+αな気持ちで読むとよいかもしれません。
本書で気になったワード

僕はよく英語で、「Leadership is mobilzing people to tackle tough problems.(リーダーシップとは、難問に取り組むために人々を動かしていくこと)」という定義を用います。
Learn, Relearn, Unlearn
学ぶことは大事だが、ただ知識を増やす(Learn)だけではなく、学び直す(relearn)の必要があります。完全に時代遅れになった考え方、価値観や信念は手放す(unlearn)べきです。
Posted on

スクラムを3ヶ月やってみて

スクラムガイド

スクラムを初めて3ヶ月たったので振り返る

スクラムについて

スクラム(英: Scrum)は、ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと

一定の周期で計画会議→開発(スプリント)、スプリントレビュー、クロージング(振り返り、リリース)を繰り返すことが大事

スクラムを始めたきっかけ

前まで

  • マネージャーの管理コストが高い
    • 開発メンバーが今なにやってるかを把握するのが大変
  • リリースサイクルが決まっていない為開発、営業、運用の連携が困難
    • 開発したものが放置されやすい
  • 突発的な開発対応に追われる
  • 開発者は言われたものだけをひたすら開発するというサイクルになりがち

スクラム体制後

  • マネージャーの管理コストが下がる
    • 開発チームがなにやってるかを把握できる
  • リリースサイクルが決まる為営業、運用、開発の連携がしやすい
  • 品質が上がる
  • 振り返りによりチーム力が上がる
  • 開発が考えるシナリオを推進することができる
  • 開発チーム個々が自発的に行動できる

デメリット

  • 運用などの担当者が必要で担当者がかたよる

スクラム体制について

  • 1スプリント2週間、クロージング1週間とする
  • プロダクトオーナー
  • スクラムマスター(自分)
  • 開発チーム4人
    • ミドルエンジニア
    • 若手ベトナムエンジニア
    • 新卒ベトナムエンジニア
    • 新卒エンジニア

スプリント振り返り

1月中旬から始めて3スプリントを実施した。

スプリント1(1/16〜1/27)

機能概要

  • データ解析+グラフ化

Good/Keep

  • 設計レビューにより実装前の軌道修正ができる
    • 開発チーム+スクラムマスターのレビューにより各自の実装の認識をあわせる
    • プロダクトオーナーレビューにより更に違った目線からの指摘があり最終的な実装の認識をあわせる
    • 設計段階で認識を合わせることにより品質があがる為トータルコストがよい
    • 画面を伴う機能は特に設計レビューによる効果が大きい
    • 設計レビューでアウトプットの認識があうのでビジネスへのアプローチがしやすくなる
  • テスト環境すら整ってない新卒エンジニアがモックテストまでできるようになった
    • 局所的なハンズオンやペアプロは効果が高い
    • スクラムは各自のスキルアップに効果的

Problem

  • プロダクトオーナーとスクラムマスター以外がスクラムの取り組みにおいて受動的
  • ドキュメント・テストケースの書き方の各自の認識が違う
  • Trelloの更新がうまくできなかった
  • JavaScript処理が複雑

Try

  • GitFlowに切り替えるにあたりバージョニングを検討した
    • セマンティックバージョニングにしたかったがメンバー全員に周知し徹底することが難しいと判断し文字列でタグ付けすることとした
  • チームメンバ全員がモックを使ったPHPUnitが書けるようになったので全員UTを書く開発体制にした
  • ドキュメントの書き方の認識をあわせた
  • JavaScriptの構成やフレームワーク変更を検討する

スプリント2(2/6〜2/17)

機能概要

  • 画面レイアウト変更
  • レポート系

Good/Keep

  • クロスブラウザ・端末テストなどマンパワーを要するテストをみんなで分担してできる為テストが楽で早く終えられる
  • チームメンバー全員がモックテストがかけて開発コードのほとんど(不要な部分は除く)のカバレッジをカバーできている
  • 設計レビューの恩恵
    • 要件定義時に認識があっていたと思っても設計すると認識がずれていたりするがレビューの中で最適な解を見つけることができる
    • 実装前のレビューで懸念点をつぶしてながら設計できるのが気持ちいい
    • 実装前にの実装イメージが具体的に湧く為テストが書きやすい
    • 設計後実装の分担をするとテストを先に書けるケースが出てくる
  • 開発チームが各自自発的に行動するようになった

Problem

  • ドキュメント作成に時間がかかる
  • コーディングスタイルの指摘が多い
  • 最初に作成したスプリントバックログの作業量をオーバーした
  • タスクの粒が大きいと初日のスプリントバックログ作成の時間だけでは正確な見積もりができないことがわかった

Try

  • 計画会議とプロダクトバックログ作成を1日で実施した
  • 翌日以降の個人の動きが明確になり個々人が個別に自主的に動ける
  • デイリースクラムにスクラムマスターが参加しないようにした
  • コードフォーマットチェック(php-cs-fixer)をgitのpre-commitに導入した
  • WIPを導入した
  • 次回以降はもっとIF・クラス設計に重点を置いて開発する方針にした

スプリント3(2/27〜3/10)

機能概要

  • 機能の外部埋込プラグイン

Good/Keep

  • 失敗覚悟でギリギリのベロシティのタスクを設定したところ色々新しい課題がみえた
  • 開発メンバ各自の実機テスト環境を改善した
  • 既存バグの修正ができた

課題

  • タスクの難易度があがるとコミュニケーションコストがかなり高くなる
  • 受け入れ条件の範囲を超えた作業をした為余計に時間を費やした
  • 2週間という期間にしばられて品質を落とす形になった
  • コミュニケーションコストを見積もりに入れてなかった
  • 結果的にチーム力と品質向上の取り組みをせずプロダクトができてしまった
  • スプリントレビューの対応でデグレを引き起こした
  • クロージング期間をテストのバッファ期間として使ってしまった

取り組み

  • スプリント予定外の作業はしない
  • まだまだチームが成熟していないのでじっくりやるべきことをやる
  • スプリントレビューの指摘は(話し合いの元)基本的にはクロージングでは対応しない
  • 実装の前に設計にもっと時間をかけることにした
  • 必要に応じてペアプロをする
  • IDEの使える機能は使う
  • ステークホルダーとの確認を怠らない

まとめ

今は下の画でいうところの、形成期と混乱期を行ったり来たりしている状態で、このプロセスをしっかりふんで統一期・機能期に進んでいく計画。スクラムをはじめて以前までのデメリットが解消し、開発チームが積極的に要件定義・設計・開発をする体制になってきた。次は開発チーム全員でフロントエンドの強化をする予定。

参考
以下の記事は何回かスプリントをこなした後に読んだけどあるあるなことがわかりやすくまとまっていて大変参考になった。

Posted on

スクラムの取り組み紹介

スクラムを初めて約3ヶ月がたったので取り組み内容を簡単にまとめてみました。

参考にした文献


SCRUM BOOT CAMP THE BOOK Amazonより

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) Amazonより

ジョイ・インク 役職も部署もない全員主役のマネジメント

参考書籍


SCRUM BOOT CAMP THE BOOK Amazonより

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) Amazonより

ジョイ・インク 役職も部署もない全員主役のマネジメント