エンジニアと子育ての成長でできること

12月も20日と余りを残してクロージングである。今年1年どうだったか。

イチョウなんとかとかときどき見かけるが、自分自身の能力の一つでも成長しただろうか。1年も仕事をしていれば何か1つくらいこれができるようになったとか具体的な名前を出して成長したことを認識したいがこれというものが浮かばない。

もし何も成長していないなら、あるスキルでやってきたのか。そうだとしたら、実質、スキルは増えず、あるもので1年間をやり過ごしたのだから時間に対してスキルの価値は目減りしてしまっている。そう考えると成長を確認できないことは辛い。

自分のスキルの成長について、思うように伸ばせていないのだから、他人の、チームのメンバのスキルを伸ばさせようとするなんてどれだけ難しいことか。

これまで、それぞれのメンバのスキルを伸ばすことは、手を替え品を替え試みた時期もあったが、すぐに止めてしまった。

その代わり、ToBeを考える方向に誘導するようにした。メンバの将来をメンバ自身が考える機会を作るようにした。

人は知っていることだけで判断する。知らないことをいくら伝えてもわからない。であれば、仕事を続けていく上でどうして行きたいかを本人に考えてもらう方がいい。その方向を考える機会を作り、継続的に促すようにしたのである。

どうしたいかを尋ねると、大概、わからないと答える。

わからなくてもいい。わからないだろうから、そういったことを考える時間を、機会を作っているのだ。

これをチーム全員にする。

自分でなりたいToBeを持っているメンバは勝手に育つ。自分を自分で引っ張る力を持っているからだ。でもToBeを持っていないメンバは、そういったメンバを見て真似を始める。

そこまで行けばあとは勝手にやり始めるので大丈夫だ。そうした環境を同じように作ってもやらないメンバもいる。それを無理強いしてやっても何も得られないから無駄である。

やりたければ自分でやっているのだから。

こうした考えをどこで身につけたかというと、現場での育成の実践知と子育てである。

自分の血は繋がっているのに、自分とは全く違う人格を持ったヒトである。親の都合には合わせてくれないし、親の思うことを配慮もしてくれない。

できることは、知らないことばかりの子どもにこういったものもあるという知る機会を目の前に置くくらいだ。どれに興味を持つかは子ども次第である。

メンバの成長と子育て。

何に興味を示すかも、どれを選ぶかも、自分ではない。

成長には指差すことだけしかできない。

できることは選択の幅を示すこととくらいである。

その機会をどれだけ作れるか。

 

 

大正製薬 新ビオフェルミンS錠 540錠 [指定医薬部外品]
 

 

 

 

 

1年間は短いが、今始めれば1年後には成果を手に入れられる

facebookには過去の同じ日に投稿した写真を見せて思い出をシェアしたらと勧めてくる機能を持っている。

先日、1年前から本腰を入れて週末に取り組んでいるきっかけになった写真をリコメンドしてきた。正確にはその数週間前くらいからなのではないかと思うが、facebookに投稿するようになったのはそのあたりからなのだろう。

その思い出の写真に写っているものは全くの畑違いで、言わば素人がやっているようなものである。1年前の自分は何を考えたか、その道のプロの友人に見せて、感想をもらった。

プロは素人がやったことには文句はつけないものだ。それよりやったことを褒める。そうしてファンを増やしたり、沼に引き込む。わかりみを共有できるクラスタは多い方がいい。

そこから半年を過ぎたあたりから、そのプロである友人がだんだんと本気になってきたような気がする。何があったかというと、そっちの方面で(小さく)ビジネスをしないかというようになってきた。

自分もそれについて毎回作る際にデータを取るようにして、違いを説明したり、計測した上で定性評価を行い、パラメータの変更点を共有することでどうして定性評価に違いが出るのかお互いに意見を話すようになっていた。

そんなことをやっていたらfacebookで1年経ったと思い出させられた。

ところで、ネットでサブカル界隈のネタをいくつか知った中でワナビ(長音で伸ばさない)という言葉がある。

よく言えば志望、つまりあるコンテンツを作りたいと思っている志望者である。志望者であるから実際にコンテンツを何かしらの形で出していない。そこのあるのはいつかはやりたいという志望だけである。

手前味噌だが、自分は1年前にやりたいと思って実際始めた。そして1年の経験を積んだ。

エンジニアにもワナビがときどき紛れている。誰かが進めている案件に、急須の口を割り込む。そのアプローチより自分が考えているアプローチの方がいいと思うと主張する。

いやいや、あなた、人の案件に感けてないで自分の案件を進めた方が良いのではないかと老婆心ながらヒヤヒヤしてしまう。でも当の本人はそういた自分のことに対しては気は回らずに外にばかり目をやる。

本来そうした意見を並べて議論するのは良いことであるが、それはその議論をするタイミングがあるものだ。方針やアーキテクチャを検討している時期ならウェルカムであるが、仮説を検証する段階においては混乱させるだけにしかならない。

もしそれでも自分の仮説を持ち出して優劣を競いたいなら、評価しやすいように自分の仮説に基づいた動くもので比較できるように闇研でもなんでもして、触って評価できるようにしないと迷惑でしかない。

でも結局、場を混乱させ、自分のタスクの優先順位は変えず、自分の考える最強のアーキテクチャの方がいいと主張するだけでしかない。

同人でもエンジニアでもワナビワナビでしかない。

やった人と同じ土俵に立ったとしても勝負にならない。

本当に実現したいなら、自分のリソースを割いて最優先で行っているはずだ。それをしないのだから、あれこれと意見を言っているのは嘘でしかない。

1年間は短いが今始めれば、1年後には1年後の成果を手にしている。

1年は早い。

1年後に手に入れている収穫は大きい。

 

 

 

退職エントリまとめ(2019年4月〜6月)

2019年版の退職エントリのまとめを作ろうとして4月に手をつけて、後悔をしたので四半期に分けたその 2回目。つまり、2019年の4月から6月分。

四半期の終わり、つまり6月に退職エントリが割とあって、夏の賞与まで待たなかったのだな、と思ったりした。感覚的に、賞与をもらってから辞めるとか多いのかと思っていたので。

その辺の感覚がずれているのはエンジニアの流動性が高まっているからなのかもしれない。そのため、6月だけでも十分多く、斜め読みだけでも時間が溶けていく。これは月刊の方が良いのかもしれない。

月の括りは実際の退職月が違うかもしれないが、まとめていると割とどうでもよくなって揺れが生じてくるのは性格なのかもしれない。その点はご了承の上でご覧いただければ。

 

fumisan.hatenadiary.com

 

6月

退職は2016年12月ですが。

note.com

 

退職後も面倒臭いことになっている増田

anond.hatelabo.jp

anond.hatelabo.jp

 

入った会社に生理的に無理な人がいたら割り切るしかないけど、無理だと思った人の会社で働くのはもっと無理では。

anond.hatelabo.jp

 

好きなアニメで退職を語る新しいスタイル。

29udon.com

自分のバリューを活かせないのはストレスだものなぁ。

ottiee.hatenablog.com

あまり社内がイケてない感じが溢れている。

blog.munieru.jp

_φ(・_・

ちなみに、五反田の会社に訪問するときはウッキウキでした(「おにやんま」のうどんが食べられるので)。

note.com

NTTなんちゃら系

monta-k.hatenablog.com

退職は7月だけどいいか。

www.msawady.com

 

スタートアップの楽しさ感があるなー。

rela1470.hatenablog.jp

LINEに行ったのかな。

blog.manj.io

 

www.wuzuki.com

続きは書いたのかな。

note.com

 

www.shimataku.work

クックパッド退職エントリーまとめ

taisyoku.company

 

5月

anond.hatelabo.jp

転職イベント

findy-code.io

フリーランスかー。

suzan2go.hatenablog.com

退職する会社がアレだったやつだ。

www.gunshi.info

 

peraneko.hateblo.jp

NTT営業系サポセン

anond.hatelabo.jp

 

転職振り返り的な?

typewriter.hatenablog.jp

 

NTT系退職エントリーを読んで得た仕事に不安になっている人の心中

anond.hatelabo.jp

創業したのは偉いなー

note.com

TV局Webデザイナーを辞めた話

www.shirousagi.site

 

takachi.hatenablog.jp

 

4月

嫁チェックがきびしかった人

chichi1091.hatenablog.jp

失敗例は貴重。

www.kazto.net

3末の退職なのね。

note.com

新日鉄の退職エントリと言うか製鉄は珍しいのでは。

montblanc18.hatenablog.com

インターンでも書くのね。

kawasin73.hatenablog.com

NTT系退職エントリ。

gold-kou.hatenablog.com

NTT系退職エントリの考察的なもの。

www.orangeitems.com

本文は有料。

note.com

NTT系。別のリンクは切れていたけどこれは見られる。

note.com

 

www.gunshi.info

 

tbpgr.hatenablog.com

 

4回目。

blog.coquelicotlog.jp

  

inari111.hatenablog.com

  

note.com

 

 

 

『2018年退職しました』退職エントリまとめはこちら。

fumisan.hatenadiary.com

 

 

鬼滅の刃 18 (ジャンプコミックスDIGITAL)

鬼滅の刃 18 (ジャンプコミックスDIGITAL)

 
ザ・ファブル(20) (ヤングマガジンコミックス)

ザ・ファブル(20) (ヤングマガジンコミックス)

 
転生したらスライムだった件(13) (シリウスコミックス)

転生したらスライムだった件(13) (シリウスコミックス)

 

 

 

 

 

今どきの企業カルチャーと宗教ぽさ

Web系の組織だとカルチャーを全面に出してアピールをする。これは採用で組織のカルチャーにフィットする=共感する人材『だけ』を採ることを狙いとしているのだろう。

想像してみよう。どこも人材難でエンジニアは昨今特にひどい。それなりの技術を持っていればあっという間に数社から声がかかるだろう。場合によっては言い値で採用してくれるかもしれない。転職するエンジニアは少しでも企業を決定する自分の価値観に合う会社を選びたいと考える。それは待遇かもしれないし、やりたいことを実現できると言う先方のコミットに、かもしれない。

採用する会社からすれば、そうした活動でコストを掛けてまでもエンジニアが欲しい。それは実現したいことがあるからで、入ってもらったらパフォーマンスを発揮することを期待している。

当たり前のことであるが、それがその当たり前が実現されないことがある。入ってみたら、外から見えていた風景とは違うものがエンジニアにストレスを及ぼす。

それは、仕事をするときの意思決定での価値観の違いである。創業者の独断であるとか、不条理な意思決定とかいい加減な仕事ぶりでも進めてしまうなど、振る舞いとして現れる。

1日のかなりの部分を仕事が占めている。その大きな時間の中でエンジニアの考え、価値観、意思決定のズレが何度も起きているとしたら、パフォーマンスは発揮されるだろうか。

エンジニアがそれに気付いたとき、急速に気持ちは冷めていくだろう。こうしたケースも多々あるのだろう。

採用はとてもコストが掛かる。現業に投下できるリソースを割いているかどうかわからないエンジニアを探すのだから。苦労して採用したエンジニアが実は意思決定の価値観で合わないとわかっていたらどうだろう。割り切って採用するだろうか。多分しない。遅かれ早かれどちらかがストレスフルになってしまうからだ。

入ってからミスマッチを知るより、先に曝け出して合うエンジニアに来て欲しいと言う切実なアピールなのだと思うと、新卒で大量に採用するSIerは離職のリスクを相当抱えながらやっているのだと思うし、リスクより採用コストの生産性(低コスト化)を図っているのだなと思う。

全面に押し出す価値観に合うエンジニアばかりが集まると宗教じみていると感じるのは、こうした背景があると想像することでなんとなくわかったつもりなれる。

 

 

 

 

 

機能していないカンバン

とあるカンバンがある。

カンバンとはアジャイル開発などで出てくるカンバンであり、ホワイトボードに付箋がペタペタと貼ってあるイメージをしてもらえればイメージはだいたい合っている。そのカンバンである。

その、とあるカンバンは機能しているかと言うと、本来のカンバンとしては機能していない。使い方が単にタスク(チケット)の備忘のスペースでしかない。

カンバンを使うのは次の目的があるからである。

  • プロセスの可視化
  • チケットの進度の共有
  • WIPの制限

プロセスの可視化

ホワイトボード(壁の方が広く柔軟性があっていい)を縦の列に区切るのは、プロセスを定義して、そのプロセスで働くことをチームで合意する意味合いがある。

列ごとにプロセスで行う処理を決め、それを充足し、確認をしてチケットを先のプロセスに進める。

ウォーターフォールで使うWBSは、管理の繁雑性との折り合いから5営業日以内で設定することが多い(最近はもう少し単位を小さくしているケースもある)。5営業日の場合、いくつかの作業プロセスをチャンクにするケースも出てくる。

そのような場合、塊の中になってしまうので、アクティビティがどのプロセスにいるかは担当するエンジニアに委ねてしまう。この場合、プロセスの可視化は行われない。アクティビティはWBSにしておき、実作業をカンバンでやるならそれは解消されるがWBSの意味はあるかと言う別の議論が起きるだろう。

チケットの進度の共有

チケットのプロセスを可視化することで見積もりした作業の規模に対して進度、つまり作業スピードを可視化する。この可視化で得られるのは、あるチケットの進度が停滞しているときに、担当外のメンバが異変に気づける情報を何の新たな手段を導入することなく実現できることである。

WIPの制限

work in progressである。進行しているアクティビティを可視化する。可視化することで、1人が複数のチケットを進行させるようなことを止め(チームで決めたのチケットの上限以内に)作業を集中させることを促せる。

カンバンとして機能していないカンバンは、WIPを制限していない。作業仕様が具体的になっているからとWIPに貼るから備忘のためのカンバンになる。

これのどこがまずいかと言うと、タスクの優先順位づけができないエンジニアはあちらこちらに手を付けてどれも終わらないのである。あちらこちらに手をつけるようなエンジニアは個々の見積もった規模は当たり前のように記録もしない。見積もった意味もなくなってしまう。

一つひとつ終わらせないといけないのは、その見積もりの妥当性を検査する意味合いもある。差異があるならそれを共有しないとチームの見積もりに知見がフィードバックされない。

 

 冒頭のカンバンはToDoリストであり、個々のチケットは可視化されない優先順位により適正に行われるとするのであれば、それはそれでタスクの情報の共有の意味合いしかない。

 

 

 

マンガでわかる トヨタ流の生産方式とマネジメント

マンガでわかる トヨタ流の生産方式とマネジメント

 

 

締め切り駆動型の仕事

アジャイル開発の場合、チケット(タスク)の作業規模はプランニングポーカーを使い基準となるタスクと比較して大きさをチームで(合意する大きさに)見積もるか、理想時間で見積もる方法を取る。

どちらの方法であっても、その作業を純粋にやったらという前提がある。それは、日中、仕事をしている上で、集中して作業をすること自体難しいと言っているようなものである。万難を排して作業に集中したら、あれ(基準のタスクで掛かった)時間のN倍で終わるはずだ、理想時間なら2時間で終わるはずだ、と言っているからである。

ところで、どちらも正味の作業ボリュームを表現しているのであるから、作業ボリュームを合意した時点で納期を約束したようなものである。

お分かりだろうか。

ウォーターフォールでできの悪いプロマネの馬鹿げたスケジュール(と呼ぶには勿体無い)アクティビティの完了予定日を設定されているのと同じである。ましてや、自分の見積もりのボリュームと他のメンバの見積もりが違っていて、そのギャップを埋めた後では、そこまでやるのかとか思った以上にやることあるなと気付かされている訳である。

そうは言っても馬鹿らしいスケジュールを結果的に集中する時間を捻出してやったことにするよりは天地の差があるくらいマシではある。

どちらにも共通していることがある。それは締め切りを設け、それに合わせて仕事を終わらそうとするということである。自らを律しなければとても実現性は低くなるし、中途半場にやっつけでやるとお釣りを受け取る羽目になるばかりか、明日の自分の時間を今日の自分のせいでドブに捨ててしまいかねない。

締め切り駆動型とも称することもあるが、このやり方でアクティビティ、仕事を終わらすことができないエンジニアは、二つの観点が抜けている。

  • 自分自身の技量レベルの認識
  • 他者の作業をコントロールする意味

例えチームのメンバと合意していたとしても、自分の技量レベルをポテンシャル=期待値でしか見れなければ期待した以上にパフォーマンスは得られない。

同じように、自分が主導権を握らなければならないアクティビティに他者の作業が絡んだまま、それを他者に手綱を渡したまま見積もっているなら相当の段取りマスターか昼行灯でしかない。

結局のところ、みんな仕事は締め切りに追われる仕事の仕方をしていて、その締め切りの中でコントロールできる人だけが余裕を作って仕事をできるのである。

 

 

 

鬼滅の刃 18 (ジャンプコミックス)

鬼滅の刃 18 (ジャンプコミックス)

 

 

 

食える仕事、やらない仕事

かれこれエンジニアとしてのキャリアは、年代で何をして食べていくかを考えると方向性を決めやすいと言ってきた。あちらこちらに、ことあるごとに書いてきたから探す気にもなれない。

奇特にも過去のエントリを読まれている方は、ああそうだね、くらいの反応だろうし、、またか、と思うかもしれない。まあ、そのまたか、ではある。

 

ざっくりと自分のキャリアを年代に紐付けると次のようなイメージになる。

  • 20代 (パッとしない)エンジニア
  • 30代 プロマネ
  • 40代 マネージャ
  • 50代 コンサル+マネージャ

年代きっかりではなくて、だいたい年代の前半に準備期間のような次をどうするかを考えている時期があって、年代の半ばにピボットしていた。

そうするとそろそろ60代に向けたピボットを迎えてもいい時期ではある。

食える仕事か

1年経てば1歳年をとる。いいように使われていれば、そこそこの価値はあるのかもしれないがこちらの期待の収入は得られそうにない。

食える仕事とは、今やっている仕事を続けたとき、10年後に今の年収だったらやってられるかということだ。

流されて仕事をしていればい+微増くらいだろう。そうそうびっくりするような評価は期待できない。

それでいいのかという価値観で今の仕事を続けるかどうかを考えた。もちろん、食っていけないだろうという結論になる。

だったら、食える仕事を選ばなければならない。 

やらない仕事を選ぶ

年代の中盤でピボットをしたとき、自分の中ではそれなりに伏線はあったのだと思うが、次の年代でする仕事を選んでいたのだと思う。逆に言えば、続けない、やらない仕事を選んでいたのだ。

適性もあるから今の延長線の方向ではない。いくら自分のポテンシャルに過大な期待を抱いても実現される可能性はない道を選ぶ理由はない。

それよりは、やりたい方の仕事をどうしたら手に入れて結果を出せるかを考えた方がいい。今思えばそういうことだったのだろう。

次のピボット

今の環境は割と次のステージを嗾けるようなことをいうエンジニアがいる。いやいや、その方向ではイメージが持てないから積極的に考えていない。ここでやらないと決めて置いてきた仕事の大事さを知る。結局物を作れなければ仕組みを作るしかないのである。

もう2つくらい方向性の違う選択肢があるが、1つは思ったよりポテンシャルがわからない。もう1つは、それで食えるかと言えば、完全にピボットするのはギャンブルでしかない。

 

年代とロールを紐づけるとキャリアの方向性は見つけやすい。ロールは所属する組織の役職にしない。ミッションで考えた方が組織に依存しないので良い。

そんなことをぼんやりと考えていたりする。