組織開発できるエンジニア

今から思えば自分が考える組織を開発したのかよくわからない。正しくは、組織としては存在していたが、中身が自分が考えるような仕事の仕方ができていなかった組織を再構築し直した、かもしれない。それはそうだ、その組織に異動したときだって組織としては存在していたのだから。でもこれから目指そうとしていたビジネスに耐えられる構造にはなっていなかった。

プロジェクトチームを編成するとき、プロジェクトの成果物を作成するスキルを持つエンジニアを集める。インフラのプロジェクトであれば、HWやNWの知識を持つエンジニア、OSやMWの知識を持つエンジニアを集めてチームを作る。そうしないとプロジェクトの目的を実現することは難しくなってしまうからだ。

組織にその考え方を当てはめると、ビジネス目標を達成できるエンジニアを育成し、育成したエンジニアに仕事をアサイメントし、エンジニアが仕事をやり遂げることのリターンでビジネスが達成される。

そこには、育成、仕事、遂行とキーワードが並ぶ。このキーワードだけで言えば、再構築する前の組織においても同じキーワードは存在したはずだ。でも、再構築しなければ思い描いていたビジネスは実現できなかったはずだ。

見方を変えれば、実現したいビジネスと持っていたスキルややりたかったことが一致したから再構築ができ、ビジネスもついて来れたのかもしれない。巡り合わせもあったかもしれないが、ビジネスに必要な組織がなんであるかデザインできなければ、いくら頑張ったとしてもビジネスはついて来ない。やればやるほど失敗し、赤字になってしまう。

ビジネスをやるにあたって、エンジニアの持っているスキルとこれからのスケールするビジネスに必要なスキルをアセスメントし、誰がビジネスをキャリーするリーダになるかを見定め、重点的にアサイメントを配慮することでエンジニアを育てる。

プロジェクト型の人材育成の焦れったいところは、すぐに育成面での結果が得られないことだ。短期プロジェクトといっても半年はかかるし、狙うビジネスはそこではないから余計に時間がかかる。そうした時間的な制約を理解し、組織の再構築の成果が見え始めるのは3年後だろうと思っていたが実際、そのくらいの時間が経たないとメンバが自在に動くような組織の骨格にはならないものだ。

こうした組織を開発するということは誰かに教えてもらったことは一つもない。組織にそうした研修があったわけでもなく、組織づくりを手伝って覚えたこともない。不思議なことに、エンジニアからプロマネを目指し始めたときにはプロマネに必要なことを考え、プロマネになったときはマネージャの仕事を考えていただけだ。そしてプロマネとマネージャで共通するのは機能する組織を作ることを考えていたということかもしれない。

 

スラスラ読める Pythonふりがなプログラミング (ふりがなプログラミングシリーズ)

スラスラ読める Pythonふりがなプログラミング (ふりがなプログラミングシリーズ)

 
スラスラ読める JavaScript ふりがなプログラミング (ふりがなプログラミングシリーズ)

スラスラ読める JavaScript ふりがなプログラミング (ふりがなプログラミングシリーズ)

 

 

 

調達 スラスラ読める Pythonふりがなプログラミング

 

スラスラ読める Pythonふりがなプログラミング (ふりがなプログラミングシリーズ)

スラスラ読める Pythonふりがなプログラミング (ふりがなプログラミングシリーズ)

 

 

年上の50代のエンジニアを育てる

年上のメンバがいた。2−3歳くらい上だったと思う。技術的にはとても優秀で、業務を進める上で抜け漏れなどの考慮不足を許さない気質から気配りもするし、人当たりもとてもソフトなエンジニアだ。

若手エンジニアが技術習得に時間を使っていなければ、時間を取って更新育成もする。

なかなか、いいエンジニアでしょ。

もちろん、得意なスキルもあれば、不得手なスキルもある。ファシリテーションは今ひとつだし、進行させるとついつい技術よりに話が行ってしまい収集がつかないときもある。

簡単にまとめれば、技術は優秀だけどドジっ子なお兄ちゃんなエンジニア、である。

多分、技術的に優れているので誰もドジっ子な部分があっても誰もあれこれ言わない。というか言えない、のかもしれない。技術の部分については、製品仕様や機能としてリファレンスがあるので間違っていれば若手でも「違いますよ」と言いやすい。「ほら、ここに書いてありますよ」とさし示すことができるからだ。

ただ、プロジェクトでのファシリテーションや運営になるとリーダとしての資質の部分や経験知によるドジっ子なお兄ちゃんエンジニアの世界が繰り広げられるので同じチームになったメンバはお付き合いするほかない。

これは他のプロジェクトマネージャであっても同じである。リーダ役が広げる世界観でプレイする他ないのだ。でも、いくら技術的に優秀でも天は二物を与えないようなので、お兄ちゃんエンジニアにドジっ子属性を与えることにしたらしい。

ドジっ子属性満載でファシリをすると技術よりそっちでドッタンバッタン大騒ぎになる。側で見ている分には面白いので放置する。

でも、そのドジっ子属性を誰からも突っ込まれないのはキャラとして可哀想だ。これはドジっ子属性というよりは、年齢的なところにもよるのかもしれない。年上だからね。

そうした技術が優秀でドジっ子であることを(一応は)理解しているので学ぶことについては人一倍貪欲である。

苦手だけれど、苦手だから、ある意味、コンプレックスになっている部分もあるのだろう。

でも、誰もそういったところは面と向かって言わない。

なので、マネージャとしてあれこれとおもちゃを渡す。例えば、人的ネットワークでつながっている専門家のワークショップのようなものを見つけて「こんなのがあるよ」と情報を渡す。同じように人的ネットワークでつながっている人が書いた書籍のタイトルをアマゾンで見せて、書店で中身を見てみたらと情報を渡す。

あとで聞いたら、ワークショップは行ったらしい。それで、ああいったスキルを身に付けたいが多分自分の性格的に無理かもしれないけれど理屈も効果も勉強になったと話してくれた。ああいったことができるようになりたいとも言っていた。

多分、根本的にドジっ子属性なところは本人がいくら望んでも変えられないだろう。でも、それでいいのだ。ときどき、思い出して、使ってみれくれれば。

そんなことを考えていて、ああ、年上の50代のエンジニアでもまだ、育てられるのだな、と。

 

 

 

エンジニアは正解に合わせるのではなく、正解を作る仕事している

ある日、ミーティングに出ていながら「(そうじゃないんだよ)」と感じたことを記憶に引きずったまま、翌朝、それを電車の中で思い出した。

その場では、話の持って行き方はケースごとに変えないとおかしくなってしまうよ、と伝えたがいったいどれだけ通じていたか。

システム開発は、顧客の実現したいことを探りながら工程で詳細化することでコードに落とし込み、それをテストを組み上げることで動くものとして実現する。

このアプローチの良いところは、作業する前にゴールを設定できることだ。これを作ればいいと確認した上で、作業を始められる。

別の切り口で見てみよう。

内製で作るのでなければ、つまり、作業を外部に委託する場合、その組織間には契約が生じる。その契約を履行させたい、履行するために、双方で役務を具体的に書面に記述する。

ここでもまた、履行したかどうかを判定する基準が定められる。そのため、お互いに成果物となっているかを検査する。ここにも作業前にゴールを設定することになる。

2つのことから、それを実現するエンジニアには契約を履行するための成果物を正として作業をすることになる。また、それができるようになるように刷り込まれる。

それの弊害が、作業をする前に正解を求める。

確かに、委託元とのやり取りではそれでもいい。その相手が組織の中であったらどうだろうか。

組織の中でも分掌があるのだから契約書は交わさないまでも分担するのだから、作業のゴールがあるだろうという意見もあるかもしれない。一担当であればそう考えていてもいい。でも、それで許容されるのは担当までの話だ。組織の成長ステージによっては、新人だろうがそういう考えはリジェクトされる。

エンジニアが正解を作らなければならないこともある。現実にはSIプロジェクトでもエンジニアが正解を作りながら、作った正解を積み上げながらプロジェクトを進めているのだが。

今はこうだ、という仮説を置き、積み重ねるのはそうしないと進まないということもあるが、間違っていたらそこまで立ちもどれるようにするためだ。

そう言ったやり方は、正解だったじゃないかと人質にとるようなものではない。エンジニアが正解に合わせて作業をしていては単なる作業工でしかない。そこには知的労働は皆無だ。エンジニアは正解を作る側を担う専門職であるのだから。

 

 

 

チームのスケールとリーダのキャパシティ問題

チームをスケールさせることの難しさはリーダかマネージャのロールをやってみないと実感出来ない。やってみたことがないと経験知を持ち合わせていないから自分の担当としての経験値で判断してしまうためだ。

そしてやってみてわかることは、世間で、あちらこちらで見かけるチームビルディング、チームの向かう方向性、チーム内の意思伝達などである。

その点を事例として学ぶには次の記事の「SmartHR使い物にならない問題」から読むと良い。

 

logmi.jp

 

チームをスケールするのはビジネスニーズに応えようとするからだ。手のつかないバックログ、多忙なエンジニアの負荷軽減など見えている事由は様々であっても、結局は、エンジニアのリソース以上に仕事が多いことが原因だ。

エンジニアサイドで期待値に応えられるベロシティが出ていればバックログがあっても問題ないかもしれないが、そうでないと外部からのプレッシャーが高まる。エンジニアも期待に応えたいからと良心に任せてしまうとそのツケはいずれ利子がついて回ってくる。

経験から言えば、リーダのロールを担う人材、例えばマネージャやVPoEのキャパシティでエンジニアの組織の構成を構築する必要がある。

なぜここでマネージャのキャパシティが関係してくるのかというと、人は一度に目を掛けられる人数がバラバラであるからである。3人のチームなら目が行き届くリーダもチームが5人になった途端、2人は視界から消えてしまう。これをリーダのキャパシティ問題と個人的に呼んでいる。

このキャパシティ問題を知った上で、組織構造を見つめ直すと見え方が変わってくる。例えば、リーダとメンバのフラットなチームを考える。

  1. リーダ(1人)ーメンバ10人
  2. リーダ(1人)ーメンバ50人

2が成り立つのは、リーダが50人に渡って目が届くことが前提になる。つまり、チームがチームとして機能するかどうかはリーダの資質に強く依存する。

それを認識しないでメンバをスケールし続けるとどこかで崩壊し始める。その崩壊も自然に始まる。なぜなら、リーダ自身がキャパシティの閾値を知らずにスケールさせているからだ。

この崩壊は、リーダの世代交代で突然起きることもある。想像がつくだろう。キャパシティはリーダの資質だからだ。

このように組織構造を眺めてみると、構造化した組織は一概に悪いとは決め付けられないことがわかる。

であればリーダの資質で組織は少しだけ階層を持たせた方が良い。単純なケースではプロダクトやシステム単位の機能で分割する。

  1. リーダ(1人)ーメンバ10人
  2. リーダ(1人)ーAチーム(サブリーダ+メンバ24人)
          +Bチーム(サブリーダ+メンバ24人)

 ここで次世代のリーダを育てることを考えるのは正しい。ただ、チーム分割をするとチーム内の文化が生まれてしまうので、全体での方向性やシャッフルをしなければ技術が固定化されてしまう。

エンジニアには常に新しいテーマの選択肢を与えることもリーダの仕事である。

 

 

キャズム Ver.2 増補改訂版 新商品をブレイクさせる「超」マーケティング理論

キャズム Ver.2 増補改訂版 新商品をブレイクさせる「超」マーケティング理論

 
ライト、ついてますか―問題発見の人間学

ライト、ついてますか―問題発見の人間学

 
ピープルウエア 第3版

ピープルウエア 第3版

 

 

 

 

情熱があるからやるのではなく、やっているのを他人が見ると情熱に見える

それだけだ。やっている方は、もう作業になっているのだから。

これを実現したいと思うことがあって、それをやり始めてみる。やり始めると、思ってもみなかったことが次から次と湧いて出てくる。

そんな湧いてくることなんてやりたいくないけれど、片付けないと今わかっているのはその面倒なことを片付けないとやりたいことにたどり着けない。だから、黙々と片付けている。

それを他人が外から眺めると一心不乱にやっているように見える状況を知っている言葉に当てはめたら、それが情熱だった。

それだけだ。

実は、ポイントはこの裏返しにある。

外から見ている他人は、やってみたいことを持ち合わせていない。

もし、やりたいことを持っていたら他人にかまっている時間なんか無い。そんな時間は全部やりたいことにつぎ込んでしまう。

周りにいる他人は、やりたいことがある人がそれを実現するために地道に始末している作業を見て、それを情熱と勘違いしているだけだ。

そう、情熱はやりたいことを持ち合わせていない他人の勘違いなのだ。

以前書いたエントリのやる気スイッチなんて存在しない、も同じことだ。終わらさなければならないことをやり始めたかどうかだけだ。

いや、それでも、始末しなければならないことを片付けるための情熱や終わらせるためのやる気スイッチが欲しいというなら、一つ、考え方を変えればいい。

それは、作業は言われて、指示されてやってはいけない。作業は、その作業をする本人が作業のゴールを設定し、作業の段取りを考え、自分で始末する。

たったこれだけで情熱ややる気スイッチと呼ぶ何かを手に入れられる。

自分でその作業を始末しないとやりたいことが手に入れられないとわかっているからである。

淡々とやりなさい、とは、つまりこうしなさい、と言っているのだ。

 

 

行動経済学の逆襲

行動経済学の逆襲

 

 

 

エンジニアの思い込みバイアス

なんでもそうなんだが、仕事になっているかなっていないかは、自分でそれをたとえ机上だったとしても試したかどうかで見極められるのではないか。

以前こんなことがあった。管理部に依頼事項があったのだが、依頼したことに対して明後日の回答が戻ってきた。たまたま管理部門がいる場所の側まで行く用事があったので少し早めに行って、その部門に足を運び、なぜそんなことになっているかを尋ねてみた。

人は知っていることでしか結論を導くことができなことは何度かエントリとして書いてきた。まさにそれであった。管理部門の担当者は、自分が知っていることだけでこちらの依頼を判断し、返してきたのだった。

このことからの教訓は、(特に普段コミュニケーションを取っていない相手に対しては)背景も一緒に伝えるか、先に背景を説明した後に依頼をした方が良いということだ。

こうした経験による思い込みへのバイアスは、エンジニアの仕事でも起きる。殊更、ユーザの操作など人が絡むところで発生しやすい。

エンジニアだからシステムとしての仕組みの作り方を知っているし、これまでにシステム化した業務の経験から「こう作るものだ」と思い、仕様を決めてしまうのだ。

でも現実には、エンドユーザごとの組織ごとに文化が違う。文化が違うということは意思決定の判断が違うということだ。

そこに過去の経験と技術サイドの都合を持ち込んだらどうなるかは想像がつくだろう。

エンジニアにコミュニケーションスキルが必要だというのは、こうしたことを対立するのでも媚びるためでもない。作って欲しいものを作るためである。もちろん、自分で自分が設計したものをドッグフーディングするのは当然としても、それがそれで良いのかどうかは、システムを使うエンドユーザに使ってもらうしかない。

舞台裏で一生懸命作り込むよりも先に、動くものを触ってもらった方がいいのはそういうことだ。

 

 

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン