http://w.atwiki.jp/minanana/ minanana @ ウィキ ja 2009-11-27T20:50:32+09:00 1259322632 https://w.atwiki.jp/minanana/pages/59.html **links ・[[プロジェクト開始前の準備>http://itpro.nikkeibp.co.jp/article/COLUMN/20080729/311687/?ST=lecture]] WBS分割前に大枠の見積もりを行い，そのうえでWBSの積み上げによる見積もりを行って両者を比較する 実際の開発規模が数倍になることを防ぐには，複数の方法で見積もり，結果を比較することが必須である。最低限，WBS分割前の大枠の見積もりと，WBS の積み上げによる見積もりは実施するべきだ。余裕があれば，大枠の見積もりでも複数の見積もり方法を使って欲しい。比較の結果，大きな差が出た場合は原因を調べる。この過程で，機能の欠落や見積もり漏れを防ぐことができる。 2009-11-27T20:50:32+09:00 1259322632 https://w.atwiki.jp/minanana/pages/58.html **見るべき重点ポイント 支払い 権利 トラブル発生時の対応 ** **関連ドキュメント [[リンク>http://www.atmarkit.co.jp/news/200409/15/req.html]] **分からないことは？ 2009-10-14T19:06:05+09:00 1255514765 https://w.atwiki.jp/minanana/pages/57.html **戦略策定～企画の段階 新しいシステム（＝新しい業務の仕組み全体）が果たす機能や効果はどうすれば得られるのか、その目的と原理を明らかにします。 業務の仕組み全体の見直しが必須 **要件定義と基本設計 新しい業務の手続きや手順を明らかにし、これに沿ってITに頼る範囲やコンピュータの利用方法を決め、画面・帳票のデザインなども明らかにします。一言でいえば「要求仕様に基づいて“開発するシステムの機能”を決定する工程」 **基本設計（外部設計） 開発しようとするシステムが、コンピュータの外部（ユーザーや外部システム）に対してどのような機能、インターフェイスを提供するかを設計する ** **関連ドキュメント [[リンク>http://www.atmarkit.co.jp/news/200409/15/req.html]] [[リンク>http://www.atmarkit.co.jp/news/200301/22/rational.html]] **分からないことは？ 2009-07-15T20:23:32+09:00 1247657012 https://w.atwiki.jp/minanana/pages/56.html **チェックポイント **短納期開発プロジェクトに適した要求管理のアプローチ 「要求を構造化でき、不備を発見しやすくすること」「要求のセットを明確にし、合意を得ること」「変更による影響範囲を正確に把握できること」） **要求管理のために。 良いユースケースというのは、機能要件を知るべき人々にとって円滑なコミュニケーションを可能にする ユースケースというのは、要求管理の重要な一部分 開発が進む過程で要求のエラーを修正するにはコストがかかりすぎる。そもそもユースケースは、何を構築するのか、あるいは何を構築しないのかをまず明確にすることから始まる。 ユースケースは機能要件をストーリーとして書き出すことが必要である。その後、ダイアグラムに落としていく。しかし、機能要件を書き出す段階が難しい。表（個条書き）のように書いてしまうのは簡単だが、それでは機能要求を十分に補完することは難しい。そのため、一貫した“話（ストリー）”として表現しなければならないのだ。何がどうなったら、どうなるのか。これが起こらなかったら、何が起こるのか？というように。構造化手法で[[システム開発]]の経験があるエンジニアがよく陥る。 では、何をアクターにし、何をユースケースとするのか。その判断基準は何だろうか。アクターの定義にはいろいろな解釈があるが、標準的なTipsとしては、プリンタやDBはアクターにはならない、プログラムをしているシステムはアクターにはならない、デバイスはアクターとしてモデリングしないなどの “常識”を知っておくとよい。このような基本的な指針に沿ってアクターを決めていく。行き詰まったら、無視して先に進むこと。重要だと思ったら、後から追加すればよい。 　ユースケースを書くにはスタイルがある。例えば、フローのステップごとに番号を打つのかタイトルだけにするのか、メインフローとサブフローを分けて表現するのか、使われる用語などなど。ユースケースを書くうえでスタイルを統一することが重要だ。これが守られていない例は多い。 ラショナルが提唱するスタイルは、各ステップにナンバリングをするか名前をつける。メインフロー（main flows）のステップは、代替フロー（alternate flows）を参照しないようにするなどだ（メインフローとは、搭載される予定の機 2009-07-15T19:18:04+09:00 1247653084 https://w.atwiki.jp/minanana/pages/55.html **概要 「情報システム」とは、「ユーザーに意思決定やアクションを起こさせるような仕組みを提供するもの」 # 新しい業務の仕組みを考えること # 業務に合わせてコンピュータシステムを作ること # 業務を刷新し、その効果・効率を上げること システム開発を「企業戦略や業務の流れをあらためて検討・整理するチャンス」ととらえ、コンピュータシステムに対する要求を正確に明示することに専念すべき **関連ドキュメント -[[リンク>http://www.atmarkit.co.jp/im/cits/special/five_system/01.html]] 2009-07-10T16:59:55+09:00 1247212795 https://w.atwiki.jp/minanana/pages/54.html **概要 ITILでは、プロセス（Process）、ピープル（People）、プロダクト（Product）の「3つのP」の重要性がよく指摘されます。どれが欠けても、大きな効果は期待できません **関連ドキュメント -[[リンク>http://www.atmarkit.co.jp/im/cop/special/fivemin/itil/05.html]] 2009-07-10T16:05:20+09:00 1247209520 https://w.atwiki.jp/minanana/pages/53.html **概要 PMO （project management office） [[プロジェクトマネジメント]]・オフィス / プロジェクト管理オフィス 個々のプロジェクトが終了しプロジェクトチームが解散すると、そこで生み出されたPMノウハウは失われてしまう恐れがあるが、こうしたノウハウを吸い上げ、体系化し、ほかのプロジェクトチームに移植するといった知的財産管理的、ナレッジマネジメント的な機能を期待 各案件は、弊社の場合、「○○対応」という形で事業部門から、やってくる。 現状、案件ベースで管理がされている。 しかし、サービス毎にどういう案件を経て、今に至っているか 管理がされると、 そのサービスについて、どういう進化を遂げたのか、 投資対効果はどうだったのか という分析が出来るのではないだろうか。 PMOのもう１つの視点 組織間の調整や会議のファシリテーション、進捗管理やリスクマネジメントなどのプロセス導入、事務作業のサポートなど幅広い。ＰＭ個人の能力に頼るのではなく、組織的な支援を行うことでプロジェクトマネジメントの質を向上させる **関連ドキュメント -[[リンク>http://www.atmarkit.co.jp/aig/04biz/pmo.html]] -[[ITPro>http://itpro.nikkeibp.co.jp/article/COLUMN/20080724/311429/]] 2009-07-10T16:04:11+09:00 1247209451 https://w.atwiki.jp/minanana/pages/52.html **概要 リスクは “回避・低減・移転・受容又はその組み合わせ” のどれか **関連ドキュメント 2009-07-03T17:02:59+09:00 1246608179 https://w.atwiki.jp/minanana/pages/51.html **特徴 日本はカスタム（カスタマイズ）にかける費用が多い 競争力に寄与するIT投資は惜しむべきでないが、 凡庸な機能はリーズナブルなソフトウェアを購入すれば事足りる オープンソース製品がわずか5％にすぎず、2割前後に達している北米や欧州、アジア・パシフィックに大きな後れを取っています。→安価なオープンソースを部品として使えればコストを下げることができる。品質は実績で判断して導入すれば安定しているはず **関連ドキュメント [[リンク>http://itpro.nikkeibp.co.jp/article/COLUMN/20090608/331480/?ST=management&P=3]] **姿勢 コスト削減の最も基本的な考え方は、まずコストがどんな要素から成り立っているのかを可視化し、一番大きな要素が何かを把握したうえで、その部分を減らせる可能性を検討する、というものです。 ベンダーに支払うサービス費用も、大きな割合を占めています。すべてを外部に任せるのではなく、ストレージ運用管理ツールを使って、一部分だけでも自社で運用すれば、コストを下げることができます。 #image(http://itpro.nikkeibp.co.jp/article/COLUMN/20090608/331524/zu03.gif) 2009-07-02T15:29:12+09:00 1246516152 https://w.atwiki.jp/minanana/pages/50.html **概要 そもそも情報システムに関連するコンサルティングには3つの分野があることを確認しておきます。すなわち、1.「今の情報管理体制や採用技術などが適しているのか」といったシステム・コンサルティングと呼ぶべき分野、2.「業務をどう変えるべきか」といった業務コンサルティングに類した分野、そして 3.「何を情報化すべきか」といった方向の経営コンサルティングに近い分野、という3つがあります。コンサルタントに仕事を依頼する場合は、この3つの違いをよく念頭に入れておく必要があります。 　専門的なスキルと経験を蓄積すれば、1.であれば、例えば「情報セキュリティー」とか「ネットワーク安全性」「災害対策、事業継続」「[[内部統制]]」など、対象を絞り込んだ専門家を目指すことで、比較的経験年数が短くともコンサルタントとして活躍しやすい **関連ドキュメント [[リンク>http://itpro.nikkeibp.co.jp/article/COLUMN/20090610/331609/?ST=biz_leader]] **姿勢 有能なコンサルタントの下について何年かやったとしても、コンサルタントになれるわけではありません。参考になることは多くても、決して近道にはなりません。それよりシステムの仕事で第1に顧客に信頼され、第2に部下や同僚、協力会社に信頼され、第3に上司に頼りにされることです。 「こういう市場でこういう存在になろう」「そのために、まずはあの製品を自分たちで直接売ってみて経験を積もう」「そのために必要なコンサルタントを採用しよう」「しかし、長期的には仮説に基づく独自製品を作ることであり、その時にコンサルタントとシステム屋が一枚岩になって製品の魅力を高めたい」「そのための準備期間がこれから3年間だ」といった明確なメッセージを発信すれば、結果は異なる 日本が優位に立つのは、多くの人々が知恵を出し合い、それを1つの形に結晶させる時 日本中で通用する情報システムを作ることを目標にするべき 2009-07-02T15:10:34+09:00 1246515034