LTから始めよう

例えば、1000人入るキャパの大ホールで講演をしたら、どんな気持ちになるかを知ってみたいとは思わないかな。1000人入る大ホールのイメージ自体がつかめない人は、住んでいる地元の市民会館とか文化会館の大ホールを思い出してみよう。大体そのサイズらしい。今住んでいる文化会館が約1000人のキャパだなーと話したら、他からも○○市の市民会館も同じだと聞いて（サンプル数は2だけれど）標準的なサイズなのかもしれない。

まず、普通にエンジニアをしていたら、まずは、そんな機会があるとは思いもしなくても普通なのかもしれないけど。ただ、話をしていた方がエンジニアは割と大勢の聴講者の前で話す機会は来るものだよ、と。どんなケースで、と尋ねてみたら、ベンダーなら事例をカンファレンスなどで話すとき、事例の顧客とエンジニアの組み合わせで講演をしたり、コンサルとエンジニアでやはり講演とデモをするケースだよと言われて、ああ、言われてみたらよくあるなぁと。

ちょっと勇気を持ってみよう

 大人になってから勇気のいることをやってみたことはあるだろうか。多分、多くのエンジニアは仕事一筋、勤勉に、バカがつくほど真面目に働いていると思うんですね。人がいい、素直、それが組織の評判や顧客からの受けになっているなら間違いなくそうです。

でも、仕事一辺倒でいたら、エンジニアが5年、10年と経験して積み重ねて来たことは埋もれて光が当たらないままになってしまうのですよ。

なんと勿体無い。

エンジニア一人ひとりがやっていることは実は職人の技術習得と同じです。それはそのエンジニア以外の他のエンジニアにとって、とても参考になる技術のプラクティスなのです。

それを、ちょっとだけ勇気を持って話して欲しいんですよ。

どこで始めればいいだろう

もし、人前で興味を持ったとしてもどこで話せばいいのだろう。そう、機会は自分で見つけないといけない。なぜなら、運営サイドや事務局サイドはあなたを知らないのだから。名前が売れているなら機会を見つける心配をしなくてもいいのだろうけれど。

試しに人前で話してみたい。

もしそう思ったら、勉強会やカンファレンスのLTを狙うのがいいと思うのですよ。

何せ、5分で打ち切りです。LTは5分で次から次へと交代していくから、多少の失敗なんて気にしなくていいですし。

 LT慣れしている諸先輩はすごいなと思うだけでいい。とにかく、1回LTをやってみよう。

1回やれば違う世界が見えて来ます。また次でリベンジしたくなるものです。

LTの先にあるもの

 LTをやったら、もっと上手に、もっと受けるLTをやりたくなるのはエンジニアという困った性壁をもつ職業特有から来るものです。

次はカンファレンスで30分枠のトーク、その次は60分。1人でも複数のチームでもいいのです。その先には大ホールで1000人の聴講者がエンジニアの話を聞きたがっています。

伝わるデザインの基本 増補改訂版 よい資料を作るためのレイアウトのルール

マイクロソフト伝説マネジャーの 世界№1プレゼン術

ロジカル・プレゼンテーション――自分の考えを効果的に伝える戦略コンサルタントの「提案の技術」

8時間20日160時間作業に当てているエンジニアはイノベーティブになれない

従来型のウォーターフォールのシステム開発手法のエンジニアから見たら、今風のアジャイル開発でのシステム開発手法を取るプロジェクトのエンジニアは平日の昼間からカンファレンスに行ったり、週末も勉強会に行っていることに対して不思議だと思っているのはないか、と思うわけです。

どちらがホームグラウンドかと聞かれれば、ウォーターフォール型のシステム開発手法を開発手法としたプロジェクトマネジメントの経験が多いので、日中は座席にずっと座っているか会議をしている方の位置から眺め直すとアジャイルなエンジニアの働き方というか、時間の使い方はとても異質に感じると言われても違和感は感じないのです（もともとそっち側だったし）が、今は違うな、と。

そして、今の方がとてもイノベーティブというかクリエーターな働き方をしていると思わなくもない、つまり、そう思っているよ、ということです。

昨日1日何をしたか 

昨日は全世界的に月曜日でした。代休でもなければ働いていたでしょう。ワタシも同じです。

ここで、思い出して欲しいのです。1時間単位のざっくりとした感じで良いので、昨日1日何をしたか思い出してください。

会議、資料書き、コーディング、テスト、レビュー、メール、チャット、sns…何をしてましたか。

会議を除けば、全部、コーティングとか資料作成とかで、全部埋まってしまっていたのではないでしょうか。

そのしていた仕事は、担当することになっていて、ただ、アウトプットを作るためだけに「作業」をしていませんでしたか。

どうでしょうか。そう言われればその通りではありませんか。

その仕事って、処理をしていただけではありませんか。

1日を全部作業で埋めない

もし、 1日の働く時間を全部作業で埋めてしまっていたら、一体、どこで新しい技術を学んだり、プラクティスを見聞きしたりするのでしょう。

エンジニアが持っているスキルとスキルレベルの成分は、経験知と形式知で構成されるものです。

スキル＋スキルレベル＝経験知＋形式知

経験知は、エンジニア自身が経験しなければ広げることも深めることもできません。それをできるようにするのは他所から持ってくる形式知だけです。

ではどうしたらそうすることができるようになるか。それはエンジニア自身が外に出て自ら手に入れる他ありません。

であるとすれば、1日の労働時間を全部作業で埋めてしまっていては手に入れようがないじゃないですか。

8時間に試す時間を潜り込ませる

アジャイルなエンジニアが昼間から外に出てカンファレンスに行っていることを僻んでも、羨んでも8時間を全部作業で埋めてしまっているエンジニアに何もリターンはありません。

しなければならないのは、作業以外のことを試す時間を創出することです。

これは誰かがしてくれることではなくて、エンジニア自身が自分で自分のためにしなければならないことです。 

そして、その試す時間は、8時間の中で作らないと意味がありません。なぜなら、実戦で使えるかどうかの検証と試行錯誤ができないからです。

一度も使わない、使われない形式知は知識の不良在庫なので。少なくともエンジニア自身が気になったのだから、自分の範疇でお試しくらいはしておかないと。

間違っても平日夜や週末をあてにしないこと。それは、8時間でお試しするネタを仕入れたり、情報共有するために使うのです。

隙間がいっぱい

ウォーターフォール型のシステム開発だと8時間20日160時間全部プロジェクトに売ってしまっているのでそんなことはできなと思っていたら、それは違うんじゃないかなと思うのですけれど。

まあ、デスマならそうかもしれませんが。

デスマでなければ、ウォーターフォール型のシステム開発はタスクごとにスラックがあるのでそうした作業ごとに隙間の時間が隠れている、いやエンジニア自身が隠しているのですよ。

で、全部、作業に当ててしまっているんです。でもその時間を紐解けば、生産的でない作業をしてる方が多いんです。

それをわざわざ誰かに言う必要はありませんが、だったら、試す時間に使った方がいいんじゃありませんか。

あなたがそのプロジェクトを終わったときに、ちょっとだけイノベーティブな価値を増やしておくために。

ジョブ理論 イノベーションを予測可能にする消費のメカニズム (ハーパーコリンズ・ノンフィクション)

イノベーション・オブ・ライフ　ハーバード・ビジネススクールを巣立つ君たちへ

「解決策を持ってこい」と言われる前にエンジニアが考えておくこと

大の大人に向かって上司は「報連相をしろ」と言う。ではと報連相をし始めると解決策を持ってこいという。だったら、解決策を持ってこいと最初から言えばいいのにと思っても当然です。

では、報連相をしろと言いながらどうしてマネージャは解決策を持ってこいというのでしょうか。

誰もが専門性を持っている

特にエンジニアは同じ組織であっても適用する技術が幅広く、技術の深さもあるので専門とする技術領域がエンジニアによって違いがあります。

この考え方を頭の隅に置いておかないと間違いを引き起こします。

相談に行くエンジニアはそのエンジニアの専門性があります。プロジェクトマネージャだったとしても育ってきた技術のドメインがあってその延長線上でプロジェクトマネージャになっていることが多いものです。それはエンジニアには必ず技術的な背景を持っているということでもあります。

それと同じように、マネージャもいきなりマネージャになったわけではなく、相談にきたエンジニアと同じように専門的に育ってきた技術ドメインがあり、プロジェクトマネージャなどを経て管理職のキャリアパスを歩いてきています。

これはどういうことかというと、技術の詳細な話をされてもついていけるところとついていけないところがあるということです。技術ドメインを持っているので他の専門的な技術でも概念は理解できるけれど詳細で込み入った話になったら置いてきぼりになるということです。

相談したい理由

エンジニアが相談したい、相談しなければならない理由には何があるでしょうか。マネージャが知りたいから、エンジニアの考えや方針に自信がないからでしょうか。違いますよね。

エンジニアがマネージャに相談するのはエンジニアが担当するロールとしての責務の範囲を超えていると認識したからです。

意思決定をしたいのは誰か

エンジニアが自分の責務を超えた事案に対してマネージャに相談するのはなぜかというと、事案の対処の意思決定をしたいからです。

意思決定をしたのは誰か。

もちろん、エンジニアです。マネージャではないのです。ですから、意思決定できる2つのことを伝え、裁量を持っているマネージャに判断を要求しなければなりません。

あえて、要求と書いたのは、そうしてほしいと思っているのはエンジニア自身であるからです。

伝える2つのこと

では、伝える2つのこととは何か。

1つ目は、意思決定したい事象の事実です。これは伝える側の推測や判断が混在してはいけません。

客観的なエビデンスを出せる事実を伝える必要があります。

2つ目は、どうしたいかという意思表示です。専門家として、現場に一番近い立場のエンジニアとしてプロジェクト最適化を踏まえるとどうすることが良いのか、その時の立場で伝えます。

ここでも、個人的な感情は棚に上げて続けなければなりません。意思決定に個人の感情は不要なので。

まんがでわかる 伝え方が9割

考える技術・書く技術―問題解決力を伸ばすピラミッド原則

ロジカル・プレゼンテーション――自分の考えを効果的に伝える戦略コンサルタントの「提案の技術」

断線…買い替え

Anker PowerLine II ライトニングUSBケーブル【Apple MFi認証取得 / 超高耐久】iPhone / iPad / iPod各種対応 0.9m ホワイト A8432521

なんですと！ 「苺ましまろ(8)」

 4年半ぶりの新刊…

苺ましまろ(8) (電撃コミックス)

失格なプロマネはヤリ○ンなナンパ師になれない

このツイッターのまとめをどうして引用しているかがわからないとプロジェクトマネージャに優しくされるだけされて、でも、目一杯働かされた後にリリースされてお終い、なんてなりかねませんよ。

togetter.com

ポイントはここです。

ヤリチンの一番の特徴は「女に何も期待しないこと」なんだよね
ヤリチンは無限に女を甘やかし肯定してくるけど、ソレは「ヤレればどうでもいい」からこそであり、逆に本気男はどうでもよくないからこそ「苦言を呈す」
そこを見誤る女は如何に出会いや婚活に精を出しても、ヤリチンの精を出して終わる

— 脱税レイヤー風呂屋さん (@557dg4) 2017年10月26日

「ヤレればどうでもいい」というところ。これの「ヤレれば」を「アウトプットしてくれれば」に置き換えれば完成。これがプロマネの立場としての最優先事項だから。

そして、プロマネをマネージャに置き換えてもそれは同じです。「ヤレれば」を「儲けるビジネスをやってくれれば」で。

では、このヤレればを実現するためにどう振る舞うかというとこれも書いてある。それは

「何も期待しないこと」

です。

いやいや、アウトプットしてもらうために絶賛期待するでしょう、と思ったら、それはプロマネとしてもマネージャとしても失格です。

自分に与えられた役割はプロマネもマネージャも結果を出すことです。それ達成しなければならないのに、メンバにそれを期待するということは、依存してしまうということになるので。ではどうして依存することが失格なのかというと、依存したメンバが期待した結果を出せなかった場合の代替手段、リカバリをしないからです。

上手くいけば自分の手柄にしようとすることが見え見えですし、失敗したらあいつが、となることも目に見えています。

できるプロマネやマネージャは結果を出します。もう、しっかりコントロールして結果を出す。詳細に見れば、遂行上の必要なリソースのメンバだけしっかり見ます。影響しないメンバは誰かに見させることで自分のリソース配分を最大限効率化して使います。20％のメンバを集中的にコントロールすれば全体の80％が確保できるわけですし。

では、なぜできるプロマネやマネージャは期待しないのか。自分のリソースのフォーカスを完全にプロジェクトやビジネスオペレーションの結果に結びつく主要なアクティビティに定めているからです。それは役割を果たすためにどこで何をすればいいかが見切れているからできるんですね。

 何をすればいいか、どこにリソースをかければいいかがわかっている。そうするとどんな態度をとるかというと、ニコニコと日常からコミュニケーションを取り、進捗上の障害となる芽を探し回りメンバから吸い上げようとするのです。

「問題ないよな」、ではなく、「気づいたことがあったら教えてね、そういえばあれは…」と声をかけまくるわけです。優しくね。

あら、ナンパ師と同じだわ。

口ベタ営業マンが渋谷ギャルをナンパし続け半年後に1億の契約をとった件

口説きの教典 ──カリスマナンパ師ミステリーの恋愛メソッド

本物のナンパ師は女性に「ナンパ」だったと思わせない。

クラブナンパの教科書＜基本編＞: ?凄腕ナンパ師が語るクラブナンパの理論とテクニック?

エンジニアにとってのプロジェクトマネジメントとは

「プロジェクトマネジメントはプロジェクトマネージャがするもので、エンジニアはプロジェクトメンージャの指示されて作業をするだけだ」

もし、エンジニアがそう思っていたら、そのプロジェクトはそのエンジニアが思っているようにプロジェクトマネージャのものになってしまう。

プロジェクトマネージャのプロジェクトになるということは、プロジェクトマネージャだけで考えたプロジェクト計画書により、1から10まで全てがプロジェクトマネージャの経験と知識に塗り固められた計画で執行されることになる。

もう一度書くよ。

エンジニアがプロジェクトマネジメントがプロジェクトマネージャのものであると思っていたら、プロジェクトが始まってから終わるまでずっと指示され続けるということになるんだ。

エンジニアはそれを望んでいるのかな。

そうなることを望んでいないことは明らかだ。全ての作業を指示されるということは、仕事の中で自由がないということだ。

緻密なプロジェクト計画書を書き、それをエンジニアに求めるプロジェクトマネージャのプロジェクト運営がどんな風になるかは想像できるだろう。作業のひとつ一つを細かく指示され、その通りにやらないと事細かく指摘され、再発防止のためにさらに無数の作業をすることを求められるマイクロマネジメントを実践させられる立場になるのだ。

一方、ズボラなプロジェクトマネージャは、プロジェクト計画書をろくに書きもせず、作業の当日になって行き当たりばったりで指示とも言えない指示を出し、現場がうまくいかないと対処を現場に投げてくるのだ。そこではプロジェクトマネジメントのプの字も存在しない世界でエンジニアは無能な名ばかりのプロジェクトマネージャの尻拭いをプロジェクトが終わるまで続けることになるのだ。もし、終わるのなら。

エンジニアは、自分を守るためにプロジェクトマネージャがやろうとするプロジェクトマネジメントを知っておく必要があるのだ。プロジェクトマネージャとは同じチームになるのだから決して敵対な関係になるという意味ではなく、相手が使う手法を知っていれば先読みができるので自分を守りやすくなると捉える必要がある。逆に言えば、プロジェクトマネージャが使うプロジェクトマネジメントを知らなければ、エンジニアはそれに関する知識を持ち合わせていなければ、一方的にプロジェクトマネージャのターンで終始するということになるのだ。

それでは耐えられないだろう。

世の中のプロジェクトマネージャが全て優秀なわけではない。どちらかと言えば、優秀うなプロジェクトマネージャを探す方が難しい。

この事実については誰もが同意することだ。同じように優秀なエンジニアをチームに迎えることは難しい。

エンジニアにとってのプロジェクトマネジメントとは何か。

それはプロジェクトマネージャが考えていることを先読みするためのシステム開発手法を左右するプロジェクトマネジメントというプロジェクトの管理手法を知ることで実務である設計やコーディングの作業のリソースを確保し、そのほかの実務が生産的な活動からリソースを裂こうとする行為から保全するために必要な武器なのだ。

つまり、システム開発手法を知り、実践できる必要があることと同じようにエンジニアにとってプロジェクトマネジメントはエンジニアにとっても必要な実務の知識なのである。

それを手放ししてしまうことで生じる結果は、一方的にリソースを消費され、何も生まない活動に自分自身を繰り返し投下し続けるだけの存在というポジションしか得られない。

選びなさい。プロジェクトマネジメントのフォースを使うソルジャーとなるか、無双されるオークとなるかを。

SHIROBAKO ~上山高校アニメーション同好会~ (1) (電撃コミックスNEXT)

SHIROBAKO ~上山高校アニメーション同好会~ (2) (電撃コミックスNEXT)