調達 ゼンハイザー IE80 リケーブリング

断線しかかっているのに気づいたので。
IE80は李ケーブリングできるのが素晴らしい。
＃買ってから知りましたけど。

 さすがに25Kは高い…

Song's Audio イヤホン・ヘッドホン用リケーブル Universe Pro For Sennheiser IE ミニプラグ⇔専用端子 [1.2m]

 このくらいかなぁ。 

Woodhifi YGSH リケーブル イヤホンケーブル 交換ケーブル 着脱式ケーブル アップグレードリケーブル 耳掛型 ゼンハイザー ie8 ie8i ie80に対応 7N 単結晶銅

ゼンハイザー カナル型イヤホン 耳かけ式/低音域調整機能 IE 80【国内正規品】

品質管理ってなんだ

「品質管理ってなんなんでしょうね…」
「どうしたの、元気ないねいつも以上に」
「あのですね、テストするじゃないですか」
「するね」
「バグが出るじゃないですか」
「出る人は出すね。すごいエンジニアには難しい仕様が割り当てられるからどんなにすごいエンジニアでも出すね」
「そんな大した仕様じゃないんですよ…。それで…バグ直さないといけないですよね、ね」
「バグだからね」
「仕様が悪かったんですから、仕様書いた人が直せばいいといかいう人がいて。信じられないでしょう」
「新しい…かな」
「最近多いって聞きましたけど…そうじゃなくて」
「そのエンジニアって呼んでいいのかな。その人何しに来てるの」
「えっそんなの私に聞かれても」
「いやいや、あなたのチームでしょ」
「私もメンバです…」
「でもアーキテクトなんでしょ」
「そうらしい…ですけど。それはいいんですけど、バグのレベルも酷くて」
「なんか想像つくね」
「書いてあることしかコードにならないし、調べ物も自分でしないんですよ。情報くれくればっかりで」
「仕様を書かないでなんでエンジニアと呼ぶのかが謎だな。だったらオフショアでいいじゃん」
「そうなんですがそれはほら上が海外は懲りたって」
「どうせ丸投げして失敗したんだろ…」
「ノーコメントにしておきます」
「金銭感覚ないんだな」
「かもしれませんね」
「それで品質がどうしたんだっけ」
「仕様を見てコードを書くじゃないですか」
「書くね」
「テストを書くじゃないですか」
「書くね。逆の順番の方がいいと思うけど」
「そうするとまた、今度はそんなやり方は知らないし、やりたくないっていうんですよ」
「帰ってもらえば」
「できるならそうしたいですってば」
「なぜキミが中間管理職的なポジションにいるんだい」
「わかりません。いつの間にか…いつも遅いし仕事多いし…」
「もう、定時で帰りなよ。責任は果たしてるでしょ。上に責任とらせればいいよ」
「結局上同士で丸め込まれて…あーやだ、もう」
「それでどうしたんだっけ」
「品質管理できないエンジニアが多すぎなんですよ。もー。品質管理どう考えているのって聞きたいです」
「仕方がないから、1つだけな。どうせ愚痴りたいだけで話を聞いて欲しいんだろうし。そのチームに社員はいるんでしょ。そう、いるんだ。じゃあさ、その子を育てよう。その子がキミの次のアーキテクトにしよう。そうだな、３ヶ月だけやってみれば」
「それはそれで…」
「その子の所属は。そう、だったら問題ないじゃん。どこかでその所属のエンジニアが受け取らないといけないんだし」
「そうなんですけど」
「でもキミが我慢することはないよ。責任を感じなければならないのは上だし。プロとして役割を果たせばいい。今日きた品質もそう。品質の方針だって本来はPMだろう。なんでキミが案を出しているんだか。キミの上司なら代わりに行って小1時間問い詰めるところだよ。しないけどさ」
「時々本当にしそうになるから怖い…」
「あはは、気のせいだって。したことないし。まあ方針くらい出してあげるのはいいと思うけどね。そのPMがやるより良さそうだし。アドバイスは求められていないと思うけどさ、次の春までに抜けられる環境は作っておこうよ。そこまで頑張れたらまたプロジェクトの環境も変わっているよ。品質も」
「そうですね、育てるのは楽しいですけど。やってみようかなー」

テスト駆動開発

システム開発はどれから教えれば良いか

とても漠としたタイトルだけど、この問いにどう答えれば良いのだろう。多分、質問を投げかけられたエンジニアの生い立ちに強く影響を受けた回答が出てくるのではないかと思うのですが。

開発指向の強いエンジニアなら、コードを書くために必要な思考方法を１番にあげるかもしれないし、設計指向のエンジニアならアーキテクチャのデザインをするために必要な思考方法をあげるかもしれない。多分にもれず、プロジェクトマネージャならシステム開発の全体を把握して欲しくてプロジェクトマネジメントとは、から始めてしまうからも知れない。何れにしても、やはりそれぞれのエンジニアの専門性のある領域から手をつけてしまうと思われますが、どうなんでしょう。 

システム開発の全体とは何か

ところで、システム開発の全体とはどこからどこまでなのでしょうか。そしてどこが入口なのでしょうか。

多くのエンジニアはここを捉える前に、目の前に出された質問に答えなければいけないと早とちりして自分が持ち合わせていることから教えなければ、と思い込みをしてしまうのではないでしょうか。

まあ、システム開発の全体の外枠はここからここまでとビシッと線引きできるんだっけ、という考えもあるのですが、世の中は多くが曖昧なので、システム開発の全体とはに対する考え方は一旦線引きをするけれど、違っている事が後でわかったら線を引きなおせばいいじゃん、くらいで。

道具より世界観

 戦力が欲しくて採用をしているので、採用者が未経験なら道具の使い方を教えたくなりますが、それでいいのかという疑問を持つことも一つの考え方です。

今に限らずエンジニアの課題は技術はできるけれど全体を考えられないパートタイマーなエンジニアが多いという嘆きです。それもそうなってしまったエンジニアを育てたのは誰だよ、と嘆いているシニアなエンジニアやマネージャにつっかえせばいいだけなのですが。

世界観というとこれまた、世界の構成を細々と説明しなければならないのかと早ガッテンして事故を起こしそうになるエンジニアが出てきそうですが、そんなことはおいおいでいいのです。

ただ、システム開発の全体、世界観を示すことは教える対象のエンジニアに対して今後のキャリアの選択肢を広げておくという考えがあることに気づいて欲しいところです。エンジニアで採用してもやってみたら違ったとか合わなかったとかザラなので。やりたいことを仕事にする考え方もありますが貢献できるキャリアを見つけさせるのも必要なことです。

そのために、世界観を示す必要があるのです。

4つと3つ

4つとは、システム開発の4つのレイヤーのことです。

1. マインドセット
2. ツール＆テクニック
3. システム開発手法
4. プロジェクトマネジメント/プロダクトマネジメント

次の3つとは、

1. 企画
2. 開発
3. 運用

のライフサイクルです。この4つと3つのマトリックスの中に様々な役割と仕事が押し込まれていて、それをドットとしたときにエンジニアはどこを自分の陣地として広げていけばいいかをしめすのが、今の所良いのだろうと思います。

教える側は、マトリックスの中のどこをこれから話そうとしているかを示しながら教えれば、教えられるエンジニアは迷子にならずに済むし、蛸壺に入り込んでいるなんて馬鹿らしいと思ってもらえるのではないかと。

あとはプライオリティの高い業務から教えればいいです。

人材開発研究大全

50歳を過ぎたエンジニアがキャリアを再構築するために

50歳を過ぎると60歳まで、あと10年もないです。当たり前ですね、簡単な引き算ですから。組織によっては65歳まで組織が必要とするならば、雇用延長もあるかもしれませんが。

そこそこ資産があり、仕事以外でやりたいこともあるのなら。そちらで精を出してもらえればよろしいのではないかと思いますが、多くのエンジニアはそうもいかないかもしれません。

今出来ること、出来ないこと

今出来ることと出来ないことを棚卸ししてみましょう。あと、レベルですね。列に出来ること、行をレベル分けして、ITSSV3のレベルでプロットしてみましょう。

注意したいのは、ここで自己評価を甘くしないことと、辛くし過ぎないことです。

自己評価を甘いかどうかの判別方法は、実績があるかないかで簡便的に判定できます。

辛くし過ぎていないかを判別する方法は、レベル評価との紐付けが低くしていないかで判定します。

まあ、どちらのケースでも自分で自分の評価を偽れば、あとで苦労するのも自分なので厳密性は問いません。

組織の○○さんの組織名を外してみる

端的に言えば、自分の名前をエゴサーチしてみて、名前が出てくるかどうかです。ネット上で自分が専門とする技術領域で名前が売れているかどうかを判定します。

別にネットで名前の認知度が高くないから残り10年のキャリアを諦めないといけないかと言えばそうではないです。クローズドな専門家としての付き合う学会的な集まりもあるので。

それでも敢えてエゴサをというのは、どこかのタイミングで組織を去るときには、組織の看板が外れるのだということを今から理解しておくことには意味があるので。

今から、真面目に、今から専門領域の会合やセミナーに出て行って、5年も活動すれば組織の○○さんの組織が外されても○○さんと名前が関わった人に残ります。

組織の看板が外れた後に持っている技術を生かして何かビジネスに関わりたいときにそうしたつながりと名前の記憶が役に立ちます。

出来ることの隣を耕す

はじめに出来ることを尋ねたのは、出来ることの幅を増やすということを今からしておきましょうという前フリだったのでした。

歳をとれば新しいことを考え、理解することだけでも億劫になるものです。でも、それでは現役で第一線に残ることは難しいだろうし、それだったら年齢の高いエンジニアより若手を選ぶのが顧客心理です。

50歳を過ぎたエンジニアがああしたい、こうしたいと自分の都合だけで考えても誰も買ってくれません。買い手の気持ちになって買ってもらえる、つまり、対価を支払ってでも50歳を超えたエンジニアを買いたいと思わせる価値を自分で作る活動を始めなければなりません。

考えるより、行動を起こすこと。

今日、やらないと一日分だけ機会を失い、10年にも満たない残りの余白がゼロに近くだけです。種まきは今しなければならないのです。

結局、組織の中で必要とされるのは組織にいる間で、それもそれなりのロールについているエンジニアだけです。一担当のエンジニアは期間満了でパージされるのです。

散々、システム開発でエラーケースを考えて実装してきたのですから、キャリアでも同じように組織から外れた時のケース文を準備していきましょう。

シニアITエンジニアに送る ５０歳になったらインフラを覚えさない

将来の技術的負債を作らないチーム作り

マネージャやプロジェクトマネージャがプロジェクトメンバを調達し、アサイメントする際に犯してしまう間違い…それは頭数を揃えてしまうことです。

プロジェクトマネジメントとしてプロジェクトの目的を達成するためには、プロジェクトの目的達成でのアウトプットを作成するために必要とするスキルセットを持っているリソースを調達しなければなりません。もちろん、リソースにはIT機器や人的リソースが含まれています。

マネージャやプロジェクトマネージャは、プロジェクトの立ち上げの準備作業で多忙という言い訳をしてプロジェクトチームとして必要なスキルとスキルレベルを充足するメンバを集めるまでを考慮せず、その手前の人数だけで揃えてしまうのです。これが間違いであり、プロジェクトチームに見積もりやプロジェクト計画で考慮されていないリスクを潜在的に抱え込ませることになるのです。

こうしたエンジニアの調達をどこかで見かけた記憶はありませんか。

そう、大規模プロジェクトの多重契約で見かける風景です。javaが書けるということになっているエンジニアを頭数だけ揃えて、あとはプロジェクトで教育してください、というやつです。これがどれだけプロジェクトにリスクを持ち込んでいるか、将来の技術的負債を持ち込んでいるかわかっているかを小1時間問い詰めたいし、負債解消のためのコスト負担を請求させて欲しいくらいです。 

どっちのチームがお好み

あなたがプロジェクトマネージャだとして、次のどちらのチームでプロジェクトを回したいですか。

1. プロジェクト計画の見積もりで必要なエンジニアの頭数を揃えたチーム
2. プロジェクト計画で必要なスキルセットの充足には一部足らないが精鋭なチーム

 個人的には項番2を選択しますが皆さんはどちらを選びましたか。

心理的に必要とするリソースを埋めたくなるのはわかります。でも、どちらを選ぶにしてもメリットデメリットがあるわけです。

将来の技術的負債には何があるか

 チーム1の将来の技術的負債にはどのようなことがそうてできるでしょうか。

• チームとして必要とするスキルとスキルレベルを充足できない。
• スキルとレベルに満たないエンジニアの教育コストが追加でかかる
• スキルとレベルに満たないエンジニアのフォローのためにコミュニケーションコストが積み上がる
• スキルとレベルに満たないエンジニアのフォローのためにできるエンジニアのリソースを使ってしまい進捗が出ない
• メンバ別のスキルとレベルに満たないエンジニアのアウトプットがプロジェクトの品質目標に満たず修正コストが積み増す
• スキルとレベルが足らないエンジニアの成果に対し、期待していた成果分のキャッシュアウトが発生する

将来の技術的負債の観点で抽出しているのでデメリットばかりです。スキルとスキルレベルが未達でも投入せざるを得ないケースも組織的な戦略上取らなければならないケースもあります。それは若手や技術転換などのエンジニアの育成です。このケースの場合は、組織からの財政的支援やKPI的な数値の引き下げなど組織的なサポートを考慮しつつそれでも行われるのは教育なので将来の投資の観点があり、将来的にはプラスになることを期待するからです。

チーム2の技術的負債で考えられることは何でしょうか。

• プロジェクトチームとして必要とするスキルとレベルが不足した状況で運営せざるを得ない。
• 進捗はメンバのスキルとレベルが充足される場合と比較して遅れる。
• メンバに負荷が掛かる。

 でも、このくらいなんですよ。ここのエンジニアに対してのスキルレベルが必要とする分だけは充足されているので作成するアウトプットの品質は期待できます。

遅れることを是としてスケジュールを引けば、ですが。

さらに、低レベルなエンジニアが混入してこないのでコミュニケーションコストは想定の範囲で済みますし、期待するスキルとレベルを持っているのでフォローアップは必要ないので想定外のコストを払い出す必要もありません。

進捗についてさらに言えば、チームに必要とするフルなリソースでの計画に対して、足らない分だけの遅延で済みます。

将来の技術的負債を作らないチーム作りのメリット

育成以外であれば、無理して適切でないエンジニアをよそから持ってこない方がプロジェクト最適化の考えからいえば、ベターな判断です。

とはいえ、全く途中でエンジニアを補充しないのもアレです。基本的にはマネージャやプロジェクトマネージャは、不足した状態でプロジェクトを始めるなら、それでできる範囲でのスケジュールを引いてステークホルダと協議し、受けれてもわなければなりません。

ただ遅れるよという伝え方もありますが、プロジェクトの計画を多段階にする（＝ステップ分けをする）など見せ方の工夫もできますし、全機能のリリースリミットを伸ばせるなら、人的リソースの面積は伸ばした方が品質管理上の観点からも合理的です。

まあ、その際には段階的リリースをすることでのメリットを前面に持ってくることが必要でしょうが。

人材開発研究大全

調達 iPhone8 強化ガラス

 前に買ったのが剥がれてしまったらしい。

TCJOY iPhone8 強化ガラス 液晶保護フィルム ゴリラガラス素材 3D曲面加工 全面保護 ホワイト

後任のリーダをどう育てるか

プロジェクトマネージャもマネージャも、そしてSEリーダでさえ、常時、後任を育てなければならない。後任になる候補がいないならその仕事から抜けることを考えるか、ビジネスを育てて後任候補をアサインしてもらえるところから始める必要があるの。

なぜ後任を育てる必要があるかは、これまでのどこかのエントリに書いてきたので割愛するとして、後任をどう育てるかを考える。

多くのリーダは、頭では後任や後進育成（こちらの方が対象が多くなる）が必要なことはわかっているけれど、実務のやりくりの中で後任を育成することについては全くもって手につかない状態のままだ。

なぜなら、後任育成についてのメリットを体感していないことと後任育成で手に入れられる価値の大きさをわかっていないから。

もうひとつある。リーダ役のエンジニアが後任を育てないのは、そのポジションの居心地がよく、居座るつもりだからだ。

このパターンのリーダの下についたメンバは、そうであることを察したら早々に配置転換をマネージャに伝え、出ていくことを考えた方がいい。そうでなければ都合よく使われて、しかも、他で通用しない古く、適用力のない業務しか身につけられないからだ。

話を戻して、後任をどう育てるか。

リーダである自分自身が育ってきたことをそのまま繰り返そうとするリーダが少なくないが、それはそれで育ってきたリーダが適用できただけで、これから育てようとする後任がフィットするかはわからない。

ひとつ確認しておきたいことは、リーダは人に教えをする技術を身につけているかどうか、である。教えることの技術を持ち合わせていなければ、自分の体験を後任に同じようにしたとしてもリーダのようにリーダとして育つと思ってはいけない。多くの場合は、育てられた経験は反面教師であることが多い。

後任を候補として育てるのであれば、次のことを行うことを検討してほしい。 

• 期待する後任の範囲を対面で伝える。
• 後任候補として担当する作業。特に、後任候補として増やす担当業務の部分。

特に配慮したいところは、後任候補として増やす担当業務がリーダの仕事の中で中核の業務に位置付けられているかどうか。ここを考えずに作業を増やすと単に都合よく使われている感が増すばかりだ。

更に言えば、実際、リーダが中長期で不在になったケースを想定したときに業務が回るかどうか、である。この観点で渡す業務が適切かをテストすればいいのである。

もし、業務が滞るようであれば、それは担当させている業務が適切でないということだ。

もうひとつ。マイクロマネジメントにならないように＝仕事の仕方を考え、自主的に完了させるために、仕事の目的と完了状態を伝えることを忘れずに。 

ヤフーの1on1―――部下を成長させるコミュニケーションの技法