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

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

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

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

序章

チームで活動していると、振り返りとか課題提起とかよくやると思うのだけれど、
「○○を改善しよう。」とか「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
この辺くらいならわかる!

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

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