ヤフーの1on1という本を読んだ。
ヤフーの1on1―――部下を成長させるコミュニケーションの技法
- 作者: 本間浩輔
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2017/03/25
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
ヤフージャパンの人事部長が書いたという本。
上司との個別面談は定形化されている会社は少なくない。 話を聞いてアドバイスをする、確認をする。そんな上司中心の目的ではなくて、 相手の本質を引き出して前に向かわせるような、 まさに部下を成長させるコミュニケーションの技法が書かれている。
部下は上司を尊重するもの、尊敬するものといった いわゆる日本企業の常識を持った会社ではおそらく実践することはないだろう。
30代前半の個人的に思うのは、 スマホをいじれる子供、学生時代から将来を見据えて努力する若者、 といった人々が増えている現代社会において、 大人になってからITだのスマートフォンだのといって現代ぶってるおじさん、おばさんよりも、 前を向く若者達のポテンシャルを引き出す事こそ、現代の上司と呼ばれる役割の人々が世の中のためにできる大きな仕事ではないだろうか。
この本はそれを前提としている感じがして凄く好き。
中房温泉
長野の中房温泉という場所に行きました。槍ヶ岳の麓辺りにある温泉地です。
ここ↓ Google Maps
来館予定時間を1時間もすぎてしまい、到着は17:45頃 0度近い夜の山道で薄着でバイクを走らせ到着しチェックイン、岩風呂の女性専用時間が18:00で終わるらしく、 また18:00から夕食が始まるらしく、夕飯前の15分で温泉に少し入ってきたらいいよと勧めてくれました。 凍えた体が温泉で一気に心も体も暖まりました。
山ならではの料理がとてもおいしかった。
あと瓶の濃厚牛乳が300円くらいで朝ご飯につけられるのだが、これがまたとんでもなく濃厚。人生で飲んだ牛乳の中で一番濃厚だった。 写真を取り忘れたのでリンクを張ります。とにかく濃い。瓶のふたに白い牛乳の固まりが残るくらい濃い。美味しいです。 北アルプス牧場自然牛乳(2本入) 北アルプス牧場直売所|牧場直送の絞りたて牛乳!!のお取り寄せ、通販はかっちゃお.com!
景色も濁りなき青空でした。
温泉はとても気持ちのいい硫黄泉、単純温泉でした。(写真なし。是非確かめに行って頂きたい。) 温泉の沸き出し元でおいもをふかしているそうで、帰りに"よかったら持って行って。"とお宿の方に頂きました。
お宿の方が本当に本当に親切で、女性は指定時間以外は混浴なので泊まりでないと 不自由を感じることがあるかもしれませんが、是非皆さん中房温泉に一度お越し下さい。
追伸: 山道は非常に狭く、バイクを使う人にはお勧めですが、車の方は十分ご注意ください。結構長い山道ですし、猿もいます。 でも乗り越えた先の達成感は半端ないです。
伊豆の夜桜をあなたに
河津から天城に向かう途中の桜。
おまけ:相棒と夜桜
今年桜を見忘れた方。来年は河津に小型バイクで訪れるのがお勧めです。
5分で焼きそばを作る方法
忙しいあなたに。最高で低コスト&短時間でできるレシピ、焼きそばの最速で調理する方法を記載しよう。
※もやし以外の野菜(キャベツ等)に関しては、 野菜ミックス or あらかじめ切った野菜をストックしておく。
材料:
やきそば(まるちゃんのソース焼きそばがなんだかんだ一番美味しい)
もやし
キャベツ
1.家に帰ったらフライパンに火をつけ(強火)、油をひく (10秒)
2.手を洗う(20秒)
3.冷蔵庫から肉を取り出し入れる。(30秒)
4.野菜を投入(強火)(30秒)
5.やきそば、水(100cc位) を投入。麺をほぐしながらいためる(3分)
6.皿に盛りつける。(30秒)
合計5分で完成。
(+5分でできること。目玉焼き。)
7.4の間火を止めずに、フライパンに水を100cc位入れる(10秒)
8.フライパンに卵をおとす(10秒)
9.アルミホイルをかぶせる(3分)
10.焼きそばの皿に出来上がった目玉焼きをのせる(1分)
4分20秒。
わずか10分たらずで目玉焼きをのせた焼きそばができるのだ。 自炊する時間がない人は、ぜひ焼きそば生活を試してみよう。 健康に良いか、飽きるかは別として、コスパ最強です。
PDMもPOもPLもいないとき。
タイトル通り、プロダクトマネージャももプロダクトオーナーもプロジェクトリーダもプロデューサもディレクターも、いないとき開発エンジニア採用された私のキャリアの一つとして、こうゆう道もありなのかなー。と思ったので書いておく。
一般的には、 BU/Marketing - PO/PDM/PL/Director - Engineer Leader/Scrum Master - Engineer/Programmer
こんな構成が一般的だと思う。 私のグループには PO/PDM/PL/Director このポジションがいない。正確には、 PO/PDM/PL/Director - Engineer Leader/Scrum Master ここの境目がない。ディレクターはエンジニアにタスクを振ったり、エンジニアリーダが事業の要望をヒアリングしたりする。 Sprintも組んでない(やっと組めそうな予感)のにスクラムマスターなんて大層な肩書きは語れないが、 私は元々エンジニアとして入社し、メンバーにタスクを降り始め、今はプラスで事業要望のとりまとめをしている。
POとScrum Masterは一緒にやってはいけない理由は、両立は手が回らなくなるから。と聞いた事がある。 噂通り、このままでは全く回る気がしない。
ただ、希望があるのは、BU/Marketingがめちゃめちゃ協力してくれることだ。 彼らは私たちに事業コンセプト、ツールのコンセプト、要望の目的・背景・効果をしっかり伝えようとしている。 私たちもそれを把握し、納得した上での開発改善だ。デメリットは、決して最速の方法ではないということ。
なぜこうなったか。実は元々 PO/PDM/PL/Director は、いた。 ヒアリング、コンセプトの把握、基本設計、効果検証は彼らがリード出来た。 やはり一番効率的な構成がベストなのだろう。
ちなみに、メリットとしてはBUとエンジニアが相互にお互いの事情を把握出来、 POが一人で握っていた事が一気に展開される事だ。
結論、POは必要。そしていなくても、BU or Engineer LeadからPOは勝手に生まれる。
私は今の会社で初めて尊敬出来るPOに出会った。経営管理とかしてた人なので、 その人に数字の追い方、コンセプトや事業の方向性に対する考え方がまさにProfessionalで感動した。
その内容は事業貢献という視点ではあるものの、エンジニアが成果をあげたりやりがいを感じたりするために必要な要素も沢山詰まっていた。 優しい人、奉仕精神にあふれた人にはなれないだろう。 コンセプト、方向性をしっかり抑え、造ったものが成果を上げ、そのために強い信念を持てる人 が向いてるんだろう。
エンジニアって職業は大好きだ。 でも他のエンジニアにやりがい持ってもらいたいー。とか、ちゃんと事業にメンバーがすごいってことを見せてあげたいー。って思うので、そのために出来る事をしようと思うのです。誰かがそれをしないとエンジニアはそこに居たくなくなるんだろうな。
プロセスビルダーうーむ。。
salesforceのプロセスビルダー。使ってみたが利点が不明である。 フローチャートを書くようにプロセスを記載できるのだが、エラーハンドリングやループ処理等ができない故に 汎用性がない。 特にエラーハンドリングができないと、プロセスそのものが失敗し、トリガー処理も含めた全処理がとまってしまう。
なにが良いんだろう。ページのパスも他のページのようにIDではなく、lightningほげほげで、 どフロントだけで画面遷移してるのか、プロセスごとのURLを持っていない。 つまり、
“プロセスビルダーの、ほげほげって言う名前の処理がね。えっとまずはプロセスビルダーを開いてね。”
っていう共有になる。 うーむ。。。。結果使わない方が安全という感想である。
SOQLのWHEREステートメントへの文字数制限は本当か?
salesforceのクエリの文字数には制限があるという噂を聞いた。
WHERE ステートメントに4000文字の制限があるという。 以下のバッチ処理を書いてみた。
public class QueryLimitCheck implements Database.Batchable<sObject>, Database.Stateful{ public Database.QueryLocator start(Database.BatchableContext BC){ List<String> list1 = new List<String>(); for(Integer i = 0; i < 10000;i++){ String a = 'a0D330000007EY9a'; //実在しないID list1.add(a); if(i == 9999){ String b = 'a0D28000007EY9g'; //実在するID list1.add(b); } } System.debug(list1.size()); String query = 'SELECT Id, Name FROM Jobseeker__c WHERE Id in :list1'; System.debug(query); Database.QueryLocator q = Database.getQueryLocator(query); System.debug('q = '+ q); return q; } public void execute(Database.BatchableContext BC, List<Jobseeker__c> scope) { System.debug('xxxxx =' + scope); } public void finish(Database.BatchableContext BC) { }
1万IDをぶっこんだので、クエリの文字数は15万を超えます。 実行したら普通にID=a0D28000007EY9gレコードが結果(executeのscope)として返ってきた。 噂によるとクエリの文字数制限を超えると結果が返ってこないという恐ろしい現象が起きると書いてあるのだが。 どうゆうことだ。。。同じIDだからいけないのかな?んなあほな。