初めての上流コンサルティング ― ＠IT
本稿では、ITを活用した事業の事業性判断を行ったプロジェクト事例を紹介する。その中でIT技術者の秋田くん（仮名）の視点から、上流工程のコンサルティング案件を初めて担当する際に気を付けるべきポイントを述べる。なお、この事例は弊社が過去に実践した複数の事例を組み合わせた架空のものであることをあらかじめお断りしておく。 （1）プロジェクトの概要 「今回のプロジェクトには秋田くんをアサインしたい。彼はこれまで、IT技術者としてソフトウェアの設計や要件定義の経験を積んできたが、さらに“上流”の仕事を経験させることで、より幅広い見識を持つコンサルタントに育成していきたい。よろしく頼むよ」 プロジェクトの提案を1週間後に控え、体制の相談をしていたPMの私は、所属長からこう依頼された。 このプロジェクトの目的は、ある顧客企業のITを活用した新規サービスの事業性を判断することである。この企業は、アパレル業界
第4回 RIA開発の見積もりはなぜ難しいのか
本連載ではリッチ・インターネット・アプリケーション（RIA）開発におけるマネジメント領域の課題とその解決策というテーマで，RIAコンソーシアムのマネジメント分科会における研究結果をもとにいろいろな面から考察してゆきます。今回はRIA開発の見積もりについて考えてみたいと思います。 RIA開発で考慮しなければいけないこと 見積もりという観点でRIA開発において考慮しなければならないことはなんでしょう。従来のWeb開発では作業工数ベースによる見積もりやFP（ファンクションポイント法）など，システム開発に取り入れられてきた手法を用いるケースが多いようです（デザインの部分はその限りでは無いのですが）。 一方，RIA開発においては，デバイス（PC，携帯電話，ゲーム機など）によって開発対象や難易度が大きく変わること，エモーショナルな部分（飽きない，疲れない，楽しい，など）やユーザビリティの良し悪しなど，
階層アーキテクチャの利点は、複雑さの減少 ― ＠IT
個々のコンポーネントを組み上げて、どのようなシステムを構築するか。構造（アーキテクチャ）によって、できあがるシステムの性質が変わってくる。作り手側の視点に立てば、どのようなアーキテクチャを採用するかによって、作り方も変わってくる。いままで連載した記事を通して、わたしたちは、個々のコンポーネントの作り方を学んできた。今回からは、コンポーネントをいかに組み上げるか、という課題に知恵を絞ることになる。コンポーネントの利点を最大限に生かすこと。それがアーキテクチャ設計の現実的な意味の1つだ。そして、1つの有効なアプローチに階層化アーキテクチャがある。 前回「使いやすくて、変化に強いコンポーネント」までにサブシステムなどを利用したコンポーネントの作り方についてお話ししてきました。それでは、コンポーネントは実際どのような単位で作り上げていけばよいのでしょうか。 コンポーネントの単位として考えられるのは
Vol.02 やりっ放しの弊害 作ることにかまけて社内の信頼を無くす
新規システムの計画や開発業務は，大変なこともあるが面白い。新しいものを作っていくからだ。しかし，それにかまけて活用をおろそかにすると…。 インテリア製品の製造・販売会社S社で働くK主任は29歳。7年前に入社して以来，管理本部情報システム・グループに在席し，一貫して社内のシステム化に携わってきた。ここ2年ほどは，600人の全社員向けの電子メール，グループウェアの導入や活用支援を担当。今では「仕事をきっちりこなせるようになった」と自負していた。 ところが，そんなK主任にとって最近，ショッキングな出来事があった。経営層を含めた重要な会議の場で仕事の成果を問われ，きちんと返答できなかったのだ。 新規案件にやりがい感じる 大学で管理工学を専攻したK主任は，卒業後，コンピュータ関係の仕事につきたいと漠然と考えていた。S社に入り情報システムを担当することになったのも，特に強く希望したからではない。情報サ
第20回 その「リアリティ」はプロジェクトに不必要
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■リーダーシップトライアングルにおける位置付け この連載では、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点＝私点」を皆さんにお届けしています。 今回の内容は、リーダーシップトライアングルLove／Communicationに関係します。Loveについては、第10回「正しいことをし、行動力を発揮するココロ」を、Communicationについては、第8回「コミュニケーションはリーダーシップの基礎
【IT Service Forum速報】「システムの信頼性向上には可視化が重要」，経産省が新ガイドラインを解説
【IT Service Forum速報】「システムの信頼性向上には可視化が重要」，経産省が新ガイドラインを解説 「情報システムの信頼性を高めるには，信頼性を“可視化”することが重要だ。経済産業省ではそのために有効なガイドラインを公開しているので活用してほしい」――。経済産業省（経産省）商務情報政策局情報処理振興課係長の上原智氏は11月21日，日経BP主催「IT Service Forum 2006」の特別講演において，同省が公開した「情報システムの信頼性向上に関するガイドライン」などを解説した（写真）。 経産省では2006年1月，大規模な情報システム障害が相次いだことを受けて，情報システムの信頼性を高めるためのガイドライン策定を開始。そこでまず実施したのが，ベンダー企業ならびにユーザー企業に対するアンケートとヒアリングだった。 「その結果，開発段階における問題としては，ユーザーとベンダーと
第2回 RIAの開発に必要なキャストと要求スキル
本連載ではリッチ・インターネット・アプリケーション（RIA）開発におけるマネジメント領域の課題とその解決策というテーマで，RIAコンソーシアムのマネジメント分科会における研究結果をもとにいろいろな面から考察してゆきます。連載第2回目のテーマはRIAの開発体制についてです。 開発に必要なスキルや作業範囲が拡大している 前回の「発注者とのコミュニケーション」において，RIA開発は実現したい機能の特性からプロジェクトに参画するメンバーの職種が多岐にわたる点を指摘しました。具体的には，デザイナーに要求分析のスキルやシステム的な思考が求められ，エンジニアにデザイナー的な感覚が求められる，といったように，作業範囲や求められるスキルが広範囲になってくるということです（図1）。 図1：RIA開発で求められる作業範囲やスキル（RIAシステム構築ガイド2．0（2006年度版）より引用） このことはディレクショ
「従来の見方で基幹系システム分野を語ってはいけない」、アナリストが新しい見方を提示
「ベンダー企業の経営、ユーザー企業の動き、技術の進展などさまざまな変化が、基幹系システムの分野を大きく変えている。だから我々は基幹系システムの分野を、新しい視点や考え方でとらえる必要がある」。調査会社ガートナー ジャパンのアナリスト、亦賀忠明エンタープライズインフラストラクチャ担当バイスプレジデントはこう語る。亦賀氏は同社のCIO向けイベント「Gartner Symposium/ITxpo 2005」で、サーバー市場全体の動きを解説しつつ、次世代の基幹系システムに求められる要件や考え方を整理した。亦賀氏の発言の主旨は次の通り。 米IBMはシェアを拡大しつつある。仮に1000万円以上のシステムを基幹系サーバーとした場合、ガートナーの調査では1999年に33％だったIBMの市場シェアが、2004年には49％に上昇している。市場全体の規模は縮小傾向にあるが、IBMの売上の絶対額は下がっていない。
【上級】プロジェクトを成功させる組織作りの考え方，進め方 第2回
戦略を設定したら，その戦略を遂行するための「組織モデル」を決定する。組織モデルには「機能型」，「プロジェクト型」，「ウィーク・マトリックス型」，「バランス・マトリックス型」，「ストロング・マトリックス型」の5つがある（表1[拡大表示]）。 5つの組織モデルの違いは，(1)開発，営業，技術支援といった特定の業務・機能を単位として組織を分けるのか，それともプロジェクトそのものを単位として組織を分けるのか，(2)プロジェクト・マネジャーやメンバーがプロジェクトの専任なのか，それとも兼任なのか，(3)プロジェクト・マネジャーの権限や責任が強いかどうか，といったことにある。 注意すべきは，あらゆる戦略に対応可能な組織モデルは存在しない，ということだ。どの組織モデルにもメリットとデメリットがあり，それらの特徴を理解した上で，戦略に応じた組織モデルを選択する必要がある。 組織モデルを選択するための判断基
上流工程の問題解決 仕様変更編【前編】
システムが以前よりも複雑化している現在，多くの開発者やユーザーは，「仕様変更がある程度起こるのは仕方がないこと」と前向きに受け止めてはいる。だが一方で，仕様変更によるコスト超過などが原因で，プロジェクトが失敗に陥ることが非常に多い。仕様変更によるトラブルを極力防ぐにはどうすればよいのか。現場担当者の知恵から解決法を探ってみた。 「設計書の50％に手を加えなければならないほど仕様変更が続出し，収拾がつかなくなってしまった」。NTTデータ東北の太田雅典氏（法人システム事業部 第一開発担当課長）は，数年前に手がけたある出版社の広告管理システムで，開発中に起こった仕様変更のトラブルを振り返る。このプロジェクトでは，設計が一通り終わり，実装（プログラミング）フェーズに入ってから，データベース（DB）の構造や，帳票出力用の計算式，他システムとの接続インタフェースなど，システムの根幹をなす仕様の変更を次
RFP作成術【後編】：評価しやすいプロセスを作る
どんな精巧なRFPを作ったつもりでも完ぺきではない。選ぶまでのベンダーとのやり取りの中で，RFPの不足を補う必要がある。また，最終的に納得のいく形でベンダーを選ぶために，比較する方法にもコツがある。 作ったRFPをベースにベンダーを選ぶプロセスを見ていこう。図10は，アキュラホームが月次決算処理合理化の案件で実際にベンダーを選定したプロセスである。これが典型的な例で，「RFP配布，説明会」→「提案書受け取り」→「プレゼンテーション」→「ベンダー決定」と進む。このケースでは1カ月かけているが，一般的にも1～2カ月は見ておく。 ケースによっては，RFP配布の前に「RFIの発行による情報収集」を入れたり，ベンダー決定のために「2次選定」を実施したりすることもある。提案書受け取りとプレゼンテーションが同時ということもある。 どんな精巧なRFPを作ったつもりでも完ぺきではない。選ぶまでのベンダーとの
開発標準導入の阻害要因
ソフトウェア開発を主業務とする企業や部署においては、常にその改革・改善が求められているはずだ。そこでは開発標準の導入や改善が、1つの大きな改革・改善項目の候補になることは明らかである。 1. ソフトウェアの開発標準の現状 「自社の開発標準がある 52.2％」 これは、少々古いですが2003年に日経ITプロフェッショナル誌が行ったアンケート（日経BP社発行 日経ITプロフェッショナル 2003年7月号 「開発プロセス大全」より引用）結果です。これだけを見ると、半数とはいえ日本でも開発標準を活用した組織的なソフトウェア開発が行われているようにみえます。しかし、同じ調査で以下のような結果も出ています。 「開発標準の種類：ウォーターフォール型 82.8％」 これだけでは何とも断言できませんが、おそらくこれらの標準の大半が、メインフレームやオフコン向けの開発標準の可能性があります。実際、筆者がいろい
スペシャリストはリーダーになれない？ ― ＠IT自分戦略研究所
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■リーダーシップトライアングルにおける位置付け この連載では、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点＝私点」を皆さんにお届けしています。 今回の内容は、リーダーシップトライアングルのLove／Communication／Capabilityに関係します。Loveについては第10回「正しいことをし、行動力を発揮するココロ」を、Communicationについては第8回「コミュニケーションは
【中級】反復開発 現場のノウハウ
ここまでは「リスクを解消する」という視点で反復開発の現場のノウハウを見てきたが，反復開発そのものを実施する上で鍵となるようなノウハウもある。成功事例から得た4つのポイントを紹介しよう。 (1)複数の手法から“いいとこ取り” 百科事典のように重いがしっかりとしたRUPも，軽くて動きやすいアジャイルも，根底には(1)リスク駆動の考えで，(2)フィードバックを早くして，(3)PDCAサイクルを続ける，という部分で一致する。そのため，「RUPやアジャイルの各手法は相性が良く，プロジェクトの状況に合わせて適宜組み合わせて使うとよい」（ウルシステムズ ディレクター，テクノロジ 河野正幸氏）。 図5●RUPとXPを組み合わせる ディーシーカードは，これまでの失敗を繰り返さないため，RUPとXPを組み合わせて採用した [画像のクリックで拡大表示] DCカードがカスタマイズした例を見てみよう。冒頭で紹介した
【中級】反復開発 現場のノウハウ
“要件を決められない”という要件リスクに対して，反復開発では「短いサイクルでリリースする“動くシステム”を呼び水に，ユーザー要件を引き出すことができる」（みずほ情報総研 開発第二本部 第五部 務台（むたい）博海氏）。動くシステムが開発の末期でないとリリースできないウォータフォール型との決定的な違いだ。 このメリットを生かし，みずほ情報総研はある企業の基幹システム刷新プロジェクトにおいて，毎週水曜日の午後いっぱいをユーザーとの定例会議，その翌週の金曜日をリリース日と決め，1週間という非常に短いサイクルでシステムを次々とリリースできた。 一般に反復開発では，従来型の開発方式よりユーザーの高い参画度が求められる。このケースでは，ユーザー自身に「小さく生んで大きく育てることや手戻りを許容する開発手法を望む姿勢があった」（同部 担当課長 浦田智之氏）ことが成功の下地になっている。 ユーザーの“代理人
再び塩漬けされる，システム内の「ブラックボックス」
「なぜここで，無関係としか思えないパラメータを参照しているか」 「今の業務なら，ソース・コードのこの部分を実行することは絶対にないと思うのだが，削除しても大丈夫だろうか」―― 長年にわたる機能拡張や仕様書の紛失／メンテナンス不足により，こうしたシステムの「ブラックボックス化」が進んでいる。団塊の世代の大量退職などで，ブラックボックス化に拍車がかかるという2007年問題も取りざたされている。 ブラックボックスを放置すれば，システムの仕様が不明確な部分への改修に多大なコストがかかってしまう。システムの改修によって生じる影響の分析には，改修自体の3～10倍の工数がかかるとも言われる。情報システムだけの問題で済めばまだよいが，経営環境の変化にITが追いつけなくなる点なども指摘されている。 しかし最近，基幹系システムの再構築プロジェクトを取材する中で，システムに存在するブラックボックスには手を触れず
ITPro: 基本設計におけるレビューの勘どころ
どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「考慮していない外部システムとの連携が詳細設計で見つかった」，「仕様間の不整合が実装フェーズで発見された」――。どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「欠陥防止」を徹底する 改めて言うまでもないが，基本設計の成果物の品質を向上させるプロセスは，(1)設計作業を実施する，(2)成果物をレビューして欠陥を洗い出す，(
【上級】失敗プロジェクトの共通項 第5回
想定プロジェクトでは，多くのサーバーやミドルウエアが使われる。OS，Web/APサーバー，データベース，負荷分散装置などだ。プロジェクト内にこれらの製品のうちひとつでも利用経験者がいなければ，スケジュールは見直しを迫られる可能性が高い。使用方法を取得するのに多くの時間を要するからだ。多くの残業，休日出勤を招くことになり，納期にも影響を及ぼす。 スキルマップの整備が不可欠 プロジェクトと技術者をうまくマッチングするには，社内での分野別スキル保有者リストが欲しい。スキル保有者がいなければ，社内からの協力を仰ぐといった運用が可能になる。 スキル評価の方法は，一般的には大分類から小分類へツリー構造で細分化していくのが使いやすい（図7）。 大分類としては「技術」「業務知識」「マネジメント」の3つが標準。技術なら「ハード」「ネットワーク」「OS」「開発言語」など中分類に分け，さらに開発言語なら「Jav
企業向けソフトウエア業界が迎えるパラダイム・シフト
企業向けソフトウエア業界では，頻繁にパラダイム・シフトが起きるものだ。実際われわれも，今まさに新たなパラダイム・シフトを迎えようとしている。「アプリケーション・ホスティング・サービス」の台頭だ。米Microsoftのアプリケーション配布技術「ClickOnce」も，クライアント/サーバー・システム（C/Sシステム）の復権にはつながらないだろう。 新しいパラダイム・シフトに触れる前に，まずはわれわれが過去に体験してきたパラダイム・シフトについて説明しよう。元来われわれは，サーバー・ベースのアプリケーションとロール・スクロール式のダム端末に依存する，大型の中央メインフレーム・システムを利用していた。これらのシステムは，大規模な組織以外のほとんどの企業には手が出せないほど，高価なものであった。小規模なコンピュータの処理能力を必要とする企業は，米IBMのような企業がホスティングし運用しているコンピ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
大量トランザクション処理に適したアーキテクチャ ― ＠IT