あなたが成果を生み出すエンジニアであるかを知る10の質問

on エンジニア 成果を生み出す

 

  1. 健康である
  2. 手際が良い
  3. 理解する能力に長けている
  4. 学習する能力が高い
  5. 喜んで責任を引き受ける覚悟を持っている
  6. 創意工夫することが好きだ
  7. 転機をきかせることができる
  8. 専門以外の一般的知識を持っている
  9. 専門の知識を持っている
  10. 経験から形式知を導き出せる

 

 

Nintendo Switch 大乱闘スマッシュブラザーズ SPECIALセット

Nintendo Switch 大乱闘スマッシュブラザーズ SPECIALセット

 

 

 

経験をパターンに書いてみよう

on パターン 経験

日々、仕事をしているので何かしら経験をしているハズである。その経験は、日によって得られる経験値の価値は違うかもしれないが何かしら得られている、そう思いたい。

ただ、そうした経験を日々得ているハズだとか、今日の経験は何だろうと捉えるよりは、些細なことで良いから経験を得た、という体験を持つことの方を優先したい。

そうした経験の中で、デジャブな経験をすることがある。『あ、これやったことがある』『こうして上手くできたやつだ』と無意識に感じるそれである。

そうした、繰り返される経験は、無意識に自分にあった最適化される。あるタスクをするときに、自分での経験をベースに順番や加減を自分好みに調整するのである。

そうするといつの間にか、自分のタスクの処理方法のレシピが出来上がる。

このままでは、単なる習慣でしかない。自分だけの、ただ、自分でも感覚ででしか覚えていないものである。

では、その得たハズの経験はそのままでいいのだろうか。自分の経験として貯めておけばいいのか。

まあ、それでも構わない。構わないが、よければ一度試して欲しいことがある。それは、経験を自分のパターンとして言語で表現してみる、というものである。

経験を言語で表現するということは、経験を知に変換する行為である。それにより、無形の経験は経験知に変わる。

今のところ、誰に見せるものでもないから、気楽に、恥ずかしがることもなくお試しにやってみよう。

 

  1. 名前…パターンにした経験のラベルである。最後につければいい。ちなみに、悩むときには悩む。
  2. 要約…パターンで得られる効能のエッセンスを表現したものである。数行でいい。
  3. 状況…どういった状況、環境下でそのパターンを使うかシチュエーションである。自分用であるから、事細かく書かなくても良い。
  4. フォース…パターンで問題を解決するときの条件である。解決したい問題がかけてくる制約である。
  5. 問題…パターンで解決したい障害である。
  6. 解決…パターンで解決する方法である。その問題解決には、こんなやり方で、と書く。
  7. 事後結果…パターンを適用した後の状態である。パターンを適用した後なので、問題が解決されていなければならない。

まず、上手に書けない。それは気にしなくて良い。書き出すことで言語化される。ここが狙いの一つである。経験を見える形にすることは、とても価値のある行為なのである。

 

 

おいしいパターンで気ままに作るごはん

おいしいパターンで気ままに作るごはん

 

 

IT会社の社長なら、ウチに来たらいくらでも教育して技術身につけさせてやるぜっていうくらい言わないと優秀な学生なんて見向きもしない

on エンジニア 育成 新卒 大学

昨日、ITの会社の社長が大学にエンジニアになるなら大学で教育したらいいのではないかとツイートしていたので、自分とは違う考えの方が所属する組織の長でなくてよかったと思った。

 

新卒のエンジニアは配属される前に集合研修を一定期間受けることになっている。集合研修では、組織のルール、模擬開発によるプログラミングなど実技の訓練をしている。

そうした組織の人事部門なりに開発部門のニーズを拾い上げたカリキュラムを作っている。集合研修だが、最後にテスト的なものがあり、それをクリアしないと開発部門に配属されない。年によっては、一定数の新卒が延長戦に突入することもあるという。

そうしたステップを踏み、開発部門に配属となる。

配属されるとチュータをつけられ、チュータが育成計画を作ることになっている。それを上司が確認の上、実行されるのである。

なぜ２段階を踏んでいるか理由がわかるだろうか。１ステップ目は、システム開発のやり方を学ぶ。仕様を決め、開発環境を自分で構築し、フレームワークの上で自分でコーディングし、テストをする。こうしたごく当たり前の開発手法を身につける。

１ステップ目は、配属先での教育になる。ここでは、OJTと個別の講座がメインとなる。１ステップ目での言語は組織内で多く使われている言語を選んでいるようだ。２ステップ目では、配属される開発部門で変わる。JavaかもしれないしPythonかもしれないしSwiftかもしれない。配属先によっては使う道具は、言語ではなく、OSやMWかもしれない。いづれにしろ、開発部門のビジネスに必要な道具を仕事を通して学ぶ。

なぜこのようなまどろっこしく２段階も育成をしているのだろうか。それは組織として必要なスキルを持つ人材になって欲しいからである。

もし、ビジネスの需要やビジネスの方針から特定のスキルとレベルを持つ人材を必要とするなら中途採用になる。それは一から育成していてはビジネスニーズを逸してしまうからである。

育成は、2つのステップの集合教育やチュータが作る育成計画ばかりではない。目標管理制度を取り入れているので、実質、退職するまで育成を続けることになる。どういうことかというと、一人ひとりのエンジニアは、年度始めに自分で育成計画を作り込み、実行することを求めるということである。

これは、組織は継続してエンジニアを育てることを、制度により意思表示をしているのである。

エンジニアに理解して欲しいのは、こうした育成制度を行なっている組織は、エンジニアに見えないが相当な育成コストを投資しているということである。

実際、そうしないとエンジニアの技術は実務で必要とされるだけの技術とスキルレベルしか装備することができないため、エンジニアの技術的な価値は著しく低い。技術レベルが低ければ市場価値も低いため、価格競争力に巻き込まれる。

これらのことから、組織が社員のエンジニアの育成を外部に期待すること自体、おかしいな考え方である。

 

ゆるキャン△ 志摩リンのストライプマフラー

ゆるキャン△ 志摩リンのストライプマフラー

 
あたりまえを疑え。 自己実現できる働き方のヒント

あたりまえを疑え。 自己実現できる働き方のヒント

 

 

 

あなたに次のマネージャをやって欲しいと言われたら

on マネージャ

安心して欲しい。8割の人はこれからも言われることはない。

 

 

自分から手を挙げた人以外は、大体、マネージャをやって欲しいと唐突に言われるものだ。なぜなら、人事に関わることは人事関連の通達が出るまでは人事部門と関係部署だけ進められるからだ。ただ、本人には、内定の事前通達が行われることが多い。これは意思確認の意味合いがある。

さて、マネージャ業は初めてのはずだ。何か準備した方がいいのか、マネージャ業はどうやればいいのか、わからないことばかりだ。組織が古く大きいければ新任マネージャ研修を開いてくれるところもある。ただ、そういった組織でなければ『やりながら覚える』ことを求められる。これは人事部門が手が回っていない（機能していない）のと同じなのだが。

それはさておき、おめでとう。では始めようか。どこから手をつければいいかわからないなら、まずは自分のことから手につけよう。

 

マネージャ自身関連

  • マネージャのポリシー（意思決定の基準）を1つ作る
  • 担当するビジネスの構造を把握する
  • 数字に強くなる

マネージャなので、基本的にビジネスの意思決定を行うのが仕事である。上意下達の強い組織であっても、担当組織内での意思決定者は担当マネージャの領分である。

マネージャには部下のメンバがつく。メンバはマネージャを見ている。そのマネージャの意思決定を表すポリシーを自分の基準として1つ作っておくこと。この基準は随時見直して良い。役に立たないポリシーはメンバの仕事の邪魔になるだけではなく、ビジネスの失敗につながる。

担当するビジネスを知らなくては話にならない。マネージャは事業を分担して収益を挙げていくのが仕事である。エンジニアであった頃は知らないことがたくさんあることを知るだろう。特に、営業プロセスはそれまで関わりが少なければ思っていた以上に泥臭いことを知るだろう。その上、エンジニアリングのマネージャなのにかなりのリソースを使うこともあるかもしれない。そう言ったビジネスの構造を早々に把握する必要があるが、把握する前に案件に連れていかれるので否応無しではある。

数字とは担当するビジネスをキャリーするため、お金を扱う。会計、簿記の初歩くらいの知識がないととても困ることになる。例えば、黒字のはずだったのに月遅れでの請求書で赤字になってしまった、なんてことがあっては台無しである。

 

 

メンバ関連

  • メンバを把握する
  • メンバのスキルマップを作る
  • ロールの世代表を作る

メンバを把握することは、メンバの仕事が進むようにするためである。マネージャの仕事はビジネスを推進することだが、現場でそれを担っているのはメンバのエンジニアであり、そのメンバの推進じょうの障害があるのないのかを知るためにマネージャのリソースをどれだけ割り当てられるか鍵となる。

メンバとビジネスに必要なスキル、スキルレベルを対応させる一覧を作る。ビジネスの形態が複数あるのなら、ビジネスごとにリーダをアサインし、責任と権限を与える。

ロール世代表は、スキルマップに付加しても良いが育成と次のマネージャ候補の情報につながるので分けた方が良いだろう。現役のリーダ、次世代のリーダ候補、その次の、さらにその次の、くらいまで世代分けしておく。もちろん、組織を担うかビジネスだけのリーダか分けておく方が良い。

 

こうした項目は紙に書いてみること。そして、お正月の三が日に半日を割り当て、そこでざっくりと1年の計画を作っておくこと。

 

 

 

 

女騎士、経理になる。 (1) 【電子限定カラー収録】 (バーズコミックス)

女騎士、経理になる。 (1) 【電子限定カラー収録】 (バーズコミックス)

 
アロマティック リキッドソープ 柿渋 620ml

アロマティック リキッドソープ 柿渋 620ml

 

 

 

 

マネージャに何を求めるかでマネージャ像は変わるーサイボウズのマネジャー論が画期的ー

on マネージャ サイボウズのマネージャー論

TLを眺めていたら、画期的というキーワードに惹かれてハッシュタグのまとめを読んでみる。

サイボウズで次に制作予定の『新しいマネージャーの教科書』本に関するnotetとあるので、どうやら企画イベントなのか。

それはさておき、

 

togetter.com

 

の、冒頭のツイートで画期的というキーワードを使っている。

 

 

1番目は同意。日頃書いているブログのエントリのあちらこちらに書いてあることと同じ思想だ。

2番目もそう。弱みを見せよう、というよりは、エンジニアに得手不得手があるようにマネージャにだって得手不得手があるということ。それを隠すと不得手も頑張らなければならなくなる。その不得手を得意なメンバに任せて、マネージャが得意なところをやればいい。その目的を共有してから得手不得手を見せ合うのは意味がある。

3番目はどうか。指示しなければならない時もあるし、育てなければならないときもある。ただ、どちらもマネージャからアプローチするときは、期待するような結果は得られないことが多い。期待するレベルにするには結局のところ、手とり足とりとなってしまうものだ。

4番目のメンバのことを把握さえしてればいい、とある。これも同意。

 

さて、この4つの項目に優先順位をつけてみてほしい。

 

[　]番目　マネージャは役割である
[　]番目　マネージャは偉くないし、立派じゃない
[　]番目　マネージャは指示したり育てられない
[　]番目　マネージャはメンバを把握している

 

 改めて４項目を眺めると、1番目はマネージャの機能について述べている。2番目はマネージャの人物像について述べている。3番目はマネージャのスキルについて述べている。4番目はマネージャの仕事について述べている。

この4つの項目に順位をつけるということは、マネージャに対する何を期待しているかという、順位づけした人の欲求を示していることになる。

自分としては、4→3→2→1に順番をつける。どうしてそう考えるのかというと、その答えは1番目に書いてある。

ところで、最後の『究極的には雑談さえしていればいい』とあるが、これを勘違いして文面の通りにやってはいけない。

これは、4番目を実現する手段であり、単なるツールなのである。昭和のおじさん達のタバコ部屋と同じなのだ。自分はタバコ部屋には入らないが。

この4つの項目以外にいくつか抜けていると思うのだが、

 

 

の3点は仕事を楽しく前に進める上で必要なことだと思う。さらに、

 

 

ご本人自身で『諦める』を座右の銘と言われているが、必要なタイミングで線引きできる能力も必要である。まあ、線引きしたその後が大変なので線引きできないマネージャが多いのもまた事実なのだが。

ちょっと脱線するが、

 成果とプロセスの問題は、こう捉えればいい。成果は業績評価にリンクさせる。プロセスは、スキル、コンピテンシの育成で評価する。これがベスト。

スレッドを読み進めると『共通言語』と出てくる。これはちょっと手に余るだろう。なぜなら、誰と誰の間の共通言語か、とその言葉の定義をしないと進まないからだ。それでも共通言語を作りたければやればいいと思う。最終的に、共通項だけになりITSSのエンジニアのコンピテンシのような文章になってしまうだろう。それを作ることはその言葉を定義する組織にとっては意味を持つ。ただ、組織外の人にとっては、役に立たない。

 

共通言語でバラバラだったチームをまとめようとしたら…とある。これも、バラバラのチームをまとめる必要があるかどうかという観点で考えると別のアプローチにたどり着けると思う。チームは機能すれば良いのであって、まとめる必要はないことを頭の隅に置いておこう。だって、マネージャも役割（＝機能）なのだから。チームは人の周吾隊としての人と見做すと捉えると良い。

 インセンティブを聞くのは組織にインセンティブを支払える制度があるからできることである。それはそれで他所のお家の話であるが、素晴らしいと思う。ここの本質は、実現したいという部下の進捗を妨げる障害を一緒に考えるマネージャであるということである。これも過去のエントリで述べていることだ。

キリがないので最後に『説明責任』『質問責任』とある。責任をresponsibilityと捉えるなら同意する。説明は、（誰にかはさておき）何かを他人に働きかけるのであるから、その働きかけに期待する結果を得たければ説明を省くことは期待する結果が得られなくても文句をいう筋合いではなくなる。結局、どうしてそれをやりたいのか背景を話すことになるのだ。

長い。

マネージャを学びたければ、OVERLOADを読むと良いんじゃないか。

 

 

終わりと始まり

終わりと始まり

 
オーバーロード1 不死者の王

オーバーロード1 不死者の王

 

 

 

 

 

 

 

 

 

 

 

火消しより💮をつけるのが仕事である

on 火消し 炎上プロジェクト 💮

今年もあとひと月を切ったし、平成もあと半年くらいか。温泉でサウナと水ふろを２往復したあと、休憩所みたいなところで地の方言を大声で話す老人たちのノイズをBGMに絶滅したプロジェクション型TVに映っているゴルフを眺めている。

声を抑えて話すことは、場や話す内容により選ぶ必要があるから、ある種のスキルなのかもしれない。ずっと声を張り上げて話すおばあちゃん、何を話しているのか聞き取りにくいおじいちゃん。地方はこんなものなのだろう。

盛り付けに一切気を使っていないクリームあんみつの寒天と小豆あんを掬いながら、就職は都会に限ると改めて思う。

水風呂で延髄がじんじんする感覚を感じながらfacebookのTLを眺めていると「火消しは得意じゃないんですよ」というのを見かけて、そういえば最後の火消しはいつだったかと記憶を辿る。

実は、ボヤといえばボヤな案件があるが、案件の性質上、それほど問題になっていない。ただ、年明けにイベントがあり、そこには間に合わせなければまずいので、今まで他の複数の案件にリソースを使っていたところの配分をシフトしてネジを巻いてやらないといけない。

エンジニアはどうして放置されるとズルズルと終わらせる予定日をずらしていくのだろうか。

どう考えても、終わらせると約束した日に一旦、終わらせてしまった方が楽ではないか。放置した結果がこれであるから、これは自分のプロジェクトの関係者でなければ、つまり、他の案件ではもっとひどいのかもしれない。

それはさておき、プロジェクトでどれだけ火消しをしたかよくわからない。火消しは関わりのないプロジェクトを外から立て直しに入る仕事である。

まあ、火消しに入るときは、だいたい、そばにいて火の粉が降りかかってきそうだというのがわかる。役員か上司と見ていて、やばそうだと言っているうちに巻き込まれるからだ。

自分で最初からやればこんなことはならないのに、と思う。それに、大騒ぎしたエンジニアは再チャレンジする機会を与えるのは良いが、当たり前に仕事をして当たり前に終わらすエンジニアをより評価するようにしなければアホらしくてやってられない。

まあ、火消ししなければならない案件は目立つから、であるのだが。

そう思って、最近はかなり平常運転であるからこそ、うまく回しているメンバを持ち上げる実験をしている。これが割と面白い。

実は役員級に評判がイマイチのエンジニアがいるのだが、今の仕事でうまくやっているので擁護キャンペーンをしている。上司や役員なんて自分が見ていた時の印象をずっと持っている。そうした印象は後を引いて昇格時に割と響く。

自分にとって、部下と恋人の過去はどうでもいい。

今、自分の部下として期待することに期待通り応えてくれるなら、花丸をいくらでもあげる。自分の仕事は部下に○をつけることなのである。

今年は大分💮をつけれたのでいい1年で終われそうだ。

 

 

くまモン の スタンプ / 大変 よく出来ました / はんこ ゴム印 / ゆるキャラ グランプリ 2011 1位獲得 熊本 県 の キャラクター / くまもん グッズ 通販

くまモン の スタンプ / 大変 よく出来ました / はんこ ゴム印 / ゆるキャラ グランプリ 2011 1位獲得 熊本 県 の キャラクター / くまもん グッズ 通販

 

 

小さなチームを作っている

on 小さなチーム 笑顔

いろいろなチームを作ってきた。プロジェクトマネージャとしてプロジェクトのチームを立ち上げればプロジェクトの目的を遂行するためのチームを作ってきたし、管理職としてメンバを抱えれば複数のプロジェクトを遂行できるチームを作ってきた。管理職のときは、プロジェクトごとに大きなプロジェクトチーム、小さな数人のプロジェクトチームを編成するときでも、ただヘッドカウントだけがあっているチームではなく、プロジェクトチームとしてのスキルセットを考え、足らないところは何かしらの策でリスクを予防することを『当たり前』として編成してきた。

ここ最近、育てているチームは小さなチームだ。エンジニアの年代はバラエティだ。平均年齢にするとだいぶ高いが高い分、仕事の推進力もまだまだ馬力が出る。グイグイと引っ張ってくれる。若手はこれから本気を見せてくれるだろう。そんなチームだ。

チームのミーティングの時間を連絡事項を改めて言うなんて相当なことがなければしない。もっとチームのために使う。ミーティングの時間を通知のために使うなんて馬鹿げているじゃないか。

メンバの活動で共有しておきたいテーマがないかを尋ね、ネタも尽きたところで自分からネタを振る。

もう、師走なので来年の、このチームミーティングの使い方を考えようと案出しをしてもらう。チームの存在理由としての活動をしなければならない。これは枠として入れておくが、法則があるので時間時にプロットして入れておく。

こうした計画づくりも、『来年の計画を作ろう』と言うだけであとはメンバが勝手に考えてやってくれる。困ったときは自分の方を向いて『このイメージで良いか』と手探りしながら一緒に考えようとしてくれる。

こうした計画はメンバが主体的に考え、立案してくれると勝手に実行されるのだ。マネージャがああしろ、こうしろと云うと作らされ感が付きまとってやらされ感しかなくなるのである。

そうして枠を埋めていくと、残りとしての枠はかなり残る。それはチームのメンバが使う時間に当てる。週次開催だから間は開いてしまうが、ちょっとずつ使えるのは大きいし、何より、プロジェクトから離れて別のテーマをチームで考え、各自の中に取り込んでいくのは本来の業務に良い影響を与えないわけがない。

テーマ活動をしているときは、ほとんど、チームのメンバだけにする。つまり、さっさと退席してしまう。やはり、自分がいると中堅以上のエンジニアは発言に少なからず気を使っていることを見たことがあったからだ。チームの時間はチームのメンバが主役、リーダになるべきだ。

こんな小さなチームだが、ミーティングに集まるとき、いつも笑顔だし、よく笑う。真剣な顔をして話しながらも、楽しさがある。

どこにも他にない、いいチームだと思う。

 

 

 

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

 
徒花ネクロマンシー

徒花ネクロマンシー

 
チームのことだけ、考えた。――サイボウズはどのようにして「100人100通り」の働き方ができる会社になったか

チームのことだけ、考えた。――サイボウズはどのようにして「100人100通り」の働き方ができる会社になったか