試行錯誤中。
計画
平易で分かりやすいのがこのあたり。
だけどターゲットとしているタイプはもっと上流の人たちなので、計画とは、を説いても意味がない。
そんなことは分かっている。
みなさん頭ではわかっているはずなんだけど、どちらかというとすぐに動くタイプが多いので、それを求め（求められ）てしまう。
突っ込み所としては、「だから今のこのニッチもサッチもいかない状況があるんじゃないの ?」ってことなんだけど。
このコンテンツとてもいい。まさに現場で起きていることが書かれている。
- 20年前に進化が止まった日本のIT業界 見渡せば経営に役立たないシステムだらけ
- 情報システムからなぜ「計画」が抜け落ちるのか
- 開発コストを膨らませる日本文化「仕様変更」 ユーザー要件をすべて汲み取ると何が起きるのか
- システム開発は6割スタートがちょうどいい？
各エントリーのポイントを引用しておく。
20年前に進化が止まった日本のIT業界 見渡せば経営に役立たないシステムだらけ 3/4
（1）「計画」と（2）「分析」に関するソフトを「上流CASE」と呼び、（3）「設計」と（4）「コード生成」に関するソフトを「下流CASE」と呼ぶ。総称して「統合CASE」と呼んでいる。
この「上流」「下流」の区分は、欧米のシステム開発では当然の考え方である。システム上流工程と言えば（1）「計画」と（2）「分析」を指し、システム下流工程と言えば（3）「設計」と（4）「コード生成」を指す。
ところが日本ではこの区分が異なっていた。日本では、（3）「設計」がシステム上流工程であり、（4）「コード生成」がシステム下流工程と呼ばれていたのだ。
実際、日本で飛ぶように売れたのは、（3）「設計」のソフトである。（1）「計画」のソフトは、全くと言っていいほど売れなかった。
これは、いかに日本のシステム開発において「計画」「分析」が軽んじられているかを意味している。欧米に比べ、ほとんどの日本の経営者は、自社のシステム開発には全くと言っていいほど関心を持たず、参画しない。つまり、「計画」が行われないままシステム開発に突入しているのに等しい。
JBpress(日本ビジネスプレス)
まさに、その通り。
国内の現場しか知らないので日本独特かどうかは分からないが、上流と呼ばれる、その内容に違和感がずっとあった。
最近は、一般的に使われる「上流」では表現できないため「超上流」なんて表現もあるくらい。明示的に「計画」や「分析」を意味する訳だから、ある意味、良かったのかもしれないが...
小規模な開発案件や機能がある程度確定しているシステム、連携するシステムの要件などが明確な場合は、RFIやRFPを作らないことが多い。だが、コンサルティング会社は、RFIやRFPを効率よく作るノウハウがあるので、この工程を勧めてくる。その場合は、相当高額なコンサルティング料を求められることがあるので、要注意だ。
総開発費用が1億円のシステムなどで、この工程を行うと、3～4割程度がRFIやRFPの策定に課金される場合がある。残りの6～7割でシステム開発やハードウエアの購入、ネットワーク構築などがあると、予算不足になり、大抵の場合、予算を追加しなければならなくなる。
JBpress(日本ビジネスプレス)
RFP はよく使っていたが、RFI という言葉を意識し始めたのは最近。プロジェクトのスケジュールを考える際に RFP と RFI は明確に区別しよう。（と思う）
開発コストを膨らませる日本文化「仕様変更」 ユーザー要件をすべて汲み取ると何が起きるのか
- プロジェクト担当者は「兼務」ではなく「専任」で
- パッケージソフトの機能に業務を合わせる
- システム開発会社を次々に替えると損をする
JBpress(日本ビジネスプレス)
この連載、ビックリするくらい僕の考えと一致している。
先日、インドを訪問した際に感心させられたのだが、インドは国を挙げて（産官学が一体となって）システム開発の基準を作っている。また、ソフト開発の実力を計る「SEI-CMM」という世界標準の基準があるが、最高レベルのレベル5を取得している世界の企業の半分以上はインドの会社である。インドのシステム開発会社は、「品質」に絶対的な自信を持っている。国が主導する基準作りは日本でもやはり必要である。
JBpress(日本ビジネスプレス)
本題から外れるが、これで合点がいった。
以前 (前職で)、インド / インド人と絡めそうなプロジェクトの話があった。
結果的にプロジェクト化には至らなかったが、依頼人のシステム開発会社が CMM のレベル 4 を取得していて、その方の会話はとてもスマートだった。
なるほどね、こんな背景があったのかっ。
こうしたメソドロジーを所有し、実践している会社はまだまだ少ない。存在を知らない会社もほとんどだ。手順書を持たずに経験と勘だけで構築しているのが実情である。
メソドロジーは、「オブジェクト指向」などの方法論とは別の視点で捉える必要がある。システムの「品質」の担保に、メソドロジーは必須なのだ。
JBpress(日本ビジネスプレス)
恥ずかしいが、この回に書かれていることは僕の経験そのもの。
- 大卒で専門的な知識もない文系がシステム開発会社に入り
- 独自のメソドロジーなどあるわけなく、オブジェクト指向すら分かっていない開発体制で、それこそ経験と勘で開発を進める
- そして PG (プログラマ) から SE (システムエンジニア) へとキャリアを変えていく ...
可視化
可視化の際のポイントが書かれているけど、読み手の能力 = 可視化されたものを読み取れる "読解力" が必要、という点は再認識。
標準図法については、前日色々調べた。これについては、今度エントリーしたいと思う。結論だけ書くと UML でも 官公庁の EA モデリングでもなく、BPMN。
- 可視化では、それを見る側の可視能力を考慮する必要があるが、必ずしもEAやUMLでの図表（標準図法という）は、経営者などの素人には分かりやすいとはいえないものもある
- しかし、全体最適化の観点から、経営者にも標準図法の可視能力を持ってもらいたい
- 標準図法が分かりにくいのではなく、これまで慣れてきた表記法と異なるので違和感を持っているだけだ。その違和感を払拭（ふっしょく）するには、繰り返しと段階的誘導が必要だ
- それにはベンダや利用部門の協力が必要だ。日本版SOX法対処の専用ツールの採用は、経営者の認識を高める良い機会でもある
＠IT情報マネジメント
プロジェクト管理
うぅ ... ん、いまいち良い記事が見つからない。
- 第45回 ユーザー企業の組織的PM力を強化せよ（1） - PMO（プロジェクトマネジメントオフィス）を生かす：ITpro
- 第46回 ユーザー企業の組織的PM力を強化せよ（2） - PMO（プロジェクトマネジメントオフィス）を生かす：ITpro
- 第47回 ユーザー企業の組織的PM力を強化せよ（3） - PMO（プロジェクトマネジメントオフィス）を生かす：ITpro
チラっと読んでおくかな。
- ユーザー企業側プロジェクトマネージャの勘違い − ＠IT情報マネジメント
- PMBOKだけでなく「ユーモアセンス」も必要？～プロジェクトマネージャに求められる資質とは（3/3）:企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)
- ユーザ企業のシステム担当者こそプロジェクトマネジメントを学ぶべし（1/2）:企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)
- なぜプロジェクトマネジメントは普及しないのか - 記者の眼：ITpro
- プロジェクト管理計画の重要性 - SourceForge.JP Magazine
後で読む
30年前のロードマップと変わらない Apple とか。
