on

チームを自律させた次に目指す先は変動組織へ

エンジニアのチーム運営は、プロジェクトマネージャやマネージャのトップダウン的な指示からチームに権限をデレゲート、つまり、権限移譲することで裁量を増やしてチームが自立し、さらに自律へステップアップする方向に遷移するのが当面の目標だと思うので…

PM「なんで毎日進捗確認してるかわかる?」SE「…」

はーい、ここでみなさんに次の質問に適切な選択肢を選ぶか、答えていただきまーす。さあ、どうぞ。 Q「なんで毎日進捗確認しているかわかる?」 A1「(エンジニアが質問を守らないからかな?)」 A2「(わからない、知らない)」 A3自由回答「 」 進捗を…

エンジニアだもの、業務時間をハックして勉強時間を確保しよう

ライフワークバランスはだいぶ死語になってきましたが、働き方改革がまだ息をしている間に業務時間をハックして、エンジニアに必要な勉強時間を確保しましょう。 エンジニアはどうして勉強しないといけないの それはね、新しい技術や技術の更新速度が速く、…

チームのゴールとエンジニアの働くモチベーションのギャップと対策

チームのゴール設定はマネージャ(が考えていればマネージャ)のミッションを実現するためにミッション最適化で方策を考え、チームのゴールとしてチームのメンバに 「この(マネージャが考えた)ゴールを目指そう!」 と年度始めにやるわけです。で、 「じゃ…

常駐はプロジェクト適用技術の最適化で技術力をスポイルしてしまう

中堅くらいまではある時期を除けば、ほぼプロジェクトから抜けるたびにプロジェクトルーム若しくは客先が変わるので勤務地が移っていたんですね。 プロジェクトが変わると通勤経路が変わるのでそれはそれでそのプロジェクトに参画しなければ経験できないこと…

お勧めできないエンジニアの頑張れる限界点の見つけ方

タイトルからやばそうなのでお勧めしませんが、自分なりのどこまで頑張っていいのか、その一線を越えたら無責任に仕事を放り出してしまうかもしれなよという限界点の見つけ方のご紹介です。はい。 やばい体験 20年くらい前にひどいプロジェクトがありまして…

エンジニアのないない疑惑

システムは事業上の課題を解消するためにある部分をシステム化により解決手段を実現するわけですが、どんな要件であるか事業上の課題を持っている事業主体です。情報子会社でもSIerでも事業上の課題は自分のものではないのです。 ここに要件のオーナとそれを…

積み本

2番目のから読んでみようかなー 自衛隊メンタル教官が教える 折れないリーダーの仕事 作者: 下園壮太 出版社/メーカー: 日本能率協会マネジメントセンター 発売日: 2017/03/24 メディア: Kindle版 この商品を含むブログを見る 自衛隊メンタル教官が教える …

介入とフィードバックは次元が違うよ

on

あるプロジェクトがあって、プロジェクトはプロマネに任せていたけれど、立場的に顧客との会議は出席しなければならないので必然とプロジェクトチームの仕事ぶりの一部を観察することになるのです。 傍観を決め込む もちろん、出席する会議は進捗会議です。…

ベテランエンジニアの能力開発

on

若手や中堅のエンジニアであれば、仕事上スキルを身につけたり、スキルレベルを上げていかないと仕事にならないのである意味、放置していてもどうにかなるんですね。 でも、ベテランになってくると持っているスキルでどうにか仕事をやってしまうケースが多々…

育てたようにしかエンジニアは育たない

最初、別なことを書いていたけれど、別なことが頭を過って、そっちの方が書きたくなったので書き書けを気持ちよく消して書き直し。 最近のテレビ番組の凋落ぶりがひどいのは周知の事実で、特にバラエティ番組は一般にしてはいけない、いじめや不快なコンテン…

素直に話を聞く価値

on

仕事をしていて、やっとここ最近は仕事が少しはましにできるようになったと思えるようになったのですが、何を変えたからそう思うようになれたのかというと、素直に周りの人の話を聞くようにしたことを1番に挙げます。 ずいぶん前に、顔見知りの同僚に「武闘…

チームを成長させるための6つのテーマ

on

ここ1−2年かな、チームについて色々な取り組みを共有するケースが多い気がするのですが。例えば、心理的安全もその一つだし、このブログでも時々取り上げているような気がするけれど。 多分、それは今まで以上に少人数で、短期間で、より高い成果がチームに…

天はエンジニアに二物を与えず

on

天はエンジニアに二物を与えず 経営者にもしかり 経営者が求めればそれは無い物ねだり 天はエンジニアに二物を与えず 経営者にもしかり 経営者が求めればそれは無い物ねだり / “スタートアップベンチャーはスーパーエンジニアを求めるけどエンジニア界隈と起…

モブが潜在的な問題にスポットライトを当ててくれる

on

モブの良いところは、タイプする人(ドライバ)はキーボードを打つだけ、モニターを見てアドバイスをする人(ナビゲータ(ドライバ以外))は何を打てばいいか教えることと役割を分担するんですが、全員でアウトプットに関与できるんですね。 モブのいいとこ…

Kindle本50%OFF大型セール エンジニア向けビジネス4冊

on

ビジョナリー・カンパニー 時代を超える生存の原則 作者: ジムコリンズ;ジェリーポラス 出版社/メーカー: 日経BP社 発売日: 2014/08/29 メディア: Kindle版 この商品を含むブログを見る ビジョナリー・カンパニー2 飛躍の法則 作者: ジムコリンズ 出版社/…

資料作りはトップダウン志向の方が断然早い

on

ちょっと年次が上だと思う(同僚でも部下でも年齢とか全く興味がないので確かめてもいないで…)メンバにアサインした仕事がどうも怪しい。 状況証拠として、以前にも資料作成を任せたとき 「期待するようなイメージとは違うな」 と感じていましたが、出来上…

普通に終わらす方を評価しよう

on

togetter.com プロジェクトXは嫌いではないけれど、録画したり、時間を確保してまで見ようとは思わないですね。取り上げられるテーマに興味がある場合、例えば杜氏だとか自分の興味がある場合だけ録画する程度なので1年に数回あれば見た方なんですね。 なん…

タックマンモデル(動乱期と安定期)が混在したままチーム運営せざるを得ないのが今のプロマネの限界なのではないか

on

PMBOKなんてデカくて重いし、改訂の度にページは増えるし、なので滅多にpdfを開くこともよほどのことがない限りはないのですが、タックマンモデルというチーム育成のモデルの初掲載はいつだろうと調べてみたら「PMP資格取得に向けてPMBOKガイド第4版を解剖…

エンジニアの2つの学習

on

エンジニアを続けていくためには、技術習得を続けますよね。これを前提にしますがこの前提に対しては肯定していただけるのではないかと思うのです。 まず、新卒の学生若しくは別の業界から何か勘違いがあって中途でシステムエンジニアとしてのリクルーティン…

5年後に達成したいキャリアプランを持続するために

on

20代なら40年、30代ならあと30年は働き続けないといけない。アラブの石油王に見初められるとか、自宅の庭から油田を掘り当てるとか、でもなければ。 ただ、エンジニアは面白い仕事なので大丈夫。ここに30年くらい続けているおじさんエンジニアもいるので。他…

兼任のチームと技術への弊害

on

チームで活動するのに専任と兼任のどちらが良いかを問えば誰しもが専任を選ぶんですね。じゃあ、実際はというと専任の方が良いのはわかっているのに兼任でアサイメントしているマネージャが多いのですよ。 人月商売だと兼任は起きにくい これ、忌み嫌われる…

エモいWBSの直し方

on

「フェーズの始まり毎にWBS作るの面倒ですよね、センパイ」「必要なんだからしょうがないだろう。ほら、今日のうちに終わらせちゃおう」「だって、正直適当に作っているじゃないですか。やっているうちにだんだん変わって行っちゃうし」「え、適当に作ってい…

SIerの大企業病の兆し

on

SIerだって大企業病に罹患するし、一度罹ったら二度と回復することがないだろうな、と思うのですよ。御多分に洩れずね…。 大企業病に陥りやすいSIerっの特徴ってあるのかしらと思いつくままに挙げてみると…こんな感じかしら。 ・真面目・ノーと言えない #真…

進まない目標は定例会議の時間内でやってしまおう

on

チームのメンバが設定する目標管理の中に直接業務に関わる目標の他に、将来の種まき的な目標も設定しているのですが、目の前の業務ではないためについ先送りして中々手がつかない時期が続くと、当事者のメンバもなんとなく今はいいかと、自分で自分を流し始…

さぁ、エンジニアのくせに祈った罪を数えろ!

on

エンジニアの不思議な行動様式の中に「祈る」というものがあります。 エンジニアの祈りの例 エンジニアの祈りとはどんなものであるか具体的な例があった方が良いでしょう。以下に祈りの例を懺悔の形態で示します。 --ここから懺悔 正直に話せばエンジニアに…

大器晩成のエンジニアの方がいいのかもしれない

on

と書くと3年寝太郎をイメージして「大器晩成のタイプだから」と何もせずに日々過ごそうとしているエンジニアを助長してしまうのではないかと思わないこともないけれど、大器晩成の解釈はどうやらそうでないようです。 anond.hatelabo.jp で引用されている 「…

エンジニアにありがちなプロダクトアウトな提案思考を変えるためにかかった期間

on

標題だけで37文字。長いです。長さはさておき、エンジニアが提案しようとするとついつい担当する技術エリアや事業部門で取り扱う製品名を前面に出して語るわけです。ろくに要件も聞き取る前から。まあ、仕方がないのかもしれませんけど。そなってしまったの…

会議をそろそろ機能させて意義ある時間に変えよう

on

巷では会議は無駄な時間らしいですね。過去のエントリを読んで改善の参考にしてしていただければ幸いなのですが。 何でもかんでも会議と名前をつけているから会議の時間が無駄だと思うようになるし、意思決定に関与する当事者でない出席者にまで出席を要請す…

価値判断基準のリトマス試験紙を使って業務を設計する

on

「ボリュームのある繰り返し作業をするときに何から手をつけるか」 エンジニアに生産性の観念があるかどうかを確かめたいなら。ボリュームの作業をするときに何から手をつけるかを尋ねてみよう。 この質問に対する答えで生産性、効率、手戻りというムダに対…

エンジニアとして判断するためのコンパスを持つメリット

on

目指す将来像に近づくためには、漫然と日々をやり過ごしたりタスクに追われていては一歩でさえ近づくことは難しいです。それは行動の判断基準が手元にない状態で仕事をしているからです。そしてその行動の判断基準を作ることは容易くはないのです。 仕事が向…

意識してリーダになるための2つの大切なこと

on

担当エンジニアからサブリーダ、SEリーダ、プロジェクトマネージャそしてマネージャと組織の中で経験を積み適正として問題がなければどんなに遅くても中堅程度の経験を積めば組織は一担当からリーダとしての役割、つまりロールとしての貢献を期待するもので…

余命1年と宣告されたらエンジニアとして何をするか

on

年齢的に棺桶に首までとっぷりと浸かっている状態であるし、定年の年齢もそこまできているし、厚生労働省が年金受給年齢の見直しと雇用延長を延ばさなければ、そちら側へ赴く日はそう遠くないのです。 死に対する価値観は割と池波正太郎の小説で固められた感…

新規プロジェクトをこれから始めるなら導入したいプラクティス

on

新規にプロジェクトをこれから始めるならプロジェクトマネジメントとして導入してみたいツールやプラクティスって何だろうなぁと思いつくところを書き出してみよう。 プロセスデザイン VSMによる作業プロセスの検証。検証しなくても大丈夫だと思うけれど、思…

会社に依存しない働き方

on

www.bloomberg.co.jp 出だしの引用は事相を踏まえた例だけれど、東証一部上場企業の業績としてもここ数年稼ぎ頭に復活した事業部門が経営の尻拭いのために売却されるといニュースを横目で見ていると会社に依存した働き方をしているとしたらその梯子を外され…

コードが神様ならエンジニアは創造主になり得るか

on

モブプログラミングでは、タイプするエンジニアに周りのモブが憑依しつつコードを書いていく様はまるで神が降りてコードを創造しているのではないかと思わなくもないけれど、コードが神であるという考え方はモブプログラミングに陽の目が当たる歴史以前の、…

全てのプロジェクトでコミュニケーションに起因するトラブルの芽を抱えている

on

プロジェクトがトラブルを抱える理由に必ずあげられるのはコミュニケーションです。それについては何度かこのブログでも取り上げていますが、この点についてエンジニアであれば違和感を持つことはないでしょう。ただ、これから述べることについてを除いて。 …

機能するチームを実現するために必要な価値判断基準

on

チームを作る理由はこれまでのエントリで好きに書いてきたように、組織の中で期待されている分掌に応えるために人的リソースを確保することで体制を構えるのです。 通常、業務を止めないとか仕事量とか多くの技術的知見から複数のメンバをチーミングし、プロ…

エンジニアはキャリアを自ら選びマネージャは支援する

on

これまでエンジニアの育成に対するマネージャの支援のあり方について書きたい度に書いてきたように、エンジニアはキャリアを自ら選び、マネージャはそれを支援することが結果的に組織の成長に寄与すると思うのです。 そうした背景からいえば、当たり前だよね…

生産性の速いエンジニアと思わせたいなら

on

なかなかキャッチーなタイトルですよね。生産性が何について語ろうとしているのか、生産性は高低じゃないのかと突っ込みどころ満載ですけれど。 仕事をアサインしている側の視点 仕事のアサインは担当から決められているケースも自分からタスクのチケットを…

働き方改革と換金する尺度

on

どこもかしこも働き方改革ですね。まあ、国が旗を振っているからですが。本来は長時間労働時間の削減から労働環境の改善を狙っているのでしょうから歓迎される活動であることは間違いありません。方向性を間違わなければ。 間違った方向 誰でも思いつくのは…

怒らないための3つのこと

on

昨日、怒る人の行動についていくつかツイートしたところ、割と反応があったのは日頃から怒る程度はあるとしてもそうした人と接することが多いいのだろうかと思ってしまうのです。 その、昨日いくつかツイートしたうちの一つがこれ。 得てして、怒る方が情報…

プロジェクト管理は誰がしたいのか

on

プロジェクトマネージャのお仕事は、管理をすることではない、と常々思っているのです。 プロジェクトマネージャはプロジェクトの目的を達成するためのリーダなのです。そこにプロジェクト「管理」と言葉を充てるからエクセルと睨めっこを始めたり、トップダ…

エンジニアとして労働集約的な働き方と小さく早く小回りの利く働き方のどちらを選ぶのが良いのか

on

メンバのエンジニアに失敗を恐るなと言ってもあまりその言葉に効果は生まれないでしょう。なぜなら、失敗して良いと言っているのが期末の評価者でもあり、評価をされるメンバからその時になって失敗したことを持ち出される可能性を捨てきれないからです。 反…

書き始めれば終わる

on

何かを加工して誰かの目に触れないと終わらない作業は、頭の中からいかに早く出してしまうか、それ自体を頭で考えずに書き出してしまう行動をとることが最善です。 「いいから書くんだよ」 ということです。 頭の中でぐるぐるとああでもない、こうでもないと…

利用から作り出す方へ

on

ある平日の夕方、時間的には定時後にピンポンダッシュするくらいの感じで某所に数人のエンジニアが集まっているのを横から見たら怪しい集団の悪巧みに見えたかもしれないのですが、当人たちは全くもって自覚はないのですけれど。 その際に出た話題の延長線上…

ウォーターフォールの難しいところ

on

特段、プロジェクトの特性がなければ無意識にシステム開発手法はウォーターフォール型を選んでいるものです。まあ、場合よってはプロジェクトの特性に気づかずにウォーターフォールを選んでいるというケースの方が多いんじゃないかと思うのですが。 標準の型…

課題 阿藤さんが1.0、伊藤さんは1.3、江藤さんは0.7の処理能力がある。 チームのひと月当たりの処理能力を1.0とした場合、将来懸念されることを書き出しなさい

on

1人で作業をしているのであれば、作業が遅れても能力の問題なのか作業見積もりの甘さが起因しているかは割と曖昧に処理されるけれど、2人、3人と人数が増えてチームになると人の比較が生じるので無意識に作業の処理能力が比較されるようになります。阿藤さん…

工程の中の品質

on

エンジニアの品質に対する捉え方は、同じプロジェクトのチームで活動しているのに様座です。それはここのエンジニアが参画してきたプロジェクトにおいての品質に対する考え方がバラバラだったからです。 共通して言えること システム開発でもプロダクト開発…

一生エンジニアでいるために

on

システムエンジニア35歳定年説が本当であれば、すっかり定年済み、と表記したほうが良いのかもしれません。実際に、プログラミングなんていつが最後だったか…。幸いにもエンジニアの仕事はプログラミングばかりではなかったのでこの業界に残り続けていますが…