エンジニアを育てる環境と立場の違いについて
エンジニアを育てる環境と、コミュニティのありかたについて - 滞舎路日記
のタイトルから育成とコミュニティの2つのテーマをどう繋げるのか興味があって読みんでみた。
前半は、エンジニアを育てるのはエンジニア自身なのはそうなんだけど、それだけで良いのかと疑問を呈しているのだろう。
それについては、自分を自分なりに育ててきた、いや、やってみたいロールに就くためにやったことが、回りまわって自分を育てることになっていた、と言う経験を振り返ると、ロールに就くためにやったことの中で幾つかの要所を自分で作れるかどうかなんだと思っている。
の中で引用されているツイート
昨日の飲みで、某CTOが「エンジニアを育てるって言うけど、紀平さん誰かに育てられました?自分で育ったでしょ?だからエンジニアに対しては、頑張れ、としか言いようがないと思うんですよね」って話をしていて、まあ確かにそうだと思った。自分はしかし親に環境を用意してもらったな。本とかPCとか。
— Takuo Kihira (@tkihira) September 4, 2018
その1つが環境を用意すると言うことだ。自分で自分を成長させることができるエンジニアは成長するための機会と環境を自分で作ることができるのだ。
機会と環境を作れるためには、自分でロードマップが間違っているかもしれないけれど、ロードマップを描く時点ではそれで行こうと決められる程度には自分のものになっている。
こうしたことを暗黙にできるから自分を育てられるのだ。
ただ、これが組織の話なるとそれで良いとは言ってられなくなる。エンジニアの育成はビジネスに組み込まれるためだ。エンジニアの育成がビジネスに組み込まれると言う意味は、育ち、必要とするスキルを持ったエンジニア、多くはビジネスをリードできるエンジニアをビジネスニーズに応じた規模で供給することを経営者は期待していると言う意味合いである。
エンジニアの成長について「自分は自力で育った」「今まで見てきた人は誰かに育てられたというより自力で育ってきてた」は観察としてたぶん真なんだけど、「だからこれからもそれでいい」は明確に偽だと思うんだよなー。それって各種の職人業が次々廃れてるのと同じことを再現するだけのような気がする
— Dai MIKURUBE (@dmikurube) September 5, 2018
それを踏まえてツイートを読むと、エンジニアの育成はエンジニアが自分で育つことに期待するだけではダメなのだ、と言う考えにいたるのではないか。
コミュニティをエンジニアの育成とどう繋げるのか。もう少し、元のブログを読み進め、引用されているリンクを読むと、そうなのね、と。
ふむ。
自分としては、エンジニアの成長をビジネスサイドが求めるビューで見ているのだけれど、その視点に立つと期待はビジネスサイドが持っているから、エンジニアの育成に必要なリソースはビジネスサイドが担うものだと思っている。
だから、エンジニアの育成機会であるアサイメントも育成の環境もビジネスサイドのミッションだ、と思っている。
ニューヨークのコミュニティを読んだ今、自分のエンジニアの育成を振り返ると、hacker schoolではないが、自分がなりたいロールに必要な外部団体の催しに参加したし、身に付けたい、知りたいと思った手法はそれを扱っているコミュニティに参加した。
何が言いたいかというと、自分のエンジニアとしての育成は、そうした外部コミュニティも育成の一助としたが、立場が変わってマネージャとしての役割になった途端、期待する側の都合でエンジニアの育成を考えるようになっており、どの帽子を被っているか(=立場)で育て方を変えているということに気づいた。
これは勉強になった。
Fire HD 8 タブレット (8インチHDディスプレイ) (Newモデル) 16GB
- 出版社/メーカー: Amazon
- 発売日: 2018/10/04
- メディア: エレクトロニクス
- この商品を含むブログを見る
チームの文化を育てる
豪雨や地震があるたびに、過去に経験をまとめた『断水しても困らないようにしておくためのまとめ』にアクセスがある。
被災された皆さんの参考になれば良いのですが、何分にも断水の予告がある前提のまとめなので、被災されてからだとお風呂の水が残っているかどうかがある意味(トイレを流すの意味で)生命線になる。
こういった備えは、どんっと一回でやるより、ちまちまと小さく、続ける活動とした方がいい。それは、チームの文化を変えていくことと同じだ。
今のチームは技術をバリバリと使いまくるエンジニア業というよりは、コンサルティングチームに近い。もちろん、これまで麺が経験してきたエンジニアとしての知識や経験を活かしての、と前提があるのだが。
そうしたチームでもチームを作ったばかりの頃は、チームと呼べる状態にはないから全員が手探りで、空気を読もうとするばかりに一歩も二歩も引いた位置から関わろうとする。
そうしたチーム(まだ、チームと呼ぶにはおこがましい)には、新しい文化を作らせなければならない。こういったとき、つい、インストールをすると言う人がいるが、そんなものはチームの文化に根付くわけがない。どこから持ってきたか分かりもしない他人の価値観なんて気持ち悪いことこの上ないではないか。
たとえ、よそから持ってくるにしても、それは持ってきた物の中から、チームに良さそうなものだけが使われるのだ。よそから持ってきたものを考えも、判断もせずに適用するなんて盲目的すぎる。
そうしてチームとして良さそうなものを使ってみて、本当に良いかはチーム全員で判断しなければならない。なぜなら、それを使い続けるのはチームのメンバだからだ。
よくありがちなのは、使う、使わないの判断をチーム『全員』で判断をせず、今使っているからと言う惰性で使い続けることである。そんなことをするならすぐに使うことをやめた方がいい。少なくとも使い続けるメリットはないのだ。
こうして積み重ねられていく実態のないものがチームの価値観であり、チームの文化として育っていく。
文化は継続して育てられていくもの、なのである。
初めてプロジェクトマネジメントに関心を持ったときにすること
ウォーターフォールやアジャイル開発などのシステム開発手法に限らず、プロジェクトマネジメントはシステム開発とは切っても切れない縁がある。
プロジェクトの予算を出す側、つまり、プロジェクトオーナーの立場で見ると、切れない縁というよりは、プロジェクトをプロジェクトチームに任せておくと6割以上のプロジェクトで品質、コスト、納期のいずれか若しくは複数で計画通りにならない事態になるので、プロジェクトの状況を知りたくてプロジェクトチームにマネジメントの考え方を取り入れたのがプロジェクトマネジメント、と言っても差し支えないだろう。
エンジニアが仕事を覚え、チームの中で複数人のメンバのリードを担えるようになると大なり小なりのプロジェクトを任されるようになる。エンジニアにこうした機会が訪れると、プロジェクトを上手にやってみたいと思う(エンジニアが出てくるかもしれない)。
最初にシステム開発手法を覚えよう
プロジェクトマネジメントに関心を持つとPMBOKの本を読めばいいのかと思うかもしれないが、まずは、システム開発手法を覚えよう。
システム開発手法を覚えるといっても、何も難しいことはしなくていい。今やっているプロジェクトで知っていることを書きだすだけでいい。
リーダーとして担当している作業ではどのようなことをしているか、それを図に描いてみよう。ウォーターフォールを採用しているなら、どこの工程から始めて、どの工程までやっているかを描けば良い。アジャイル開発ならどの開発手法でやっているか、それの進め方を図にしてみよう。
簡単でしょう。
計測しているのは何かを描き加えてみよう
描いたシステム開発手法の図に、システム開発の作業の中で計測している情報があればそれを描き加えてみよう。色付きのフリクションがあれば色を変えてみよう。
描き加えた計測している情報が誰に渡しているか情報の行き先を描いておこう。
情報の行き先は、チームないかもしれないし、スクラムマスタかもしれないし、プロジェクトマネージャかもしれない。誰に渡しているかを描ければオーケー。
情報の種類を分類してみよう
誰かに渡しているシステム開発の情報は、次の3つのどれかに当てはまるだろう。
- 進捗(スケジュールの計画と実績)
- コスト(予算と使った費用の実績)
- 品質(開発しているソフトウェアの出来)
もし、上の3つに当てはまらなければ、それはシステム開発のテーマ(機能)かもしれない。
- スコープ(始めたときに作るつもりだった機能と実際に作っている機能)
プロジェクトマネジメントでやりたいこと
プロジェクトマネジメントでやりたいことは、進捗、コスト、品質、スコープが計画どどれだけズレているかを計測して、ズレていれば計画を見直すか、計画に近ずけるためにアクションを立てるか、そうした活動の情報を欲しい人に欲しがっているタイミングで渡す(レポーティング)ことだ。
これがプロジェクトマネジメントでやりたいこと。
やりたいことがわかったから
さて、やっとプロジェクトマネジメントでやりたいことを確かめられた。あとは数多ある市販されているプロジェクトマネジメントの本の中から、気に入った本を読んで、使えそうなところを実践してみよう。
なんのためにプロジェクトマネジメントをしたいかがわかれば何かしら関心を持ってプロジェクトマネジメントを覚え、実践することができるようになるはずだから。
アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)
- 作者: Scott Berkun,村上雅章
- 出版社/メーカー: オライリー・ジャパン
- 発売日: 2006/09/07
- メディア: 単行本(ソフトカバー)
- 購入: 20人 クリック: 361回
- この商品を含むブログ (186件) を見る
プログラミングが好きな50代Web系エンジニアだからこそ
50代のエンジニアとしての生存戦略の話になると、丁度、スィートスポットなので関心を持たざるを得ない。何についてかと言えば、これである。
まあ、Qiitaだし、Web系エンジニアと限定しているので記事のタイトルを見たときにはスルーしていたが、気にはなっていたので読んでみたら、ちょっとねぇという内容で。
結論の前に、前提事項があるのだろうと、まずは感じざるを得ない。特に、30代中盤の金融資産の下については、書かれている方の想定しているライフスタイルが少なくとも自分とは違う。
自分のライフスタイルから見れば、この方は独身が前提であることが手にとってわかる。晩婚と言われてから随分経つ。仮に30歳で結婚したとすると、50歳はまだ大学生である。40代は中高生と教育費用が掛かる年齢だ。これを書かれている方は、塾の費用について情報をお持ちではないのだろう。
自分のことを前提にするなら、結論の前に自らが暗黙で置いている前提事項を書かなければ、読者は混乱するだけだ。
続けて、50代は一線で働けないとでも思っているのではないか。これも何か前提があるのだと思うのだが、これは判別する情報が伺えない。
キャリアの考え方、エンジニアとしての技術を使いたいという欲求とエンジニア一人ひとりで違う考え方があるだろう。
その一つの考え方として、30代から40代で一度はマネージャを経験しておくことが必要だと考えている。その考えは、50代に入ったら、また現場で働くことを勧めている。なぜなら、ビジネスは現場にあるからである。マネージャを経験した後、現場に戻すのは、マネージャの新陳代謝を促すためであり、誰もがマネージャの素質を持っているとは限らない(=ミスマッチを早い段階で気づかせる)ため、組織として代謝させることで適職に戻すという狙いがある。
さて、話を戻して、50代になったら処遇が下がることを受け入れる許容することは冗談ではない。その理由は上述したのでここでは述べない。逆に、許容することはないが、収入に見合うビジネスをキャリーさせれば良いのであって、それを一律下がることを許容するように引っ張ることのメリットがさっぱり不明瞭である。
ところで、『良質な脇役』というなんとも都合の良い役割があるが、これを目指すならそこそこ中堅のSIerでなければ実現できないのではないか。
自分が経営者であれば、それこそ、縁の下の役割をフリーランスのエンジニアには任せない。自社のシニアエンジニアにその任をやってもらう。
というか、フリーランスのエンジニアを雇うのであれば、先端的な技術や手法を社員が学ぶ時間より買ってきて、それをスキトラするために使うだろう。常用的にフリーランスを使うのであれば、そのフリーランスを雇用してしまう方が突如やめられてしまうリスクでヒヤヒヤするよりなんぼもマシである。
言い換えれば、フリーランスで採用の声が掛からないエンジニアは代替が利くエンジニアである。
あと、Web系エンジニアで50代のロールモデルがないというのは、Web系の技術が(日本で)採用され、広くエンジニアが増えたのは2000年後半でこれから増えてくるのではないか、つまり、今は単に有名人がいないだけか、世代的に少ないだけではないかと思うのだが、どうなんだろう。
どこでも誰とでも働ける――12の会社で学んだ“これから"の仕事と転職のルール
- 作者: 尾原和啓
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2018/04/19
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
プロジェクトチーム活動のReady!!と備えの違い
プロジェクトチームがマネジメントしなければならないテーマにリスクがある。そのリスクの対応は、移転、回避、受容、低減のいずれかを対応方法として予め決めておく。
リスクの受容なんて、識別したリスクをどう評価したかはさておき、リスクが起きてもいいよ、というようなものだ。ただ、一般的にはコンロールしなければならないリスクは何かしら対策を考え、準備しておく。
ところで、日本語には備えるという言葉がある。ここ数年多い災害に対する防災は災害に備えるという意味において代表的と言って良いだろう。
そなえ〔そなへ〕【備え/▽具え】の意味
出典:デジタル大辞泉(小学館)1 ある事態が起こった場合などに対する準備・用意。「万全の―で試験にのぞむ」
2 防備の態勢・陣立て。「国境の―を固める」
さて、ここで言葉のニュアンスの違いからムムムと感じたら、それは期待する反応である。災害に対する備えは、程度もあるが過去に起きた災害程度は回避できる備えを策とする。そうした基準を設けなければ際限がないためだ。
同じようにプロジェクトチームのリスクについても、リスクが起きたときのインパクトと頻度を掛け合わせてエクスボージャを導き出し、その導出した結果でリスク対応方法を選択する。
さて、ムムムと感じて欲しいのは、防災は過去に起きた災害の対策を取ることが既定路線であるということである。言い換えれば、過去に災害起きていれば必ず対策は行われるのだ。
でも、プロジェクトチームのリスク対策は必ず、ではない。
ところで、なぜリスクや防災の備えの話をしているかといえば、何も防災の日が近かったからというわけではない。
プロジェクトチームでのリスクを識別していると、つい、やっておいた方が良いという思考に囚われ過ぎたり、周りからあれこれと備えるようにと言われてきりきり舞いしてしまいかねない。
起きるかどうかもわからないことにリソースを突っ込むことはできない。ただ、何が起きようとしているのか、それの準備が必要かをプロジェクトチームは、自分たちのこととしてリスクを識別し、対処するかどうかをテーラリングしなければならない。
そうした始めるための準備を整えた上で、プロジェクトチームの活動を始めなければならない。
Are you ready?
TVアニメ「アイドルマスター」オープニング・テーマ「READY!!」《通常盤》
- アーティスト: 765PRO ALLSTARS
- 出版社/メーカー: 日本コロムビア
- 発売日: 2011/08/10
- メディア: CD
- 購入: 2人 クリック: 65回
- この商品を含むブログ (14件) を見る
35歳定年説から、28歳定年説の時代へ
知り合いのエンジニアが『これまでのエンジニア経験を下敷きに、今やっている開発手法と勉強してきた各種手法がようやく結びついて腹落ちするようになった』とこぼした。
知り合いは、さらに言葉を続け、こんなことを言ったのだった。『それもこれも30代に入ってから覚えたものだ。35歳定年説とは一体なんだろうか』と。
即座に思いついたことは、35歳まで、いや、この人は30歳を超えたときから、それまでエンジニアとして経験してきたことの蓄積と30代に乗ってから勉強して得た形式知がようやくシンクロし始めたのだろう、ということである。
それを言葉として発する前に、自分の身上で考え直す。年齢やタイミングは違えど、先に経験する相応の期間があり、後からPMBOKなどの形式知を導入し、実務の経験と外部から導入した形式知の歯車を噛み合せることである意味、初めて自分のものになったような気がしてならない。
でも今はどうだろう。
自分の頃に比べ、経験する速度は仕事の案件の高速化と繰り返しにより得られる経験知の濃度が上がったのではないだろうか。さらに、各種手法や方法論が自分の頃と比べて、情報を入手しやすく、また、インターネットを介して得やすくなっているのではないだろうか。
それを仮説とすると、35歳定年説のマジックナンバーである35は30か28くらいまで差がてきているのではないか。
つまり、28歳か30歳になれば、経験知と形式知との歯車が揃う時代なのかもしれない。それは、35歳定年説から28歳定年説に年齢が下がったということだ。そう言った環境に囲まれている時代なのだとしたら、自分のような年次のエンジニアは、より不安定な環境に自ら身を置き、ときどきは経験知と形式知の歯車を取り替え、さらに先を歩かなければならないのかもしれない。
エンジニアとおみくじと知命
50歳は『知命を知る』お年頃である。孔子が晩年にそう振り返ったらしい。さて、自分の天から与えられた使命はなんであろうか。自分の専門はプロジェクトマネジメントであると据えているのは自称でしかない。天から告知があったわけではない。エンジニアの育成もマネジメント業に至っては、組織のアサイメントで偶々そのお鉢が回ってきただけである。
自分の知命はまだわからない。
先日、某神社でおみくじを引いた。ここ1年、その神社に立ち寄る機会が増え、その度におみくじを引くようになった。そして毎回、大吉だった。ところが、である。今回は末吉だった。おみくじが良くできていると思うのは、いくつかの思いつきのような思いに対する示唆が含まれているということだ。
新しい組織、例えば、スタートアップ、スタートアップから組織の成熟度をあげたいニーズを持っている企業からオファーがあれば移ることを考えたい、と思っている。ただ、求人サイトの有料会員になってまで、というわけでもない。こういった転職関係は口コミの方が良いと思っている。
さて、その末吉である。『何事も激しい変化は、将来のためにならず』とある。自分にとっての激しさと言えば組織を移るということになるだろう。確かに、今の担当する顧客へのインパクトは大きい。自分を買いかぶっているわけではないが、事業企画と実行のとっかかりの所謂、0から1を作るところをやっている。ここがなくなると、1から展開するところが行き詰まってしまう。
自分の事業ではないので別に誰かが代替すればいいのであるし、そこに責任は持ち合わせていない。
であれば、おみくじなんぞ気にせずに色よいオファーがあれば移るのも一手である。そこにふと、自分の知命はなんであるかが気になり始めた。確かに、今は気分的にイケイケでないという少し弱含みがないわけではないが、やけっぱちや考慮不足、勉強不足でで組織を渡り歩くことのリスクを引き受けるほど受容できるとも思えない。
ということは、今は(この瞬間は)インプット、チャージする時間なんだろう。確かに、インプットが足らないのである。そうしないと薄っぺらいままで歳を重ねてしまう。インプットしながらもう少し世の中を眺めてみよう。