調達 HMB

 ちょいと、協和の方を試してみようかと。

オレンジのボトルの方はカプセルが大きいのよ。

協和食研 HMBタブレット 360粒入(1粒HMBカルシウム250mg )(国産原料使用)

Now HMB 500 mg 120 Veggie Caps 海外直送品

エンジニアとして仕事は楽しいですか

「エンジニアの仕事は楽しいですか」

そう訊ねられたら楽しいと答えるかな。でも、何が楽しいかと問われると楽しい仕事もあり、忍耐力を鍛えるような仕事もあり、心中はスパッと楽しいとは言えないのですけれど仕事が１つだけということはエンジニアにはないので、全体からいえば、概ね良好なのではないかと思うのです。

とは言っても、どのような仕事だとしても共通的なことがあると言えばあるような。

新しいアイデアを探る

過去に担当した経緯からではあると思うけれど、いや、多分に他のメンバのスキルから消去法というか優先順位できにで同じ結果になると思うけれど、割と難しめのタスクが回ってきたのです。

いよいよ手をつける時期になった（自分で開始時期を宣言していた）ので、状況を整理してみたら獏とした印象しか残らないほど、現時点で掴みどころがないのである程度ロジックを作ろうとすると、多少の権威づけをしておきながら、ゴール設定をしつつ合意形成に繋げるというエンドユーザ側での構想立案という企画なお仕事になるのだな、とぼんやりとしたアウトラインを脳内に描くまでがやっとのところで。

そう言えば、こうした考えるお仕事はランチの後でさえ睡魔が襲ってこないのでもしかすると自分にとって楽しい仕事のなのかもしれません。

アイデアの主導権を取られないために

こうした獏としたお仕事の場合は、誰一人としてゴール設定を持っていないところを認識しておかないと痛い目にあうのは確定していることです。

どんな痛い目にあうかというと、裁量を持つステークホルダと思って頼ってしまうと、そのステークホルダ自身が答えを持っていないとき、散々振り回されるだけ振り回されて最後にちゃぶ台を引っ繰り返されるパターンに確実にハマるということだけが確約されているから。

そうした状況、つまり誰一人として答えを持っていない、偶像が見えていない場合は、偶像のアウトラインを権威者を使ってこれが見えるでしょうと言わなければならないのです。信じたものだけが形になるので。

普段の仕事でもそうですが、意思決定の主導権は最後まで手綱を手放してはいけないのです。それがお膳立てをするだけだとしても、筋書きをする主導権を握っていれば、思い描くようにことを運べのですから。

アイデアは良くあるために存在する

ここでいう権威者とは、内部の最終権限を持った人でなく、外部のデファクトとなるガイドラインや法律に類似する経典に当たるもの、若しくは、枢機卿の教えのような諮問委員会での決定事項などです。

こうした獏としたところからアイデアを出す仕事とそれに影響を受ける過去のシリーズとしての現行業務のしがらみを考えつつ、それらの中から都合の良いものをだけを選び料理することを考えなければならないのですが。

何れにしてもアイデアは今を良くするために変えるものであり、今はそのアイデアを適用する場所にはないものです。

アイデアは無からは作れない

ただ、こうしたことを全て自分一人では知識も経験も見識もないので、友人関係者から業界動向や他社の動向や専門家としての意見を伺い、自分なりに消化してろくろを回し軸を作ることをしなければ自分が先頭に立って仕切れないのです。仕切れないということは状況的に無知な裁量を持つステークホルダの思いつきで揉まれてしまうため消滅感を覚えてしまうのでそうした事態にならないように事前学習はとても大事でためになるので欠かせません。

こうしたアイデアを作り、ことの運びを作り上げるところがとても楽しいのです。

これか

アヲハタ 塗るテリーヌ 国産鶏のチキンレバーペースト 73g

アヲハタ 塗るテリーヌ 北海道産スモークサーモン 73g

アヲハタ 塗るテリーヌ ポルチーニ香る3種のきのこ 73g

アヲハタ 塗るテリーヌ 広島県産牡蠣 73g

アヲハタ 塗るテリーヌ 牛肉の旨み引き立つビーフペースト 73g

アヲハタ 塗るテリーヌ フランス産フォアグラ 73g

予定していた作業を確実に終わらせる予定のレシピ

プロジェクトマネージャやSEリーダ役の悩みの１つは予定完了日にワークパッケージが完了しないという進捗遅れでしょう。有期限性の特性を持つプロジェクトだからこそ、完了する日に完了しないとスケジュールが遅延してしまい、ドミノ倒しのようにプロジェクトの納期に影響してしまうのだから。

進捗把握の仕方を疑え

いつも、毎回、どのプロジェクトでも予定した作業が遅延してしまうなら、まずは、進捗把握の仕方を疑いましょう。

疑うその前に、作業のプロセスをおさらいします。

予定を作る、作業をする、実績を把握する

まずはこれは正しい姿です。ところが実績把握をして予定どおりに完了していなければこの作業プロセスが変わってしまいます。

予定を作る、作業をする、実績を把握する
遅延の対策を立てる、遅延の対策を実施する、対策の実績を把握する

 予定どおり終わらなければ、次に予定していた作業とは別に、終わっていない作業が完了して始末するまでアドオンで乗ってきます。

こうなってしまうのは進捗の把握の仕方に問題があるからです。進捗がトラブるプロジェクトは、得てして進捗を把握したいメッシュと進捗の実績のメッシュの単位がずれているのです。

進捗把握の単位を知る

ちょっと、今ジョインしているプロジェクトの進捗把握の単位が何かを思い出してみましょう。日単位か週単位か。もちろん、プロジェクトチームの中で、で。

日単位であれば、毎日の作業を把握する仕組みがプロジェクトチームの中の作業プロセスとして実装されているはずです。

週単位であれば、週の作業を把握する仕組みが（以下略。

実績の把握の単位を持ち出してきたのは、進捗実績を把握するサイクルは、実は遅れが把握できてたときには、その遅れを取り戻すにはその3倍以上のリソースが必要となることを肝に命じておく必要があるよ、ということを言いたいためです。

図にするとこんな感じ。

凡例　△＝作業予定　▲＝作業実績　□＝予定完了日　■＝実績完了日

①予定　△△△△□
　実績　▲▲▲▲▲　←5稼働日で終わらない

②予定　△△△△□
　予定　　　　　　　△△△△□　←当初予定していた計画。
　　　　　　　　　　　　　　　　　下をやるので手がつかない
　実績　▲▲▲▲▲　▲▲▲▲■　←10稼働日で終わる

③予定　△△△△□
　予定　　　　　　　△△△△□　→　△△△△□　←　翌週にスリップ
　予定　　　　　　　　　　　　　　△△△△□　←当初予定していた作業
　実績　▲▲▲▲▲　▲▲▲▲■　←10稼働日で終わる

これを可視化して把握していないから、②で終わらせますという裏付けもないメンバのコミットを真に受けたり、②で終わらせて欲しいとメンバに無理強いをしたりすることになるのです。

終わらないとリソースがなくなる

 上図で学習できることは、

「予定していた作業が終わらないと未来のチームのリソースを食いつぶすよ」

 ということです。じゃあ、その対策はどうすればいいかってことになるのですが。

遅れる作業はいくら把握しても遅れてる

 じゃあ、どうするかといえば予定作業を終わることを把握することですが、把握するサイクルを変えればいいのかってことです。

週次を日次に変えればどうなるでしょう。

やっぱり遅れる作業は遅れるのです。

これは、進捗把握の単位と作業の単位がずれているから生じます。やってしまったこと＝遅れてしまっていることをいくら把握しても早くなったりしないのです。

予定作業を終わらせる予定を作る

ではどうすればいいか。予定していた作業を予定どおりに終わらせるレシピです。

1. 進捗把握（＝進捗管理）は日次で把握する
2. 作業は時間単位まで分解する
3. 1日の実作業時間は5時間を上限にする
4. 実作業時間に割り込みをしない 
5. 1日の最後に作業のアウトプットをリポジトリにコミットする

大事なことは1日いち日と終わらせることをです。

プロジェクトマネージャの立場であれば、項番3は、フルフルの8時間（1日＝8時間労働の場合）としたいところですが、

1. 進捗把握の時間
2. コミュニケーション（＝情報共有）の時間
3. 仕様検討、レビューの時間
4. 研修、教育などの間接時間
5. 休暇などの間接時間

など正味の作業時間（＝ドキュメントやコードを書く時間）には直接関わらない、でも必要な時間を控除した上で実時間を設定しなければ、いくら綺麗で整合性のあるスケジュールを作っても必ず遅延します。

でもやっぱり遅れます。パッケージのバグやAPIの動きが想定していない動きをするとか、メンバが風邪で寝込んでしまった、忌引きがあった、などなど想像しようと思えば想像できることを予定に組み込まないでいるからです。

それはプロジェクトの局面やスプリントごとのバファをプロジェクトマネージャがプロジェクトのバッファとして確保しておくことが必要です。

このバッファは誰にも言ってはいけないし、絶対に守らないといけないバッファです。そうしないとプロジェクトを直接回しはしないのにステークホルダーとなっている関係者が（特に身内から）削ろうとしてくるので。

システム開発のためのWBSの作り方（日経BP Next ICT選書）

PMBOK対応 童話でわかるプロジェクトマネジメント

アプリ開発チームのためのプロジェクトマネジメント ?チーム駆動開発でいこう！?

なぜアジャイル開発の検証するかその狙いを理解しようとしないの

「あ、お久しぶりです」
「ああ、こんにちは。久しぶりだね。今はどのプロジェクトをやっているの」
「顧客の役員がアジャイルをやってみて課題は何かを検証するプロジェクトなんですよ」
「アンチパターンそのものだね。上から手法を指定されたプロジェクトで成功した試しないよ」
「やることは決まっていて、アジャイルで開発することになってて」
「それであなたは何をするの」
「リーダです」
「へー、じゃあスクラムマスターなの（POではないのか。PMならPOな気もするけど。でも要件持っているのは顧客だよね）」
「ああ、スクラムマスターっていうんですね」
「ん、アジャイルって一括りに言っているけどどの開発手法でやるの。アジャイル開発は幾つかメジャーな手法があるから」
「スクラムでやろうと言われています」
「言われてって…大丈夫なんかな。心配になってきたよ」
「これから勉強したいので何か情報教えてもらえませんか」
「まあ、知っていることは教えられるけどさ」
「お願いします」
「じゃあamazonのサイト開いて。このキーワードで検索して。アジャイルサムライ

、SCRUM BOOT CAMP THE BOOK　くらいは読んでおいたらどうかな。あとこのキーワードでサイトを検索して。そのサイトにスライドがあるから読んでみたら」
「へー、こんなスライドがあるんですね。ありがとうございます」

「でさあ、要件決まっているならウォーターフォールでいいんだよ。どうしてわざわざスクラムだって言っているのか知っている」
「顧客の偉い人がアジャイルでって」

「うーん（失敗はして欲しくないけどなぁ、さて）。そうだこれで検索して。

フロー効率性とリソース効率性について #xpjug　をめくって。それ、6ページの上がウォーターフォールなんだ。乱暴だけどさ、イメージはそう。ABCの機能は納期にならないと出来上がらないじゃん。そこで初めてビジネス的に価値があるかどうかをソフトウェアとして確かめられるんだよね、顧客は。わかるかな」
「…ええ…」
「下がアジャイル開発でやったらになるイメージね。小さなスプリントに収まる必要な機能だけを繰り返し作っていくんだ。ほらA機能はさ、5つ目で終わるでしょ。そこで顧客はソフトウェアがビジネス的にリターンを得られるか確認できるんだよ。それもマーケットで。ウォーターフォールとは違うでしょ」
「はあ…なんとなく…わかります」

「そうだ、アジャイルソフトウェア開発宣言　のサイトって知ってるかな。そう、じゃあアジャイル宣言で検索して。ここのね、

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を 

引用　http://agilemanifesto.org/iso/ja/manifesto.html

 ってあるじゃない。顧客の欲しいものを作るのが強調のところ。動くソフトウェアはA機能をいち早く使える状態にすること、それが期待と違っていたら顧客の欲しいものが変わるから続けて作るソフトウェア自体を変化させることが対応、短期間で作る必要があるから関係者で会話しないと進まないから対話、とね、さっきのスライドがこうしたことを背景に繋がっている、とね、そう思っている。ワタシだけかもしれないけど」
「…」

「たぶん、失敗するよ。今のままだと」
「それは困ります」
「いいじゃないの、検証なんだから間違った課題設定で間違った結果となっても」
「それじゃ」
「じゃあ、その検証はなんの目的でやるんだろうね。それを突き止めないとなんかやりましたとか、そのエライ人の期待する結果に合わせた報告をするだけになってしまいそうなんだよ」
「どうしたらいいですか」
「アジャイルコーチを雇ったら」
「コストが」
「じゃあワタシが傍観してあげようか。コスト必要だけど」
「そこは無料で」
「コーチを入れた方がなんの目的でやるのかから根掘り葉掘り詳らかにしてくれてていいと思うけどなぁ。ワタシでもやるけど」
「…」
「まあ、困りそうな前に何かあったら雑談にでも誘って」

転職で成功するエンジニアと失敗するエンジニア

昨日の朝に　その後の人生を分ける！エンジニアが34歳までに考えるべき3つのこと - paiza開発日誌　をざっくりと読んで思ったこと呟いたら、paiza開発日誌のツイ垢の方にフォローされてしまってちょっとざわざわした気持ちになったりしたけれど。

市場価値の大部分は、個人名が市場で認知されているかですよ。 / “その後の人生を分ける！エンジニアが34歳までに考えるべき3つのこと - paiza開発日誌” https://t.co/MvaGyouboY

— ふみさん (@finayama) 2017年10月3日

まあ、↑で書かれていることはこのブログでもだいたい同じようなことをあちらこちらに書いているので一生懸命探して読んでいただけるとよろしいかと思います。

ただ、実体験から言えば、上のエントリには1つ書かれていないことがあるのです。

転職のトリガーを誰が弾くか

34歳と35歳定年説を意識した（と思う）1つ前の34歳に設定しているところがなかなか目の付け所がと思ったのはそこに置いて、転職できる準備は34歳の前からしておいた方が良いけれど、それはあっちに置いて転職のトリガーを誰が弾くのかはよく考えて欲しいと思うのです。

どう言うことかと言うと、転職には2つのパターンがあるのです。

・自分から他社に移る
・オファーが他社若しくはエージェントから掛かり、他社に移る

これ、全然違うので。何が違うかわかりますか。

自分で判断基準を下げてしまう

 自分から他社に移ることを決めて活動をし始めるとコストを掛けて転職活動をすることになります。

ここで何が発生するかと言うと、自分の時間を使って自分のリソースを使っているのでサンクコストが発生するんですよ。

そうするといくつか面談で不採用が起きると条件を自分で下げ始めるようになるのです。これ、絶対に起きます。

「ここまで時間をかけてきたのでこれは諦めるか…」

転職のサンクコストを作らない

 だったらどうすればいいか。市場で名前を売って、買手の企業からオファーを貰えばいいのです。

それよりいいのは、口コミで企業なりエージェントからオファーを受ける方です。これは紹介者が自分の知り合いになるので事前に情報を手軽に集められますし、確度がとても高いです。

何より、オファーされるので自分のリソースを使ってサンクコストを作らない。

だから、条件が合わなければ、いつでも転職することをやめられるんです。オルタネーティブな選択肢を持っているのはとても強いです。

「今はちょっと…」と言えるので。

オファーを貰うために

オファーにも誰構わず総当たりで電話やメールで声を掛けてくるエージェントがいるけれど、そうしたコンタクトは切断するのです。

そうした輩は、手数料稼ぎしか脳にないので雑です。 

まずは、会社名を背負っていてもいいので、社外でプレゼンスを発揮することが必要です。セミナー、カンファレンス、会社主催の勉強会。

なんでもどんな手段でも使って、自分の得意分野をアピールする。もちろん、エンジニアなので課題解決になっていないと技術力が認められないのでそっちが重要ですけど。

そうした場で認知をあげると勝手に口コミしてれます。あの人はこれが得意だよ、と。

つまり、口コミにつながる認知度を作ることが必要です。これ、自分というプロダクトのマーケティングですから。コツコツをやっていくしかないのですけれど。

そこにたどり着くまでは、この↓ツイートを自分に問いかけながら仕事をしよう。

自分の売値で自分で買うと思える仕事をしているかな

— ふみさん (@finayama) 2017年10月3日

エンジニアとして世界の最前線で働く選択肢　?渡米・面接・転職・キャリアアップ・レイオフ対策までの実践ガイド

エンジニアの成長戦略

エンジニアになりたい君へ 理工系学生のためのキャリア形成ガイドブック

ひとりでできる！ITエンジニアのキャリアデザイン術 ?望みをかなえる「壁」の越え方

35歳、今がラストチャンス　転職を成功させる９つのヒント: 実際に成功した著者だから知っている、転職あれこれ。 (うみがめビジネス文庫)

「助けたいが何を手伝おうか」と言ってエンジニアの仕事の脆弱性を診断する

どうももう1つのチームの進捗が今一っぽい。ランチタイムには、リーダ役が愚痴を垂れ流すし、セカンド役は一緒になって現状の酷さを盛るように話すのですが。

愚痴を言いたければ好きなだけ話したらいいじゃないと基本的にはスルーしているけれど、他にタイミングがなければ一息つくお昼時に言いたくはないけれど、進捗させるために何をしたらいいのかを聞いたりすることもあるのだけれど。

愚痴を言っているときには指示しても変わらない

仕事上の愚痴をエラーログのように吐き続けているときには、あれこれ言っても愚痴を言っているエンジニアは届かないのです。だって、愚痴の根元が解消されないと気はそっちに回っているので。

それを踏まえないといけないのです。

つまり、愚痴を言っているところで「お前の仕事の仕方が悪い」とか「こうやってごらん」とか言っても聞く耳を持ってもらえないのです。

進捗しないのは周りが悪いと思っているから。被害者意識ですね。的外れですけど。

逆に、優しい言葉をかけてあげると聞いていないことまで話してくれるのはエンジニアは本来優しくして欲しい生き物なんだなと思うのです。

助けてあげたいが何して欲しいと聞いてみる

マネージャがあれこれ言うと、進捗していない状況と言うタスクが積み上がっているかスタックしている状況で、さらにマネージャからタスクを積み上げてしまったらどうなるでしょうか。

まあ、さらに身動きできなくなりますね。だって、自力で進捗していないんですから。

だったら、助言をしようとしていることを勝手に代替してできたものをあげればいいんです。

資料の作成に手が回ってなくて、作る順番を間違えているよ、先にこっちを作らないとロジックの展開がおかしくなるよ、的なものがマネージャが気になるなら、その足らないものを勝手に作って渡せばいいんです。

ただ勝手に作って渡してもいいけれど、

「助けたいが何して欲しい」

と問いかけることでそのときエンジニアが一番気にしていることを聞き出すと言うやり方もあります。これはあれですね、ハードニングしていないOSに色々情報を聞き出すのと同じやり口と言うか、セキュリティ上の脆弱性をついて余計な情報を引っ張り出す手口ですね。

まあ、エンジニアの仕事上の脆弱性診断をするようなものかもしれません。

資料を作って背中を見せる

 それはさておき、マネージャが心配してくれると思ってくれることと、頑張らなきゃと思ってくれればそれは幸いで、こちらとしては拙い進め方をテコ入れしたいだけなんだけれど、進むならどうでもいいですが。 

別な切り口で言えば、背中を見せると言うことでしょうか。資料はこう作るんだよ、と。

ただ、資料を作ったマネージャは当事者でないので全ての情報を手に入れられないので、作った資料はエンジニア自身がレビューして採用するかしないかの判断をさせることを忘れてはいけないのです。

あくまでも、作業の責任者はエンジニアなので。マネージャは好き勝手に作っただけで、それを使う使わないはエンジニアが判断すればいいのです。そう言う気持ちを持って作らないと、エンジニアがマネージャのリソースをあてにしてしまうんです。それはダメです。それはエンジニアの仕事なので。

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

学習する組織 ― システム思考で未来を創造する