悪い習慣をやめる - 室長のひとりごち
最近止めたものに、このブログがある。何を止めたかというと、連続更新を止めた。 これまで体調が悪いときならベッドの中で、旅行のときなら普段どおりに起きてコーヒーを飲みながら毎日書き続けていた。数年に1回くらいどうにも時間が取れないときには、前々から仕込むと無駄に続けていた。 アルファブロガ（死語）からニッチなサイトですねと言われたり、実際にアクセス数は大したことはなく、なんのために書き続けているかと言えば、書くことの素振りでしかない。 ニッチだからこそ、一時期は毎日はてブとコメントをつけてくれたエンジニアがいて、その時期は割と楽しかった。ただ、こちらで書くことがプロジェクトマネジメントやチームビルディングのhow toからシフトし始めるとフェードアウトした。 続けることが閾値を越えるたびに、途中でこのブログをやめようかと思ったり、noteに移るかと思ったりしたこともあったが、結局、惰性と変ん
プロジェクトは課題解決をしなければならないが、チームは課題解決ばかりしてはいけない - 室長のひとりごち
プロジェクトは課題解決をしなければならないが、チームは課題解決ばkりしてはいけない 矛盾しているか、矛盾していないと思うか。 プロジェクトの場合、課題はプロジェクトの進捗上の障害であるから、解決しなければならない。 ことの起こりとして、課題はアクティビティの予実の較差や制約条件の取違もしくは前提条件の未達など、こう進められるはずだ、こう出来るはずだ、が実現しないと見込まれるか、実際、できなかったから課題になる。 であるから、プロジェクトの課題は解決しなければ、プロジェクトはQCDSのいずれかを達成できな可能性がある。よって、プロジェクトは課題を解決しなければならない。 一方、チームはどうか。課題解決ばかりして、なぜいけないのか。 業務の活動には、課題はつきもので、それは運用をしているから生じる。業務運用を設計したときのデザインがもともと悪い、チームの対外が変化して影響を受ける、チームの体制
退職エントリまとめ（2019年4月〜6月） - 室長のひとりごち
2019年版の退職エントリのまとめを作ろうとして4月に手をつけて、後悔をしたので四半期に分けたその 2回目。つまり、2019年の4月から6月分。 四半期の終わり、つまり6月に退職エントリが割とあって、夏の賞与まで待たなかったのだな、と思ったりした。感覚的に、賞与をもらってから辞めるとか多いのかと思っていたので。 その辺の感覚がずれているのはエンジニアの流動性が高まっているからなのかもしれない。そのため、6月だけでも十分多く、斜め読みだけでも時間が溶けていく。これは月刊の方が良いのかもしれない。 月の括りは実際の退職月が違うかもしれないが、まとめていると割とどうでもよくなって揺れが生じてくるのは性格なのかもしれない。その点はご了承の上でご覧いただければ。 fumisan.hatenadiary.com 6月 退職は2016年12月ですが。 note.com 退職後も面倒臭いことになっている増
エンジニアの辞める組織に対する振る舞いの基本 - 室長のひとりごち
エンジニアが所蔵する組織を辞めるときいくつか気をつけておいた方が良いことがある。辞めようとしている組織に恨み辛みがあろうが、サラリーの問題であろうが、超過労働であろうが、上司が気に入らないだろうが、世間いや業界は狭いので立つ鳥跡を濁さずで行きたい。 貫徹まで笑顔で 目的は新しい仕事場で仕事をするサインをして、新しいチャレンジを始める先にある。それを手に入れるために腹立たしいことがおきないようにしたい。 また、離任する組織に対しても良い印象を残す振る舞いは正しい。これを実現するのは笑顔である。終始笑顔で、些細なことがあっても聞き流す。重要なのは初心を貫徹することである。 社内規程を確認しておく 従業員規程、就業規則などを読み込み、社内ルールの流れを押さえておく。法的には退職は2週間前までに伝えれば良く、規則も法に沿っている（はず）。 ただし、退社時の手続きは退社する社員にしか伝えられない。
リーダの野望のないところに共通の価値観は育たない - 室長のひとりごち
スタートアップやWeb系の組織ではミッションやバリューを言語化することで、組織の価値観を表現しているケースをしばしば見かけるようになった。特に価値観の言語化はニュージョイナーへのフィルタリングとして機能する。ニュージョイナーが組織に対して関心を持ったとき、その組織に入った後に価値観の違いにより離れてしまうのは、組織とニュージョイナー双方の時間とリソースを無駄にしてしまう。何より、価値観の不一致によりエンジニアのキャリアで成果がない時期を作ってしまうとしたら、エンジニアのダメージは少なくない。であるから、組織の中での振る舞い、意思決定に対する価値観のズレは極力避けたい。もちろん、旧態の巨大な組織には経営理念や行動規範をおく組織もあるが、それに共感してニュージョイナーが集まるかと言えばそうではない。組織へのブランドイメージの方が大きい。 組織の価値観は、組織の多重構造、複雑性により希薄化する。
チームで採用課題を作る意味 - 室長のひとりごち
以前のエントリで採用のチャネルについて述べた。 採用のチャネルについて こうしたサービスを使う 企業の採用サイトを使う 縁故 推薦（教授など） OBOG インターン生 fumisan.hatenadiary.com リファラル採用推しであるが、どうやら世間も同じようにリファラル採用に傾斜しそうだ。 DIAMONDハーバード･ビジネス･レビュー 2019年10月号 ［雑誌］ 作者: ダイヤモンド社 出版社/メーカー: ダイヤモンド社 発売日: 2019/09/10 メディア: Kindle版 この商品を含むブログを見る とは言え、エージェントレスで転職希望者にオファーする転職サイトやエージェントのパイプラインがなくなるわけではない。リレーションのないエンジニアでハズレ、つまり、チームの価値観やスピードに合わないエンジニアは働いてみないとわからないでは、いくら試用期間を設けていたとしても双方に
付箋紙で溢れるホワイトボード - 室長のひとりごち
後輩「こんにちは、センパイ。どうせ今日もランチはぼっちなんでしょ。私がそんなセンパイをぼっちから助けてあげますよ」 先輩「ん、もうそんな時間か。って、なんだよ、久しぶりに顔を見せるなりぼっちとか」 後輩「だって、周りの人はみんなエレベーターに向かって行きましたよ。だからぼっち。ランチに声をかけてもらえないなんて可哀想じゃないですか」 先輩「キツイんだか、優しいんだか、相変わらずわからん」 後輩「どっちでもいいですから、ランチ行きますよ。お財布持ってくださいね。わたしの分もですよ」 先輩「はいはい。それで今日はどちらへ」 後輩「そーですねー、先輩は何食べたいです」 先輩「さっきまで仕事してたんだから、何も思い浮かばないよ。ほら、連れてってよ」 後輩「しょうがない先輩ですね。いいですよ、私のグルメアプリの『行ってみたい』フォルダを炸裂ですよ」 後輩「どうです、なかなかいいお店でしょ」 先輩「想
エンジニアの採用はどこを見ているか - 室長のひとりごち
エンジニアの自己評価を見るとき、気になる言い回しがある。 『○○をやった』 『○○を達成した』 そう書きたくなる気持ちもわからなくはないが、そう書かれると『それで』と返したくなる（言わないが）。 同じように、中途採用のレジメを読んでいると、エントリいただく方々の多くも、やはり『やった系』の書きっぷりが多い。例えば、 『○○業務プロジェクトでプロジェクトリーダとして云々かんぬんをやった』 などと書かれる。そのあとに、適用技術を列挙されたりする。 果たしてこれで、エントリされている中途採用のご希望を持たれているエンジニアさんとして、どこをアピールされているのだろうか。少なくとも自分にとっては、魅力的に感じられない。 こちらでご応募願いたいエンジニアさんに一緒に解決していきたい業務課題をあげているわけだ。であれば、その課題を解決しれくれそうなエンジニアとまずはカジュアルに会話してみたいと思うので
カンバンあるある病からの脱出 - 室長のひとりごち
カンバンスキーなので、カンバンを使っているのを見ると、どのように運用しているか興味を持つ。 あるチームのカンバンがあるのを知って見たら、これはすごい（褒めてない）と思わず黙り込んでしまった。カンバンを使っているチームの中で、カンバンが機能していればどんなカンバンでも、運用でもいいわけだが、２−３日立ち会って見たら、どうも機能していないし、カンバンを見ながらやっているデイリースタンドアップミーティングも暗い。重力が二倍くらいあるのではないかと思うくらい重い。 自分から見えるDSMの風景は、こんな風に見えていた。 ToDo…チケットの中身が曖昧のまま。Readyな状態になる前にDoingに突入してしまう。 Doing…仕様や完了の定義が曖昧、つまりReadyでない状態のまま突入している。アサイメントも、リーダが割り当てている（これはこれで別の問題があることを認識していながら一方リーダが指名する
エンジニアと出世 - 室長のひとりごち
全く参考にならないと思うのだが、自分はメンバのどこを評価して職位を引き上げているかというところを書こうと思う。なぜ、参考にならないかというと、自分はこのエントリの読み手のマネージャではないからだ。過去に見聞きした範囲や世間話などで知っている限りでは、マネージャも評価の付け方（エンジニア個人のレーティング、担当配下の割り当てなど）はガイドされても、エンジニアの評価のした方は丸投げされているところもある。運用と言えば運用。自分からすれば、その運用がひどいところも箸にも棒にも引っかからない運用もあるということだ。とは言え、自分の運用が良いとは思わないエンジニアもいるだろう。 出世＝収益寄与 エンジニアで出世するのであれば、端的には組織の中でビジネスを引っ張るロールにつくことができるかどうか、と考えている。 担当のエンジニアよりは、プロジェクトマネージャ（単体のビジネスで収益を上げる）、マネージャ
エンジニアの業績評価をやめるべき理由 - 室長のひとりごち
身も蓋もない言い方をすれば、エンジニアの評価なんて必要ない。というか、できない。 できない理由は幾つかある。エンジニアに求められるスキルは広く深さがある。その人を形作る基礎スキルはもちろん、エンジニアが身につけている技術を適用してアウトプットする技術スキルの両方が評価対象となる。 評価対象は、所属する組織の事業により違いがある。事業領域が広ければ、事業として必要とする技術領域は広がる一方、そうした技術の幅は一人のエンジニアでは賄えないから複数のエンジニアでカバレッジをすることになる。結果、同じ事業を一翼を担うエンジニアの担当する技術は違うが、評価は同じ軸で行われる。 そこで持ち出すのが事業への貢献、役割になる。ビジネスでリーダーシップを発揮したか、などを問うようになる。 担当する業務もSI（新規開発）とSO（維持管理）で同等の評価をしない。SIでは新しいビジネス、サービス開発により事業貢献
エンジニアがタスクリーダになったときに知っていると助かる5つのステップ - 室長のひとりごち
ビジネスオーナから無茶振りされるタスクをもらうと、どこから手をつければいいのか的に迷うのだが、こういったシチュエーションはエンジニアの誰にも起きる。やったこと、経験したことがあれば、過去に自分が何をやったかを思い出せば、だいたい見通しをつけられる。 でも、自分としては初めて振られるようなタスクだと、どうしていいものか、どこから手をつけていいのものか迷う。迷うんじゃないな、お手上げ状態になるんだ。 昨日も、ミネラルウォーターを取りにフロアを歩いていたら、名前が聞こえて、オープンスペースで打ち合わせているBOがこっちを見ている。 どうやら捕捉されたらしい。 近づいて話を聞くと、内心それ分掌かかかかと疑問符が20個くらいつきそうな全社横断のタスクをやって欲しいという。殺し文句は『これプロマネでしょ』だそうだ。 やったことがないからやってもいいよ、と意味深なレスを返しつつ、ざっくり聞くと、やっぱり
成長が停滞している中堅エンジニアに手を差し出せるマネージャになるために - 室長のひとりごち
目標管理での業績評価を伝えたり、目標設定でのスキルの育成計画の元となる評価を話すとき、キャリアが滞留しているエンジニアに一つの特徴がある。 エンジニアに必要なスキルは2つに分けられる。1つは基礎スキルで業務を推進する能力やリーダシップのようなエンジニアの行動様式を構成するスキルだ。もう1つは技術スキルで方法論や適用する技術そのものを習得したり適用するスキルになる。 目標管理でもOKRでもエンジニアのスキルの成長のための目標を設定する際に大事なことの1つに現状を客観的に観察できるか、というポイントがある。現状認識をあるがままに捉えられるかどうか、これを過小でも過大でも甘く捉えてしまうと設定する目標の位置を間違えてしまう。 目標設定を低くしてしまえば容易に目標達成となるため、成長ののりしろはほとんど得られない。目標を達成するために掛けた期間が無駄になってしまう。方やとても高く目標を設定してしま
メンタルダウンの部下を持ったら - 室長のひとりごち
なんとなくタブーな気がしないこともないけれど。でも現場にはメンタルダウンしてから復帰しようとしているエンジニアもいれば、まさにメンタルをダウン仕掛けているエンジニアもいると思うのです。でも現場のエンジニアもマネージャもメンタルダウンの専門知識はないからどうしていいのかわからない、とも思うのです。 突然複数のメンタルダウンの部下が ある組織のマネージャになったんですね。そこそこの規模の組織だったのですが、着任後、人事関連の方から呼び出しがありまして。 「あの方とその方とあと…はメンタルダウンなんですよ。それで…」 まあ、そうなんだ、としか言いようがないですよね。病気ですから病気と付き合って仕事をしてもらうんだな、他の疾病もそうだし、みたいな感じしかリアクションは取れないんですよ。 マネージャは病気の専門家ではない 人事関連の方の説明を聞いて自分に言い含めたのは、自分は専門家ではないということ
部下を無能ということに躊躇わないマネージャは無能である - 室長のひとりごち
情報収集と言うソーシャルを徘徊といってもはてブかtwitterかfacebook程度をチラチラと眺めているだけで、そんなことに時間を使うなら本の１冊でも読んだほうがいいのはわかっているけれど、ちょっと本を読むまでの気力がないというか。これも立派な言い訳なのだが。 ソーシャルを眺めているのは何か気づきが得られるというかインスピレーションが湧くキーワードを探しているのだ。それはわかっている。だったら積ん読の山を崩したほうがいい。それもわかっている。ただ、本を読むのは電車の中でが一番好きだ。これもまた立派な言い訳である。 無能を.する意味 昨日だったか、目についた記事は無能へペナルティを課しても組織から一掃されない的な話で、流しながら読めば、目新しいことは何一つない。パレートの法則やらドラッカーが引用されている。 blog.tinect.jp 記事の中では無能をクビにすることが極論として出ていた
理想のマネージャ - 室長のひとりごち
誰にとっての理想のマネージャなのかという観点を忘れてしまうとこのようなテーマを扱うと議論が発散してしまう。 組織 → マネージャ ← 部下 ↑ マネージャ自身 少なくとも３つの視点がある。視点というよりは立場、である。組織は組織としてマネージャに対する期待を持っているし、部下は部下でマネージャに対する期待を持つし、マネージャはどのように振る舞うことがマネージャとして良いのか悩み続ける。 またマネージャ自身も自分の上にマネージャを持っていて、自分自身が部下の位置になる。その意味では、マネージャは2つのロールの立場で物の見方を暗黙に要求されていることになる。 部下としての理想のマネージャ 部下から見たときの理想のマネージャ像は、なかなかこれだと1つには絞りきれないだろう。マネージャと部下は１対Nの関係になるため、一人ひとりの部下であるエンジニアの理想を尋ねれば、尋ねたときに部下が関心を持ってい
SIerもいつか潰れる - 室長のひとりごち
学生のとき、会計学を履修した。なぜ、履修したか、その理由は覚えていない。必修科目だったのかもしれない。いずれにしろ、履修した割には退屈な印象しかなかったのは、その程度の理解力しか持ち合わせていなかったということでもある。 ただ、1つだけ覚えている言葉に『継続企業の前提 - Wikipedia』がある。 継続企業の前提（けいぞくきぎょうのぜんてい）とは、企業が将来にわたって無期限に事業を継続することを前提とする考え方のこと。ゴーイングコンサーン（going concern）とも呼ばれる。 引用 同上 つまり、企業は潰れない前提で事業をしているといことである。ところが実際は倒産する。 2017年の倒産件数は8405件ある。 www.tsr-net.co.jp もちろん、IT企業も含まれているのだろう。 で、である。 www.businessinsider.jp ベゾスの発言を知って、そりゃそう
人月の神話、ウォーターフォールとアジャイル開発とエンジニア - 室長のひとりごち
人月の神話 は、旧版で読んでいて気づきのあった書籍である。ある意味、エンジニアなら誰でも通る道の類の本であるから、書かれているブログエントリも多いのだろう。 サムネイルが印象的なエントリがあり、ざっと読んでみると、本を読み、記録を残しておくことはやはり良いことなのだろうと思う。 motohasi.hatenablog.com 書かれている記事の中で『そうだよな』と思うところと、『そうでもないよ』と思うところがある。『そうだよな』よりは『そうでもない』方がやはり気になる。 例えば、下表をまとめられている。 世界観 ウォーターフォール アジャイル 科学アプローチ いわゆる古典的科学 いわゆるシステム科学・生物学的アプローチ 全体と部分 全体は部分の集合によって説明可能 全体と部分は異なる性質を持つ 認識 変化しない 変化する 分離・分類可能性 分離可能 分離不可能・分類困難 事実・真理 事実・
そして要件定義をできるエンジニアはいなくなる - 室長のひとりごち
要件定義では要件を決める。少なくともシステム化要件を知らなければ、システム方式や実現仕様に詳細化、展開しようがない。 ところが、システムが何世代も続くと要件定義をせずに、基本設計からとか、詳細設計からプロジェクトが始まることがある。こうしたやり方を繰り返すと開発者のエンジニアサイドに弊害が起きる。 何が弊害となって困るか想像がつくだろうか。 いくつかの改修を繰り返してしばらく経つと、途中から人が入ってくる。特に、大規模なシステムや数年経ったパッケージ開発ではよくあることだ。そうした環境下で中途参画してくるエンジニアが入ってくれば、まず、業務説明をする。 その業務説明では、こんな風に業務は説明される。 『こうなっているので』 『これがこのプロジェクトのルールに決まっているから』 経緯は一切説明されない。 これが拙い。『なぜ』がないのである。 気づきの感性を持っているエンジニアはそこに違和感を
カンバンおじさんvs子どもさん - 室長のひとりごち
実は、一度、件のブログを読んでこれは『いかんやつだ』と思いつつも流してしまっていた。それをもう1度目にする機会があり、読み直してみたら、やはり『根本解決にはならないのではないかなー』と思った。 そんなことを感じつつ、『顧客が本当に必要だったものは』を思い出してしまった。 で、これが件のブログ。 backlog.com 可視化ツールであるバーンダウンチャートは使いたくなるんですよ。可視化したい病に罹ると。気持ちはわからなくもないし、バーンダウンチャートを選ぶこともやってみることも悪手ではない、と思う。 ところで、我が家でも子どもの夏休みの宿題だか、お受験のダイニングでカンバンを使ってみてはどうかと子どもにご提案したことがある。 我が家では皆ダイニングに集まる習性があり、ちょうど、白く広い壁があるので『カンバンにはもってこい』な環境なのである。 そこでカンバンおじさんがムクムクと登場するのであ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
