カイゼンにっき。

@hyokota です。主にtwitterに呟いていますが、twitterに書ききれない事をここに綴って行こうかと。

アジャイルな計画の有効性を伝えるための障壁とは 〜アジャイルサムライ新宿道場#04に参加しました!〜

アジャイルサムライ新宿道場#04に参加してきました。
下記、参加して私が感じたことのまとめです。
※例によって、勉強会のまとめではないことにご注意を。

他のアジャイルサムライ新宿道場#04の記事

アジャイルな計画の有効性を伝えるための障壁

主要な(そして回答が難しい)批判

  1. 最初に全体を見通せないので、適当でないアーキテクチャになったり、局所最適化に陥らないのか?
  2. 最初に全体を見通せないので、契約や予算どりをどうするのか?

この辺りの問いはよく聞かれるが、(少なくとも私は)答えるのが難しい。
常に向き合っていくべき問いなのかもしれない。

下記は勉強会で学んだこと。

最初に全体を見通せないので、適当でないアーキテクチャになったり、局所最適化に陥らないのか?

陥る。
これは認識されており、アーキテクチャの大々的な変更は「アーキテクチャジャンプ」と呼ばれている。
※ニュアンスとして、「避けられればもちろんよいが、避けられない」もののように書かれている。

ただ、アジャイルなソフトウェア開発(主にXP)では、従来の常識と異なり、
変更コストは「時とともに急激に上昇」しない、という仮定を置いている。
※この仮定は、UT, CI, リファクタリング, DRY, YAGNI などのプラクティスからもたらされる。

よって、アーキテクチャジャンプのコストは、それほど大きくはならない。

でも、最初に全体を見通していれば効率よく出来たのに。

答えは二つ。

変更は常に起こるし、最初から完璧なものは出来ない、とされている。
最初に全体を見通すためにいくら努力しても、結局それは正しくない、変更する必要が出てくる、よって無駄だ、という理念がある。

・インフラを構築するために、顧客に価値を提供しない時期が長時間あってはいけない、という理念がある。

では、アーキテクチャはどうすればよいのか?

アーキテクチャ創発を「自然に起こる」のを待つ とのこと。
何となくわかるものの、これでは説明できない。

私にはまだ答えが出せていない。ただ、下記が参考になりそう。

また Jim Coplien は、

開発は2つのレベルで進行する。
(1) アーキテクチャ
(2) 実装
2つは同時進行し、かつ、お互いに強い相互作用がある。
新しい実装はアーキテクチャの変更を示唆する。アーキテクチャの変更は、ふつう大幅な実装の変更を強制する。

と示唆。

アーキテクチャとは? Grady Booch によると。。。:An Agile Way:ITmedia オルタナティブ・ブログ

また、RUPではアーキテクチャを初期に構築している。こちらの考え方も学ぶ価値があるかもしれない。この辺り、もっと勉強したい。

アーキテクチャジャンプは顧客に価値を生まない。どう説明する?

下記の事を、誠実に顧客にそのまま伝えるしかないと思う。

  • 実施しないと、以後の作業コストは増大していく
  • 実施すると、最悪1イテレーション程度、新しいストーリーを実現できない

最初に全体を見通せないので、契約や予算どりをどうするのか?

個人的な見解としては、アジャイルなプロジェクトが誠実なだけではないか、と思っている。
WF(ウォーターフォール)型では、本当に最初に全体が見通せているのか?

そもそも、WF型は全てが予測可能で変化しないことを、アジャイルでは全てが変化することをそれぞれ前提にしている。
両者とも上手くいく、という仮定をおけば、より都合のよい前提を置いているWF型の方が有利なことは当然である。

問題は、その前提が成り立つかどうかだ。私は(そしてアジャイルを推奨する方々も)その前提は成り立たないと確信している。
そして、WF型はこの前提が崩れると弱い。

アジャイルでは、最初に全体が見通ず、確実なコミットメントができないことを真摯に伝えている。

とはいえ、契約が難しいことに変わりないよね?

おっしゃる通り。私も答えは出せていません。
IPAでレポートが出ていたります(私は、実はまだ読んでません)。

参考になる!

なお、海外では、日本よりもずっと、委託側の個人や部門の権限が強いらしいので、
アジャイルなソフトウェア開発における契約形態は、日本ほど問題にならない、とのことです。

この辺りも、もっと勉強したい。

その他学んだこと

私のtwitter上のまとめメモを掲載します。

チーム運用島



宇宙チーム



ワールドカフェ外

SIerでアジャイルコーチ志望の私が、勝手に新社会人(に限らない)SIer社員さんにオススメする本3冊

こちらの記事に触発されて。

mike、mikeなるままに…: @HIROCASTER さんに刺激されて書いてみた、新社会人Javaプログラマー向け、失敗しないんじゃないかなと思う書籍

「読む価値のある本」と言われたら100冊くらい出て来てしまう。ので、3冊に絞ってみました!(と言いたいんだけど。。。)

1冊だけ選ぶなら

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道


プロフェッショナルとしての在り方。職業倫理。
そして、それをIT技術者に当てはめると、具体的にどんな行動とるべきなの?
simpleだけど実践は難しく、いつまでも読み返して行きたい本。

胸を張ってプロという為にどうするか、
Noと言うべきとき、Yesの言い方、
長時間労働ってどうよ?、プレッシャーとの付き合い方、テストの重要性など。

実は技術的な話は、直接的にはそんなに出てきません。今すぐ読めます。だから読んでいるJava入門書はとりあえず放っておいて、


今すぐむさぼるように読んで欲しいです。
今です、今!
「この○○を理解してから読んでみます」とか言わないで!

(幸いJava入門書は待ってくれるので、2日後位にまた読めばいいと思います。)

3冊と言われたら

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解


お仕事をマネジメントする上で、本当に目指すべき形を考える為の本。
答えは、タイトルの通り、よい「ゆとり」が大切。

これは単純に
「本当は馬車馬のように働いた方が儲かるし仕事は早く進むけど、
ワークライフバランスとかあるから、人も大切にすべきだよねー」
という話ではない。

もちろんそれもあるが、
もっとも効率よく勧めるには「ゆとり」が必要、
と確信できる本。

あれ、2冊しかないよ?

もう一冊選ぶのが難しい。。。ごめんなさい。候補を羅列します。

プログラマが知るべき97のこと

プログラマが知るべき97のこと


ソフトウェアアーキテクトが知るべき97のこと

ソフトウェアアーキテクトが知るべき97のこと


よい記事が集まっている。本当の技術者を知る事ができるし、目指すべき理想像が見つかるはず!


達人プログラマー―システム開発の職人から名匠への道

達人プログラマー―システム開発の職人から名匠への道

  • 作者: アンドリューハント,デビッドトーマス,Andrew Hunt,David Thomas,村上雅章
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/11
  • メディア: 単行本
  • 購入: 42人 クリック: 1,061回
  • この商品を含むブログ (335件) を見る

基礎教養。
少なくともこれを読むまで
プロフェッショナルプログラマは名乗れない。

営業とか人事とか、プログラムを書かない方でも、プログラマと関わる人なら知っておくべきレベル。


XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法

XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法


タイトルがいろいろ誤解を生む。とりあえず入門書ではないと思う(英語はXP Explained)。

アジャイルやXPよりむしろ、
ソフトウェア開発で目指すべきゴール、
そのために必要なこと
、がみっちり書かれている本。
最終的に「アジャイル」なプロジェクトを目指さないとしても、是非読んでおくべき本。

※間違えて第二版を買わないように。第一版と第二版は、誇張抜きで全く別の本です。第二版も名著だが、まずは第一版を読む事を強く推奨。

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−


まず読んでみよう。話はそれからだ!簡単に読めて学ぶ事が多い本。

XP入門より先にこちらを読んでおくと、理解しやすいかもしれない。


Joel on Software

Joel on Software



出る杭になるために、出る杭になろうと思う為に、この辺りは読んでみて欲しいなあ。

すでにITとかじゃないけど、こちらもオススメ!

7つの習慣―成功には原則があった!

7つの習慣―成功には原則があった!

  • 作者: スティーブン・R.コヴィー,Stephen R. Covey,ジェームススキナー,川西茂
  • 出版社/メーカー: キングベアー出版
  • 発売日: 1996/12
  • メディア: 単行本
  • 購入: 143人 クリック: 4,708回
  • この商品を含むブログ (774件) を見る

読まないと人生を半分損するレベルの名著。

人を動かす 新装版

人を動かす 新装版


人に関わる仕事をしているなら必須の一冊。特に「部下」が出来たら絶対に読んでおく。

はじめてのGTD ストレスフリーの整理術

はじめてのGTD ストレスフリーの整理術


複雑な知的労働をするなら必須の考え方。
アジャイル」なプロジェクトを目指す方は、「アジャイル」の考え方を理解するためにも必要な教養。

アジャイルな時間管理術 ポモドーロテクニック入門

アジャイルな時間管理術 ポモドーロテクニック入門


簡単に出来て、数多くのメリットが得られる、凄い技。
読むと分かるが、簡単なプラクティスの裏には、深い理由がたくさんある。

アジャイル」なプロジェクトを目指す方は、「アジャイル」なプロジェクトを経験するために便利な、一人でも始められるプラクティスでもある。

最短で達成する 全体最適のプロジェクトマネジメント

最短で達成する 全体最適のプロジェクトマネジメント


この本を追加。
CCPMはもはや必修科目です。広めるのはあなたですよ!

お疲れさまでした!

これらの本は基礎ばかりです。読んでいるといろいろ知りたい事、分からない事が出てくるきっかけの本です。これをきっかけにどんどん本を読んで下さいね^^

他にもオススメの書籍がある諸先輩方、新社会人(と私!)にその本を教えて頂ければ幸いです。

平凡な僕らが世界を改善していくには -Agile Samurai Dojo Gatheringで私が学んだこと-

このblogの(たった今考えた)基本ポリシーとして、
私が個人的に「今回学んだ/考えた中で最も重要と思っている三点」をご紹介します。
イベントのサマリではないのでご了承願います。

今回はAgile Samurai Dojo Gathering!
http://agile-samurai-ja.github.com/dojo-gathering/2012/

これが改善!

「みんな良くない事を黙って見て見ぬ振りをしている。
僕はそれが許せないんだ!」
「僕は死んでも構わない。かかってこいよ!」

ひたすら胸熱。何度スライドを見直しても泣ける。

出来ない理由は不安と恐れ
  • あなたの目指す世界は?
  • 今日は世界の何を変える?

ぶちかませ!!


ねえちゃん、「明日」って「今」さッ!


コミュニケーションと朝会

オム子さんのお話と、ワールドカフェからヒントを得て、独自にやってみたいことを整理してみました。

朝会重要

コミュニケーションを取れる場として、状況を共有できる場として、問題を報告できる場として、朝会の存在は重要。
朝会は「チームビルディング」のために必須であり、「チーム」が出来ていないと、
メンバーのモチベーションが上がることはない、と思っている。


なぜ*5

タスクの「何故」を常に掘り下げないと、方向性を容易に見失ってしまう。定期的な確認が必要だ。

  • 朝会で、本日のタスクの「なぜ」を掘り下げてみる。

タイムボックスを破らない範囲で実施出来るのならば賛成。ひとまずやってみたい。

おやつタイム・LTタイム

こういった時間を「業務時間内」に「固定」で導入してみるのはどうだろうか。
「おやつタイム」は単純なコミュニケーションの場として、
「LT時間」は、メンバーが少し挑戦的な新しいプラクティスやコミットメントを提案する場として。
率直に会話出来る場を固定化することが大事だと思う。

本当のプレゼンの時間を作って共有したい。
  • 本当のプレゼン
    • 「予定にない何か」「新しいこと」を
    • 「断られること前提」で
    • 「相手の利益になるという理由から」「提案」する

現実には、何か「やらされてるだけ」の「報告」で「時間の無駄」な「プレゼン?」が多い。

本を書こう!

You are unique.
You have the ability and skill to create something no one else can!

ジョナサンの講演から。
私は研究者を名乗っているくせに、 本の執筆を考えた事もなかったとは情けない。
貢献することを考える上でも、状況を整理するためにも、本を書くことを考えるのは良いことではないか。

解決したい、自分が強く感じている問題に対して、 最大限の情熱をぶつけて、本を書くんだ!
  • Let your passion shine through.
  • Show them the pain.


読者の人生を豊かにすることにフォーカスする。 何を伝えれば読者の人生を豊かに出来る?
  • 現実的かつ魅力的なストーリーから始める


なお、ストーリーについては、ストーリーテリングの本がある。これを参考にしてはどうだろうか。

ユーザエクスペリエンスのためのストーリーテリング -よりよいデザインを生み出すストーリーの作り方と伝え方 -

まとめ

あなたにしか出来ない事がある。出来ない理由は不安と恐れだけだ。
今あなたが思っている問題を解決していくんだ(そしてそれを本にしてしまおう)。

個人的には、「チームビルディング」が本当に大切だと思う。
全ての根幹のはずなのだが、なぜか軽視されている。
チームを作るためには、失われがちな「コミュニケーション」を取れる時間を「固定的」におくことだ。

固定的であることは重要だ。プログラマは集中するのがお仕事。
「いつでも声かけてよ」と言っても、声がかけにくいのは避けられないのだ。



おまけ:名言コレクション!





※@ryu22eさん コレクションになったのは偶然。

ブログ開設です。

ブログを開設しました。
テストのためにひとまず書き込み。
現在いろいろ設定中。。。

文字数上、
twitterにはつぶやけないことを書いて行こうかと思います。
まだ何を書いて行くかも未定。。。