-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinsapporo20111024
irasally edited this page Oct 24, 2011
·
5 revisions
- 2011年10月24日 19:00-21:00
- エスプランニング開発室
- 参加者 5人
- 5.3 ～ 5.4
- 6ヶ月という期間はどうか
- 「これを超えると危険」というのは感覚的になんかわかる
- フェイズを切って6ヶ月越えないようにしたいと思う
- 長期のプロジェクトの場合「中間納品をして一括入金にしない」などでリスク回避をしないと経営的にもなかなか辛いよね
- 最初から6ヶ月以上かかるだろうとおもわれるプロジェクトは、お客さんにとって本当に必要なものがはっきりとしていなかったりするんじゃないかな
- 必要な物がはっきりしてないと、優先順位をつけたり、スコープを調整したりもできないよね
- 夢（欲しい機能）だけを語ればどんどん大きくなるしね * 最初は本当に欲しいものだけを作るべきだよね、ニーズはどんどん増えるわけなので、小さい動く物をだしていって、改善していきながら大きくしていく方が本当に欲しい物に近づくよね
- 発注者（SIer、お客さん）が欲しい物を、小さな単位で発注できればいいんだよね
- お客さんに発注できるスキルがないからダメ、ではなく、こちらが本当に欲しい物を導き出せるかどうかじゃないかな
- 契約形態としては多分プロジェクト期間 ＝ 契約期間ではないのだろうな
- アジャイル = 1プロジェクトの契約期間が短い = 短期プロジェクトしかないから会社という組織で仕事が回らないというリスクがある となるとは限らないだろうと思う
- お客さんとは長い付き合い、信頼関係のあるという前提で、ただ、それぞれのプロジェクト期間は短い、というようなイメージで読んでいたよ
- 「提案する計画がコミットメントだと思われちゃいけない」ことを理解してもらうことが難しいところだね
- 「できるっていったじゃない」「じゃあいつできるの？いつはっきりするの？」と聞かれる
- 一回数字を出してしまうと覆せなくなるので出したくないと思ってしまうね
- 変更できるなら最短距離を出せるけど、変更できないから最長距離（安心ライン）を出してしまうんだよなぁ
- コミットメントではないという前提で「最短距離」を常に伝えられるようになりたい
- または、最長距離を伝えておくが、短く済んだらコスト分で見積もったお金をきっちりお客さんに返すというやり方はできないかな
- こちらから信頼関係を作る
- 契約としては請負ではなく準委任契約となるかな
- 人月積立的な、柔軟なやり取りがあるお仕事（信頼前提）だったことがあるよ（契約は通年だけど、こことここで集中して開発をお願いしたいというような形）
- お客さんにはビジネスカレンダーがあり、それに合わせて全部作らなくてはいけない、だから「期日について幅を持たせる」ことができることは少ない
- たぶんそういう場合「全部」を一度に詰め込まずに、「やりたいことを実現するため」に必要なものを優先順位をつけて実装していこう（フィーチャを調整する）んじゃないかな
- ビジネスカレンダーにあわせてどれを実装していきますか、という感じで
- 「期日やフィーチャを調整する」ことができるという前提が自分の現実と一番かけ離れているところだな
- 「フィーチャを調整する」ということが感覚としてよくわからない
- 身近なものに置き換えて考えてみると良いのではないかな
- 例えば、屋根のない家をつくることはないから、期日までに屋根は必要だけどインテリアや内装はあとからでも取り付けられますよね、というような感じ
- ↑と同じようなことを、システム開発でこちらがお客さんに提案、説得できるようにならなければいけないね
- フィーチャをしっかり捉えておく、互いに把握しておくことが必要
- 何がやりたいかを聞きだせる技術が大事になるね
- 「期間があって、予算があって、作るものが決まっていない」事が多い現実のプロジェクトの中で一番折り合いがつかないところがフィーチャの調整になる
- 作るもの、欲しいものをはっきりさせることが何よりも大事だね
- こういう考え方をするんだな！と目からうろこだった
- 時間と予算と品質は入れ物（バケツ）、スコープが入れ物に入るもの（水とか）というイメージだね
- 裏テーマ：お客さんとのつきあいかたを考えるだよね
- このあたりはお客さんのことを抜きにしては実現できないことだよね
- 残業 - 残業ありき、で時間を考えるのはタイムボックスを最初から大きくしていることになるからよくない
- 時間、予算を本来よりも大きく固定していることになる
- 何が何でも残業をしてはいけない、というのではなくて、最初から予定に組むのはよくないよね
- 「私達の会社は同じ予算・同じ期間で他の会社よりも作業時間を増やすことができます（キリッ」という形での「他の会社との差別化」
- その差別化を素晴らしい！と思うお客さんと一緒にものが作っていけるかを考えた方がいいと思う
- じゃあどうすればいいか「いざという時は時間が増えます！」ではない方法って何だろう
- いざというときに、お客さんと優先順位をつけながら一緒に考えるということなんじゃないかな
- 品質を固定する、そうだよなぁ、本当に大事
- お客さん：「期日を短くしてください」、自分：「それでは品質は保てません、下がりますよ」というやり取りをしてしまう（こちらから品質を下げてしまうことを言ってしまうようなやり取り）
- でもなかなかバグがあるとわかっているものを出せないよね、そこはそういいつつ期間が短くなっても品質担保を頑張ってしまう
- チームメンバーはジェネラリスト、そしてスペシャリストしかいないという前提（保とうと思えば品質を保つことができるメンバーがそろっていることが前提になっているよね）
- 実際は技術的に未熟で、技術の学習コストを考えたりしなければいけないこともあるよね
- 品質を落としてはいけないというプロとしての考え方をきちんともっていたいね
- 現実問題、テスト期間が一番短くなり品質が落ちてしまうことが結構あるよね
- プロであれば考え方に妥協をしてはいけない -> 期間が短くてもテストをしなければいけない -> 日々の勤務時間ががが
- 品質を保証するためには徹夜をしなければいけない ということを言いたいのではないよね、注意しないと
- スコープが固定ではないと考え方がセットであるからこそ成立するんだよね
- 「なにがなんでも品質を落としてはいけない、機能を落とさずテスト期間死守」というのではなく、「短期間だから（品質が落ちても）仕方ない」という気持ちを持ってはいけないということを言いたいのだと思うな
- 結果的に品質が落ちてしまう現実があったとしても、それを是としてはいけないよね
- 品質を落とさないためにスコープを調整したりしていくことになるんだよね
- スコープが調整できるというのは、ソフトウェアを「機能売り」で見積もるのじゃなくて「まるごと、要望を実現する」という単位で任せる形だよね
- 信頼貯金がないから「機能」に値段を付けて売り買いする方が安全と思ってしまうのかな
- 「こういうことを実現したい」「こういうことで困っている」お客さんに対して、技術者として「こういう方法はどうでしょう」と最適解を示してあげることができるのが、プロジェクトとしてあってほしい姿だよね
- 「目的を話してもらえばきっちり形にできますよ」というプロ意識や前提となる技術が、技術者にあることがもちろん必要だね
- 「機能単位で売るのではなく、実現したいという要望をまるごと任せてもらう」ことのイメージがつかないお客さんにどのような例えを出すとわかりやすいかな
- 贈答用の果物や花を注文：店頭で見せながら果物やお花を選んで調整していくような感じとか
- お酒とかワインや食事：体調や好みを伝えたら、それにに合わせて選んで作ってもらえるとか
- 家を作るとき、とか
- 定既にある部品を組み合わせるだけにとどまらないところがソフトウェアの開発が果物や花を売るのと違うところだよね * 「お客様にぴったりの物・方法を」”考える”ところが大事なんだと思う * だからこれからも、パターンや部品が増えて行っても、すべて自動化プログラミングで人の手いらずで解決、とははならないよね * 「本当に欲しい物をつくる」プロジェクトはきっとそういう方向にはすすんでいかないだろうね
- 「そのお客さんが欲しいもの」を作っていったら全く同じソフトは出来上がらないよね * 常にオーダーメイド（パッケージソフト等でない限り）
- トレーニング
- 長期的に一緒に仕事をするお客さんとの話として考えていいんだろうなぁ
- 業務知識の教育とか
- お客さんがアジャイル的な開発になじむ時間であるとかもトレーニングになるんじゃないかな
- チームはどの要素も大切に考えている、とお客さんに理解してもらうことは本当に大切
- 信頼関係を築いている「彼らならやってくれる」
- 「お客さんが」優先順位をつけることが大切
- これは順位であってリソースをさく割合ではないよね
- MAX-MINと書いてあるから、（我々の）力の入れ具合・頑張り度合い、という印象を一瞬持ってしまうけど、（お客さんにとって）重要 - そうでもない を示してもらうメモリだよね
- 「相対的に」が大事
- アジャイルじゃなくても優先順位は大切だよね
- スコープを諦めてもらう、というメモリの調整をお客さん自身に選択してもらうことに意味があるんじゃないかな
- 四天王の話では時間、予算、品質は「固定」とかいてあったけど、ここでは「相対」になるの？
- ここでの「相対」は物理的なパワーを相対的にどうするという話ではなく、何が大事かを決めるという話
- 何が大事かをはっきりさせた上で、状況に合わせた時間・予算を考えていきましょうという話じゃないかな
- トレードオフ・スライダーは「認識を合わせる道具」
- 優先順位リスト じゃなくて メモリなのが大事、心の重みをメモリに
- 「どれも最優先はまかりならぬ」を納得してもらうことは難しい
- メモリを数値化すべきなのかするべきじゃないのか
- このメモリの割合が現実の契約や計画の数値に直結するのか
- 数字が独り歩きしていくのは怖いよね
- ここでは数値よりも何を大切にしているかを知ることが大事なのではないかな
- このメモリの割合が現実の契約や計画の数値に直結するのか
- トレードオフスライダーアプリをつくればいいんじゃないかい
- Intangibles ＝ 辞書には無形財産とかいてあった
- あえて「とらえどころのないもの」と訳したのかな
- 現実に立ちはだかる四天王の存在が大きくなりすぎて、インセプションデッキに書いてあることを忘れてないか？と問われた気がした
- プロジェクトのコンセプトを見失わないように、アウトプットしておくことは大事だね
- 大事なものが何なのかを気づいてもらうために、目に見えるようにしようということだね
- インセプションデッキなどで、プロジェクトの目的や大事なこと、やらないことを明確化しているというのが前提だね
メモ：P84-85にかけての日本語はちょっとおかしい気がするという話
- それから、どうすればフォースをプロジェクトで活用していけばよいのかについても。
「どうやって」または「活用していけるのか」かな。
次回は11/8 5.5から。