-
Notifications
You must be signed in to change notification settings - Fork 49
Readingagilesamuraiinsapporo20111011
irasally edited this page Oct 11, 2011
·
12 revisions
- 2011年10月11日 19:00-21:00
- エスプランニング開発室
- 参加者 6人
- 4.5 ～ 5.2 まで
- ご近所さんが全くいないと思っていることと、意識しておくこととではぜんぜん違うよね
- 二次請け、三次請けだと「良好な関係を築く」のは難しいよね
- 他の関係者のことをお客さんに説明したら怒られることがある
- プロジェクト内で影響があるかもしれないところを意識しておくのは大事だよね
- それは大事
- でも往々にしてひっくり返されてしまうのだよね、担当者にINPUTしておいても
- INPUTしてもどうにもならなかったということも結構あったんだよね
- マネージャー層や一次請けの会社に意識して欲しい内容ではあるね
- 二次請け、三次請けだと「良好な関係を築く」のは難しいよね
- 関わってこようとしてくるのではなく、参加して欲しいのに関わってくれない「ご近所さん」もいるよね
- 挿絵の矢印の方向（ご近所さん→コアメンバー）と逆の場合もある
- 矢印の向きにかかわらずコミュニケーションを取るのは難しいよね
- 仲間は多いに越したことはない
- 同じ会社内の「ご近所さん」は他の部署の人になるよ
- 大きいプロジェクトだと余計に、（社内などの）他プロジェクトなどの人との関係が重要になる
- 良い関係を築いておくと、いざというときに助けてもらえた
- 何かが起きたときに初めて会うというのはとても気まずい
- 普段からコンタクトを取ることができるようにしておくとよいねー
- 喫煙所コミュニケーションもあるよね
- よくも悪くも
- ご近所さんを助けるときの「工数の壁」-> 社内でもプロジェクトが異なると工数を出さないと何も動いてくれない
- 信頼、良い関係が大切になってくる
- 組織から頼むと色々大変なので、個人のつながりを作れる方法を模索する必要もある
- 普段から一緒にご飯を食べているとか
- おみやげを渡すとかそういうことも含めて
- 総務の人を味方にするのって結構大事
- 大切なご近所さん
- エンドユーザーをプロジェクトに巻き込むと、自然とご近所さんも近くなるよね
- 見えないご近所さんも自然と増えていく
- エンドユーザーを巻き込めないとなかなかご近所さんとの関係がご近所にならない・・・
- チームの仕事がチームだけで成り立っているわけではないことは意識しておく必要がある
- アジャイル的な開発の実践はチームだけで実践できることが結構あるけれど、進めていくと「お客さんを巻き込む」ところが第一関門となる
- 現実問題その先の実践がとても難しい
- 「ご近所さん」とうまくやっていくための作戦って？
- 「助けを求めたくなる前から知り合いになっておくあれこれ」
- 今あるコネクションを使って、ご近所さんと知りあう
- 「このプロジェクトやってます、よろしくお願いします」と挨拶する
- 先に恩を売っておく（何かあった時に助ける） とか
- 文化として他の（立場の、プロジェクトの）人が来ることを好まないところへどう入り込んでいくか、難しいねぇ
- 顔見知りになるためだけにどこかで偶然出くわすとか
- 営業の人はそういうノウハウありそうだねー
- いろいろな選択肢がある、煙たがられたらごめんなさいで他の方法を探せば良い
- とにかくまずはやってみる
- アジャイルの良さや価値を共有できていればやりやすいけど、経験則（ウォーターフォールでの開発実績）を元に判断されて、新しいもの（実績がないアジャイル的な開発）を警戒されてしまう
- 経験則を開発者側からうまくひっくり返していく方法が難しい
- 継続的なお客様だと徐々に導入していくこともできそうだけど、単発のお客さんだと難しい
- 「弊社の実績」として導入していくとか
- エンドユーザーと開発者の間にいるSIerを味方に付けないとねぇ
- 本来SIerはそういう橋渡しができる立場だよね？
- 「助けを求めたくなる前から知り合いになっておくあれこれ」
- 「ご近所さん」を洗い出すというプロセスをやったことがなかったけど大切だなぁ
- 最初のブレストでやってみるのはよいなぁ
- PMの立場の人にもぜひ知っておいて欲しい内容だね
- これは！現実的には厳しい！
- この弟子、普通の会社だとクビになっちゃう・・・
- 実際問題、マスターセンセイの言うようにできることなら中止したほうがよいプロジェクトってある
- マスターセンセイはあえて厳しいことを書いているんだと思う
- 書いてあるようにお客さんにはっきり言ったり、他のお客さんの仕事をするというわけにはいけないことが多いけど、理想に近づけるためにどうしていくかだよねぇ
- これはアジャイル的な開発じゃなくても大事なこと（PMBOKにも同じようなことが書いてあるよ）
- 特に「解決策に同意していることを確認すること」は重要だね
- ツールや技術に抱く「期待をマネジメント」すること
- やること、やらないことを明確にする
- 方針については4章で考えたプロジェクトの方向性が主軸になるんだよね
- 解決策の検討は、顧客を交えてやることだよね
- ですね
- 最初の検討でどこまできめるのか
- ガチガチに決めて「絶対に変えちゃいけない」となってしまうと大変
- ある程度は「これから」っていうところがあってもいいはずだよね
- 規模感、予算がはっきりする程度にはこの段階で決めたいよね
- 有償/無償プロダクトの選定とか、サーバー台数とか（政治的なことも関わってくるね）
- アーキテクチャが政治的に決まっていてどうにもできないこともある
- チームを選ぶ＝アーキテクチャを選ぶ
- チームが先に発足していて、チームの得意な分野で開発できたら最高
- リーダー（一人）だけ決められて、アーキテクチャが決まった後に他のメンバーを選ぶ（呼び集める）こともある・・現実はそっちのほうが多いかもね
- 「アーキテクチャはこんな感じ」と描いた資料が「あとから絶対に一つも変更しない必須の要件」になってしまったら大変
- 出来るかできないかを判断するための目に見える材料として描くことは重要だね
- 描いたものをもとにしてお客さんや他の人と話ができるようになる
- 足りないところ、やばいところを可視化する重要性
- アーキテクチャでよく見る「アウト」なケース（余談）
- 全体像を見極められていないケース
- アーキテクチャの設計段階でシーケンスが書かれていてシーケンス単位で値段がついている（驚愕）
- 役割を説明できないのに「処理内容」だけが先に書かれているアーキテクチャ
- アジャイルじゃなくても大切なこと
- プロジェクトのはじめにリスクを出すのは大事
- 不安の解消に必要なことだよね
- チームメンバーとしてリスクを出しあうことは大きな備えになる
- お客さんに対してリスクを隠蔽したがる、お客さんは完璧を求めたがる
- お客さんがリスクがあることを許してくれない
- お金を払っているんだからリスクはゼロにしてよ
- お客さんが協力してくれるかどうか、それがリスクだったりする
- 「あなたが一緒にプロジェクトに関わっていくことが成功への道なのです」ということをうまく説明できるといいな
- お客さんがリスクがあることを許してくれない
- リスクがあることをお客さんにインプットすることがタブー視されている
- 「リスクゼロです」と言われても不安になると思うんだけどなぁ
- リスクがあります、というと仕事が取れないシーン
- A社「このプロジェクトにはこんなリスクがあります、こんな回避方法を考えていますが、プロジェクトが進まないとリスクと思っていることが発生するかどうかはわかりません。」
- B社「このプロジェクトにはこんなリスクがあります、こんな回避方法を考えていますが、プロジェクトが進まないとリスクと思っていることが発生するかどうかはわかりません。」
- C社「我社がやればリスクなんて一つもありません。全部できます、完璧です。」← お客さんがこれを喜んでしまう
- ほんとうにそうならC社が一番いいだろうけれど、ぜったいにリスクとなることがない場合なんてあり得ない
- でもこれってリスク検討にお客さんが入っていないよね？
- リスクの検討にお客さんが参加していないと「リスクゼロでできます！」を信じられてしまうよね
- 逆に「リスクがあります」とお客さんに言うと「なら全部のリスクを出せ」と言われてしまって大変な思いをしたことがある
- そういう問答になってしまうのは、そもそもお互いの信頼関係が足りてない気がするよね
- お客さんにも「やってみなくちゃわからない」ことを理解してもらう
- 安心を与えるためにリスクを洗い出し、その対処法、対策を伝える
- リスクを発見するのは往々にしてエンジニア
- エンジニアからどうやって指摘するか
- 「良いシステムを作りたい」という思いが指摘しても問題ないはずだよね
- 信頼関係があるのが前提
- なかなか人に思いを伝えるのが苦手な技術者が多い
- 技術者、と一括りにするのはよくないけど、傾向として
- 「無理です」「代案も無いです」としか言わない技術者 -> それはもう「技術者」じゃない
- 現実世界では技術的無理より納期や予算による「無理」が多いのも事実だけど
- 「作っても売れるかどうか（使われるかどうか）がわからない」リスクがあるケース
- 本当にお客さんのためになる、お客さんが求めているものなのか？
- 自分たちの食い扶持とモチベーションとの天秤
- プロジェクトを続けていくかどうか考えた方が良い
- 「プロジェクトを進めることが最大のリスクである」ケース
- その他のリスクを考えるよりもまず、プロジェクトの進退を決めることが一番のリスク管理である
- そのようなシーンでの決断も重要
- 作るものと予算がガッチリ決まっている所がリスクを見積もりを難しくしているのかな
- 完成形の機能に対して人月でお金がついてしまうとリスク管理が難しくなる => リスクを少なく見積もっている方が好まれる => 「機能」の値段を下げることができるから
- お客さんが形のないもの（リスク分）に対してお金を払いたいと思わない
- リスク検討をお客さんと一緒にしたら、理解が変わるかもしれないよね
- 仕様変更のしやすさも将来のリスクへの対応（付加価値）だよね
- お客さんにそういうところの理解もしてもらえるようになりたいね
- お客さんがお金をかけて過剰にものを作ってしまっている（こちらからは無駄だなあと思ってしまう）状態の場合
- いらないものとして捨てる（作らない）ことを提案できるかどうかが大事
- 最初に機能を盛り込むかを決めるときに「価値」を考えることが大切だよねぇ
- 費用対効果は金額で（売上だったり作業効率だったり）こちらから示す
- 出来上がったものを「買う」から「一緒に作る」にシフトチェンジできたらいいのだけど
- 例えば、一戸建てを注文するとなると当事者意識が生まれているよね（コンセントの位置まで口を出したい）
- ソフトに対しても家の何％くらいでも思い入れがあればなあ
- ソフトの場合は、アジャイル的な開発で部分リリースしながら使い勝手や機能を改善していくことができるよね
- 一戸建てでもあり得る話だよね
- 仕事としてソフト作りを回しているのではなく、自分のものとして気持ちを持ってもらえたら嬉しいな
- この本に出てくるチームメンバーのお客さんは「自分の家を買う人」に近いイメージがある
- お客さんが「できない、理解が不足している」前提で話しをしがちだけど、相手を理解しきれていないこともあるんじゃないかな
- 開発者だけで話をしているだけだと陥りそうになる罠
- 本来作りたい物について一番見識があるのはお客さんのはずなんだけど
- こちらが無駄だと思っているけれども必要なものもあるかもしれない
- 無駄だということを開発者が決め付けることはいけない
- 信頼関係を築いたうえて、忌憚なき意見を言えるといいよね
- 信頼関係がない状態で意見だけ言って「なんか怒ってる？こわい」となってしまったことがある
- 無駄な気がするけどなんか違和感のある機能、引っかかる機能
- 話を聞いてみると実現方法がちょっと違っただけで、本当に必要なものはそこにあった
- 形を変えて実現をしてあげたら顧客満足度が大幅にアップした
- 決め付けと上から目線はイクナイ
- なるべく同じ目線で話をしたい
- お客さんが本当に必要なモノを手にしているかをコンサルしている人ってでてこないよね
- 建前的にはSIerか。
- だからこそ、アジャイル的な開発では、先にお客さんを巻き込んで、信頼してもらって、何が必要かを一緒に話しあえることが大事だよね
- 「その機能そのものは技術的には無理だけど、お客さんが実現したいことは何ですか？」「この方法ではどうですか？」と提案できるようになりたい
- そう言えるプロジェクトばっかりではないという現実があるよ
- ほんとに無理なものは本当に無理だとわかってもらう事が必要
- お客さんは敵ではないのだからいかに気持ちよく発注してもらえるか
次回は 5.3 からです。 次回は火曜日ではなく（えにしテックカフェがある！） 10/24（月）でお願いします。