チームを変えたいならチーム全員に同じ講座を

ほら、あるじゃないですか。中堅やマネージャになると行かされる外部の集合教育って。教育の専門業者が都心の割とアクセスの良いビルで開いている企業向け研修。

例えば、人間力とか組織活性化とか部下とのツーウエイコミュニケーションとかね。エンジニア向けだとベンダー講座とかシステム開発手法など、どれでも受講料が馬鹿高いですよね。

まあ、無料のものは広告だったり、有償研修の一部のお試し(客寄せ)だったりしますので、ただより高いものはないのですけれど。

研修の評価

企業内研修でもそうですがこうした講座には最後にアンケートがつきものです。そして受講者はみなさん大人なので講座の評価をそこそこ

「有用だ」

と評価します。だって、業務に使えないと思ってそうマークしたら理由の欄にその理由を書かなければならないでしょう。

心から有用だと思う受講者もいるでしょう。受講したその日だけは。

翌日の現場では

週末でなければ翌日、現場で研修前までの仕事を再開するのですが、研修で学習した人間力とか組織活性化とか部下とのツーウエイコミュニケーションの講座のプラクティスを使うでしょうか。

それより、受講してもらってきたテキストはどうしたのでしょう。研修から家に帰ってそのまま本棚あたりに留置しているのではありませんか。よくても仕事場のキャビネの中に直行でしょう。

違うのはベンダーの有償講座で、技術的ノウハウが書かれたテキストは仕事場の机の上に置かれるケースが多いですね。よく見かけますし。ただ、基礎スキル系の○○力や組織開発や意識改革系は見かけたことはないです。

経営者は受講アンケートを見てはいけない

企業内研修で集合教育だと主催者は人事部になります。人事部も、経営課題の解決を経営者から振られるので、今後の企業を背負う中堅の次世代を担うゾーンを狙って改革にふさわしい人を人選するものです(たぶん)。

でも、現実は翌日以降の行動を見れば一目瞭然です。

人事部は受講アンケートをまとめて経営者に報告して振られた経営課題は「対応済み」とするのです。

経営者は、受講アンケートを見ても意味がないことを見抜かなければなりません。本当に調べさせなければならないことは翌日以降の効果測定です。

人、エンジニアに対して投資をしているのですから効果がなければなりません。効果がなければお金をドブに捨てているようなものです。

こうした考え方は、エンジニアの技術研修でも同じです。受講して学習したことを現場で使わなければ高額な受講料は受講者の自己満足で終わってしまうのです。特に、チームビルディングやプロジェクトの運営に関わる講座は。

受講者は誰が適切なのか

翌日の現場でのシーンで学べることは、

「学習したプラクティスを使う環境がなければ学習したことは使わない」

ということです。ましてや○○力などの組織に働きかけるテーマについては、中堅クラスの人が意識を持っても、

「周囲は誰ひとり同じような組織を変えることについて思っていない」

のです。受講者がひとり頑張っても単なる空回りなのです。

組織に変化を求めるのであれば、組織に影響力を与えるほどの権限を持っている人が最有力の候補者です。

もう一つ、

「組織全体に対して変化を受け入れさせる環境を作る」

こともできます。例えば、マネージャとプロジェクトチーム全員が受講したらどうでしょう。翌日、現場に戻るとプロジェクト関係者全員が同じ研修を受けているので、講座の中でチームに取り入れたいことを新たな知識の習得という負担がなく取り込むことができます。

人選するなら組織に対して変化することを持続し続ける権限を持っているか、チームなど組織単位で受講させないと組織もプロジェクト運営も変化は起きません。

 

 

 

 

 

「謙虚・尊敬・信頼」より「理解・信頼・対等」がチームに必要な価値観

facebookでここ数週間、「Team Geekを読んでよかったよ」というコメントがTLに流れたのですね。ツイッターほどじゃないけれどTLで目に止まるのは気にかけているからだし、気にかけているのは買ったのに積み本にしているから、なのですけれど。

じゃあ、「読んだら」なんですが、優先して読みたい本があるので、というそういうことも重なって、気にはなっているけれど、というあるあるな状況です。

さて、TLでも出てくるのが「HRTの原則」です。HRTは、

「優れた開発チームでは、謙虚(Humility)、尊敬(Respect)と信頼(Trust)の3つの価値が大切にされる」

というもので、チーム、組織、顧客とプロジェクトを運営する上でこの価値観を共有することで成功に繋げる、というもの。

気になる「謙虚・尊敬・信頼」の順序

読んでいないので、というのは間違っていたらごめんね、なのですが、自分の価値観から言えば、

尊敬>信頼>謙虚

何ですよね、ワタシ的には。ただ、尊敬とかは意味合いとしてどうなのかしら、と思うわけです。特に、

その人の人格をとうといものと認めてうやまうこと。

下線を引いた「敬う」という箇所。

dictionary.goo.ne.jp

尊敬ではなく理解ではないか

尊敬という言葉の意味合いを仕事で持つとか、人生で持ったことはないのです。

尊敬とは自分のできないことをできる人に対して持つ感情なのです。だから、無条件に自分ができない技術を持っていると「すごいな」と思うのです。

そして、プロジェクトチームを編成する際には、チームの目的を達成するためのチームとしてのスキルセットが必要になるので、メンバは必ず何かしら「すごい」エンジニアになるのです。

だから、けものフレンズのサーバルちゃんの

「すっごーい!○○が得意なフレンズなんだね

は価値観が一緒なんですよ。

自分としては、尊敬より「理解」なのではないかと思うのです。

意味としては2番目の方の

「他人の気持ちや立場を察すること」

の方です。

dictionary.goo.ne.jp

○○ができるから信頼する

チームとして必要なスキルセットとスキルのレベルがチームの存在目的を達成するためにあるのですから、メンバには期待する貢献があるのです。

プロジェクトの中で、実際にアウトプットされたものの品質、スピードを確認するとはじめて、

「ここまでなら任せられる」

と信頼できるのです。プロジェクトマネージャの業なのか、性格なのかはわかりませんが、このどこまで任せられるは、どこまで放置しても同じ結果が得られるという信頼に基づいているものです。それを見誤ったら、自分で始末するんだな、という。

謙虚より対等

尊敬ではなく理解、アウトプットに対する信頼。あとは謙虚です。

謙虚は謙虚でもいいのですが、謙虚も辞書を引くと

「へりくだる」

とかあるのが今ひとつ感覚的に違うなぁ、と。

dictionary.goo.ne.jp

プロジェクトチームでは、役割分担をします。プロジェクトの目的を達成するために編成するチームですから、必然と目的達成が見込まれるスキルとレベルを持っているメンバで構成することについては前述したところです。

であればこそ、それぞれが得意なフレンズなのですから、へりくだったり慎ましくする必要はないのです。

ただ、相手を理解することにより、相手の存在を認めるのですから、上下関係はなく横一線に並ぶのです。つまり、チーム内は上下関係はなく、フラットな対等の関係であると思いますし、実際のチームビルディングをする際にはそれを明言しています。

変に気を使って言わなければならないことを言えない環境を作ることは望んでいませんから。

 

理解・信頼・対等がチームが成功するために持っておきたい価値観です。

 

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

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

 

 

刺激を与えてれくる人が周囲に何人いるかで実現できるかがわかる

エンジニアとして成功するためには何をしたらいいのでしょう。技術を身につけ、プロジェクトで貢献し、ロールを移り、専門的な領域で名前が知られるというようなことかもしれません。

仮にそうした人物像を目指すとして、では、今、目指す人物像を実現できる環境にあるかと問われるとどうでしょうか。

環境の影響は見過ごせない

経験から言えることは、何かを実現したいときにはそれを実現できる環境が必要です。実現するために必要な要素がなければ、無いことを理由にして実現したいことを諦める理由を自ら作ってしまうからです。

自分の実現したいことを真剣に実現したいと望むなら、自分が言い訳するような退路を塞ぐ環境を作り、実現に向けて進めるだけなのです。実現したいと思うなら、思ったときに一歩を進められたかどうかで真剣さを測ることができます。

自分の実現したいことを実現する環境は誰も作れない

エンジニアとして実現したいことがあるなら何が必要かくらいは自分で調べることができます。プロジェクトチームの運営をより良くしたいなら、アジャイル開発系のプラクティスを取り入れることもひとつの方法です。

であれば、自身で学びながら実践している人の経験を聞いたり、相談に乗ってもらうのもひとつのエンジニアとして実現したいことを実現に近づけるための方法です。

そうした環境は誰も自分のためには作ることができません。

なぜなら、エンジニアとして何を実現したかは、自分自身しか知らないからです。

周りに刺激を与える人が何人いるか

環境を変えるために必要なことは、自分にとって刺激を与えてくれる人が何人いるかです。いくら自分で変わりたいと思っても、ひとりでは体験できる時間が短すぎます。ですからそうした経験のうち、周囲の人が体験したことを知ることで自分の体験のように刺激を与えるのです。

エンジニアとして実現したいことがあるのであれば、エンジニアとして使える時間、それは仕事中かもしれないし、オフの時間かもしれないです。いづれにしても自分で自由にできる時間に関係する度合いの高い人から書き出してみましょう。

実現したいことに対して刺激を与えてくれる人が何人いるか

その中に、エンジニアとして自分の実現したいことに刺激を与えてくれる人は何人いるでしょうか。

もし、ひとりもいなければ、刺激を与えてくれる人に自ら会いに行く機会を作らなければなりません。

仕事の中で自分の実現したいことに対して刺激を与えてくれる人がひとりもいなければ、オフの時間と自分のリソースを使う必要があるのです。

そうした機会を作っても、自分の実現したいことに刺激を与えてくれる、刺さる言葉を発してくれる人は限られます。つまり、機会を作れば確実に得られるものでもありません。何度も試行錯誤して、より高い刺激を与えてくれる人と関わりを持つことが必要です。

そのためには、give & takeの関係にならなければなりませんが。

刺激を与えてれくる人を3人作る

エンジニアとして実現したいことに影響を与えるほどの刺激を与える人は何人つくればいいのでしょうか。

経験から言えば、3人が望ましいです。ワタシの場合は元のマネージャが20代からずっとお付き合いさせていただいていますが、これは会うたびに刺激をもらえるからです。

あとはアジャイル界隈の方。そして気づきを与えてくれるワイフ。

まだまだ実現したいことはあるので、元マネージャとワイフを除き、ステージごとで変わって行くかもしれません。

 

積み本

これは買ってみよう。Kindleも値段同じなら紙だよなぁ。

でもこれ、年間購読にした方が良いのかも…。

 

 

 

低待遇でエンジニアを採用しようとする企業は、教育コストに対する価値観を物語っている

medium.com

ごもっともです。ワタシも是非とも高額で御採用のオファーがあれば考えなくもないです。こちらの前提は、今のポジションと仕事の面白みと残りのエンジニアとしてのキャリア(プロジェクントマネージメントとマネージャの専門性を生かせる)とするならば、ですけど。

優秀なエンジニアって何?

先のエントリを読んで、言っていることはわかる。が正直なところです。ただ、各社の採用する側が

「優秀なエンジニアを採用したい」

という優秀なエンジニアとはどんなエンジニアかは各社によるのです。なぜなら、各社の事業内容や事業の進捗により必要とするエンジニアに多様性があるからです。

では定義できないのかといえば、そんなこともありません。

でも、優秀なエンジニアを各社で共有できるように表現するとすれば、ITSSv3のレベル7の人物像のようなものにならざるを得ません。各社の事業を振り落とし、共通項としてしか表現の仕様がありませんから。

今必要な、優秀なエンジニアを示す

採用する各社も今必要な優秀なエンジニアやこれから3年以内(の中期経営計画など)で必要となる優秀なエンジニアの人物像なら示すことができます、というか示すことができなければなりません。事業をしている側の経営者や採用部門なのですから。

肝心なことは、「今必要な」です。事業を継続することが企業を存続させるために必要なことですから、経年すれば事業ステージも主要な事業も変わっていくものです。

だからこそ、今必要とする優秀なエンジニアの人物像が描けなければなりません。

優秀なエンジニアが採用できない理由

もし、採用で自社が必要とする優秀なエンジニアの採用ができていないとするならば、採用側が必要とする優秀なエンジニアの応募条件を示すことができていない可能性がとても高いです。優秀なエンジニアを必要とする採用側の各社がこのアクティビティの主体者である限り、優秀なエンジニアにリーチし、取り込むところまでが役割分担なのですから。

では、優秀なエンジニアを採用できない理由のうち、優秀なエンジニアが採用したい各社に接触するまでにどのような障害があるのでしょうか。

採用担当ではなくても、応募する側としての視点でも仮説を示すことはできます。優秀なエンジニアを採用できていない理由で想定できることは次のとおりです。

・優秀なエンジニアにリーチできていない
・欲しい人材が持っていなければならない諸元を示すことができていない
・曖昧さ故に、応募側が回避している
・応募があってもミスマッチを起こして不採用となっている
・必要とするスペックを持っている優秀なエンジニアが元々この世に存在していない

採用での低待遇は将来の教育コストを示している

結論から書けば、本来、自社で育成するところをすっ飛ばしていきなり即戦力、それも優秀なエンジニアを欲しいというのは子どものわがままのようなものです。

本来であれば、自社で育成するところの時間と手間を端折っているのですから。

逆にいえば、本来自社で育成し負担する育成コストをどう見ているか、という育成に対する価値観を応募するエンジニア側から探る指標ということができます。

応募する側で注意をしておく点がもう一つあります。本来自社で育成することができないのは自社で育成する力量がない他に事業を進める上で育成している時間をコストとして買っているというケースもあるのでどちらの理由で中途採用しているのか、です。

ただ、いづれにしても優秀なエンジニアを採用したい各社は、事業を進める上で中途採用する他に手段がないのです。

手段がないのであれば、育成または時間を買うのですから、相応の教育コストを盛り込む必要があります。それを含めた待遇となっているかどうかが判断ポイントなのです。

つまり、低待遇で優秀なエンジニアを採用としているとするならば、

「採用後の育成コストに投資するつもりはない」

というメッセージと捉えて良いのです。だからこそ、低待遇では優秀なエンジニアを採用することができないのです。

 

ワーク・ルールズ!―君の生き方とリーダーシップを変える

ワーク・ルールズ!―君の生き方とリーダーシップを変える

 

 

 

時間に追われてもまずまずの出来の資料の作り方

ペアプログラミングは、二人一組がコードを書く役割と書くコードに対してプロポーズ(積極的に提案)する役割になってコードを書くプログラミング技法です。

#かなり雑な説明ですけど

技術のギャップが強制的に徒弟関係を作れる

ペアプログラミングの良い点は、技術的に優秀なエンジニアと組むことで成長途中のエンジニアに対して(そのコードを書いている間に限り)徒弟関係が成立することです。

徒弟関係が成立する間は、積極的に優秀なエンジニアの技術移転が進む環境が作られます。成長途中のエンジニアに対し、技術的なホワイトスペースや仕様をコードに変換する思考、つまり、発想の仕方を半ば強制的にインストールすることができます。

まあ、捉え方によっては、ですけど。

徒弟関係で技術移転を図れる

でも、技術的なギャップは意識をせずに生じるものですから、なら一層のこと技術的なギャップを作り、優秀なエンジニアから成長途中のエンジニアに技術移転を図ることが組織的な技術の向上を進める上で採用しない手はないことになります。

では、コードになる前の、

「仕様案を作る際のペアプログラミングに相当する手法はないのかしら」

と思ったのです。

 

文書作成でも同じ効果の方法があるか

さて、あるのでしょうか。「ブレスト」はどうでしょう。イメージします。会議室に複数人が集まり、ファシリテータがホワイトボードの前に立ち、テーマについてディスカションを促します。

現実はどうでしょう。ブレストでも他の会議でも話す人は話すし、話さない人は話さない。

では「レビュー」はどうでしょう。レビューアとレビューイに分かれ、レビュー観点に沿って指摘をし、合否を決定します。

ペアプロと圧倒的に違うのはレビュー対象が事前にできていることが前提で、静的なオブジェクトに対してウォークスルーするのです。また、レビューは基準をボーダーとして合否を決め、リジェクトされれば修正の上、再レビューというプロセス設計になっているところがあります。ペアプロはその場でより良いコードに修正して行きますから時間に対する価値観が違うという見方もできます。

知っているインプットでしか仕様は作れない

以前、トラブルの説明をする必要があるにも関わらず、技術的な情報を持ち合わせていない(メンバが知っている)ときに、プロジェクタにワードを映し、メンバにはそばについてもらい、技術情報を教えてもらいながら資料を作ったことがあります。

ある意味、ペアプログラミングの手法をしつつトラブルの説明資料を作ったとみなすことができるでしょう。

その際の経験で思ったことは、インプットをもらいながら文字に変換しなければならないので「会話」をしながら文字を生成するプロセスをするのはしんどいな、ということです。

じゃあ、会話せずに文章を作ればいいじゃないかと思うかもしれませんが、何せ情報を持っていませんから会話をせざるを得ないのです。

会話をする、理解する、文字で表現する、実際に打ち込む、声に出して読み上げる、ということをリアルタイムにするわけです。

とても難しい作業で終わった後、さずがにヘタリましたがアウトプットされた資料はまずまずでしたし、出来上がりも早かったです。

この事例から、ペアプログラミングと同じように仕様を検討する資料を作る(デザインする、でもいいかも)際にも、ペアで作成する方が効果的かもしれません。

 

 

 

エクストリームプログラミング

エクストリームプログラミング

 

 

エンジニアとして開発手法やツールを変えたいと不満を言うより確実に変えるために

エンジニアが所属する組織の中で、特にプロジェクトの開発手法、ツールなどにおいて、あれこれと思うところを場面場面で意見だったり愚痴だったりを言っている光景を見かけることがあるのですが、そうした行為、つまり、意見や愚痴がどれだけ実現に向けて進むかと言えば、ほとんど実現しないのではないか、と思うのです。特に、愚痴の類は。

担当エンジニアができること

担当エンジニアができることは自分の裁量の中で、です。

チームのプロセスや手法を変えるためには、影響と、リスクと、見通しの裏付けが現状取られているコストに対して優位性が必要です。

不満に思っていることが、現状を変えるコストを投下し、且つ、リスクをテイクしてまでチームを動かす判断に至るかどうか、と考えることです。

チームのプロセスや手法を変えるために、自分の裁量の中で実績を作り、それを口コミで広めフォロワーを増やすことでチームのデファクトにしてしまうというアプローチもあります。

リーダエンジニアができること

 

リーダになると何らかのロールを一任されるので裁量の範囲が広く重くなります。ロールを一任されるということは、プロジェクトマネージャの権限を一部ですが権限移譲されてるということですから、担当する領域に限り、プロジェクトマネージャと握れれば好きにできます。

担当エンジニアとリーダエンジニアの違いはロールの範囲、つまり、負う責任に伴う権限の有無です。

プロジェクトマネージャができること

プロジェクトマネージャになるとそのプロジェクト全般の推進に係る範囲において責務と引き換えに権限を持つことになります。

プロジェクト内についてはヒラエルキーの頂点に立つ(現実は、開発責任者やプロジェクトオーナーがいるので中間管理職ですが)のでプロジェクトに向かう場合は最高権限を持っていることになります。

持論から言えば、チームの存在意義はプロジェクトの目的を達成するために存在するのであり、プロジェクトの開発手法やツールはプロジェクト最適化で選択されなければなりません。

ただ、負う責任の範囲において、裁量を持っているのでプロジェクトに対してプロジェクトマネージャの嗜好やプロジェクト内でのLabを試すことができます。

マネージャができること

マネージャができること。組織の中で担当するビジネスをキャリーする立場です。担当するビジネスに対して結果を出すことが大前提なので、結果に到達するオペレーションであればどのような開発手法もツールもプロジェクトチームに対して影響力を行使することができます。

 

 

ここまでロールで分けてそのロールの立場から開発プロセス、開発手法、若しくは、ツールにおいて変えたいとか改善したいと思うとき、愚痴をいうことがどれだけ無駄かがはっきりしたのではないか、と思うのです。

エンジニアにおいても組織のメンバである以上、組織を巻き込んでまで負う責任とひもづく(はずの)権限がなければ変えることはできません。

現行の開発プロセス、開発手法又はツールを変えることによる効果の実績がなければ。

逆に言えば、権限を持ち合わせれば、その権限に応じて変えていくことができます。

つまり、組織の中で自分自身を超えた範疇まで影響を及ぼすようなシステム開発をしたければ、影響を及ぼしたいポジションにつくことが必須なのです。

 

影響力の武器[第三版]: なぜ、人は動かされるのか

影響力の武器[第三版]: なぜ、人は動かされるのか