読者です 読者をやめる 読者になる 読者になる

どこぞのエンジニアなマネージャーのブログ。

Perlとかviとかcssとかjavascriptとか(rubyとか)git >> https://github.com/rozary hatenaIDがrozrayなのはtypo

Developers Summit 2017に行ってきた。

f:id:i47_rozray:20170217165022j:plain
知らない人を写さないようにパシャリ。
f:id:i47_rozray:20170217113030j:plain
おNewのスケッチブック

f:id:i47_rozray:20170217113953j:plain
ラーメン一寸星の濃厚煮干しラーメン
https://tabelog.com/tokyo/A1316/A131601/13189651/
麺がとても好みだったので、是非また行きたい。

あんど
f:id:i47_rozray:20170216123331j:plain
ラーメン田丸のネギチャーシューメン
https://tabelog.com/tokyo/A1316/A131601/13189651/
昔ながらのラーメンという感じ。
懐かしい。

セッションのメモ。

f:id:i47_rozray:20170221014429j:plain
f:id:i47_rozray:20170221014457j:plain
f:id:i47_rozray:20170221014516j:plain
f:id:i47_rozray:20170221014540j:plain
f:id:i47_rozray:20170221014555j:plain
f:id:i47_rozray:20170221014604j:plain
f:id:i47_rozray:20170221014617j:plain

ちょこちょこと総括
  • プロジェクトマネージャー(PJM)とプロダクトマネージャー(PDM)のあり方みたいなのがスッと認識できた。

プロジェクトマネージャーだけではおっつかなくなって、というよりも世の中の環境として運用が求められるようになり、
プロダクトマネジメント」の必要性が生まれてきた。

  • 目線を高くもてとか言うけれど、環境に合わせて変化適応させていく大事。
  • 意味なんか後からついてくる。今までの働き方に拘っていたら新しい物は得られない。
  • 要求と設計と実装のジレンマとかあるある。
  • 請求書は、開発費と書かずに初期開発費とする。<<運用を見据えてたりする感じがとてもプロダクトマネージャー感。
  • 自己組織化、どういう状態が理想であるかが共有されていて、それに向けてチームが自走できる状態。

プロダクトマネージャーの有用性を認識できたのは気づきだな。
PDMっていう言葉にとらわれるつもりはないけれど、今の環境って作って「はい終わり。」で立ち行かなくなってきていると思っている。
だからこそ、こういった役割が生まれてきたんだなと。
なんか、視界が広がった感じ。

おまけ

メモをどこ見たらいいのかわからない。
なんかただノートにメモしてましたって感じ。
もうちょっと自由にかこーっと。

MyNA(日本MySQLユーザ会)会 1月に行ってきたッ。

遅刻して参加!

yokuさんのLT芸を見に来ましたよっと。

MySQL即効クエリチューニング(Think IT Books)

「MySQLerの7つ道具の話」
(slideどこだ??
(これでいいのかな。

www.slideshare.net

今日の驚き。
innotopが本にのった!!

innotopが本にのった!!

innotopが本にのった!!

innotopが本にのった!!

あたくし、innotopが好きなのです。

tmax & dstat
innotop仕事してる感ある。<<わかる。
メンテナさんが変わったりなんだりで開発が停滞していたけれどJST1/21で再スタートしていたのだそうだ。
よかったよかった。

(そういえばgh-ostってどうなんだろ。
(ぐぐってみたけれどあまり記事がないや「gh-ost github

4年前のMySQL初心者な自分に贈りたい本とかなんとか。

Explain EXTENDED
optimizer後とか見れる
なんで重いのか見れたりする。

visual explain!!
optimizer_trace << 書き換えている途中が見れる。
20kくらいあるんだと。

performance_schema
autoresizeで、勝手にメモリ食いやがる。

show engine performance status

alter tableの進捗が見れるようになった!<<すげぇ。
(fast index creation = index張る時に全体いじってたのを一部だけいじって対応するやつ。

Use Our Brain!!

タイトル通りチューニングに特化な内容。
いろいろ調べることなく、コレ一冊で勘所が押さえられる感じでとてもよい本!!
今回ツールのお話でしたが本の中には、チューニングのやり方まで書かれているのでかなりよい。

つづいて梶山さん

やさしく学べるMySQL運用・管理入門【5.7対応】の紹介??
黒板本。
確しかに新卒向けに良さそう。

発表は、ボツネタ供養!!

MySQL版あの人は今。

プライバシーのために没!!

歴史に消えたストレージエンジン!!

Falcon
BDB
DB2
この辺くらいならわかる!

以上、遅刻していってしまたけれど、楽しかったぜい。

Regional SCRUM GATHERING Tokyo2017に行ってきた。

@fullvirtueさんが「講演内容を1枚に書く?描くことで、見てもらえやすいだろう。」とやっていた1枚まとめが大変素晴らしと思って
早速真似して自分でもやってみた。
あまり上手く出来ているわけじゃないけれど、描くことで今でも覚えている。

RSGT2017全部のまとめ
f:id:i47_rozray:20170124032504j:plain

Scrum / DevOps の導入を加速するグローバルマインドセット ~8つの習慣 その1 ~
f:id:i47_rozray:20170124032404j:plain

※8つの習慣について具体的に一枚まとめに書いてはいないので以下のスライドを参照するとよし。
講演者のブログ
http://simplearchitect.hatenablog.com/entry/2017/01/16/080245
スライド
https://docs.com/ushio-tsuyoshi/8469/scrum-devops
過去の同テーマのスライド?
https://docs.com/ushio-tsuyoshi/363c32c5-1277-48c0-a02d-1e750ef19a8c


缶詰屋さんの課題解決にスクラムを使ってみた
f:id:i47_rozray:20170124032406j:plain

結果的にスクラムになってる!なのがいいと思う!
f:id:i47_rozray:20170124032407j:plain

最短で成果を上げる!強いスクラムチームの作り方
f:id:i47_rozray:20170124032409j:plain

シン・未来会議 - スクラムチームを支える組織づくり -
f:id:i47_rozray:20170124032413j:plain

Pitfalls of Scrum -- My findings from coaching / スクラムの落とし穴 〜アジャイルコーチが遭遇するよくある問題とその解決方法
f:id:i47_rozray:20170124032411j:plain

つらい問題に出会ったら
f:id:i47_rozray:20170124032351j:plain
ゲーム開発を盛り上げる技術とチームを支え続ける原動力
f:id:i47_rozray:20170124032414j:plain


エンジニアの技術力評価は難しい? - 5年間運用してきた相互評価制度の改善の歴史 -
f:id:i47_rozray:20170124032501j:plain

アジャイル・メトリクス実践ガイド
f:id:i47_rozray:20170124032502j:plain

今回一番衝撃的だった気づきは、(この1枚まとめもかなり良い刺激だったけれど。)
「スプリントにはready状態になったものをいれること」
なんだかんだ横断的だったりして並行作業でスプリントを開始していたりして、
ちょくちょく完了しきらないっていう事象があったんだけれど、
よく考えたらそりゃそうよね、完了できないスプリント状態にしていたんだもの。
これなかなか気づかないポイントな気がする。

それから、8つの習慣。
agileって、スーパーマンなメンバーが揃わないとそうそうなしえないと思っていて。
(ウォーターフォールは逆にそうでもないという印象がある。)
しかし、そのスーパーマンっていうわけではなく、揃えなければ行けないのは西洋文化の価値観、習慣である。
という話にはとても合点がいった。
自分が出来るか出来ないかは問題じゃなく、大変そうな人がいれば声をかける、助ける。
っていう習慣があるとか、まさにagileじゃん。
日本だと、出来るできないみたいなのを考えたり、セクションに囚われたりしてそういうった習慣がないなと。
他にもこの習慣は、今まで思っていたスーパーマンに対する言語化であって、認識がとても進んだお話だった。

今回もとても気づきのあるRSGTでした!
運営の皆様に感謝!!

「TECH TALKS -ソウゾウ×グノシー×エウレカ 技術トップが語るこれからのエンジニア組織-」に行ってきた。

ちょっと日付が経っているのですが参加してきました。

久しぶりに組織のお話。
学びがあったので、ちょっとザクザク絞って箇条書きにしてみた。

組織、チームのフェーズに合わせてマネージャーを合わせていくのはよいなと。

それでいうとCTOはチームの立ち上げ時に基礎づくりってのは有る手。
その後は、チームを大きくしていくのが得意な人に託す。
0→1
1→10
10→100
みたいなフェーズ訳の話も思い出す。

インセプションデッキは、マネージャーを置かなくてもチームを動かすことができるとか。

最近インセプションでっきやってないなー。

基本少人数チーム。

関係ないけれど、LeSSを勉強してみたい。

PJを対ユーザーよくしようというのがPJの責任者。

システムを良くしようというのが横軸の責任者。
やっぱりPJまたぎつつチームにがっつり入るのは大変だよなー。

そもそもあんまりリファクタやらない。

ユーザーメリットがなければやらない。

これは面白いなって思ったこと。

抽象的なものを投げられる人をリーダーにする。
この表現はなるほどと思った。
そこからエンジニア観点でタスクを形成して進められる人は強いなーと。

また開催されたら参加したい。


f:id:i47_rozray:20161124205504j:plain

第5回CodeIQ感謝祭「食欲とプログラミングの秋」に行ってきた。

勉強会 備忘録

ほんのちょっとずつ、時間取れ始めたかなぁと。
またブログを書き始めてみる。
振り返ってみると、4年くらい書いてなかったのね。

09月24日に開催された「CodeIQ感謝祭」について、参加した振り返りを以下の流れで。

  • 感想まとめ
  • キーワード
  • 各々の振り返り << だらだら長いやつ。

感想まとめ

  • 初参加!!
  • 採用とエバンジェリスト話に興味をひかれていってきました。
  • とても良かった!
  • ずっとホールにいたので今度はブースとか懇親会とか参加しよう。

キーワード3つ

  • スキルも大事だけれど、カルチャーはより大事

スキルは伸ばせる。
カルチャーはなかなか変えられない。

  • 自分ごと化

当事者意識とも

  • 探求力

質問力ではなく探求力という言葉がオススメ

残りは備忘録的にツラツラと書き残しておく。
※あ、ちなみに自分の勝手な解釈が交じるので、講演内容とは違う所がままあると思います。

続きを読む

エンジニアはプロジェクトマネジメントを知るべきか知らざるべきか。

ボクの答え

「知るべき。」という自分の答えは先に言っておく。

知って、正しく進むプロジェクトなのか否かを判断するべき。
可能であれば、自分でプロジェクトマネジメントをすべき。
もっと可能であればプロジェクトマネジメントしながらエンジニアリングもすべき。
※自分のエンジニア欲求とプロジェクトの成功の為に。

エンジニアリングのスペシャリストという目指すのもあるが、
どんなスペシャリストでも解決できない物もあると思う、
それは時間とお金と人。よくいう有限なリソースですね。

どんなスペシャルであったとしても、
適切に調整されたプロジェクトでなければ、
こなしきれない問題もあると思うのですよ。
一般的にはね。

※いや、もしかしてそれをも凌駕するスペシャリストなのかもしれない。
「どんな無理難題でもそれを超越し周りに成果を及ぼす人」だ。そんな人がいれば、
その人に合わせたマネジメントを行うだけだ。

エンジニアがいくら頑張ってもプロジェクトという観点では越えられない壁があるのではないか?
※逆にプロジェクトマネジメントがいくら頑張っても越えられない壁もあると思うけどね。
青い銀行とかね。
と思うわけです。

つか、エンジニアリングに降りてくる前に、その前で訂正するほうが費用対効果が大きいわけですよ。(不確実性コーン!!

とはいっても、プロジェクトマネジメントをしたからといって成功するわけでもないのですけれどね。

偶然成功することもある、が成功するセオリーというものもある。

じゃあプロジェクトマネジメントができれば幸せか?
というわけではない。
プロジェクトマネジメントもやはり専門領域で、
エンジニアリングと並行するのはとても大変である。
そうなってしまうと、自分の好きなエンジニアリングを諦めなくてはならなくなってしまう?そういったこともあるだろう。
(実際、今の自分はそんな感じ。

だがしかし、自分の成功よりもチームの成功。という観点もある。
だよね、そこは自分が納得するものを選ばなければいけないわけだ。

そんな「決め」の問題のなかで、どうすべきか??

自分の定義する成功に対して、論理建てて行動すべきかと思う。

自分勝手に考える。
やたら頑張る。

ではなく、今までのでの人類の知見があるのだがからそれを知り、
利用するでもよいし、捨てるでもいい。
しかし、それを利用しない手はないんじゃないかと。

結局何をすべきか。

「世の中に不満があるなら自分を変えろ、それが嫌なら耳と目を閉じ口を塞いで孤独に暮らせ。 」

攻殻機動隊の言葉は有名よね。

※自分を変えろというよりも、周りを変えろ。
とか思ったりもするんですけれども

自分の欲求があるなら、それに従うべき。と思う。
「楽に働きたい」でもいいし。
「多くの人に楽しんでもらいたい。」でもいいし。
などなど、なんでもいい。

ただ、それを実現する手段として、適したものは何なのか。

今一度考えて欲しい。

それは、エンジニアなのですか?
それともまた別の手法ですか??

自分の欲求がたとえ「技術一本勝負!!」などであっても、それを実現するためには、
マネジメントが必要だったりしませんか?(自由を勝ち取る為の、周りへの情報共有、マネジメント。)

まとめ

考えだしたらきりがないし、ボクはPMは知っているべき。
という偏見から書きなぐっている所があるので、なんとも申し訳ないのだが。

結果を実現するための手段、スキルは多く深く持つべき。

と思うのです。
それだけ実現の可能性がますと思うから。

ルール以外はノールール。

「AはBだから…Cだよね。って勝手に思っていませんか?」

shibuya.pm行ってまいりました。

勉強会

http://shibuya.pm.org/blosxom/techtalks/201506.html

※以下、talkとは別に項目が立っております。

■nginxの奥深さをいまさら感じた
トラフィック抑えて高速化
gzip_static gzipしたり展開してくれる

その他楽しいオプションいぱーい。
https://speakerdeck.com/cubicdaiya/nginxfalsepahuomansutiyuningu

■Perlingual がすごい
perl のソースを なでしこに!!(phpやjsにも置換できるよ。)
http://e8y.net/post/120535406440/shibuya-pm-17-acme-perlingual(勉強会のブログ)
http://perlingual.koneta.org/(デモページ)

デモおもしろいよ!

■GazelleはISUCON用
前回優勝のkazeburoさん作

2014優勝してきたよ
http://blog.nomadscafe.jp/2014/11/isucon4-isucon.html

ベンチとか紹介とかgitとか
http://blog.nomadscafe.jp/2014/11/gazelle-new-simple-and-fast-plack-handler-for-performance-freaks.html
https://github.com/kazeburo/Gazelle/wiki/Benchmark

■h2o @kazuho
ちょっぱやhttpサーバー
http://blog.kazuhooku.com/

■one source code で「複数のサービスに対応するが schema 構成は微妙にに違います」という要件に直面したら開発はどうすればいいのか、僕なりに何日か考えた上でのややベターな結論のようなもの - @Yappo

これ、資料ないんですけれど、自分にはとてもよいきっかけになるお話だった。

想像するに、スキン替え的なことが必要なときにどうするかとか、
自作のモジュールの仕様変更をどうしようかと考えているのでよかった。

環境変数とかグローバルで処理分岐させるのよくない。
メソッドもあまり。
・クラス、名前空間をわけて管理ぐらいがちょうど良い。
だそう。

その方のISUCON2014の体験談
http://blog.yappo.jp/yappo/archives/000846.html

■その他
技術スライド英語で書こうぜ。
http://tagomoris.hatenablog.com/entry/2015/06/01/210425