要求開発アライアンス合宿
合宿つーだけで、修学旅行を思い出して気分だけでホントに楽しいんです。(笑)
示唆にとんだ話満載なうえ、午前3時まで2次会、カラオケで話しまくって歌いまくって笑いすぎた。
直前に総務につくってもらった名刺の印刷は薄いは、斜めに印刷されているは、でちょびっと恥かいちまった。
とりあえずキーワード
- 機能追加の金額は、売り上げ高換算でいくらか
- 10年稼働して追加追加でふるくなっているしかし、それなりに成熟システムをあっさり作り替えるユーザー企業さんの勇気。
- 現場担当さんからの文句とのたたかい。
- UIはではなく、まずは項目に注目。
- シンプルに業務もシンプルにBPR。 提案はSIからの方が第3者的なので受け入れられやすい。だけど言えるSIerさんってめったにいない。
- IT技術がビジネスを加速するような仕組みにしていきたい。
- 現場担当の言うとおりにしていたらBPRは進まない。多少UI不便でも半年〜1年でリリースしてしまうことが重要。
- BPR要件中のなかでITに関わるものはせいぜい3%。 (後で聞いた別の人のところでは0.3%だそうだ)人間系のシステムをまずちゃんとしないと意味がない。
- 政治の問題を技術で解決しない。 「政治が必要なら政治をやればいいじゃん」が、ユーザー企業さんステークホルダーのSIerへの要望。
- モデリングの落とし穴
- 要求メタボリックシンドローム
- やっぱりここでもRubyが熱い
- テロなかま発見。7年かかったテロ。やってよかった!
- 抵抗があろうとなかろうと、改善は絶対やっていくべき。
- それをやらないから、役所や企業の組織が硬直する。
- 勇気をもってばっさりやる。
- 正しいと思ったことは遠慮せずちゃんとやる。
- 経営者はそれを望んでいるんだということを再確認。
- BPRをすすめるIT担当は常に現場との戦いだとのこと。 戦いあって当たり前なんだ!
- レッドツェッペリンは、別の音楽の要素を取り入れようとしていたが失敗している。ただし失敗しているのがいい味だしてるわけで。
- パッケージはカスタマイズしないで、業務を合わせる方がはるかにリスクが少なく適用が早い。 機能のアッドオンはやる。
- WHATとHOWの入れ替わり現象。 トップにはWHATをちゃんと考えてもらう。