エラスティックリーダーシップ を読みました
リーダーシップやマネジメントについて悩んでいたときに良さそうだったので購入。 結構前に読了してたのにアウトプットできてなかったのでメモ。
本の感想
チームの状態に応じてリーダーシップのスタイルを変化させて対応する方法が具体的に書かれていてとても参考になりました。 リーダーシップもマネジメントもスキルで解決できることに気づかせてくれた本です。
SIerとして協力会社のメンバーとチームを組むため、プロジェクト初期の立ち上げにとても苦労していました。今はこの本を参考にチームの育て方・成長の仕方・メンバーとの接し方を実践しています。 特に印象に残っているのは「コミットメント言語」ですね。すぐにチームメンバーにも伝えました。
現実は非情である
実践していますが、なかなか自己組織化チームへの道は険しい。。。 サバイバルフェーズと学習フェーズを行ったり来たりという感じ。 メンバーとの1on1を定期的に行うことが必要と思っています。
購入したのは紙の本
Amazonで探したら電子書籍版がなかったのだけど、O'Reillyのサイトなら電子書籍版も購入できることを後から知りました。Kindleアプリでも見ることができるので参考まで。
本を読みながらとったメモ
殴り書きなのでまとまっては無いです。
スタイル
- 挑戦させる/コーチ型
- チームの問題はチームに解決させる
- リーダーがボトルネックにならないこと
- チームに意思決定の仕方を教える
- 教訓を得られる限りチームが誤った決定を下すことも許容する
- 指揮統制型
- リーダーが道を示す
- リーダーは決定者であり問題を解決する
- ファシリテート型
- アジャイル
- 自己組織化チーム
- チームが問題を解決すると信頼する
フェーズ
- サバイバルフェーズ
- チームに学習する時間が十分にない状態
- ゆとり時間を作って抜け出す
- 学習フェーズ
- ゆとり時間があり、学習や検証を行っている状態
- 問題を自己解決できるよう教え、挑戦させることで自己組織化チームへと育てる
- 自己組織化フェーズ
- リーダー不在でも問題ない状態
- リーダーが自由に使える時間を持てる状態
バス因子
- チームメンバーの何人がバスに轢かれたらプロジェクトもしくはチームが破綻するか？
- バス因子とはバス係数として数えられるメンバーのこと
- バス因子がリスク
- 単一障害点
- 物事の進行を減速させるボトルネック
- 士気を低下、雇用の不安を誘発
- チームの成長を阻害する
- バス因子の除去・発生防止
- ペア作業とコーチング
- 教師として扱う
- メンバーを安全地帯の外に連れ出す
サバイバルモード
- ゆとり時間が十分に取れない状態
- 永続化・常態化しやすい
- サバイバルモードから抜け出す
- ゆとり時間を作るためにコミットメントを取り消す努力をする
- それこそがマネジメントでありリーダーの役割である
- 指揮統制型リーダーシップ
学習モード
- 学習の変化
- 学習の進みが遅く安定高原→学習の谷→学習が大きく飛躍している峰
- 谷は安全地帯の外へ踏み出した状態
- コミットメント言語
- 事実を述べ、＂いつ＂までに＂なに＂を実行する
- 制御下にあるものにコミットする
- チームを成長させるワード
- それに関してあなたは何を行いますか？
- デイリーミーティング
- 1on1
- 笑顔と礼儀を忘れない
自己組織化モード
- クリアリングミーティング
- 全員が知るべき重要な課題を伝える
- 課題提起の機会を全員に与える
- チームの自己組織化レベルを測る
- チーム内の信頼を作り出す
- 目的は未熟なチームを迎え、成熟に向かうのを助けること
- 何を問い、何を行うか？
- うまくいかなかったことは何か？
- あなたはそれに関して何をするつもりですか？
- よかったことは何か？
- 締めの言葉(あなたがすること)
- 権限の行使について
- 物理的な振る舞いを見つけ、その振る舞いを変えたい時はどうしたら良いだろうか？
- 人に対するつらいことをやるのがあなたの仕事(1on1)
- 影響パターンを考える
- 個人レベルの能力・モチベーション
- 社会レベルの能力・モチベーション
- 環境レベルの能力・モチベーション
管理職のマニフェスト
- 管理者は、部下の自己組織化と自己管理スキルを長期的・全体的に成長させること
- 部下が求めるものは変化するという事実を受け入れる
- 部下に対するリーダーシップスタイルを変化させる
- 部下とともに改善に挑戦する
- ゆとり時間を作る
- リスクを受け入れる
- 適切な時に援護する
- 部下が組織を横断してスキルを習得することを支援する
- 部下を導くことが中核
- 自分の時間の50％をコミュニケーションに当てる
- ソフトウェアの問題を人の問題として扱い指導する
- 対人スキルとコミュニケーション技術を学び、部下にも確認させる
JJUG CCC 2018 Spring に参加しました
もう1ヶ月以上前のことですがログとして残しておきます。
１．なぜ参加したか
業務ではJavaオンリー（ほぼ）
- 業務で利用：Java5 → Java6 → Java7
- Javaの成長：Java5→6→7→8→9→10 秋には11
マネジメントに注力するには
- エンジニアリングやれる人を増やす
- まず自分が知らねば教えることができない
トレンドと自分の価値を知りたい
- エンジニアリングも面白いので続けたい
- これから身につけるべき技術の目標を知りたい
２．聴講したセッション
JavaでWebサービスを作り続けるための戦略と戦術
- 改修・バージョンアップし続けることを支える開発環境構築効率化・自動テスト
- 銀の弾丸はないが、金の弾丸はある
Java 9 Variable Handles のイロハ（Java SE 基調講演）
- MethodHandle推し
普通の人のためのJavaコミュニティイベントのススメ
- 「Don't be shy」
- アウトプットしよう
収益を支える中規模アプリケーション開発奮闘記
- 「初期サイズを指定しない」という観点はなるほどと思い、チームにフィードバックしました
- 性能観点での知見は本当に勉強になります。
Java10まとめと、どうなるJava11
- 一番に聴講を決めたセッションです
- バージョンアップにしっかり向き合いがんばろう！
請負Java開発でスクラムした成功事例
- 同じような取り組みをされている人がいるということで聴講を決定
- めっちゃ成功していて、羨ましい
- excel資料を公開いただきたいなーというお願いをしました
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
- いまの業務でも３層＋ドメイン層（by 現場で役立つシステム設計の原則）で設計していたので聴講を決定
- ソースコードレビュー観点をきちんと決めてWikiで共有（多分、自分に足りていないところ）
- 規約の浸透方法や内容に課題（わかりみが深い）
- 変換の嵐もよくわかっていたので、オブジェクト数が多くなることの懸念について質問させていただいたのですがこれから評価という段階でした
３．全体を通して
一貫して感じたこと
- 目的：ユーザーに価値を届け続ける
- 手段：改善を継続するための技術やプロセスを採用する
自分は何を行うか
- チームへのフィードバック -> レビュー観点など関連しそうな内容を説明しました。
- 組織へのフィードバック -> 参加レポートをLTで行いました。
- Javaバージョンアップに向き合うこと（戦略と戦術） -> これからやっていきます。
関西Javaエンジニアの会(関ジャバ) '18 4月度 でキャリアのお話を聞いた
今回はキャリアについてお話を聞いてきました。 スピーカー三者三様、エンジニアとしてのキャリアを生々しくも楽しく聞くことができました。 自分がエンジニアとしてどう生きるのか参考になった点をまとめておきます。
共通していたこと
- キャリアの話は難産である
- 人や環境は大事
- エンジニアとしての矜持
キャリアは生存バイアスの塊
と、だいくしーさんが言われていた通り、一般的なお話にはならないので、できるだけ共通項を探してみようという心構えで聞いてました。
でも、じゅくちょーさんの時には
と思わずにはいられなかったです。 生き様がドラゴンボールの悟空まんま。やることを決めてから猛烈に勉強・練習するやり方。ボコボコにされた後に超パワーアップするやり方。生存バイアスの塊なのでなかなか真似できない #kanjava
— mono(0w0) (@msts_0w0) 2018年4月13日
良い人とつながる・良い環境に身を置く
うらがみさんはコードを書くことに理解ある上司・関ジャバで知り合った仲間。
だいくしーさんは自分が手を出さなくてもなんとかしてくれるメンバー。
じゅくちょーさんは執筆者の会社に転職・海外カンファレンスなどコミュニティの人たち。
朱に交わればとか言いますし、お互いに良い影響を受け・与えることのできる人がいるというのはとても重要だと感じました。
また、やりたいことをやるために環境を整える・変えるというのも共通してました。 コードを書き続けるためにコードを書く以外のこともやるとか、自分の枠を超えて外へ背伸びして手を出して枠を広げるとか。
エンジニアとしての矜持を持ってる
と書くと大げさかもしれないですが、これがやりたい！面白そう！好きだ！という気持ちがこれでもかと溢れています。
また、そのための努力を惜しまない所とか(それを努力と思われてなさそうですが)、自分が他の人たちからどう見られるのかを意識している所とか。
刺さったキーワード
立場的にはだいくしーさんやじゅくちょーさんの一歩手前な所なので、マネジメントスキルについて刺さりました。
自分で手を動かさないが事業やプロダクトに対して責任を持つ人が管理者であり、そのためにマネジメントする。マネジメントスキルは 後天的に習得可能な技術であり、技術であるならハックできる。
アジャイルの本とか読んだり、コミュニケーションスキルの具体的な方法や理論を学んだりすると過去にやってきたことはマネジメントでも何でもないなと反省ばかりです。
プレイングマネジャーとして、最終的に手を出したら何とかなる状態だときちんとマネジメントしなくなる。(>_<)痛いところをつかれた！ #kanjava
— mono(0w0) (@msts_0w0) 2018年4月13日
上司からも「簡単にお前が手を出すなよ」と釘を刺されたことはあります。安易にパワープレイに頼らない戦略や戦術を持ちたい。
ただ、マネジメントに集中できる環境づくりが必要だと感じました。自分の代わりに手を動かせる人を育てるか、できる人がいるところに異動するか。
マネジメントの面白さもわかってきましたが、設計するとかコード書くとかも全くしないのはなんか違うなあと感じるこの頃です。
まとめ
- 好きなことをやる
- 環境を整える
- アウトプット・アウトカム
- 得た評価がお金につながる
まとめると至極真っ当というか、ふつうのことなんだけどそれが難しいというか。 3番目頑張りたいです。
Tech Deep Dive #2 in Osaka に参加して
前提となる知識にビビりながら参加してきました。 ちょうど今回のテーマである性能について考えることが多くなっていたので良かったです。
前提知識について
全体的に理解しやすかったですし、思っていたほど難しくはなかったです。
ただ、アプリやシステムのコーディングだけ経験しましたという人は辛いかも。設計してコード書いて、動かして、性能でないことにハマって、どうやったらいいか悩んで、みたいなところを一度は経験している方が納得しやすいと思います。
Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか reloaded
知らなかったこと、新鮮だったこと
業務ではオンプレの開発にしか携わったことがないので、クラウドを前提とした時に問題となりやすいことについては新鮮でした。
- クラウドではアプリ性能がコストに直結する
- スモールスタートでも早期にスケーリングを考慮する
- スケールアップ・スケールアウトしやすい環境だからこそ安易な実施は状況を悪化させる
再確認できたこと
- 気にすべきは「負荷×インフラ×アプリ」
- どこか１つではなくシステム全体を見る
- 負荷
- 全体と特殊な条件
- 今の負荷と将来の負荷は違う
- インフラ
- スケールアップには限界がある
- スケールアウトは他のリソースを枯渇させるかもしれない
- アプリ
- ロック時間を小さくする
- 秒間の最大処理件数=1秒/ロック時間
- 非同期はビジネス要件のバランスで要否決定
- ロック時間を小さくする
インメモリデータグリッド
Oracle Coherenceを利用した場合の性能改善には素直にスゲーと思いました。
ですが、それを導入するには、ビジネス要件とかコストメリットとか諸々のバランスを考慮しないといけないわけで。 このミドルウェアがマッチするシステムとはどのようなものか？ その辺りの判断ができるようになるために、技術や製品について理解を深めないといけないなぁと考えてます。
もしもみなみんがアプリケーション開発者だったら
よくある問題とその解決方法について、製品機能とともに説明されていました。
- オペレーションミス
- ミスの影響範囲を小さくする
- 復旧できてこそのバックアップ
- 簡単に切り替えられるスタンバイ
- 更新系
- Read Replicaによる参照オフロード
- シャーディング
- DataStoreのスケールアップ
- スケールアウト
- 性能
- 情報の自動収集
- 問題の特定と改善案の決定・適用
- 時間↓ = 処理量↓ / （速度 * 並列度）↑
- 自動テスト
- 上３つを自律的に行うシステムがベスト
各改善方法に対してOracle Databaseの機能で実現できるよという紹介があり、今後のビジョンとして自律型データベースを示されてクローズされました。
各機能は知っているものもありましたが、そうでない方が多く色々と参考になりました。今のプロジェクトで利用している機能についてインフラの人に聞いてみたいなーと思っています。
自律型データベースについては、「でもお高いんでしょう？」という声の通り、それすらも機能の一部でありビジネス要件の解決に導入するか否かの判断が大切だと思います。 あったら嬉しいとは思いますが、アプリ側とインフラ側をそこまで疎にしていいんかなーという漠然とした不安感があります。言語化難しい（´-`）
最後に
総合的な視点でのお話でとても良かったです。 ミドルウェアやインフラについてはもっと知識を深めていきたいので、また開催されるのであれば、是非参加したいです。
カイゼン・ジャーニー ／ たった1人からはじめて、「越境」するチームをつくるまで (発刊イベント)に参加して
- 日時：2018/03/12（月）19:30〜21:30
- 場所：TIS株式会社 大阪本社
発刊イベントに参加して著者のお二人からカイゼン・ジャーニーについてのお話を聞いてきました。
最初は市谷さんからカイゼン・ジャーニーのインセプションデッキについて、そのあと新井さんから発刊に至るまでの経緯と本の読み方、なぜ本を書いたかについてのお話がありました。
カイゼン・ジャーニーの中身よりも全体を通して、「あなたは何をしている人なんですか？」という問いに対する市谷さん、新井さんのアンサーを聞くことができたと感じています。
以下、メモ書きと印象に残った箇所について本の感想とともに
ぼっちに寄り添う本
カイゼン・ジャーニーは実体験ベースのストーリーとプラクティスの解説という構成で、「あるある」という共感と「やりたい」という意欲を引き出してくれます。読了直後にはこんな感想つぶやいてました。
カイゼンジャーニー読了。様々なプラクティスと熱量を与えてくれる良書です。ザ・ゴールとかSCRUM BOOT CAMPと似た感覚。
— Masatoshi Ono (@msts_0w0) 2018年3月3日
もっと既視感あるのは進研ゼミの漫画。すごくやりたくなるんだけど自分(の現場)に合わせてやらないと効果上がらなさそう。でもすっごくやりたくなる。成功したくなる。
僕自身が現場を変えたいと感じてとった行動が主人公である江島君の思いや行動とリンクしました。
まいど！Agile Japan 2017 大阪サテライトに参加して新井さんのセッションを聞いて感銘を受けたり、市谷さんのスライドに大変助けられた記憶があります。
その先にある一人から始めるカイゼンの旅。その背中を押してくれる本だと思います。
どのような人に向けた本か
- チームで仕事をする人
- 経験の浅い人
様々なプラクティスがそれを知らない人にも理解しやすく記載されています。
また、3部構成となっていて、
- 一人から始める
- チームで強くなる
- みんなを巻き込む
の通り、人との関わり方について重視されています。個人的に初めてチームリーダーになる人やプロジェクトリーダーになる人に良いのではないでしょうか。5〜6年くらい前に読みたかったです^_^
コンフリクトを恐れない
どうしてもプラクティスに目が行きがちですが、前述の通り人と関わることが大切だと教えてくれます。人と人が相互作用により力を発揮するためのプラクティスだと思いました。
コンフリクトが起きた場合の解消方法を質問し、回答いただけて感謝しております。
新井さんからは、課題解決につながる単語やキーワードをとにかく重ねていくことで理解をお互いに深める。
市谷さんからは、相手の意見を一旦受け止める。反射的に否定しない。
熱意は持ちつつ感情的にならないよう、ふりかえり、むきなおりしつつコツコツ進めたいと思います。
質問の背景としては、本の感想として、ストーリーの行間には相当な勇気を持って乗り越えないといけないものがあると感じていたからです。昔はコンフリクトをめっちゃ嫌がって避けてましたので。
それが人によっては「こんなに上手くいくわけないよね」という感想を抱くこともあるかもしれません。受け取る人次第なところもあるかと思いますが。
「ざらざら」を「つるつる」にする
何度も推敲を重ねていい物を書く。リファクタリングですね。カイゼンですね。
この記事も書くのにかなり時間かかってますので、もっと練習しないとあかんなーと思いました。
ちょっと危険なプラクティス
- 寝ない
- 週40時間勤務+週45時間執筆
市谷さんの「寝ない」というプラクティスはよくやりがちですが、できれば最後まで取っておきたいですね。常時使うと反動が大きい諸刃の剣です。
新井さんのお話も笑い話的な感じでしたが、残業がなく、それだけの時間を執筆に当てられるタスクマネジメントが素直にすごいと思いました。
カイゼン・ジャーニー読む人って残業多いのなんとかしたいという人も多いと思うんですよね。
大切なのは答えでなく問い
問い続け、答え続けることが大事とクロージングされていました。
僕が本の中で好きなフレーズは２つあります。
- 「あなたは何をしている人ですか？」
- 「気づいたときが、君やチームにとっての最速なんや」
１つ目は答えられない自分を変えたいと思ったこと。 ２つ目は20代の頃に取り組めていたらという後悔を小さくし、今からやったらええんやと思わせてくれたことです。
これからは自分に問いかけるのはもちろんチームや組織にも問いかけたいと考えています。
2017年 ふりかえり
以下の記事にインスパイアされてブログ開設しました。
ざっくりと今年をふりかえってみたいと思います。ギリギリ間に合ったかな(^ ^;)
自分の市場価値を考えてみた
プロジェクトメンバーの転職活動をきっかけに自分の市場価値について考えるようになりました。
メンバーはSES企業からユーザ企業にチェンジしようとしてたようです。今ならすごく理解できるのですが、当時はよくわかってませんでしたね。わかるようになったのも成長かなと思うようにしてます。
ともあれ、僕自身のスキルは？と考えた時に、エンジニアリングもマネジメントも中途半端に思えたので、まず基本のエンジニアリングを見直そうと考えました。
まず情報を外に求めてみた
ツイッターを始めて、興味があるjava、オブジェクト指向設計界隈の有識者をフォローしました。
これが大正解で、やっぱりその筋の人・第一人者の考えに触れることはとても刺激的でした。Qiita、SlideShare、SpeakerDeckで、これが無料とかおかしいだろと思いながら、とにかくインプットしまくる日々。
増田さんのスライドでオブジェクト指向エクササイズを知ることができ、ツイッターで直接アドバイスいただけたのは良い思い出です。
社内のツール活用ワーキンググループに参加
年齢的にも会社のポジション的にも組織への貢献というやつが求められるので、やりますと声を上げる形で参加しました。
初めはモデリングツールのastah活用を考えていたのですが、社内的にはテスト自動化をテーマにしたいということでUIテスト自動化ツールを今のプロジェクトで試用することにしました。
これは結構いい成果が出て、それをまとめた資料も社内的にも評価されました。別プロジェクトへの導入も支援しましたし、今のプロジェクトにも導入する方向で話を進められているので頑張りたいです。
コーティングをもっと重視した
コードと同じような詳細設計をやめたかったのと、とにかく既存のコードが読みにくいので、チームに読みやすいコードを目指そうと言うために資料作りました。
いろんな方の本やスライドを参考にして詰め込み過ぎたら本当に伝えたいことがぼやけちゃった（見せた人からのフィードバックによる気づき）ので改善したいです。
参考にした本
アジャイルに触れる
PMPのPDUを獲得するために、ザ・ゴールを読みました。TOC（制約条件の理論）やカイゼンとか目からウロコで、今までちゃんとマネジメントできてなかった自分が恥ずかしくなりました。
ここから、リーン開発、アジャイル、スクラム、かんばん、チームビルディング、DevOps、ペアプログラミング、モブプログラミングなどなど片っ端からインプットしました。
勉強会に参加する
アジャイルに触れたのでちゃんとお話を聞いてみようとアジャイルジャパン大阪サテライトに参加しました。
問題を解決するために人と向き合おう・対話しようと決意できた良い機会になりました。
外部の勉強会に初めて参加したのと、エモい話が多かったので完全に感化されてましたね。
今年は他に
- astah関西 第1回勉強会
- 「正しいものを正しくつくる」とは何か
- DevLOVE関西2017 commitment 〜"何"にコミットするのか？〜
に参加させていただきました。
参加した後にアウトプットするまでできなかったので、来年は頑張りたいです。
作業の属人化をなくすためアジャイルプラクティス導入
セルフマネジメントチーム（自己組織化）を目指すために、チームで色々始めてみました。
読んだ本
「許可を求めるのではなく謝罪しろ」じゃないですが、やると決めてチームには「小さく初めてアカンかったら元に戻すか別の方法考えよう」でやってみたら案外良くって定着してきた感じです。
やはり課題も多いですが、課題が見えなくてどうしたら良いんだと迷うことは少なくなりました。
今後の課題
僕自身もウォーターフォール開発プロジェクトしかやったことがなく、周りもそんな感じでした。
現在のプロジェクトは開発機能の単位が小さく、仕様が確定しなかったり、変更も多かったりするのでアジャイルになれば上手くいくかなと思ったのですが、やっぱり納期なんかは固定されており一部アジャイルがそぐわない部分もあるのは事実です。
ただ、チームがアジャイルになって欲しいので引き続き以下の点について頑張りたいです。
まとめ
- めっちゃインプットした。次はアウトプット目指す
- 俺やったわと言える成果が見えた
- チームをもっと輝かせたい
