タイヤ交換奮戦記−コストコのタイヤ付け替え工賃の有料化(2019年9月以降から700円/1本)−

コストコで夏冬のタイヤを買うと夏タイヤ→冬タイヤへ付け替えを無料でやってくれます。

やっとこさっとこ、夏タイヤから冬タイヤに付け替えをしにいったところ、ものすごく申し訳なさそうに

『今日、付け替えた冬タイヤを夏タイヤに戻すときまでは大丈夫ですが、9月以降1本700円かかります』

と話されてまして。

いやいや、手間賃かかっているし。無料の方が良いけれど自分でやる気にはなれない。増し締めするときの負荷を測るツールを買うのもあれだし、いちいちジャッキあげて外して付け直して、それを4本繰り返すのはもういいかな。20代30代だったらやったけど。

ということで、コストコでタイヤ付け替えする人は知っておいた方がいいですよ。

 

 

KTC ( 京都機械工具 ) デジラチェ 【9.5sq】 小トルクタイプ GEK030-C3A

KTC ( 京都機械工具 ) デジラチェ 【9.5sq】 小トルクタイプ GEK030-C3A

 

 

 

社外に出ようと若手エンジニアに言う前に

中堅エンジニアの方や若めのマネージャに若手エンジニアの育成をどうするかを尋ねたことがあった。そのときに多かった意見は、

  • 若手エンジニアがどうなりたいかを知る
  • 社外を見るようにいう

など出会った。前者からは、若手エンジニアの持っているだろう将来像を尊重したいという気持ちを持っていることを確認できる。

ところが、である。2点目はどうして外を見せようとしているのかを尋ねてみるとちょっと予想したこととは違う答えが返ってきた。てっきり、なりたい将来像になりやすいカリスマエンジニアは社外にいるからかと思ったら、そうではなかった。逆説的には正しいのであったが。

ところで、こうしたディスカッションをした方々の所属する組織でのエンジニアのキャリアパスの実情をぶっちゃけて話してもらったところ、実ははっきりと示されていないケースが多く見受けられた。

イメージを掴むためにもう少し踏み込んで教えてもらうと、ほぼないのと一緒なのだという。尋ねた側としては、ITSSv3程度のエンジニアの種別のレーン(あれは専門に分け過ぎているのでやりすぎだと思っているし、エンジニアの育成においては蛸壺に追い込み兼ねないので運用するにはレーンを再度纏めてくくり直す必要があると思っている)があるではないかと誘い水をしてもそうなっていないという。

自分としては、エンジニアのキャリアパスは乱暴に言えばアプリとインフラ程度のレーンとそれにバンドを設ける程度で良いからキャリアパスを示さなければ、組織の中にいるエンジニアの評価を実質できないと考えている。

まあ、組織がフラットで、評価者が一人であればその人がある意味キャリアパスの基準となるわけだが、今風のエンジニアリングマネージャを複数おこうと思った瞬間、評価基準がずれていくことを覚悟しなければならないだろう。

話を戻して、である。

根掘り葉掘り聞いてみると、モヤっとしたエンジニアのキャリアの先にあるのはスーパーエンジニア(表現が古いか)なのだという。とにかく、ずば抜けたトップエンジニアを目指そう、くらいでそこまでに到達するパスも道筋もないのだという。

だから、社外に行き、中間層のエンジニアを知り、途中のイメージ像を作らせたいということだった。

エンジニアの技術や経験は標準化できるようなものではないから、キャリアパスを示したところでそこに書かれている通りには一人も育たないだろう。

それでも必要なのは、組織が必要とするエンジニアのバンドでロールを示すことである。組織は必要とする人材の種類をパスで示し、その実力に応じたロールを示すことでエンジニアのキャリアを示さなければ、必要とする人材もロールも得られないのである。

もし、組織のパスがなければマネージャがたんとビジネスにおけるパスを示し、ロールを可視化した方が若手エンジニアは付いて行きやすいと感じるだろう。

 

好きなようにしてください

好きなようにしてください

 

 

そのガントチャート必要ですか

進捗管理のツールを探されているエントリがはてブに上がっていた。仕事の進捗管理ではなく、個人の進捗管理をされたいのだという。

色々とお試し中らしく、評価されている。

 

maname.hatenablog.com

 

評価のコメントを読んでみる。

残タスクが見えるよりも、スケジュール感や進捗率が可視化されてちゃんと進んでいることが見たいので目的と合わない感じ。
タスクを細かく分けて登録すればよいのかもしれないけれど、仕事でも使ったことがなく勘がつかめない。

ご理解のとおり、タスクの可視化ツールである。12文字で表現すると『カンバンを電子化したもの』である。

やりたいことが出来ないと言われるのであれば、そうですかと認識するが『勘がつかめない』という理由であれば、少し心理的老化を疑った方が良いかもしれない。

#冗談なので真に受けないように。

さて、ここである。

chrome拡張でガントチャート引けるみたいだけれど、それだと自宅でしか見れないので却下。

ここで疑問を持つのであるが、ガントチャートを必要とするのだろうか。達成したい目標を眺める限り、前後関係を持つタスクはないのではないか。ゆるく読書と感想を繋げたくなるが、本数が合わない(読書100冊全ての感想を書くのではなく、24本と絞り込みのプロセスが挟まっているので分断されているタスクである)。

進捗管理と言われているが、実現できれば良いのは

『目標の進度を可視化できれば良い』

のではないだろうか。

どうだろう。

つまり、2018年にで達成できなかった目標は今年こそ『年末までに達成したい』であり、ただ目標の進度の達成が視認できていれば良いのではないだろうか。

そこにはガントチャートは必要ないし、ガントチャートで予実の線を2本引いたとしてもそのあとやるのは、

  • 取り戻しのアクション
  • 目標の(スコープ)の見直し

である。

 

ご提案

trelloで十分。

まだ勘所をつかめていないとのことなので、もし自分が2019年に達成したい目標をtrelloで進捗を可視化するのであればこんな感じで使う例を示そう。

 

カテゴリは、BacklogとToDoとDoingとDoneである。これ以上はいらない。月次に分けたくなるが横スクロールになるため冗長であるし、やっているタスクだけモニタリングできれば良い。

f:id:fumisan:20190111074223p:plain

 

運用上の工夫点は、Backlogはそのまま年間目標としておき、ToDoにそれぞれの目標を管理したいタイムスパンの単位で切り出す。

本来であれば、1タスク1チケットが良い。つまり、感想であれば1感想に2週間割り当てる(trreloではチケットごとに開始日、完了日を設定できる)。ブログは3日(小数点以下は切り捨て)を割り当てる。

 

f:id:fumisan:20190111081952p:plain


さらに、チケットはコピーできるからToDoに次をレディさせておけばいい。読む本の順番が決まっているなら書籍名をいれても良いかもしれない。

タスクが終わったしたチケットはDoneにポイすればいい。

 

チケットのサイクル

あと、目標を見ると定量的な目標もあるが数字の設定のない目標もある(C++とか)。これを仮に1本とするとチケットのサイクルはこんな感じになる。

年次(C++)>月次(ふりかえり)>2w(読書)>3d(ブログ、読書)

フラクタルなサイクルぽくチケットを管理すればリズムを作りやすそうだ。

 

 

 

 

ビジュアル図鑑 自然がつくる不思議なパターン

ビジュアル図鑑 自然がつくる不思議なパターン

 
枝分かれ (自然が創り出す美しいパターン3)

枝分かれ (自然が創り出す美しいパターン3)

 

 

意識高い系でアウトプットを伴っているエンジニアが住んでいる世界

『何を言っているんですか。あなたも意識高い系具側ですよ』
『エェェェェ⁉︎』

 

不本意である。いや、自分が意識高い系だとは思っていなかったので、不意をつかれたというか、そういうことである。

とあるメディアの役員と数人の知り合いと会話をしてたときのことだ。エンジニアの成長や、育成などにテーマを移したあと、よくカンファレンスやセミナー(勉強会など)に行きますよね、という。自分と他の人を比べれば、行かない方であるという自負はある。

ソーシャルネットワークのログに流れてくる書き込みを見ているとそうしたイベントに参加したから、そうしたイベントを開催しているから来いとか入ってくる。それを自宅で眺め、やりたいことをやっている。そうした行動を自負しているものだから、ということもある。今思えば、同席していた方で自己研鑽でそうしたイベントに参加している方が多かったので十把一絡げで言われたのだろう。

そういうことにしておこう。

同席されていた方々の名誉のために擁護すると、その方々はとても仕事ができる。一緒に仕事をした経験はないが、これまで数々の会話で知り得たことや分けていただいた知見やカミソリのような鋭いコメントを思い出せばできるエンジニアだと言い切れる。それだけに、一緒に仕事をするとしんどそうだが、さらに深い学びを得られるのだろう。そのような期待もないわけではない。

いま今その役員の方の発言を考えるに、そういった場で持ち合わせている考えや経験のフィードバックをしていることを見ているからその場にいた方々を『意識高い系』と称されたのだろう。

そうすると『意識高い系』には2つの用法があることになる。1つは認知されている痛い系の方である。

www.weblio.jp

もう1つは、意識高い系でありつつもアウトプットを伴っているケースである。これまで出てきている面々は後者である。この後者の面々は同じ自分と同じ反応をしていたので全く『意識高い系』であるという自己に対する認知を持ち合わせていない。

別の機会にその方々と話をしていて、件の『意識高い系』を思い出し、なぜ、君たちは自分から出て行き、知見を惜しみなくアウトプットするのかを訊ねた。まあ、自分に問いかければ良いのだがそれでは違いを知ることはないから面白くない。

その中で一つ印象に残っている答えがあった。

『日々の仕事で色々ある。試行錯誤するしかない。課題を解決したいからヒントを探している。ヒントはそのまま使えないからまた試行錯誤する。そうした中で「上手くいって且つ楽しい」と思えるときがある。それを共有したいだけだ』

そうなのだ。『やったね!』と『楽しー!』なのだ。それを『これ知ってる?』なのだ。メタ的には(メタの用法の正しさに自信なし)、意識高い系でアウトプットを伴っているエンジニアが住んでいるのは『けもフレ』の世界なのである。

 

 

 

 

 

 

 

あとあと厳しそうな中堅エンジニアと受け身の若手エンジニアとベテランエンジニアのテーマ探し

ベテランエンジニアにちょっと引き上げてやらないとあとあと厳しそうな中堅エンジニアや受け身の若手エンジニアの育成を頼むと大概何をしたらいいか悩み始める。こちらとしては、後進育成自体、ベテランエンジニアの仕事であると方針を出しているので後はお任せする。

マネージャは更新育成をしないのか、だって。育成の機会とコストを持つのがマネージャの役割である。あと、方向性。ベテランエンジニアでもリソースの使い方の意思決定権は職務上持ち合わせていないので、それをデレゲートすることでベテランエンジニアが将来マネージャになり、育成を推進する立場になったときの練習をしてもらう。これも育成なのである。

それで今の機会に仕込んでおかないと色々と厳しそうな中堅エンジニアや受け身の若手エンジニアの育成である。悩んているところを放置プレイするのも忍びないので週次ミーティングの最後の時間で『育成の方はどうか』と相談に乗る。

ベテランエンジニアで育成を任されるくらいであれば、自分なりに技術的な学習の習慣を持っている(週次の機会やチーム内の技術的なテーマのミーティングの中で色々を撒き餌を撒いて情報を集めておくのはそのときどきにどのような技術に関心を持っているかを探るためのリサーチである)を把握している。

何を育成のテーマにするか八方塞がりになるベテランは、自分の関心ごとや自分のキャリア形成をトレースしようとして躓く。ここを気付くまでは基本放置プレイ。とは言え、時間は過ぎていくのでヒントは渡す。

あとあと厳しそうな中堅エンジニアや受け身のエンジニアにも自分からベテランエンジニアと業務としての勉強する時間を使っていいことを伝えておく。ベテランエンジニアがお節介でやっているのではなく、二人で勉強する機会を作ったのでまずは好きに使ってくれと伝える。

ベテランエンジニアに経過を聞くと、最初の数回は何をやるかで結論が出ないことが多い。あとあと厳しそうだったり、受け身だったりとイメージ的にはマイナスの属性を持っているということもある。ただ、そう見えるのは、自信を持って『これは自分でできる』というテーマに出会っていないだけかもしれない。そう思うことにしている。仕事も趣味も自信を持って話をできるテーマを見つけられることこそ続けられることになる。その意味では、ベテランエンジニアにテーマ探しの方法をアシストしてもらっているのである。

ベテランエンジニアであるからエンジニアとして色々と酸いも甘いも嚙み分ける。そうした経験を中堅や若手エンジニアに押し付けでない活かし方があることをやってもらうことも必要なのである。

テーマが決まり、2ヶ月くらい経ったあとにあとあと厳しそうな中堅エンジニアや受け身の若手エンジニアにどんな感じか(嫌々やっているならやめさせるつもりで)を尋ねると目をしっかりと自分の方を見て『こんなことをやっているんだ』と教えてくれる。

 

元・世界1位のサブキャラ育成日記 ~廃プレイヤー、異世界を攻略中!~ (カドカワBOOKS)
 

 

 

三人集まって見積もりの話をする

用事の後、甘いものを補給しようと同行していた方達とカフェに入る。お二人とも30代と見受けるエンジニアの方である。三人それぞれ所属する組織も違うし、業種セクターも違うのだと話しているうちにわかった。

顔見知りであるし、ソーシャルネットワークで繋がっているのでなんとなく興味を持っていることを垣間見ている。それぞれの趣味の話をしたり、IT業界的な話に移ったり、雑多なことについて会話する。

そうした話の中で、見積もりをどうしているかを尋ねてみた。一人は30代と言えどもまだ若い。ただ、エンジニアの経験は所属する組織に依存するから年齢に関係なく知見を持っていることもままある。うっかり思い込みで決めつけると痛い目に合う。訪ねるときは謙虚でなければならない。

前置きはそのくらいで尋ねてみると、想定していた『過去実績』で工数を見積もっているようだ。言葉に自信なさげな感じを覚えたのでも、しかすると見積もりはプロジェクトで担当する範囲や配下のメンバの作業工数くらいなのかもしれない。

もうお一人は、キレッキレの方である。そういう方はご自身も謙虚な物腰で話される。見積もりについてお話を伺うと、製品導入とコンサルティングなので見積もりはあてにならないのだという。強いて言うなら『類推見積もり』かもしれない、とおっしゃる。

話の流れ的に過日の見積もり本についていくつかの問題提起をしてみる。

  • 結局、見積もりは各種手法があるが、使えるのは過去実績による類推見積もりではないか
  • 類推見積もり自体も、過去実績の収集自体の精度が低く信頼性を伴っていないため他の見積もり手法に比べましな方程度ではないか
  • 類推見積もりから、インタフェース数、プロセス数の基準を設けて閾値を設けなければならないのではないか

甘いものを口にしつつ、概ね同意を得る。

この問題提起に至る前に、いくつかの前提を踏まえている。

見積もり手法は、対象となるシステムの構築形態により適合できない手法がある。例えば、パッケージをカスタマイズ、アドオン開発するようなソリューションビジネスの場合にFP法を適用するのはパッケージというブラックボックスの扱いに困るのではないか、などである。

また、PoCの要素が強い製品開発それも試作的なものは見積もりようがなく、スプリントゼロのようなプロセスを踏まなければ当てずっぽうでしかない、などのコメントがあった。

類推見積もり自体も、その実績値の収集の方法はバケツで掬っているようなものだから、間接工数を多く含めており正味での精度は低い、という意見について同意のコメントもあった。

導入自体は微々たる工数であるが、その後の運用での調整とそれから得られるアウトプットから、運用で蓄積するデータのゴミを捨てる補正の工数はギャンブルのようだ、などコメントがつけられている。

類推見積もりでは、単に外部インタフェース数だけではなく、内部プロセス数を設け、閾値として仮置きし、そうした設定値の調整を継続して行う必要があるのではないかとう意見もあった。若干、こうした工夫についてはFP法のノウハウがあるのかもしれない。

こうしたことや過日の見積もり本を踏まえ、一旦整理すると、

  • 誰の立場で見積もるのか
  • 見積もるのは工数か、システム全体か
  • 見積もる対象と見積もり手法の適合性を見極めているか
  • 参考となる過去データはあるか
  • 過去データの精度は把握できているか
  • 見積もりを実行する際のチームのモデルを持っているか
  • 適用技術の習得度合いを把握しているか
  • システム開発手法は確立しているか
  • リスク識別のプロセスで調整を行うか

あたりを踏まえて見積もりの何を話すかを確認しながらでないと噛み合わないような気がする。

ただ、エンジニアにフォーカスされるのは、タスクの工数見積もりであってシステム化にかかる全体の見積もりではないことが多い。

まあ、ケーキを焼くときに材料を計量する工数の話をするのか、調達から焼き上がりまでの総見積もりまでかというようなものなのだが。

 

 

 

TANITA デジタルクッキングスケール ホワイト KD187-WH

TANITA デジタルクッキングスケール ホワイト KD187-WH

 

 

 

 

理解をイメージに変え、理解していないことを知る

昨日のエントリ「SIer思考とサービサー思考を眺める」で1枚の図を描いた。

これである。

f:id:fumisan:20190106142033p:plain

 

実はいきなりこの図を描こうと思ったわけではない。初めは、2枚目のスライドから描きはじめた。元記事の1つ目のエントリを読み、誰のどこの業務について話をしているのか、書き手とブコメの読み手のズレを感じるが読み手は書き手がどこのポジションから見ているかを想像したかを問おうと思ったのである。

 

f:id:fumisan:20190107074224p:plain

 

流れて5枚ほど描いて、6枚目に差し掛かったところで決定的に違うな、と感じた。

こうした『思っていたことと表現していることが違う』という感覚は、実際に描いてみないと得られない。

過去のエントリで何度か、頭でモヤモヤとしているだけでは考えていることにはならないのだ、コピー機から紙を取り出し、ペンを持ってまずは描いてみよう、というのはこれを実感して欲しいからである。

頭の中では整理できていると思っていても図や言葉にすると全くダメだ。なに分、ページ数が多くまとまっていないし、それほどの枚数をかけるようなものでもないはずだ。

円の集合で表現するのではなく、四象限にプロットする方が対比を表現できて良さそうだ。ただ、4つのコマの特性を必要とするので、それぞれに経営者、担当、業務、ITとプロットしてみた。これも4つ埋めるまで4つが相関するキーワードを選ぶまでにちょっと思案している。

元記事の3つのエントリ、1つ目の自分のエントリ、あと、ブコメした方のエントリを行ったり来たりして自分のまとめたチャートで自分が言いたいことを言えているかを見直す。

これが仕事だとノートにラフを描いてからスライドにすることが多いし、一旦、手描きで頭の中のキーワードや図などを吐き出してみるのがおすすめである。

とにかく、描く。

図を描くことでどれだけ理解できていて、どこを理解できていないか自分で確かめることができるのである。文字だけで理解したつもりになってはいけない。読んだ文章がMECEに書かれてるとが限らないし、読み手と同じ立ち位置で書いているとも限らない。また、明示的に書かれていない前提だってあって不思議ではない。

理解をイメージにすることでそのあたりの不整合や欠落している情報を読み取れることもある。

まずは、理解したことをイメージ化してみよう。わかった気でいるより何倍もいい。

 

 

 

小林カツ代と栗原はるみ 料理研究家とその時代 (新潮新書)

小林カツ代と栗原はるみ 料理研究家とその時代 (新潮新書)