調達 アリミノ ピース フリーズキープワックス 80g

 香りが好み。

アリミノ ピース フリーズキープワックス 80g

エンジニアのキャリアとフィボナッチ

自分のエンジニアのキャリアを振り返ってみたとき、キャリアの分かれ道のどちらを選ぶ（実際には他を選ぶ理由はなかったのだが）タイミングに法則があるのではないか、と思った。

エンジニア歴は、単純にあなたがエンジニアになってからのキャリアの年数である。年齢は、例であるからあなたの年齢に読み替えて欲しい。

キャリア歴　　　　例

1年	22才
2年	24才
3年	25才
5年	27才
8年	30才
13年	35才
21年	43才
34年	56才

自分の場合は、3年目頃にプロジェクトマネジメントに出会い、8年目あたりでこのまま（当時の、の意味合い）では先がないと思い始め、13年目前後にキャリアを思いっきりシフトした。

21年目あたりも、プロジェクトマネジメントに乗るシステム開発手法をシフトしたターニングポイントになった。

キャリア歴は前後するとしても、始めてから重ねる年数はこの法則があるのではないだろうか。

1年	22才
2年	24才
3年	25才	これ以降のキャリアの方向性を左右する出会い
5年	27才	自分の特性を知るとキャリアを考える
8年	30才	キャリアを絞り込む
13年	35才	専門性のピボットの最終ライン
21年	43才	専門性の拡張
34年	56才

今の時代はもっと時間の流れが早いので当てはまらないと思うかもしれないが、それはこのキャリアの中での１つの要素であり、エンジニアのキャリアのマイルストーンとしてはこのくらいのタイムスパンで捉えた方が全体の見通しは良いような気がする。

ご自身のエンジニアとしてのキャリアをこのパターンでプロットするとどうなるかを試してみたらいかがだろうか。

フィボナッチ―自然の中にかくれた数を見つけた人

だいぶ手に余るタスクを無茶振りされたときの着地点の探し方

もともとタスクA（タスクと言ってもプロジェクトレベルの規模である）を前任者Bから引き継ぎつつ、やることになっていた。

その一部分としてのタスクがある。これは現任者Cが仕掛かり中である。気になって見たところ（ズカズカと土足で上がらないように靴は脱ぎつつも）覗いてみると中身がアレだったので、文化的に合いそうな提案して、仕掛かり中だったところの軌道修正をするなど、いわゆるテコ入れをした。

それはサブセットなので違和感はないのだが、もともとのタスクAを調べてみると、こちらの要領を得ないところがあり、なかなか進まない。手探りでアプローチ方法を見つけようと試行錯誤している、と表現するのが適当かもしれない。

手探りになった原因

タスクAはマイルストーンが決められており、ステークホルダが多い。そのスケジュールは別の部門が決めており、マイルストーンだけがぼんやりと（月レベルで）ある。

今思えば、そのスケジュールからどうすればいいか、タスクを組み立てようとしていたことがどうやら間違っぽい。

打開の緒

 どうも腑に落ちず、元ネタを読み込んでみると、文書化されている業務がちぐはぐではないか、と思えてきた。そこで、元ネタから業務を可視化しようと、手描きで図を描いてみた。

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

なんだこれは。

たぶん、文書化した元ネタは、図式化した構造から見ると一度もろくにやっていないとしか思えない。多分、他所から雛形をもらってきて、それを移植したのだろう。これでは運用が回らない。

頭を整理するには、図を描くに限る。対象のオブジェクト、登場人物をプロットするだけで良い。

横スクロールに描けば、時間の軸の意味を付加できるので業務フローになる。

立て直し方針

 プランAは、現行のマイルストーンをクリアすべく、最小限の対応で文書化されている業務を行う。だが、これでは現場がついてこれない。

そこでプランBだが、文書化されている業務のうち、やらなくても良さそうな業務を一旦、削ぎ落とす。その際に、回らない業務を回せるように組み直す。端的に言えば、文書化された業務を捨てて、作り直すということである。

どうせやっていないのだから、誰も困らないし、誰にも影響しない。やっていないのだから、サンクコストは文書化したコストだけである。

削ぎ落とすのは無慈悲にやってはいけない。よりどころが必要である。御本尊は持ち合わせているので、その価値観に合うかどうかで落とせるところは落とす。

狙う先

価値観を持っていてもそれだけでは続けられない。何しろ、業務になると継続するのでアホな業務はやっていられない。

そこで、その業務での本来の狙いと先を２案考えておく。案1は、業務の拠り所は残したままシュリンクして続ける。案2は、案1の根幹の考え方を取り込まずに、組織の価値観に合うToBeを目指す。その際に対外的には案1で参照する拠り所＋αを狙うことを目指すとコミットする。

案1は楽しくないし、挑戦もない。案2は挑戦だがマイルストーンがあり、綱渡りだ。クビが飛ぶかもしれない。でも、たぶん、楽しい。

あなたはどちらを選ぶだろうか。

カクダイ(KAKUDAI) シャワーホース 取付簡単 ほとんどのメーカーに対応 1.6m 3672C クリーム

合わない上司と仕事をするときの7つのポリシー

エンジニアになってから、こんな奴とは仕事したくないとか顔を見たくもないなんて１度もなかったのにある人事報でどうにも受け入れられないおじさんが上司の立場になったことがある。

先に伝えておくが、合わない上司と無理に仕事を続けなさいなんて言わない。無理をして精神面に影響して体調を崩しかねない。実際、職場の人間関係はエンジニアにとって一番影響する要素だと思っている。だから、仕事が上手く行かなくなるくらいなら異動をさせてもらうか、転職した方がいい。そのくらい重要なことだから、軽く見ないこと。

自分は仕事をする上で、人の好き嫌いでは選り好みをしないでいいことを自分の中では特段の性質だと思っている。好き嫌いというより感覚的に合う合わないという感覚はある。生理的に無理、という奴だ。

ただ、プロジェクトマネージャやマネージャ、もちろん、エンジニアやコンサルの１メンバとしてでも同じだが、他のメンバは自分より優秀な技術を持っているから同じ場所にいるのであり、その技術を必要とするのであれば、自分の生理的な感覚は仕事上において優先する価値はない、と考えている。

もちろん、チームの価値観と合わないのであれば、ご退場願うのはもちろんだが、そうした推進上の障害になる人物でなければチームとしてウェルカムである。

属性的には、同じプロジェクトマネージャだったので、考え方が似ているとぶつかりやすいのだろうと思うことにした。

 件の上司もそれなりに実績があったようで、自分に対する自身は相当の物を持っていたのだろう。

ただ、向こうの対応を感じ取ったところでは、少なくともいい感じで自分のことを見ていないことはよくわかる。

冷たい、認めていない、距離感がある。

そうした感覚が伝わってくる。

でも、それは自分の仕事には関係ない。分掌する担当において、パフォーマンスを出すこと、プロフェッショナルなサービスを提供することが仕事だから、割とどうでもいい話だ。自分は誰に向かっているか。自分のプロフェッショナルなサービスを待っている人に対してのみである。

では、どう対応したか。

大人のコミュニケーション

 差し障りのない、と言ってもいい。過剰にコミュニケーションを取れば、相手だって面倒だと思うだろう。こちらも必要以上に関わらない。

コミュニケーションは自分が不利なエビデンスを残さないように、丁寧に。

それ以上はしない。

ルールを守る

 組織のルール、手続きを守る。期限のあるものは、期限より先に済ませる。余計な目立ち方はしない。

オブジェクト（仕事）だけで会話する

 分掌する仕事だけを話す。上司という人や自分を前に出さない。どうすればいいかというと、主語をオブジェクトにする。

ロジックを作って仕事をする

上司に突っ込まれるスキを作らないためだ。必要があれば、説明する。もちろん、オブジェクトを主語に。

評価は期待しない

 少なくとも上司は好意的に見ていない。だから、その上司が上司である間の評価は期待しない。

時間を無駄にするようなものだ、馬鹿らしいと思うなら、異動を希望するか、転職を考えた方がいい。

幸い、その上司の定年が見えていたのでそこまでは、その上司にだけは仮面のコミュニケーションを演じればいいと思っていた。当時は。

上司の上と仲良くしておく

 プロジェクトを立て直したときの評価を聞いたときの上司の説明でこいつはロクでもない奴だ（自分の選り好みで評価しているという意味）と思ったのだが、その上司は、プラマイゼロの評価だったが『上の役員がプラスの評価だろうというからそうした』と業績評定で言ってきた。

バカである。自分がそう評価した、と言った方が心情は別にしてこちらの感情を変えるチャンスだったのに上司自ら潰したのである。

いいかい、自分の感情を前に出していいときと良くないときがある。得てして、出さないほうが良い時の方が多い。言い換えれば、ポジティブな感情でなければ、仕事の場では引っ込めておくべきだ。

この項目でのポイントは、上司がYESと従わざるを得ない上役と仲良くなっているといいということだ。なんだ、自分には無理だと言わないし思わないこと。何かしら、上司の上に自分の持っているプラスの情報を提供できることはある。

 応援に行っている火消しの概要を話してもいい。関心を持っているのは間違いないし、そうした応援先のマイナスの情報は欲しいのだ（これはこれで闇）。

さっさと次を探す

これが一番。

うちの上司は見た目がいい

進捗がやばくて助けて欲しいときに助けて貰いやすい伝え方

エンジニアのタスクは、情報集めと制約と前提条件を織り込んで、タスクを完了させた状態のアウトプットになるように、処理を行う。

1. インプットは、『情報集めと制約と前提条件』
2. 処理は、１から２に加工する
3. アウトプットは『タスクを完了させた状態』

もし、エンジニア（あなた若しくは困っているチームの同僚）が担当しているタスクで困っていて、アドバイスを必要だと感じたり、実際にヘルプをして欲しいと思ったとき、上記の1から3のどれを伝えると助けて貰いやすいと思うだろうか。

答えは3である。

3を完了させたい。

これがエンジニアの実現したいことである。

でも、往往にして、2のやり方を伝えようとする。助ける方は、2を教えられるから、そのインプットの1に関心が移ってしまう。でも、実現したいことは、3のタスクを完了させることである。

インプットから考えると、アウトプットが決まっていないからどこまでを範囲にしていいか、対象のスコープを決められない。処理から考えるとアウトプットである完了した状態が決まっていないので、処理がfixしない。描けても、概念モデルだけで、中身を描けない。それはアウトプットである、完了させた状態が存在しないからだ。

ここからわかることは、タスクは『タスクを完了させた状態』をイメージできる形で捉える習慣が必要だとうことである。

エンジニアのあなたのタスクの名は、そうつけられているだろうか。

ハリオ カフェオールドリッパー02 1~4杯用 レッド CFOD-02-R

エンジニアがタスクリーダになったときに知っていると助かる5つのステップ

ビジネスオーナから無茶振りされるタスクをもらうと、どこから手をつければいいのか的に迷うのだが、こういったシチュエーションはエンジニアの誰にも起きる。やったこと、経験したことがあれば、過去に自分が何をやったかを思い出せば、だいたい見通しをつけられる。

でも、自分としては初めて振られるようなタスクだと、どうしていいものか、どこから手をつけていいのものか迷う。迷うんじゃないな、お手上げ状態になるんだ。

昨日も、ミネラルウォーターを取りにフロアを歩いていたら、名前が聞こえて、オープンスペースで打ち合わせているBOがこっちを見ている。

どうやら捕捉されたらしい。

近づいて話を聞くと、内心それ分掌かかかかと疑問符が20個くらいつきそうな全社横断のタスクをやって欲しいという。殺し文句は『これプロマネでしょ』だそうだ。

やったことがないからやってもいいよ、と意味深なレスを返しつつ、ざっくり聞くと、やっぱり分掌違いである。まあ、一部のパートは関係する、程度だろう。知っている限りの普通のIT企業なら。

その日のうちに過去資料を読む

 slackで資料共有してもらった（送りつけられた）ので、ざっと目を通す。やってきたこと（あれば）、課題（これからやること）を把握する。

この時点は詳細でなくていい。タスクの主テーマのあたりをつけられれば。それも掴めないときもある。

無茶振りしてきたオーナを捕まえる

今回振られた資料を読むとやってきたことのアップデートとやってこなかったこれまでのスコープ外のテーマがあることを把握できた。

ではどうするか。

振ってきた本人に聞くのが一番である。

ただし、BOなど上になればなるほど、課題感はザクッとしている。スペシフィックな答えはもらえない。そこは、今後の活動を通してコンセンサスづくりをすればいいので今は先送りする。

課題、心配事は何か、と尋ねるだけだ。

キーワードからシナリオの方向性をプロットする（だけ）

BOはスコープ外のことの知識がないという。これは、情報提供して欲しいということだ。

それと誰もやったことがないテーマであることがわかったので、聞く先がない。もしタスクリーダになったテーマに過去事例があれば、それを聞きに行くこと。

今回は、前回の活動のアップデート。これは前回の活動と今との差分でやればいい。

前回スコープ外だったテーマは、コンセンサスづくりをしながら、活動をしていくことになるだろう、といったん、そう決める。

そこを今から考えても仕方がない。なぜなら、初めてみないとわからないからだ。

前回分→差分更新。

今回分→進め方、参考情報、ステークホルダ、時間軸の取り方、マイルストーンをモヤっとした感じで構わないから言語化する。

マインドマップを使うといい。

上役の人脈を確保する

 自分の場合は、BOの直下の上役と話をする。エンジニアであれば、チームのリーダかプロマネかマネージャか。

BOはこういっているけど、課題ってなにかを訊ねる。だいたい、イメージを持っていない。

だからと言って聞かなくていいわけじゃない。色々と組織内にパスを持っているはずなので、それを使わせろと言いたい。

手書きで絵コンテを描く

いつも言っているが、いきなりパワポやスライドを作らない。絵コンテを描く。フリクションペンがいい。

今なら春っぽい色で描く。

それを持って、上役に方向性はどうかと聞く。

いいんじゃないか、というはず（だってイメージないからね）なので、スライドに起こして手をつける。

パイロット 消せるボールペン フリクションボールノック 0.5 10色 LFBK-230EF-10C

チームに必要なのはルールより原則

もし、チームに心理的安全性や挑戦する文化を根付かせたいなら、ルールは作らない。なぜなら、ルールはチームメンバの行動を制限するからだ。

チームのメンバに能力を十二分に発揮して欲しいなら、発揮してトラブルを起こしても、無意識に助け合える共通の価値観がなければ、誰だってスキルを使うことをセーブしてしまう。やらかして、後始末をするよりは確実にできる範囲でしか能力を行使しなくなるのは当然だ。

メンバの誰かがやらかして、再発防止と言い始め、あれこれやめようと言い始める。中学校で散々慣らされてきているから、禁止するルールを作るのはお手の物だ。

もう、そのチームには心理的安全性はない。心理的安全性の代わりにメンバを縛るルールが鎮座する。誰もがルールに自分の行動があっているかと、照らし合わせるようになる。

ルールは心理的安全性ではない。

メンバの行動を縛る。

心理的安全性を根付かせたいなら、ルールは捨てて原則にする。

原則は、チームのメンバ全員で作り上げる。誰ひとり、欠けてはいけない。原則を作るときにチーム全員が一人ひとり、原則としたい考え、思いを言語化する。

出し合った言語の中から、共通項を絞り込む。原則は幾つでも良いが、少ない方がいい。

その原則でチームのメンバがどう行動するかを迷ったとき、原則に照らして判断できればその原則は有効である。

ルールはメンバの行動を止めさせる方にしか働かない。しかし、原則は、原則にあっているなら、挑戦を選ぶことができる。もちろん、やらない判断にすることもできる。

どちらがいいかは単純である。

チームに原則を導入すると無駄な物を作らなくなる。まず、ルールを作らない。あれは禁止、これも禁止などトラブルを起こす度にルールを作る必要がない。

やろうとしていることを誰かに訊ねても、返ってくる答えは、原則にあっているか、しかない。

チームにルールを作るくらいなら、原則に変えよう。

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

yattom.booth.pm