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

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

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

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

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

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

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

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

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

 

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

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

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

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