第8章 より効果的なアジャイル:個人および対話
しかし、アジャイルがこれまで広く注視してきたのは個人よりもプロセスのほうであり、個人に関する視点は、特定の構造化されたコラボレーションを取り巻く対話に限定されていた。
これですよ!!!
確かに~
良いチームを作れば何でもできると思いがちで、これは間違ってはいないけど、個人の高い力があってこその話であることを忘れてはならないな、と改めて実感した。
個人の効果性をとことん追求することは、組織の効果性を高めることを目的としたあらゆる計画の礎となるべきである
個人の力をここまで重視した書き方はあまりみたことがなかったかも?CleanAgile にも個人の技術大事って書いてあったか 役割の密度
シンプルにわかりやすい図なので、社内での説明で使っていきたい
有能なソフトウェア専門職は、「テクノロジに関する知識」「ソフトウェア開発プラクティスに関する知識」「専門分野に関する知識」に精通しているものだ
コード書く側としてはビジネスドメインについて欠けがち。
プロフェッショナルデベロップメントを行う状況、プロフェッショナルデベロップメントを支援するためのアドバイス、実装にあたっての質問を含め、PDLの詳細については『CareerPathingforSoftwareProfessionals』というホワイトペーパー❻を参照してほしい。
新人に一つの道しるべとしておすすめしている。
技術職には、程度の差はあれ、こうした種類の知識が必要である。...(中略)...ビジネスや科学の分野の知識はそれほど重要ではない。
ビジネスや科学の分野の知識が、具体的に何を指しているかにもよるが、少し違和感。例えば、ビジネス知識なら人にものを伝える時にプレゼンの知識は重要な気がするし、科学の知識ならソフトウェア開発を支えているテクノロジーがどう進歩しているのか知ることは重要な気もする。
技術職が相手に合わせてコミュニケーションスタイルを調整するには、明確な指導や励ましがしばしば必要になる
ちょうどこれが自チーム内でも問題に…相手の理解度や会話する上での内容の粒度の調整をどう伝えたら苦手な人ができるようになるのか…
https://scrapbox.io/files/61ae034b116c30001fe7a759.png
アジャイル開発では対面でのコラボレーションが求められる
GitLabはオールリモート、かつ世界中に開発者が散らばっている中で開発を進めているそうです。
リモートが浸透した社会でも対面でのコラボレーションを求め続けるのかどうか、気になっています。
アジャイルと分散アジャイルでは遅延して良い範囲や種類が異なっている
他者の成功をどのように手助けすればよいかについて考えるという発想の転換は、チーム内に道徳的な力を育むのに役立つ。RotaryInternationalの「4つのテスト(FourWayTest)」は、筆者が知る中で最良のモデルである⓭。■それは事実か■それはみんなにとって公平か■それは好意と友情を深めるか■それはみんなのためになるか
これいいよなーっていつも思う
推奨リーダーシップアクション
検査
■個人の能力を最大化するための組織のアプローチについてじっくり検討する。そのアプローチには採用後の継続的な人材育成が含まれているだろうか。
基本は仕事してスキルアップしようというスタイルで、書籍や勉強会の補助はなく、社外での勉強や副業は非推奨(ただし風向きは変わりつつある)。採用後の研修も新人(プログラミング未経験が大多数)向けのプログラミング研修しかない。ただ、個人がどういう力を伸ばしたいか?その力を伸ばすためにどのようなアサインがいいか?というのは4Qに一度位の頻度+望めば更に高頻度で考えてくれる。
自己啓発は会社として推奨している。チームが形成期のため、組織(チーム)としてのアプローチはあきらめている。
組織の方向性とずれていなければ書籍購入やセミナーへの参加は許可されるが、自分でやる気が出せるかどうか次第になっている。基本的にアサインされるプロジェクトは現行システムの改修・機能追加なので、自発的に取り組まないと新しいことが取り入れられない状態
■組織がプロフェッショナルデベロップメントのために設けている時間を確認する。与えられた時間からすると、現実的にどれだけのプロフェッショナルデベロップメントが可能だろうか。
使った時間と成果の測定を正確に取れていないなーっていう課題を感じている。
全く測定できていない。プロフェッショナルデベロップメントの定義が今一つ分からず困った記憶がある。
■メンバーにヒアリングする。プロフェッショナルデベロップメントの機会が明確に定義されていることは彼らにとってどれくらい重要だろうか。現在組織が提供している支援に彼らはどれくらい満足しているだろうか。
キャリアパスが明確にあると安心して働けるという人は多くいるらしい。
キャリアパスの定義や支援に偏りがあることを従業員も経営陣も課題と認識しているがまだまだ改善が不足している。自分は身近にはやっているのであまり不満が出ていないけど、そうではないところでは不満がでがちなようだ。
これ、そういえば今のメンバーには聴いたことがない。。前のメンバーはかなり重要視していて、組織の支援に満足しておらず、自主的に勉強していた。
■組織内での非技術的な対話を確認する。メンバーが実施するミーティング、共同作業、経営陣とのコミュニケーション、その他のソフトスキルはどれくらいうまく機能しているだろうか。
部署ごとで差が大きく、なんとかしないとなーっていう感じ。
上に同じ。かなり格差が激しい印象。
■チーム内で目にする技術的またはそれ以外の衝突についてじっくり検討する。メンバーのEQに点数を付けるとしたら何点になるだろうか。
8/10くらい。。。?
9/10くらい。。?
適応
■プロフェッショナルデベロップメントの時間を定期的に設けるための計画を立てる。
この部分読んで、定期的に個々人が勉強したいことを勉強する時間を取ったが、周り(他チーム)からの批判が厳しくて頓挫した。
LT会はやっているが、定期的なインプット会はあんまりやれていないかも?一律でどんな人でも週に2-4時間は取れたらなー。
■ConstruxのPDL(またはその他のアプローチ)を使って、メンバーごとに意味のあるプロフェッショナルデベロップメントプログラムを定義する。
現状、メンバーごとにはできていない。(PDLを紹介して、個々人にどういうキャリアを歩みたいか?というのを考えてもらい、それぞれのペースで学んでもらっている。)
PDLではないけど、色々やり始めていて、結果として似ているのが面白いなって感じ。
■チームメンバーの対人スキルを向上させる計画を立てる。この計画には、性格タイプについて学習する、組織全体のコミュニケーションを促進する、対立を解消する、ウィンウィンの成果を出すことが含まれる。
チームにjoinする人は、4時間位かけてどんな性格かとかどんな仕事のスタイルが好きかとかどんな価値観が好き/許せないか?とかをチームメンバー全員と共有するようにしている(ドラッカー風エクササイズのA面+B面を少し改良したようなもの)。その上で、その人にあったコミュニケーションの仕方を皆で考えて、その人自身から合意を取っている。継続的にやれてはいない。(チームメンバーが入ってきた時に、この人はこういう価値観があって...というのをもう一度説明するような感じ)
4タイプくらいの診断と、経歴と、仕事やプライベートに対する価値観と、自分のビジョンや趣味を1枚に埋めるシートがあって、それを部署に入ったら書くようになっていて、それで自己紹介をする習慣がある部署になっているので、楽。
Steve McConnell. More Effective Agile ソフトウェアリーダーになるための28の道標