本当は楽しいドキュメント作成
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。 文書作りは好きですか？ 今回からこの連載を担当いたします、アクセンチュア・テクノロジー・ソリューションズの宮本和洋です。 システム開発プロジェクトでは、さまざまな文書が作られます。私の連載ではこの文書に注目し、「文書ドリブン開発」という考え方を紹介したいと思います。 文書ドリブン開発は私の造語です。「文書が作成されることにより、具体的な開発作業が進行していく」ことを意図しています。 多くのITエンジニアは、文書作りではなく、動くものを作ることに楽しさを見いだすと思います。その作業の楽しさの中には、システムの設計に悩み、動作実証実験を繰り返す楽しさも含まれているのではないでしょうか。「この仕組みでちゃんと動くかな～、どうかな～」と試してみることが、ワク
グループ全体のシステムを統合 5年でITコスト300億円削減
セブン＆アイ・ホールディングスは、増え続けるITコストを削減するため、グループ全体のシステムを刷新した。ハードウエアやネットワークといったシステム基盤と、財務・総務・人事などの管理系システムを完全に統合。業務系システムについても、スーパーやレストランといった業態ごとに業務をそろえることで、共通アプリケーションを作成した。今後5年間で300億円のITコスト削減を実現する。 500億円かけて構築したセブン-イレブン・ジャパンの第6次システム、アイワイ・カード・サービスが発行する電子マネー「nanaco」、全国で1万3000台を超えるセブン銀行のATM（現金自動預け払い機）など例を挙げればキリがない。セブン＆アイ・ホールディングスはITをビジネスに有効活用している日本でも有数の企業である。 だが、そんな同社も「ITコストの肥大化」という悩みを抱えていた。積極的なIT活用に加えて、店舗や事業、グル
ICタグ導入に最後の賭け ---ウォルマート
誰がSOAを殺すのか 「企業システムの変化対応力を高める現実解」との期待を集めるSOA（サービス指向アーキテクチャ）。日本ではその有効性を認めつつ，採用に二の足を踏む企業がいまだ大多数を占める。しかしSOAは世界的な趨勢。日本ならではのやり方で一歩目を踏み出すこともできる。景気後退が著しい今こそ，SOAがもたらすチャンスとメリットを自ら“殺す”のは禁物だ。 景気後退が著しい今こそ… ポイント(1)固定観念にとらわれるな ポイント(2)定石を踏まえる ポイント(3)とにかくやってみる システム延命で逆風を乗り切れ 経費は一律20％カット、新規事業はゼロベースで見直し―。2カ月前の米リーマン・ブラザーズの 破綻に端を発した世界金融危機。急速に悪化した日本経済。生き残りを賭けたコスト削減目標がトップダウンで決まっていく。IT投資も例外ではない。だが交際費や交通費のようには、IT投資は削れない。保
システム内製が，日本の国力を底上げする
「最近，システムを自社で内製する企業が増えていない？」 2008年10月15日号の日経コンピュータで特集した「システム内製化 再び！～自社開発を強化する12社の決断」は，編集部内のある記者が発したこの一言が始まりだった。部内の記者や編集委員などから続々と「システム内製」の情報が集まってきた。かく言う筆者も内製回帰への兆しを感じていた。ベンダーの評判を聞いても“要領を得ない”ユーザーに最近連続して出会っていたからだ。例えば，以下のようなやり取りだ。 記者：ベンダーの提示するシステム開発のコストについて，妥当性の判断が難しいとの声を聞きます。どのように判断していますか？ A社：お役に立てなくてすみません。オープン化を機に内製にしました。社内の人件費が開発費で，ベンダーに支払うのはサーバーなどハードウエアの費用のみです。 このように内製に取り組むユーザー企業では，システム部門のプレゼンスが格段に
システム内製化に走るユーザー企業とSaaSの親和性
ユーザー企業で再び情報システムの内製化に向けた取り組みが活発になっているという。実際にここ半年ほどでユーザー企業からそんな話をよく聞くようになった。ところで、その一方でSaaSやクラウド・コンピューティングの流れがある。まるで正反対の動きに見えるが、実は同一線上にある。刺激的、かつ表面的に言うと「SIerを外そう」ということだ。 内製化と言っても、いまさらスクラッチでシステムを組み上げる話ではない。日経コンピュータも特集したが、システム開発の外注化で失われた、業務要求の取りまとめ、要件定義、仕様の確定、プロジェクト管理など本来の情報システム部門の能力を取り戻そうという動きだ。もちろんパッケージ・ソフトの活用を前提に開発も行う。外部のITベンダーを使う場合でも、一括請負を止めて、準委任や派遣で手伝ってもらう。つまり、自己責任でシステムを作りましょうというわけだ。 本来なら、これはもう当たり前
“作り手責任”が問われる：メインフレーム技術者が足りない：ITpro
メインフレーム技術者が足りない――。2007年問題がついに顕在化し始めた。ベンダー各社は定年退職者の再雇用で対処する心づもりだったが、必要数を確保できていない。若手や派遣社員での穴埋めは難しく、このままでは顧客企業のシステム開発に支障がでかねない。 「メインフレーム技術者を紹介してくれとの依頼が急増している」。IT技術者の派遣事業を手がけるリクルートスタッフィングの田中智己ITスタッフィング部部長は明かす。「依頼主の多くは大手ベンダー。メインフレームを使ったシステム開発や運用を担う技術者は今後も長いスパンで必要だが、各社とも十分な数を確保できていない」とみる。 メインフレーム用のパフォーマンス管理ソフトなどを開発・販売するソフト会社IIMには「大手ユーザー企業からメインフレームの基本的な技術を勉強できる場を設けてくれないかとの相談が頻繁に寄せられる」（梅津裕システム本部部長）。関連セミナー
世界最大のプロジェクトをこう見積もった
大規模，複雑，厳しい納期――。昨年秋に完全統合したJAL/JASの情報システム。成功を収めたプロジェクトの裏に，見積もり精度の高さがあった。プロジェクト・マネージャ（PM）を務めた岡村正司氏に，どのように見積もったのかを聞いた。（聞き手は本誌 池上俊也） JAL/JAS統合とはどんなプロジェクトだったんでしょうか。 岡村：昨年10月に完全統合しましたが，日本航空（JAL）と日本エアシステム（JAS）の約160のシステムを，JAL側のシステムに片寄せするものでした。工数は全体で1万2000人月，規模は8000万ステップと，とんでもなくデカいものです。IBMが手掛けてきた案件の中でも世界最大級でした。 時間の制約も厳しい。2002年初頭に始まったプロジェクトは，2年間で中核部分をすべて統合しなければならない。失敗は許されませんでした。 岡村さんがPMとして招かれたときの様子を聞かせてください。
インドオフショア開発のコストはいくら？
本連載では、現役のインドオフショア開発コンサルタントである筆者が、インドオフショア開発事情や勘所などを紹介する。今回は、その中でもコストについて説明する 本連載はインドのオフショア開発にフォーカスをして、方法論や課題などを紹介していきます。 なお、筆者は主に日本で勤務しているオフショア開発のエンジニアで、インド側と連携して開発を進めています。このように、筆者自身が現役でオフショア開発の現場に携わっていることから、なるべく現場にフォーカスして情報を届けていきたいと思います。 インドオフショアを導入するケースでは、目的はさまざまですが、期待する効果には大きく2つのことが挙げられます。1つは、国内エンジニアリソース不足を補うための人材確保。もう1つは、コスト削減です。今回はコスト面について解説します。 インド側エンジニアの単価レンジのイメージは？ オフショアベンダなどを通じて、日本側の企業が見え
システム開発は20年縮退している，“むしり取る”型の人材育成が必要
システム統合のトラブルや，動かないシステムの事例が後を絶たない。システム開発のどこにどんな問題があるかを明確にし，改善することが急務になっている。事故や失敗から教訓を学び取る「失敗学」の提唱者である畑村洋太郎氏に，日本的なシステム開発の問題点や改善の方針などを聞いた。 失敗学のプロジェクトでは最近，システム開発の失敗に関しても研究されているようですね。 このところ，主に経営トップ層の方々から，システム開発の失敗をテーマに話を聞かせてくださいと言われる機会が増えています。それだけ不安感や危機感があるのだと思います。 システム開発では「流用設計」「付加設計」で失敗するケースが多いようです。例えば，みずほ銀行のシステム統合でのトラブルは，主に付加設計（既存のシステムに，付加的に要求された設計を加える）が原因でした。 そのほか，よく言われていることですが，関係者間でシステムについての概念を共有でき
非機能要求は，検証できなければ意味がない
JUAS(日本情報システム・ユーザー協会）が，「非機能要求仕様定義ガイドライン」を発行した。このガイドラインは，JUASが2007年9月から2008年3月にかけて実施した「UVC(User Vender Collaboration）研究プロジェクトII」の成果で，ユーザー企業がベンダーに提示する要求仕様書(別の言い方ではRFP＝提案依頼書）における非機能要求の定義方法をまとめたものである。 JUASは，2007年に「UVC研究プロジェクト」の成果として「要求仕様定義ガイドライン」を発行しているが，非機能要求については不十分だった。これを補うために，非機能要求に正面から取り組んだのがUVC研究プロジェクトIIであり，「非機能要求仕様定義ガイドライン」だ。 言うまでもなく，ユーザー企業がシステムの非機能要求を明確にベンダーに伝えることは非常に大切である。しかしこれまでは，どんな非機能要求を伝え
＠IT：連載 INDEX - 保守性・拡張性に優れたシステムを作る
保守性・拡張性に優れたシステムを作る（12）： システム開発はなぜ楽にならないか？ これまで、本連載ではこれまで11回にわたって、システムの拡張性・保守性を考慮するうえで重要になるオブジェクト指向における分析設計の流れや考え方を解説してきた。最終回では、なぜいまもってシステム開発が楽にならないのかについて、筆者の考え方を紹介したい。（2008/7/15） 保守性・拡張性に優れたシステムを作る（11）： キミの設計に「トレーサビリティ」はあるか システム開発は5つのステップ（工程）に分けられる。全体の流れを可視化し、それぞれの工程で発生する影響範囲を追跡する。それにより、構築後の保守・拡張性をも視野に入れた作業を行うことが可能となる。（2008/2/7） 保守性・拡張性に優れたシステムを作る（10）： ドメイン層をシンプルに作るためのO-Rマッピング （2007/9/13） 保守性・拡張性に
深い業務知識が必要なのは案件の提案者と要件定義者 - ひがやすを技術ブログ
SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大
SIerが必要としているのは業務知識だという都市伝説 - ひがやすを blog
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない
学生とIT業界トップの公開対談で胸を衝かれたこと---IT産業を呪縛する“変われない日本”：ITpro
IPAのイベントで2008年5月28日に行われた学生とIT業界トップの公開対談を聞いていて，一瞬胸を衝かれた。IPA理事長で元NEC 代表取締役社長の西垣浩司氏のこの言葉を聞いたときのことだ。 コンピュータを作ることが本業ではなくなったメーカー 「数として欲しいのは，金融システムなど企業の大型システムに従事する人間。こういった領域では，個人の能力よりは業務ノウハウが重要。プログラマとして優秀であっても，業務を理解しないと，よいシステムができない。技術だけを評価して処遇することは企業としては難しい。天才プログラマのように技術を極めるのであればそれを生かす道に行くべきであって，企業に入って大型システムを開発するのはもったいないか，向いてない」(西垣氏） 必要とされているのは技術ではなく，プロジェクト・マネジメント能力や調整能力。求められているのはメーカーの人材像ではなく，ゼネコンやエンジニアリ
だれも教えてくれなかった外部設計の「極意」---目次
外部設計書で最も大切なことは，「システム開発を依頼してきたお客様」（発注者）に読んでもらい，理解してもらうことです。外部設計書を，開発メンバーではなく，発注者に理解してもらうためには，「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。本連載では，発注者が理解しやすい外部設計書の書き方とレビューの方法に関する具体的なノウハウを解説していきます。 第1回 ユーザーと意思疎通が図れない外部設計書は危ない 第2回 ［システム振舞い編］一覧表に一工夫入れることで漏れや重複をなくす 第3回 ［システム振舞い編］全体を俯瞰でき，システム化範囲が一目で分かる業務フローを作成する 第4回 ［システム振舞い編］発注者が理解しやすいシナリオの記述方法 第5回 ［画面編］見れば“わかる”「画面レイアウト」の作り方 第6回 ［画面編］画面遷移を
テクノロジー : 日経電子版
電通、三菱UFJ信託銀行など大手企業が相次ぎ参入を表明する「情報銀行」。ここに挑むベンチャー企業がDataSign（東京・渋谷）だ。同社の太田祐一社長は情報銀行という言葉が生まれる…続き 中部電力が「情報銀行」参入へ 電力データを活用 ［有料会員限定］ 「情報銀行」説明会に２００社 データ流通の枠組み始動
ITmedia エンタープライズ：遅れた日本のソフトウェア開発 その原因はここにあり!?：作業環境を改善せよ さもなくば日本のエンジニアは壊滅する！ (
作業環境を改善せよ さもなくば日本のエンジニアは壊滅する！：遅れた日本のソフトウェア開発 その原因はここにあり!?（1/3 ページ） 米グーグルでは食事がタダに。米マイクロソフトではソフトドリンクが飲み放題。そのほか、米国のIT企業の多くでソフトウェア開発者は全員、個室を与えられている――こんなこと、日本の企業であるだろうか？ 驚愕!? 海外企業における個室の作業スペース 米国のみならず先進諸国においては、ソフトウェアエンジニアの労働環境は総じていい。世界一巨大なソフトウェア会社のマイクロソフト、欧州最大のソフト開発会社として有名なSAPで働いた経験から、そう感じる。どちらの会社も、さまざまな側面において一部から厳しく評されることもあるが、そんな評判とは裏腹に、エンジニアの労働環境は良かった。 ご存知かもしれないが、米マイクロソフト本社のオフィススペースは筆者が勤めていた当時、完全な個室型
7種類の可視化でFlexのビジネスアプリケーションを大きく強化、「ILOG Elixir」：CodeZine
主にビジネスアプリケーションの用途で利用されている、Adobe Flexプラットフォーム向けの可視化コンポーネント製品「ILOG Elixir」（アイログ エリクシール）。同製品を手掛けるフランス ILOG社 プロダクトマネージャーのErwan Paccard氏、セールスマネージャーのJoel GAY氏に、ILOG Elixirの魅力について伺った。日本では、アドビがOEM提供を受けて販売を行っている。 ――ILOG社の概要をお聞かせください GAY氏： 20年前に設立したフランスの会社で、ワールドワイドで現在900名くらいが勤務しています。本社がフランスとカリフォルニアの2か所にあり、基本的にコンポーネント製品を提供している会社です。大きく分けて3種類のコンポーネントを提供していて、最適化製品が全体の40％、BRMS（Business Rule Management System）が40
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
上流工程-設計---目次
上流工程-見積もり---目次：ITpro