ITと哲学と

IT系エンジニアによる技術と哲学のお話。

AgileJapanOsakaサテライトにお邪魔しました

6/4に開催されmAgileJapanの大阪サテライトにお邪魔してきました。

agilejapanosaka.doorkeeper.jp

スクラムイノベーションを加速する 〜ソフトウェア以外にも適用されはじめたアジャイル〜(Joe Justice 氏)

5月に行われたAgileJapanのKeyNote映像を見ました。講演の資料は以下のリンクにあります。

http://www.event-info.jp/aj2016/Keynote1_ScrumIncAgileJapanJ.pdf

ソフトウェアの分野で広く浸透したアジャイルが、ハードウェアの世界でも使われ始めているというお話でした。 幾つかの具体例が示されれていましたが、その中でも圧巻だったのが飛行機の例です。 あんな大きな物理な物もアジャイルで作られるんですね。

1台の飛行機を1チームで作ろうとするとチームが大きくなりすぎてしまうので、2pizzaチームの枠に収まりません。 なのでこの例ではチームを7つに分解して作っていたようです。

会場からその後の質疑応答でありましたが、「チームを適切に分けるって難しいよね」的な話があり、実はこの飛行機作るチームも チームの分け方では失敗を繰り返し、試行錯誤したそうです。

ただ、なんか納得できないところもありました。 Scrum: 倍の仕事を半分の時間でこなす技(上記資料より引用)とか認定スクラムマスター資格を持ったコーチがチームにいれば生産性が2~4倍上がる的な話がありました。

個人的にはこんなの見てしまうと、ほんまかよ、と身構えてしまいます。 あんまり僕はアジャイルとか詳しくないんですが、タスクを短い時間でこなす技だったんですかね?うーん。。。

アジャイルの論点はタスクを効率良くこなせるかではなく、変化を取り入れながら価値を最大化するといったことだと思っていました。

倍の価値を半分の時間で出すとかならまだわからないでもないのですが、倍の仕事をこなす技ってのは違う気がします。

アジャイルと比べて、WFでは変更コストが高くつくので、アジャイルと同じアウトプットに至るまでに、変更コストを払った結果、倍の時間がかかるという事であれば、それは価値の話であって仕事量の話ではないのでは。。。

なんか言葉の表現の問題な気もしてきました。原文はどう書いてあったのでしょうか気になります。

カイゼン見える化ーチームワーク(原田 騎郎さん)

すごくすごい講演でした。グサグサ刺さる刺さる。 すごいお人ですねこの方は。

衝撃を受けすぎて散文的なメモしかありませんが、再構成しながら載せます。

見える化の文脈で出たお言葉

プロジェクトが混乱するのは、何かが見えないから。

自立していて、納期を守る、従順なチームが欲しいマネージャについてのお言葉

従順であれ!的なことをマネージャが言うと、タックマンモデルの混乱期に入れない。 乗り越えられない。チームが強くならない。

自分の欲しいものを測る方法をしらないマネージャーは、結局自分の測れるものを欲するようになる。 みなさんのマネージャはいいエンジニアを知っていますか? みなさんのマネージャはエンジニアをどう評価しますか? みなさんのマネージャのエンジニアの評価軸は何ですか?

改善について

何のために改善するの? 改善って、仕事をより簡単に安全にすることだ。

改善のために時間を。 改善のための時間は優先度高い。 改善のための時間をとって、喧嘩するべき。 それをしないからクソコードを量産するんだ。

変化を抱擁して前に進むためには

変化を抱擁するには、余裕が必要だ。

  • 時間の
  • リソースの
  • 体力の
  • やる気の
  • 心の

余裕が必要だ。

これがない状態で変化を抱擁せよとか言われてもこのやろう!としかならない。

事あるごとにこれ思い出そうと思いました。