面倒くさいことを楽するために僕らは技術を身につける

仕事は面倒くさい。

面倒くさいから顧客が自分の仕事を切り出して高い対価を支払ってまで委託する構図が成り立っている。それが組織の中だとしても同じである。組織の中で、委託元のビジネスオーナから分掌の組織に依頼され、実現される。面倒くさいことをやるのが仕事である。

だから、委託されたママやるのは面白くもなんともない。作業を見積もったり、成果物から作業を分解したり、進め方を合意したり段取りを組んだり、チームを編成したり、チームビルティングしたり、毎日朝会したり、進捗の障害を聞いたり、ステークホルダとネゴることをいつも同じやり方でやっていては。

面倒くさいをいかに軽減するか。

それは見積もったときのやり方とはチームの中とは違うかもしれない。それで余計にコストが掛かったとしても（現実にはフィジビリティスタディを自分やSEリーダや選んだメンバだけでドッグフーディングするかチームのパフォーマンスの想定値を取るためにスプリントゼロの考え方のような試行をする）、オーバーランしないようにモニタリングする。

そこに、仕掛ける側の新しいことへの興味と関心の創出を自らに仕掛ける。

チームのメンバにとっては迷惑かもしれない。同じやり方なら経験知として持っているので記憶の中から持ち出せばいいからだ。新しいことを覚え、身につけ、それを確実にできるルールを覚えさせられ、間違っていたらやり直させられ、従来のやり方以上のパフォーマンスを出すことへの期待を実現することを求められる。

面倒くさいことこの上ない。

おなしな話である。

ウォーターフォールでやっていたら何が何でもウォーターフォールでやっておけばいいものをスピードを求められつつ、今までの品質もキープしながら、場合によっては今まで以上のクオリティでリリースすることを求められる開発手法を選んだりする。それをするために仕事の段取りも変えなければならないし、新しいチーム運営に慣れないといけないし、概念的なパターンを覚えなければならない。新しい技術を覚え、使えるように適用しなければならなくなる。さらにマインドを変えよとまで言われる。

今までのやり方でいいじゃないか。そう言いたくなる。

でも、それでは今のプロジェクトにはふさわしくない。いや、プロジェクトの特性に適合せず、面倒くささが何倍も輪をかけてエンジニアを苦しめるのだ。だから、どのやり方がより楽をできるかで道具を選ばなければならない。そして道具の使い方を覚えなければならないのだ。

エンジニアの仕事は面倒くさいと感じるのは正常なことだ。心配しなくていい。

ただ、そのまま面倒くさいまま仕事をしては楽しくない。楽しまなければ。

だった、楽しめる何かおもちゃを試してみよう。

九重味淋 本みりん 九重櫻 瓶 1800ml [愛知県]

福来純 「伝統製法」 熟成本みりん 1.8L

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

人と組織の「アイデア実行力」を高める――OST(オープン・スペース・テクノロジー)実践ガイド

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

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

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

その点を事例として学ぶには次の記事の「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 増補改訂版 新商品をブレイクさせる「超」マーケティング理論

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

ピープルウエア 第3版

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

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

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

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

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

それだけだ。

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

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

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

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

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

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

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

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

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

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

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

行動経済学の逆襲