builderscon 2018に参加、LTもしてきたん。

builderscon.io

こちらのイベントの趣旨

buildersconは「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りです。

開催は、確か今年で3年目でしょうか?
初年度は、チケットが取れずに参加できませんでしたが、去年今年と参加。

ふりかえり

今年は本当にフラっと参加した感じだった気がする。
けど、途中のどのタイミングからか、「ああそうだ、『知らなかった、を聞く』会だった。」と考え、敢えて自分のよく知らない領域を聞きに回る感じで動き出して…。
結果、なぜかガジェット工作とか活用とかのセッションばかりを聞いていた。
そして、ガジェットに対して変な知識とモチベーションがついた。(気がする。)
きっとそういうことで良いのだろうな。

運営の方やその関係各所の方に感謝です。

ノベルティ

ビルコンのバッグ(トートバッグじゃないほう)がとても欲しいサイズだったので歓喜
ナフダ、うずらさんのトークで経緯を聞けてさらに実感したところがあるのですが、
あそこまでのレベルで提供できたからこそ、自分も影響されたし、他の方も影響されたのだと思う。感謝。
ノベルティが一つの袋に収まっているのは心憎いサービス。

LT

speakerdeck.com

今回は、LTにて登壇させてもらった。
自ら話すことで、持っているモチベを深められたことを感じました。
自分の考えに対して背中を押してもらえている感じをうけて。(PMの必要性についてね)
トークを聞く楽しみとはまた違った楽しみですね。
感想、質問いただけた方に特に感謝。

HUB

今回は、合間でHUBに行ってビール飲んでたりしました。
(休みを満喫している感じですね。)
たまたま居た知り合いの方(さらに知り合いの方も)ともお話ができて良かった(小並感)
そういったところもまったりと参加できて心地よかったなと。

食たち(懇親会、アフターパーティーは撮り忘れ)

f:id:i47_rozray:20180909134059j:plain
f:id:i47_rozray:20180909134604j:plain
f:id:i47_rozray:20180909134601j:plain

カレーが湯気でレンズくもる(汗

おまけ

聴講できたトークは12だけれど、聞きたくても聞けなかったトークが24。
まだ自分のビルコンは終わりそうにないのかな?

個性とワクワクで繋がる組織文化(Management 3.0 X アカツキ)に行ってきて、凡そ3行でまとめてみた。

3行

アカツキ 良いとこ 一度はおいで

アカツキさん(3行)

魂、ハート 人、組織について投資する 初期から哲学がある

Management3.0の理解。(α+3行+α)

コミュニティのように有機的であるが、活発で自律的な組織を、仕事の場所でも作れるだろうか? 逆に、意義を見いだせなかったら抜けることができる。

コミュニティは自然に任せても許されるが、仕事は自然に任せきってはいけない。 コミュニティは途中で止まっても良いが、仕事は完遂させなければいけないから。 それを”システム"に落とし込もうとしているのがManagement3.0なのかな。

システムに落とし込むときのキーワードがマインドセット

自分の疑問と考え。(3行+α...)

マインドセットしてもしきれない人間もいる。 それから、マインドセットすべきでない、認めるべき別の価値観の人もいる。 マインドセットすべき人もいるでしょう。

多様性と画一性のバランス。

今の自分は、あまりマインドセットをするつもりなく、ハマればハマるしハマらなければハマらなくて良い。 前向きにマインドセットするし、されるけれど、 コストかかるなら(例えば、若い方であれば1年、そうでないならば3ヶ月〜半年など)、別の道を歩むのが良い。

チームビルドは何かしらのアウトプットする時の本質ではないと思う為。

キーワード(3行+α)

  • 自己組織化、モチベーションと惰性、嫌悪
  • 価値キーワードとストーリーテリング
  • チームは、関係性があってのもの。自分として言うなら熱みたいなものの関係性があるのがよいな。 アカツキさんだと、魂とかハートの関係性な感じがする。

感想(3行)

Management3,0が改めてしっくりきた。 今までの理解=チームビルドのプラクティス 今の理解=現場でもコミュニティのようにワイガヤしたいんや!

つぶやき(2行)

  • management3.0のタグだけだと、他のも拾っちゃうので、もう1個タグつけるべきだった。
  • 文化が無い所は作ればいい。文化があるところは合うか合わないかを確認すればいい。 気をつけなければいけないのは、文化が無さそうに見えてあるところ。 インプットアウトプットの文化があるところが好きだな。

課題を考えるチームより理想を考えるチームが成果に近い。

序章

チームで活動していると、振り返りとか課題提起とかよくやると思うのだけれど、
「○○を改善しよう。」とか「xxがよくなかった。」とか「じゃあ次回△△しよう。」とか、
そういったコミュニケーションとってますよね。
KPTなんかもよく使われてたり。
それが如何によくないか、という話をしたい。

それって本当によくないことなの?

「問題を出し合おう。」
と言って出てきた考えに対応を苦慮したことはないだろうか?

それは今やるべきことなのか?
優先順はあっている?
最悪なことに本当は必要なことだったりしないか?
実は勝手にそう思っているだけではないか?
そういう課題ではなく別の課題の話をしたい。

とかいう話。

そこで事前にやっておくべきは
「チームとしてどうありたいのか。最適な状態は?」
とちゃんと理想を考えておく必要がある。

「どうありたいか」に対して無駄なことであれば課題であるわけだけれど、
そうでなければ今考える必要はない事柄なわけです。

それをないがしろにして「悪いよね」「改善したいよね」とか話をするから、
方向性が常にバラバラになりがちになり。
振り返りなどで改善の実感を感じられなくなる。

その改善方法であっているの?

「課題は見つかった。じゃあ改善方法を出し合おう。」
ってなったときに、また注意しなければいけないことがある。

その改善方法であっているのか。
課題の改善方法は様々である。
ある特定の期間や人、プロセスなど改善方法によって効果の現れ方が千差万別である。

これまた、
そこで事前にやっておくべきは
「チームとしてどうありたいのか。最適な状態は?」
とちゃんと理想を考えておく必要がある。

「どうありたいか」に対して因果関係がある改善方法が選ばれるわけで、
手当たりしだいに対応してはやはり無駄。

チームで同じ方向を向けているか?

(かなりそもそもな話…。
日々チームで行動しているわけだけれども、
理想はすりあっているだろうか価値観は認めあえているだろうか。
このような点がすり合っていないと、
互いにモチベーションのギャップが生まれチームワークにも溝が生まれていく。

これまた、
そこで事前にやっておくべきは
「チームとしてどうありたいのか。最適な状態は?」
とちゃんと理想を考えて互いに認識しておく必要がある。

もしすり合わなかったり、許容しあえなかったら、
早めにチームをビルドし直す方がよいだろう。

振り返り

最近ネガティブワードで話をする人が目について、結局何をしたいのか、
何を理想としているのかわからないな。と思った。

課題だけで語らず、理想をもって課題を語ることの方が、
何が必要で何が無駄なのかをちゃんと考えられるようになるだろうし、
仲間もちゃんと集められると思う。

おまけ

KPTの乱用をするな。
TODOフレームワークじゃない。

YAPC::Kansai 2017 OSAKAに行ってLTしてしまった。

f:id:i47_rozray:20170304101859j:plain
新大阪駅からの歩道はどこがどうつながっているか難解。

f:id:i47_rozray:20170304102229j:plain
会場のMOTEXビル

f:id:i47_rozray:20170304102516j:plain
次回は福岡

f:id:i47_rozray:20170304170240j:plain
A会場を見上げて

f:id:i47_rozray:20170304201028j:plain
懇親会

f:id:i47_rozray:20170304111317j:plain
カレーライスに青のりポテトハック

発表した資料
スケジュールに意志を込める〜納期と品質、立ちはだかる優先度。 その時君は何をすべきか。〜
※計算間違えしていたので修正。
※写真とかも一応パブリックなものなので削除した。
※あと所々修正。

いつになくいろいろと反省と気付き、学びの多い会だった。
次回も楽しみ。

2月22日、アトラクタさんのスクラムトレーニングに行ってまいりました。

コスパ最強?

1日通しの研修でした。
認定スクラムマスター研修は、3年前?4年前?に行っているんですが、
自分の状況も変わったので、再発見・学習の為にと参加してきました。

端的に行ってしまうと、1日の研修なのにかなりの再発見があったなぁと感じました。
スクラムマスター研修は2日 or 3日ですが、
今回のは1日の開催なのにも関わらず、かなり中身があるもでした。

得たものがたくさんあったので、その中でも特にというものをまとめてみる。

スクラムは、カオスな環境にこそ必要。

スクラムは変化に適応することを重視しているプロセスだと思いますが、
まさにその通り、要求が変わる、増えるといったプロジェクトにこそ使われるとよい。
要件定義から1個1個決定し戻れない(戻るには改めてプロジェクトが始まる状態になる。)ウォーターフォールは、
変化に適応しづらい。
言ってみればその通りなのだけれど、チームビルド的な内容もスクラムは持っているので、
カオスなのかそうでないのかという指標で導入をする、しないみたいなことも判断すると良い。
アジャイルは速度を出すものよりは、変化に適応するための手法。
オーダーメイド的プロジェクトに対する答え。

見積もり以上のものをやろうとして失敗する(ことがある)。

見積もり=合意をとった状態なので、それを完了できるようにすればいい。
見積もり以上のものをやる必要はない。<<オーバーコミット。
そして失敗しては意味がない。
この場合の見積もりは、成果物見積もり。人日の見積ではない。
この辺がちょっと、ウォーターフォール的なやつと違う。
この期間にこの成果物を完成をします。という見積もり、合意。
この作業をやるのに、この人日が必要。とは逆の感覚。

(難しい問い)人数が少ないチームの場合、技術領域がカバーできずに1チーム1スプリントで完成させることが出来ないのではないか??

人数が少ないならクロスファンクショナルになる。
クロスファンクショナルが難しい場合は、
アーキテクチャを揃えてチームを越える。
プロトタイプ的、ダミーのものでレビューをかける。
ミニウォーターフォールをある程度受け入れざるを得ない事もある。
チームごとにready状態を意識する。
=>足回り(アーキテクチャやダミー、開発フローも含まれるだろうか?)を固めるのが重要。

プロダクトオーナー=プロダクトマネージャー??

プロジェクトの価値を考えるのかプロダクトの価値を考えるのか。
自分の周りでは、作っておわりではなく作ってからも価値を変更、追加していくプロダクトが多いので、
プロジェクトマネージャーよりもプロダクトマネージャー的思考・活動の必要性を感じる。
※プロダクトマネージャーは4年程前からプロジェクトマネージャーから必要に迫られて分岐した。
的なことをこないだのdevsumiで聞いた。

結び

という感じで、かいつまんでまとめてみた。

なんか研修にいくことでウラ(研修とは別の話)ではいろいろとありましたが、
幸せに終えることができました。

次回はQAアジャイルの研修だそうです、これからもアトラクタさんのトレーニングには期待です。

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
この辺くらいならわかる!

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