『謎自信』を発動せよ!

ある案件での資料作りで、顧客からものすごい圧が掛かることがあった。あの圧を真面目に受け取っていたらちょっとしんどかったかもしれない。

どちらかと言えば、顧客からの圧よりは、資料の締め切りの方が自分としてはとてもプレッシャーを感じていたのだ。

顧客が圧を掛けてくる言い分(想像)

資料のコンテンツ自体は、あなた(自分のこと)で担当している領域の今後についてである。 であれば、どうしていくのかはあなた自身が一番わかっているだろう。

よって、あなたが資料を書くのが一番の適任者だ。

それを聞くひとはこんな人達だ。それを念頭に資料をまとめて欲しい。

こちらの言い訳(言わないけど)

 先に書いておくが、顧客との関係は悪くはない。冗談を言える間柄だし、ロジックを持って話せば理解してくれる。

それにコンサルティングのようなものだし、領域の範囲内なので契約上問題ない。

ただ、顧客が変わっていることには変わりはない。

ただ、それを言うと『お前が言うな』と言われそうだが。

 

で、である。

資料の範囲が広く、それに関わる関係者、ステークホルダーが多い。多過ぎる。それに加え、今後のことはザクっとは決まっているが、まだふわふわしている個別テーマばかりだ。

それをどう計画作っていくか…である。その状態でオーダーされた資料のレベルが高過ぎた。

資料のレベルが高いと言うのは、より概念に違い(詳細な実行計画のようなものではない)と言う意味合いで、である。

『謎自信』発動。

 生命に危機を及ぼすような資料ではない(今後の個別テーマである意味、生命に少しだけ危険が及ぶ可能性は否定できない)のである。

多くの場合、生命に関わることはほんの一握りしかない。これを意識できるようになると仕事はとても楽になる。

それに自分ひとりで仕事をしようなんて思わなくなる。結果的に、正しい人を巻き込み、助けてもらうような仕事の仕方をするようになる。

個人の、自分自身の顧客からの評価はさておき(今更感はある)、命に別状がないなら、求められる品質を備えたアウトプットをすればいいだけである。

それに、過去の案件の方がマジでやばかった。そこまで閾値に迫っていない。

それにその過去案件を思って計画した通りにやり遂げたのである。

これが『謎自信』である。

謎自信が発動すると、顧客から出来はどうかと聞かれても『大丈夫ですよ』『まー、心配しないでください』と平然と言える。

締め切りは気になるが、顧客を巻き込み切れているので最後は『じゃあどうしたいのか』と踏み込めばいい。

若いエンジニアと仕事の進め方やタスクのアサインを受けたいかどうかを話すとき、やはり『謎自信』を発動してくることがあるが、それはその自信がどこからくるかを確かめると裏がないので『若さ』が自信の源泉であることがわかる。

それはそれでいい。

一方、こちらは経験に基づく『謎自信』である。

格が違うのだよ、謎自信の。

 

 

 

小さなことに左右されない 「本当の自信」を手に入れる9つのステップ

小さなことに左右されない 「本当の自信」を手に入れる9つのステップ

 

 

チームの役割は冗長化しなければならない

プロジェクトチームを作るときに欠かせないことの1つに、分掌、役割分担を決めることである。

プロジェクトチームは、機能組織である。ある目的を達成するためだけに作られた組織であるから、その目的を達成するための機能を有していなければならない。

その機能をチームの役割に割り当てる。

ここで勘違いしてはいけないのは、役割に機能を割り当てるのであって、人に割り当ててはいけない。人に割り当てた途端、属人化が急速に始まるためである。

役割に機能を割り当てると、役割のポジションに人を置くとき、役割として必要な機能をこれから割り当てようとする人が持っているかどうかという観点でアサイメントの正しさを評価できる。これを人をポジションに置こうと考えると、その人の評価になってしまう。

これを取り違えてはいけない。

ところで、機能を役割に割り当てるとその機能の役割に支障が起きた場合、SPOFになってしまう。そうならないために、階層化の形態を取り、上位者によって冗長化を図る。

この例でわかることは、上位者は配下の機能も理解し代替できなければならないということである。

役割の冗長化は、小さなプロジェクトチーム、ワークの高速化を考えるチームには必要な考え方である。小さなチームは人ひとりがチームに占める割合が大きなチームよりとても大きくなる。

つまり、小さなチームになればなるほど、SPOFが高まる。トラックナンバーが1に近く、というのと同じである。

だから、技量の程度の違いはあるにせよ、役割の冗長化に取り組まなければならない。その取り組みにより、冗長化が進み、仕事が止まらないチームが出来上がる。

止まらないということは、仕事の平準化が何かしら利くということでもある。そして止まらないため、継続してアウトプットされる。

こうした考え方は、何も小さなチームの専売特許ではない。大きなチームのブロックでこの考え方を取り入れれば良い。大きなチームの中にあるブロックのチーム全てが冗長化を進めるとき、大きなチームは大きいままで止まらないでアウトプットが続けられるようになる。

チームの役割は冗長化しなければならない。

 

 

 

Spof the Andes

Spof the Andes

 

 

 

エンジニアが悩んでいる時にブレークスルーする方法

カンファレンスで自分の講演やワークショップをするときは、前後の時間はこれまで講演者の控え室にいることが多い。スライドを見直して、話す内容を心に留めたりして時間を潰しているわけだ。

終わったら終わったで、一仕事終えてぐったりとして何もする気になれないのでやはり控え室で甘いものでも口にしている。

ところが、あるカンファレンスでワークショップが終わった後、知り合いの方がワークショップをするのを思い出して、それに参加しようと思った。

珍しい。

ワークショップの内容は、今市場に出ているいくつものプロダクト集め、それぞれのプロダクトで想定している顧客セグメントとしている設定が、それが本当にそのセグメントで良いかを評価して欲しいというものだった。また、イチ押しのプロダクトを選んで欲しい、とオーダーがあった。

気楽にやって欲しい。そういうことで、プロダクトに触れてみて、依頼されている内容を評価票に記入していく。

終わった翌日、ふと、これは現状に対する疑問(上記の場合は想定している顧客セグメントが実は違うのではないか)があって、それを自分だけで判断せず、想定しているセグメントの顧客に評価させてしまえばいいと思い至ったのではないか、と気づいたのだった。

エンジニアが仕事をしているとやっていることが正しいかどうか、進む方向がわからなくなるときが多々ある。それは、エンジニアの仕事が決められたプロシージャで決められた通りに処理すれば片付く仕事ではないからだ。

そうしたとき、上記のように早い段階で、実験をしてみるのが良いのだ。実験といっても選んでもらうとか、行動として現れる方法を取ればいい。

実験で得られた結果は、1つのサンプルでしかないから、それが神様というわけではない。それは注意した方が良い。

ただ、実験をしなかったら、気づくことができないことに気づけるだろう。それを実験しないでて早くやりたければ、いくつも視点の違う帽子を自分で着替えられるようにスキルとなりきりに必要なペルソナを持つことだ。

それはそれでそこにたどり着くまでが大変なので、聞いてしまった方が手っ取り早いのである。

この手っ取り早く聞いてしまうも、実際は、1人でくよくよ悩む時間は何も得られないので、それを止める方法が聴く、ということだけの話なのである。

ブレークスルーする方法なんて実は大したことではない。

 

 

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

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

 

 

10年続けられる技術テーマを持つということ

 カンファレンスや研究会の後に懇親会が開かれると基調講演された登壇者やゲストが招かれる。運営は時間枠の都合で質疑を切らざるを得ないので、その場で出来なかった質問や個人的なリレーションはそちらでと誘導し、懇親会も賑やかさをキャリーするように促す。

そういった登壇者の多くは、講演で取り上げたコンテンツや経験談の背景にある経歴は10年単位である。

そう、10年もの間、どういった巡り合わせで興味を持ったのかは講演者それぞれだろうが、10年もの間続け、その界隈で自分の考えを発信したり、わからないことを先人に尋ねているとそうした先人に目をつけられ発信を求められ、結果的にその分野で一定の認知をされることになる。

そういった方に懇親会で10年続けることについて伺うと、ほとんどの方が視線を上に伸ばしつつも、謙遜しながら、感慨深く様々な経験を語ってくれる。

先日もネットでは名前だけを認識していた(いや、以前にどこかでパネルディスカッション的なものをみたことがあるかもしれない…)方が基調講演で話される機会があった。

カンファレンス後の懇親会で名刺交換後、10年続けることについて話を聞くと『10年続けられるテーマに出会えて幸せだ』と話されていた。

講演を思い出すと、スライドには多くの情報があるが、10年続けてきた過程の中で、ただ、一方的に情報を得るばかりではなく、集めた情報を整理し、整理した情報から特性を見出し、仮説を立て、検証していく様が見えてくる。

その分野で10年続けられているエンジニアの方々は、10年もの間、研究をし続けているといってもいいのかもしれない。その研究の節々で声が掛かり、成果発表されることでそれが専門でない自分のような一兵卒のエンジニアの視界に入り込み、認知されるのだ。

10年続けられるテーマを見つけられること、それ自体が幸せだといっていたが、それを見つけられるかどうか、それもまたエンジニア自身が何に関心を持つかエンジニア自身に委ねられているのである。

あなたはエンジニアとして続けられる研究テーマをお持ちだろうか。

 

 

マンガと図解でスッキリわかる プログラミングのしくみ

マンガと図解でスッキリわかる プログラミングのしくみ

 

 

 

エンジニアの勉強は『誰』のためかで考えればいい

エンジニアが勉強する、しないでまたはホッテントリになっているエントリがある。

まあ、またあの会社のエントリだ。

 

axia.co.jp

そして、今回は一切勉強させないと言うエントリが早速出てきた。

 

cloverstudioceo.hatenablog.com

 

個人的な結論は、好きにすれば、であるが、この話題の中心である『勉強』そのものの立場で見たとき、一つの解があるのではないかと思い当たった。

誰のための勉強か

 勉強する、しない。これまでエンジニアの勉強のテーマでは自分の経験談を書いてきた。PMBOKを勉強した経緯も書いてきた。エンジニアの生存戦略としての勉強も書いてきた。

その『勉強』は誰のための勉強かと問えば、答えは簡単である。自分自身のためである。エンジニアとして自分が業務時間外であっても、自分が興味を持ったテーマについて勉強した方がいいと判断したから勉強するのである。

エンジニア自身がやりたい勉強

その『勉強』が誰のためかと問いかけしたとき、エンジニアが自分のため、自分自身の興味、関心を満たすため、エンジニアがその勉強で得られるリターンを自分の武器として使うためと思えば、エンジニアは勉強するのである。

逆に言えば、そうした自分の欲求がないところでは勉強しないのだ。自分の欲求がないところでは勉強しないのは全てのエンジニアが同意してくれると思うのだがいかがだろうか。

上司がやらせたい勉強

間接的にではあるが、4年目のエンジニアの育成についても書いた。この取り組みは、実は、複数の先輩エンジニアにテーマを与え、業務時間内で良いから4年目のエンジニアにテーマについて技術を勉強させるように指示している。

明確な業務として4年目のエンジニアに勉強する(実際は先輩エンジニアから4年目のエンジニアを誘うような流れで)機会を自分が仕込んでいる。

上司がやらせたいエンジニアの勉強とは、業務で必要とする技術やエンジニア自身の基礎スキルの向上である。それこそ自分で勉強するように言えばいいじゃないかと思うかもしれないが、それでは上司側では期待する成果を額面通りに手に入れられないと見極めがついているからわざわざ仕込むのだ。

それでさせる『勉強』は、誰のための勉強かと聞かれれば、自分=上司のために4年目のエンジニアに勉強させたいのだ。それは業務時間を4年目のエンジニア+先輩エンジニアの時間を掛けてまでやらせないと業務上、支障が出ると判断したからだ。

 

エンジニアが勉強する、勉強しないをエンジニア以外の第三者があれこれ言っても始まらないのである。その勉強は誰のための勉強かで語った方が答えを得やすいのだ。

エンジニアが自身のためと思えば勝手に勉強するかもしれないし、業務上必要であれば、業務時間内にやらせればいいのである。

 

 

 

 

 

エンジニアを育てる環境と立場の違いについて

エンジニアを育てる環境と、コミュニティのありかたについて - 滞舎路日記

のタイトルから育成とコミュニティの2つのテーマをどう繋げるのか興味があって読みんでみた。

前半は、エンジニアを育てるのはエンジニア自身なのはそうなんだけど、それだけで良いのかと疑問を呈しているのだろう。

それについては、自分を自分なりに育ててきた、いや、やってみたいロールに就くためにやったことが、回りまわって自分を育てることになっていた、と言う経験を振り返ると、ロールに就くためにやったことの中で幾つかの要所を自分で作れるかどうかなんだと思っている。

 

の中で引用されているツイート

 

その1つが環境を用意すると言うことだ。自分で自分を成長させることができるエンジニアは成長するための機会と環境を自分で作ることができるのだ。

機会と環境を作れるためには、自分でロードマップが間違っているかもしれないけれど、ロードマップを描く時点ではそれで行こうと決められる程度には自分のものになっている。

こうしたことを暗黙にできるから自分を育てられるのだ。

ただ、これが組織の話なるとそれで良いとは言ってられなくなる。エンジニアの育成はビジネスに組み込まれるためだ。エンジニアの育成がビジネスに組み込まれると言う意味は、育ち、必要とするスキルを持ったエンジニア、多くはビジネスをリードできるエンジニアをビジネスニーズに応じた規模で供給することを経営者は期待していると言う意味合いである。

 

 

それを踏まえてツイートを読むと、エンジニアの育成はエンジニアが自分で育つことに期待するだけではダメなのだ、と言う考えにいたるのではないか。

コミュニティをエンジニアの育成とどう繋げるのか。もう少し、元のブログを読み進め、引用されているリンクを読むと、そうなのね、と。

ふむ。

 

note.mu

 

自分としては、エンジニアの成長をビジネスサイドが求めるビューで見ているのだけれど、その視点に立つと期待はビジネスサイドが持っているから、エンジニアの育成に必要なリソースはビジネスサイドが担うものだと思っている。

だから、エンジニアの育成機会であるアサイメントも育成の環境もビジネスサイドのミッションだ、と思っている。

ニューヨークのコミュニティを読んだ今、自分のエンジニアの育成を振り返ると、hacker schoolではないが、自分がなりたいロールに必要な外部団体の催しに参加したし、身に付けたい、知りたいと思った手法はそれを扱っているコミュニティに参加した。

何が言いたいかというと、自分のエンジニアとしての育成は、そうした外部コミュニティも育成の一助としたが、立場が変わってマネージャとしての役割になった途端、期待する側の都合でエンジニアの育成を考えるようになっており、どの帽子を被っているか(=立場)で育て方を変えているということに気づいた。

これは勉強になった。

 

 

 

アドラーに学ぶ部下育成の心理学

アドラーに学ぶ部下育成の心理学

 
Fire HD 8 タブレット (8インチHDディスプレイ) (Newモデル) 16GB

Fire HD 8 タブレット (8インチHDディスプレイ) (Newモデル) 16GB

 

 

 

チームの文化を育てる

豪雨や地震があるたびに、過去に経験をまとめた『断水しても困らないようにしておくためのまとめ』にアクセスがある。

被災された皆さんの参考になれば良いのですが、何分にも断水の予告がある前提のまとめなので、被災されてからだとお風呂の水が残っているかどうかがある意味(トイレを流すの意味で)生命線になる。

 

fumisan.hatenadiary.com

 

こういった備えは、どんっと一回でやるより、ちまちまと小さく、続ける活動とした方がいい。それは、チームの文化を変えていくことと同じだ。

今のチームは技術をバリバリと使いまくるエンジニア業というよりは、コンサルティングチームに近い。もちろん、これまで麺が経験してきたエンジニアとしての知識や経験を活かしての、と前提があるのだが。

そうしたチームでもチームを作ったばかりの頃は、チームと呼べる状態にはないから全員が手探りで、空気を読もうとするばかりに一歩も二歩も引いた位置から関わろうとする。

そうしたチーム(まだ、チームと呼ぶにはおこがましい)には、新しい文化を作らせなければならない。こういったとき、つい、インストールをすると言う人がいるが、そんなものはチームの文化に根付くわけがない。どこから持ってきたか分かりもしない他人の価値観なんて気持ち悪いことこの上ないではないか。

たとえ、よそから持ってくるにしても、それは持ってきた物の中から、チームに良さそうなものだけが使われるのだ。よそから持ってきたものを考えも、判断もせずに適用するなんて盲目的すぎる。

そうしてチームとして良さそうなものを使ってみて、本当に良いかはチーム全員で判断しなければならない。なぜなら、それを使い続けるのはチームのメンバだからだ。

よくありがちなのは、使う、使わないの判断をチーム『全員』で判断をせず、今使っているからと言う惰性で使い続けることである。そんなことをするならすぐに使うことをやめた方がいい。少なくとも使い続けるメリットはないのだ。

こうして積み重ねられていく実態のないものがチームの価値観であり、チームの文化として育っていく。

文化は継続して育てられていくもの、なのである。