調達予定 SURE ワイヤレス リケーブル Bluetooth SE RMCE-BT2

SHURE ワイヤレス リケーブル BTシリーズ Bluetooth SEシリーズ用 交換ケーブル MMCXコネクター搭載 RMCE-BT2 【国内正規品】

進捗が終わったかと借金取りしても終わらないよりReadyな状態にした方が確実に進捗する

プロジェクトマネジメントで言えば、統合管理プロセスの中のと言い始めると開発現場での感覚とずれていくのは何故なんだろうか。やはり、プロジェクト管理と訳され、製造するという感覚を引きずっているからではないか。

某氏との会話でもプロジェクトが始まったら、プロジェクトの終わりまではリスクマネジメントをするものであり、『リスクのコントロールこそプロジェクトマネジメントだ』という意見に同意するのは、PMBOKの統合管理プロセスとう言葉の言い回しにフィットフィット感を覚えているからだろう。

それはそれとして、予定したタスクが予定した期日に終わらない。終わって欲しいと（勝手に）期待しつつも（メンバは）終わらせてくれない。

それで管理という名の終わったという言葉の取り立てが始まる。要は、進捗管理である。

• 遅れているじゃないか。
• いつ終わるのか。
• 今日中に終わるよね。

こんな会話をしていたら、終わるものも終わらない。

一度、どうしたら終わるかをこんな風に質問してみてはどうだろうか。

『全くの制限ない前提で、何が揃ったら、予定した期日に終わるか教えて欲しい』

回答に詰まったら、全く何も考えていないのでいつまでたっても終わらない。担当を変えよう。もちろん、そのエンジニアはご退場願おう。

辿々しくても、必要だと並べてくれたらそれを用意しよう。必要だというほとんどのものは、仕様に絡むものだ。作業を始めようと思っても、必要なインプットが揃っていないから途中で作業が止まってしまうのだ。

それは本来なら作業を始めるには、Readyな状態になっていないだけなのだ。着手してもインプットが足らないから、作業中にインプットを揃え始めようとする。調べ始めるといつの間にかに調べることや調整事項が増えてしまい、スケジュールオーバーラン担っている、だけなのだ。

Readyな状態にするためには、１つだけすればいい。

作業を小さくすること。

時間は難易度と担当するエンジニアのスキルレベルに依存するので目安でしかないが、4時間程度で終わるとか、2時間とかくらいまで分解する。

もちろん、割り込みされない前提で。

大きなチャンクのままで作業を渡してタスクが終わったかと借金取りをするより、始められる条件に時間を掛けた方が100万倍いい。

なにせ、始められるReadyな状態なのだから不慮のインシデントでもない限り必ず終わる。

これは、プロジェクトマネージャなり、リーダのエンジニア自身が自分の価値観を変えないと誰も乗ってくれない。

【Amazon.co.jp限定】ボヘミアン・ラプソディ 2枚組ブルーレイ&DVD (特典映像ディスク&オリジナルTシャツ付き)[Blu-ray]

エンジニアと出世

全く参考にならないと思うのだが、自分はメンバのどこを評価して職位を引き上げているかというところを書こうと思う。なぜ、参考にならないかというと、自分はこのエントリの読み手のマネージャではないからだ。過去に見聞きした範囲や世間話などで知っている限りでは、マネージャも評価の付け方（エンジニア個人のレーティング、担当配下の割り当てなど）はガイドされても、エンジニアの評価のした方は丸投げされているところもある。運用と言えば運用。自分からすれば、その運用がひどいところも箸にも棒にも引っかからない運用もあるということだ。とは言え、自分の運用が良いとは思わないエンジニアもいるだろう。

出世＝収益寄与

 エンジニアで出世するのであれば、端的には組織の中でビジネスを引っ張るロールにつくことができるかどうか、と考えている。

担当のエンジニアよりは、プロジェクトマネージャ（単体のビジネスで収益を上げる）、マネージャ（担当ビジネスで収益を上げる）というようにロールを上げることが出世だろうと思う。その先もあるがここでは端折る。

組織の活動で収益を増やしたのだから、ロールの中でのレーティングを上げろ、と言い換えても良い。

ロールを上がる条件

エンジニアからいきなりマネージャのラインは考えにくい。少なくとも小さなプロジェクトであってもプレイングマネジャで実績を重ねているからマネージャに引っ張るのだろうし、自分も引っ張るなら、任せるビジネス領域を任せてもやれると見切れるか、フォローのポイントを押さえて（要は、チャレンジされるけど支援する前提）なければ任せられない。

プロジェクトマネージャもそうだが、やれると見切れているからアサイメントするわけで、そこはマネージャもプロジェクトマネージャも同じである。条件をつければやれそうだと思えばアサイメントするがそれは誰がフォローするか体制を作れれば、である。

つまり、アサイメントする側の考えとしては完璧な人材を求めているのではなく、できると思えるかどうか（ただし、マネージャは組織のロールのため空き席を作れないとアサイメントできない）という観点で決める。

マネージャに比べたら、プロジェクトマネージャなら案件があれば機会は遥かに多い。

実はそれほど競争相手は多くない

なり手が少ないから、である。プロジェクトマネージャやマネージャは大変だ、と思うエンジニアが多いので避ける。案件はあるのにプロマネがいないのである。

やってもいないのに、避けるなんて勿体無い。実はものすごく向いているのかもしれないのだから。

ある程度の経験を積めば、リーダ役は必ず付いて回る。そういう構造にしないとビジネスにならない。だったら、小さなプロジェクトから始めると良い。

準備は素振りから

リーダになったら、プロジェクトマネージャになったつもりで、現場で素振りすることを意識する。エンジニアがプロジェクトマネージャにアサインされてからどうしようか考えていては手遅れだ。

実務のシステム開発はできたとしてもそればかりじゃない。数字の予実管理もあるし、チーム運営もある。チームの協力がなければ何も実現できない。

どんなチームでプロジェクトをやりたいか、それを現場で素振りをしておく。

ビジネスへの寄与（収益）を意識する

何もこれをやって利益が増えた的な感じで捉えるとコストカットや労務時間のセーブに走りかねない。狙うのはそこじゃない。

エンジニアとして興味のある手法に入れ替えて生産性をあげられたから、その結果収益に貢献したとか、エンジニアの業務プロセスを変えて手戻りを無くしたから初期の工数は掛かったがトータルでは類似プロジェクトより品質がよく、顧客満足も高くなったなどとToDoとビジネス寄与を結ぶ習慣をつけると良い。  

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

パートナーとしてプロジェクトマネージャを選ぶときの諸注意

もしプロジェクトマネージャをパートナとして選択するなら、どんなプロジェクトマネージャを選ぶと幸せになれるだろうか。

などと、ふと思いついたので。春だし。

できるプロジェクトマネージャを選んだとしたら…

 ただ話を聞いて欲しいだけなのに、話のスコープの範囲はどこまでかの質問をされてしまう。もうここで無理と思う（だって、話を聞いて欲しいだけなのだから）。矢継ぎ早に課題の設定とマイルストーンを設定されてしまうだろう。

ただ、ここで見限るのはまだ早い。

できるプロジェクトマネージャなので、顧客（パートナ）の話には耳を傾けるように傾聴スキルを身につけているので、ハッキリと要件を定義して伝えることで改善される。

• 話を聞くだけに徹すること
• 同意のゼスチャだけすること

スコープの設定や課題解決は身に染み付いているので、なかなか慣れずに話の詳細に入ってこようとするが、それは要件ではないと毅然とした態度をとり、再発防止策を提案させること。

再発防止策は、フルーツたっぷりのスイーツのお店で奢る、などが望ましい（頭を使う仕事なので甘味好きは多い）。

 ただし、次項についての運用は注意する。

顧客（パートナ候補）から、パートナになると途端に下請けと見做しかねない。これは職業病であるから、パートナシップを締結しても、51％の経営権は確保すること。経営権が49%以下になると仕事（家事）を振るだけ振られるので、ここでも毅然とした交渉を行う。なお、ホールディングスとして100%子会社化（収入の連結決算）するのが望ましい。

 

残念なプロジェクトマネージャを選んだとしたら…

 もし、残念なプロジェクトマネージャであることがわかったら、残念であることのエビデンスを何点か確保することが最優先課題になる。

残念であるから、何事にもミスが多い。一番の欠点は、計画の構想立案能力が低いことによる行き当たりばったりな意思決定である。

これはデートの時に人気のあるお店の予約を入れない、こちらの嗜好、制限されている食べ物（アレルギーなどを持っているかなど）など要件確認をしない、などの事象として現れる。

また、品質に対する意識も低いため、デートでそのお店は選ばないだろうという安価なお店を選んだりしてしまう。ダメなプロジェクトマネージャかコスト意識が高いだけなのかは、バケットにハムとチーズを挟んだ簡単だが美味しいランチとハーフボトルのワインを大きな公園に持っていくデートを選ぶとか品質を伴ったソリューションなどで判別する。

ダメなプロジェクトマネージャはふりかえりをしない。しないから、ナレッジが蓄積されないし、ミスを再発する。なんどもされるとうんざりするか可愛いと思うかは性癖であるが相対的に幸せとは対局である。

少なくとも、美味しかったね、楽しかった、と心からの言葉がなければチームビルディングも残念である。

よって、エビデンスを示し、パートナシップは解消することが最良である。

ベスト・パートナーになるために―男と女が知っておくべき「分かち愛」のルール 男は火星から、女は金星からやってきた (知的生きかた文庫)

すごいスクラムマスターやプロジェクトマネージャやマネージャもたくさん失敗している

すごいスクラムマスターやプロジェクトマネージャもたくさん失敗している。

実物蓋もないが、そのままである。

主宰しているコミュニティ（立ち上げてからどのような関係性かを説明するときに、戸惑いつつ、モニョりながらコミュニティを使ってきたが、最近『ユニットでは』と思い当たってスッキリしている）のメンバはSMやPMやマネージャ揃いである。各方面でそれぞれ有名であり、もちろん実力もある（実際、一緒に仕事はしていないがユニット活動の中での言動、活動でのパフォーマンスを知っている限り感心せざるを得ない）。

会合の合間やそのあとの流れて食事の際に、その時々に話しているテーマに関連した失敗談を話し出す。苦労して大変だったとかではなく、さらっと失敗談を話しつつ、そこからの学びについて教えてくれる。

それぞれが失敗を話すが共通していることは、失敗を悔やむことや自己否定や他人を批判することは一度も聞いたことがない。

一度も。

リアルタイムで失敗中なら、『このような状況にいたら、あなたならどうするか』というような感じで自分からヒントを掴もうとする。

そうした問いかけに、周りは決して『こうしなさい』とか『それじゃダメだ』なんて言わない。

エンジニアのキャリアが、10年、20年、30年の経験者でもこうなのだから、新卒でエンジニアになったばかりの新人は失敗しかしないのでは、と思ってしまう。

すごいSMやPMやMgrがまだまだ失敗していても、知恵を借りながら自分の頭を使って解決しようとしているところは、いつも眺めているとすごいな、と正直思うし尊敬する。

失敗のままで終わらせないというのは、すごいエンジニアになる１つの才能なのかもしれない。

僕の小規模な失敗

調達 belkin Apple Pencilソフトケース

belkin Apple Pencilソフトケース 内ファスナー付[国内正規品]F8W792BTC00-A

マネージャクラスやシニアエンジニアの採用でババを引かない採用基準

そう言えばこのスクープ記事を読んで、気になっていることがある。

4. 2019年1月末に締め切った間接部門従業員の割り増し給付金付き早期退職を含めた今後のジョブ選択を45歳以上の富士通グループ全従業員に拡大する

tech.nikkeibp.co.jp

早期退職を始めると、肩叩きされて辞めた人と、その前に自己都合で見限って辞めた人の両方のケースが混濁して人材市場に溢れ返るが、どちらかは市場では判別つかない。

サービサーなどのWeb系の新興企業が事業拡大を進めるためにマネージャやシニアエンジニアを採用しようと考えると、なにせ人手不足から何かしらのリクルーティングサイトを使わざるを得ない。

そのとき、よくよく候補者を吟味しないとハズレを引くことになる。体力がそれほど堅牢ではないから、マネージャやシニアエンジニアのクラスだとインパクトも大きくなるから慎重に採用を決めたい。

間違って手の動かないマネージャ候補を採用してしまったとわかるのは、採用後である。

ではどうやって採用するか。

口コミ

社員の紹介が一番良い。これは社員のフィルタが掛かった上で紹介していることが一番大きい理由だ。少なくとも、紹介してくれている社員は一緒に働きたいと思っていると看做して良い。違ったら、その社員はエンジニアの力量を見る目がないということが学習できる。

ポートフォリオ

 以前にも書いたが、エンジニアの経歴は業務経歴書のような中身のない文字の羅列ではなく、ロールと専門の技術を適用したポートフォリオを書かせるべきだ。

少なくとも1000字以上の分量は必要である。この分量程度書けないということは経験をナレッジにする力量がない。それは実践知を形式知にできないばかりか、共有することもできないという証左でもある。

ポートフォリオを読むことで、ロジックの組み立て方もわかる。

であるから、ポートフォリオを出させて一次的なフィルタを掛けるのが良い。

最新技術知識

 サービサーやWeb系新興企業であるから開発はアジャイル開発を取り入れていることが多いはずだ（実際にはゲーム開発会社であってもしてもシステム開発手法はウォーターフォールのケースもある程度あることは知った上で）。

最新技術知識といっても、テックの方面ではなく、チーム運営やシステム開発手法の実践経験を確かめたい。これは、キーワードとして知っているではなく、現場で、若しくは自分の作業で適用していたか、という意味合いである。

この質問の意図は、新しい技術を自分で追い、使えるかどうかを試しているかを確かめたいということである。

現場の推進上の課題を解決する何かを自分でリサーチできるかも必要だし、それを適用して運用できるかを見極められるかという能力も判断したい。

マネージャやシニアエンジニアに対して聞く内容かと思うかもしれないが、excelとにらめっこしたりパワポを綺麗に作ったり、なんとかしろばかりの進捗管理しかできない人材は不要なはずだ。

THE TEAM 5つの法則 (NewsPicks Book)