デスマよりひどい寿司と呼ぶには憚られる握りでSAN値がゼロになる

家電は故障し始めると伝染するように故障する。その時期は少し前にまとまってあって、それ以降は小康状態である。適当に世代交代をするような感じだ。

うちの洗濯機は割と長持ちで結婚してから現役は2代目である。かれこれ10年以上毎日何度も運用している。

 

 

f:id:fumisan:20191014103427p:plain


参考画像 これは型番から後継機ぽい。

 

最近、洗濯中に止まってしまうことが多くなったらしく、困っているとワイフから相談があった。

これまで洗濯機を選んでいる。これまで機能としてこれは必要だと言って選んでいるので、困っているなら欲しいものを買ってくれればいいのにと思わないことものないがそれは言わない。

何かこだわりがあるのかもしれないと気を使ってくれているのである。

そうして相談をしてくれたので、早速見に行こうと週末にお出かけすることにした。

ホールセールのお店、つまりコストコとヨドバシどちらにと聞くとコストコ、と。で行ってみたら、型遅れぽいドラム式と多機能の縦型とドラム式の洗濯機。選択肢が少なく比較できないと言うので駅前の大型家電チェーン店に。

昼過ぎに到着したのでお昼をと思ったが不案内なところと台風明けでどこも遅いお昼の時間から営業で、オフィスビルに入っているテナントの洋食店に行ったらかなり待たされそうで隣の回転すしに入ったのが間違いだった。

これは経験的なところがあるので根拠はないのであるが、オフィスビルであたり(美味しい)と思うお店があった試しがない。

それがちょっと脳裏をよぎった。

値段はそこそこ取る店で、店内はほぼ満席で、割りとするっと入れたのでラッキーくらいで入った。

思った以上にお腹が減っていたのだろう。

あとタッチパネル式の注文も行けなかったのかもしれない。

確かめもせずバンバン入れてしまう。

それから待たされる。

それは良いとして。

出てきた鰯の握りの解凍の失敗したような風貌と味。

煮切りを塗り忘れたシャコ。

風味のついた醤油だけの品揃え。

届かない小肌。

極め付けは噛んでも水と生臭さしかしない烏賊の握り。

会計し、小肌はこれからになると言うことでキャンセル。

なるほど、そこそこする値段。

伊豆のクルクルで食べた美味しい鰯の半分くらいを期待していたが0(ゼロ)にも満たない。

これなら個人営業の寿司屋に行くべきであった。

人生は身銭を削って経験すると深く記憶に残る。

実名型のグルメサイトに評価をつけるなら無限大のマイナス評価である(つけられない)。

もしくはnull。

それから夜はずっとダメージを受け続けている。

HPは残っていないしSAN値もゼロである。

口の中におかしい感覚が残るのである。

胃がおかしくされたと思って仕方がなく太田胃散を頓服するも、メンタル的なダメージは回復しない。

 

【第2類医薬品】太田胃散 210g

【第2類医薬品】太田胃散 210g

 

 

身を呈して得る経験は他のものに代え難いし、エンジニアであれば失敗してなんぼではあるが、これはデスマ以上である。

 

前振りの洗濯機は結局コストコに戻って安価なドラム式をチョイスされたのであった。

 

プロジェクトマネジメントは海鮮丼である

もともと土曜日は引きこもってタスクを消化しようと考えていたところに令和ちゃんが15号の続けざまに19号を持ってきた。

 

いくつかやらなければならないことの1つの優先順位を入れ替えて、別のタスクの脳内にあるぼんやりしたイメージを言語化にする。

タスクによっては、いや最近は割とタスクをするときに裏付け的な根拠のための書籍の引用を紐づけておくことをしているので、必然的に書籍を読んだり再読したりすることになる。

それは結局、時間を使うことになるから進捗が想像の1/3まで落ちる。読み直し、言語化までの考える時間、言語化それぞれで時間を必要とする。

プロジェクトマネジメントの知識体系とはストレートに言うとアレである。そうPMBOK

この本でプロジェクトマネジメントを適用するプロジェクト、例えばSIプロジェクトを成功できたらびっくりする。

なぜならこれはプロジェクトをマネジメントする知識とプラクティスの丼なのであって、プロジェクトの目的を達成するためのアプローチ的な方法については書かれていないからである。

プロジェクトの目的を実現するためのアプローチ的なものを作った計画通りに推移しているか、監視、コントロールするのはPMBOKの役割である。

どこの組織でも、エンジニア、非エンジニアに関わらず、プロジェクト、プロジェクトマネジメントは割と聞くキーワードだろう。

それは業務の中でプロジェクト化することが珍しくなくなったと言うか、もともとプロジェクト的な業務をプロジェクトと定型的な業務と分離するようになったからである。

2000年ごろにプロジェクトマネジメントが流行して、割と賞味期間が短く、でも残ったのはプロジェクトを監視、コントロールすることによるメリットがあったからだろう。

プロジェクトマネジメントの丼の中にはプロジェクトの目的を達成するアプローチを実装せねばならず、その上には生産性やプラクティスの具を載せなければならない。さらに、それを美味しくいただくマインドセットが必要なのである。

プロジェクトを美味しくいただこうと思ったら海鮮丼を提供するつもりで取り組まなければならない。

 

 

 

 

令和元年台風19号のメモ

社会、防災インフラは大事。

社会、防災インフラに従事する人も大事。

ソーシャルネットワークNHKの報道がポストされるのでNHKの存在は価値がある。

 

インターネットで常時情報を収集できていたことは大きい。

放射状の高速道路は通行止で遠隔地に避難は無理であることを知る。

台風通過直後の方が風が強く不安を覚える。

隣接する地域で停電が一時的にあった。

自宅、自宅周囲で被害はなし。

ほぼTVは見なくて済む。

 

13日以降、事業継続の復旧計画に着手する組織が多いのだろうと想像。

被災地域が広範囲こととオリンピック対応で回復には相当の時間がかかりそう。

 

 

史上最大の台風の日の成果(途上)

史上最大の台風がきているのに、日がな一日PCを前にしてやっていたのは本社部門向け講座設計である。

f:id:fumisan:20191012182141p:plain

これで得られるものがあればそれはそれで良いのだが、実態はこれからスライドとワーク(ゲーム)を作らないと仕方がない。

 

 

 

 

ドーバー パストリーゼ77 スプレーヘッド付 1L

ドーバー パストリーゼ77 スプレーヘッド付 1L

 

 

実現できるかわからない計画を死守するためにPDCAを頑張るのは何か間違っている

ちょうど、とあるプロジェクトをやっている。全体で見れば年末くらいで一段落つけたいので、そこそこの半年以上のレンジである。

プロジェクトは全社に導入してた業務をある意味リニューアルするもので、仕組みづくりのし直しといった方がイメージはあっているかもしれない。

これはメジャーなマイルストーンを完了させるタイミングで協力をしてくれた関係者に述べるものなのだろうが、なんとなく先にここで書き残しておく方が良いのではないかと思い立ったのでそうする。

あれだ、フラグを自分で立てるようなものだ。

一番関心をしたのは、協力を依頼した全ての方々がとても好意的にいやむしろ積極的に対応してくれたことに関心している。

持ち戻ってどう思っているかはわからないし、依頼していること自体はやらなければならないことは頭でわかっているが、とても手間で面倒な上に業務に差し込む形になるので負担を求める。

であるから、仕事を頼む方としては変にへり下りそうになってしまう。

『忙しいところにこんなことをお願いしてすみません』的な心持ちな変なダークサイドに落ちてしまいそうになる。

そうならないように、依頼することをやり遂げる価値、意味を説明し、メリットをアピールしつつ、対面ではリニューアルした業務の利点、ポイント、理解、価値を単位ごとの組織にインストールしていく。

今思えばこれは教育のキャンペーンだったなと気づく。

このキャンペーンでの説明では何回もしくじり、試行錯誤したことがある。

それは、説明の仕方、である。

実際、50回くらい場を設けて行ったがイメージした通りに進められたは10回程度しかないし、全体の進行としても上手くできたと感じられたのは数回もない。

一見、上手く説明したと思えても、それは参加者のフォローによるところが大きい。

ここまでやってきて、一つの気づきは、PDCAはダメだなということだ。

Pが大きすぎる。

いや、硬直化するのである。

それを死守しようとして過大な負担になる。

それはおかしい。

やりたいことはGOALの達成であり、Pを維持することではない。

実際、このプロジェクトでのGOALは変わっていない。

でも中でのメインアクティビティのアプローチは試行錯誤している。

なぜか。

GOALを達成したいからである。

ではどうやって。

今思えば、OODAループを使っていたのである。

観察→情勢判断→仮説→検証

のループを回していた。

50回。

たかだか教育で、である。

でも、GOALに立ち向かいうならOODAである。

虚構の実現できるかわからない計画というPを死守するためにPDCAを頑張るのは違う。

 

 

アメリカ海軍に学ぶ「最強のチーム」のつくり方: 一人ひとりの能力を100%高めるマネジメント術 (知的生きかた文庫)

アメリカ海軍に学ぶ「最強のチーム」のつくり方: 一人ひとりの能力を100%高めるマネジメント術 (知的生きかた文庫)

 

 

エンジニアを縛る計画思考

シンポジウムやカンファレンスでワークショップをコマとして設けていることがある。定員制で、グループワークが多い。見聞きしない、でも講演のアブストラクトのキーワードに興味を惹かれて受講する。

ワークショップに参加した。初めて会うエンジニアと顔見知りになれたし、ワークは初めてで理解には及ばないが体験としては楽しい時間だった。ワークショップでこれなら仕事で活かせそうだ、と思ったやり方があった。このワークショップはまずまずだな。

そう思うこともあるだろうし、講師の立場の場合はそう感じてくれるだけでも嬉しい。

ところが、そうした気持ちは最短で会場の扉の外に出た瞬間、忘れてしまう。その気持ちが消えず、現場、チームに持ち帰りやってみたいと思うこともある。それでも、チームのメンバの顔を見るとその気持ちが消えてしまったり、諦めようと思う。

中にはその気持ちを自分に向けて、自分の仕事のやり方を変えてみようとするエンジニアもいる。

でも、多くのエンジニアは何かを得て、使ってみようと思っても実際に使おうとしたとき、使えないと感じてやめてしまう。

使おうと思ったときの対象に対して、仕事に対するアプローチとか手法とかマインドとかそういったもので何かを変えようとする。

その対象は得てして、漠としているか粒度は大きい。

  • 生産性をあげる
  • 見積もりの可視化
  • 納期を守る
  •  :

やり遂げられたら素晴らしいことは確かである。ToBeとしても相応しい。

でも、この素晴らしいToBeは実行されない。

いや、できない。

なぜなら、実際に行動に移すとき、粒度が大きすぎるからだ。

『生産性をあげる』ことをやろうと思ったとする。

さて、仕事場で『生産性をあげる』と思い、ワークショップでうろ覚えの記憶を掘り起こし、『生産性をあげる』と思ったとき、手が止まる。

ToBeはToBeのままでは手をつけられない。ToDoへ分解しなければいけない。これが実行されない理由の1つ。

『生産性をあげる』としたままでプランを作ったとする。かなりチャレンジングである。

こうすればできる、

  • なぜならチームはこうだから
  • プロジェクトはこんな状態だから
  • 自分の仕事はここが課題だから

と一人合点してプランを作る。

でも上手くいかない。なぜなら、合点したつもりの前提とした制約条件も前提条件も全ての状況は刻々と移り変わっているからである。

大きな粒度のプランと想定した状況が変わっていることを気づかない。

だから上手くいかない。

こればプランを作ろうとしたときと実際作ったときの変化を考慮していないことと変化に対応できる粒度にしていないことが原因なのである。

 

 

 

井村屋 えいようかん 5本

井村屋 えいようかん 5本

 

 

 

 

 

いわれのない仕事を押し付けられたときに整理する方法

お仕事をしていると、いろいろとあるわけです。自分の担当で終わらせないといけないお仕事や他の方が担当されているお仕事。

組織で働いているので自己完結するお仕事の方が少ない。

団体で働くということは、誰かからのオーダーがあり、何かをインプットとして、加工して、アウトプットし、オーダーをした人に届けるか、次の人に回す。

ときどき、ご自分の都合でこちら(あなた)に接触する方がいらっしゃる。

その理由は、ご自分のお仕事に何かしら関連して、こちら(あなた)に期待をするところがある。

ただ、その期待の現れは、相談か押し付けのように極端に現れることが多い。

それとその期待は、こちら(あなた)は知っている事情のこともあるし、全く寝耳に水だったり、前任者が放置していたことだったり、引き継いでいないことだったりする。

それっぽく四象限にするとこんな感じ。

 

 

        ↑ 知らない事情

              押し付け
←       +        →
相談               
        ↓ 知っている事情

 

 

ご察しのとおり右上は相当面倒臭い。

相手もなぜか強気でコンタクトしてくる、大体。

そういったとき、手をつける前に自分の上司を巻き込んだ方がいい。できれば1on1のようなオープンで相談者が自分だけで上司を占有できるときが望ましい。

 

        ↑ 知らない事情

              押し付け 上司と依頼してきた人の上司を巻き込む
←       +        →
相談               
        ↓ 知っている事情

 

 

なぜなら、カジュアル(無防備に)聞いてもらえるのと、一対一なのでこちらの話に集中してもらえる。

 そのあと、必ず依頼してきた人の上司を交えて依頼の意図を確認する場を持つ。

多分に、依頼してきた人も誰かからオーダーがあってのこと。

その場で、目的を整理するとほぼオーダー内容が変わったりする。

知らない事情もわかったりする。

 これがチーム内だったりしても、押し付けてくるのがリーダでなければ上司をプロマネなどのリーダに置き換えればいい。

 

 

Joker (Original Soundtrack)

Joker (Original Soundtrack)