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