Takao Sumitomo

だいたいいつもぼんやりしてるソフトウェアエンジニア。
思考の指針はエネルギー量保存の法則、熱力学第二法則、不確定性原理の3つ。
Github:cattaka

[こすきー @kosukeyPMP]

「バックオフィス系の部署で、のんびり働きたいんですよね」休憩時間に、4年目の後輩がぽつりとこぼした。激務続きで疲れが溜まっていたのか、口調にはちょっとした愚痴が滲んでいた。それを聞いた先輩は少し黙り込み、コーヒーを一口飲んでから、ゆっくり口を開いた↓

[Takao Sumitomo @cattaka_net]

有象無象のエクセルファイルをひっくり返して業務システムに巻き上げるのをやったことあるけど、普通に数ヶ月どころじゃなく時間が掛かった思い出がある。ムズいのはある程度のフォーマットはあるものの、ファイルごとに微妙な差異があるから、結局全部見ないと拾い損ねが出るのよね。

[すこーる🥤 @dropna_nan]

「現場にcsv保管されてるデータをDBにしよう！」
→SQLサーバーはあるがスキーマテーブルはゼロ
→現場ごとにcsvの形が違う
→何のカラムが必要かも現場やPJごとに違う
→将来なんでも使えるスペシャルなDBにして♡
→設計実装全部俺1人
→無茶では？

[Takao Sumitomo @cattaka_net]

@zangiPM これに限らず、組織のコミュニケーションパスがワークしてるかは、蓋を開けてみないと判断できないですもんね。ただ、調べようと問いかけをすると改善してしまって、元がどうだったかわからなくなったりしますががが。まぁ、成果責任を求められる立場だと、どっちゃでもいいのでしょうけど。

[Takao Sumitomo @cattaka_net]

他所のチームで、メンバーから相談が来ないので問題は無いという人がいたので、個別にメンバーに話を聴きに行ったら、単にその人が信頼されてないだけという悲しい事象も何度か見かけた思い出がある。

[PMザンギ @zangiPM]

SIerのPMとPLが本当に怖いのは沈黙だった。

PM「最近メンバーから相談来てる？」

PL「結構来てますよ。」

PM「それなら大変だけど順調そうだね。」

PL「そうですね。相談が来てるうちはまだ安心できます。」

PM「逆に相談がなくなったら危ないってこと？」

PL「はい。本当に怖いのはその時です。抱え込んでいるのか諦めてしまったのか表からは見えにくくなりますから...」

[加藤よしき（新アカウント） @FinalOhhh12945]

会社が傾く過程をいくつか見てきたんだけど、傾くのは現場が経営に怒ったり悔しがってる時じゃなくて、話が通じねぇからどうでもいいやってなった時なんだよね。この「どうでもいい」は、気持ちとして凄く強いし、怒りや悲しみより長持ちする。こうなるとどんな組織もあっさり傾くよ。たくさん見た

[Takao Sumitomo @cattaka_net]

どんな物事でもパルプンテを唱えるしかない状況というのはあるけれど、仮にそれが巧くいったとて、それを成功体験としてはいけない。

[ポスコンちゃん @posconchan]

部下を潰す上司ランキング第1位は、「コーチングとティーチングを使い分けられないこと」だと思います。

よく部下の思考力を鍛えるという名目で「どう思う？」を連発する人がいます。相手の意見を聞いているようで、結局は自分が言いたい結論に誘導する。これを繰り返すと部下は疲弊します。

仕事で「短期的な成果」が求められる場合はやり方をすぐに教えてあげるべきです。「どう思う？」を発動してよいのは1度まで。

思考力がないのは、インプット（経験）が足りていないだけです。

一方でキャリア目標など「長期的な成果」が求められるケースでは「こういうことを意識して仕事してね」という意味でフワッとした「問い」を預けてもよいのです。

[Takao Sumitomo @cattaka_net]

人間、自分が気がついてないことは、一番気がつきたくないタイミングで気がつくものさ。

[naoya @naoya_ito]

AI で現場を改善するぞ → いきなり自動化じゃなくて問題を分析しろ → 問題を分析するために業務フローを整理したぞ → そもそも業務フローに問題あるやんけ → AI 関係なかった

無限に繰り返してる

[PMザンギ @zangiPM]

PMを長くやってきたけど振り返ると本当にいろいろ失敗してきた。

・メンバーの大丈夫ですを信じすぎて炎上した
・自分で抱えすぎて気づけば自分がボトルネックになっていた
・優秀な人に頼りすぎてその人を潰してしまった
・口頭で合意したつもりがあとから言った言わないで揉めた
・全員が納得するまで待っていたら何も決められなくなった
・顧客にいい顔をしすぎてチームを疲弊させた
・遅延を残業で吸収し続けて表面上だけ順調にしてしまった
・90％完了を信じて残り10％で地獄を見た
・問題が起きるたびに会議を増やしてさらに現場を忙しくした
・自分が一番詳しくなろうとして肝心のPMの仕事ができなくなった

PMを始めた頃は失敗しない人が優秀なんだと思ってた。
でも長くやっているとそんなPMはたぶんいないんだろうなと思う。
判断を間違えることもあるし良かれと思ってやったことが裏目に出ることもある。
むしろ厄介なのはPMの失敗ってその瞬間には失敗だと気づかないことが多い。
だから大事なのは一度踏んだ地雷の場所をちゃんと覚えておくこと。
そして次に同じような場所を通るときに、チームのみんなへあそこは危ないよと言えること。
PMの経験値って成功した案件の数だけじゃなくてこれまで踏んできた地雷の数でも決まるんじゃないかと思ってる。

[Takao Sumitomo @cattaka_net]

散歩中に川沿いで休憩してたらボールが流れていった（それだけ）

[Takao Sumitomo @cattaka_net]

二段構えにしていた安全装置の前段がちょくちょくアラートを出しているので確認したら後段も知らないうちに止まっていて、首の皮一枚で繋がっていたことが発覚したので直す。定期点検大事。

[筒井.xls@エクセル関数擬人化本著者 @Tsutsui0524]

叶うといいな…

[広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi]

数字だけが並んでいて、その数字がどうやって生まれるのかが書かれていない事業計画を、たまに見かけます。あれは計画ではなく、願望に近い。

計画の価値は見栄えのいい数字ではなくて、差異が出たときに「どの前提が外れたか」を特定できる構造にあると思っています。目標と施策とチャネルが因果の鎖でつながっていれば、崩れたときに学習が起きる。

崩れること自体は問題ではない。崩れたことに気づけない設計のほうが問題なのだと考えています。

[Takao Sumitomo @cattaka_net]

大昔に自分用のメールサーバーを立てていた頃があったけど、スパムが増えて対応するのが面倒になったのでスパムフィルタのある商用のメールサービスに引っ越した思い出がある

[小柳勝範＠札幌のIT会社の代表 @k_koyanagi_null]

メールサーバを自前で立てるのは非推奨でSendGridやSESを使えみたいな話題に「情けないエンジニアが増えた」とかクソ引用をしているのを見かけた

なんというか、趣味でメール送信してるんじゃないんよな

[Takao Sumitomo @cattaka_net]

自分に責任の無い鉄火場を楽しめる人は、過去に何人か見た。世の中には色んな人がいる。

[あき@NWエンジニア @1NW1581044]

エンジニアで炎上案件に火消しで入った人たちって憂鬱な気持ちで現場入るんですかね。
普通にメンタル病みそうな気がする😓

[Takao Sumitomo @cattaka_net]

主記憶と補助記憶という言い回しが直感的では無いと言われているが、短期記憶と長期記憶のどちらを主とするかと捉えると、短期記憶なしで長期記憶は成立しないので、短期記憶を主とするのは違和感ない。が、今の呼称と比べると名前は分かりにくい（堂々巡り）。

[Haruhiko Okumura @h_okumura]

共通テスト「情報I」のこの問題、しょっぱなのサービス問題のはずが、2点満点で平均0.588点しか取れてない

[Takao Sumitomo @cattaka_net]

油圧ホースって千切れるものなのか、、、

[ディテクター @Detector_2Z]

上司「お前残業し過ぎだからなるべく早く帰ってね」
私「分かりました」
〜定時間近〜
実習生「油圧ホース千切っちゃいました」
私「おおすごい」
上司「台車の車輪壊れたから直しといて」
私「おおこっちもすごい」

[PMザンギ @zangiPM]

コンフォートゾーンを抜け出せって言う人ほど実はずっと同じ場所で同じことを言ってない！？本当に自分の居場所を変え続けている人は他人に発破をかけるより自分の次の挑戦に向き合っているからそんなこと言う暇なんてない気がするんだよね...