国内第三位の時価総額を誇るメガバンクが、クラウドの住人になろうとしている。2017年1月、三菱UFJフィナンシャル・グループ（MUFG）が、パブリッククラウドサービスの「Amazon Web Services（AWS）」を採用することが明らかになった。 これは、「一部のシステムをAWS上で構築することにした」といった、よくあるクラウド事例ではない。日経FinTechの取材によるとMUFGは、400に上る情報システムのうち、過半数を超える200以上をパブリッククラウドに移行可能と見込んでいる。勘定系システムに代表される基幹系システムは対象外ではあるものの、「大規模採用」と表現しても差し支えないだろう。 新規サービスなどもクラウド上での開発を前提にするとみられ、文字通り“クラウドファースト”の方針を固めた格好だ。 MUFGによるクラウドの大規模採用には、エポックメイキングな意味合いが含まれてい

ソフトウエアの良いところは、工業製品や建物、農産物などと異なり、たった1つだけをつくれば済むことだ。工業製品などは全く同じものでも、ニーズの数だけつくらなければいけないが、ソフトウエアはニーズの数だけコピーすればよい。だらこそ、パッケージかクラウドかといった提供形態を問わず、ソフトウエアビジネスは成功すれば、営業利益率が4割、5割といった具合にとてつもなく儲かる。 読者の皆さんにとっては、こうした話は「何を今さら」だろう。マイクロソフトやオラクル、SAPといった外資系ITベンダーは、それでしこたま儲けた。だが、日本のITベンダーの場合、ソフトウエアの素晴らしい特徴の恩恵を受けることができない。SIerや下請けのITベンダーは、単品モノのソフトウエア開発がビジネスの中心だからだ。もちろん、これも「何を今さら」の話だ。 では、ユーザー企業の側から見るとどうか。「お前ら、いくらなんでも儲けすぎ」

みずほ銀行が4年の歳月を費やしてきた次期勘定系システムの開発プロジェクトが、大詰めを迎えている。「開発完了」を掲げる2016年12月まで残り半年となった6月14日、結合テストの終了と総合テストへの移行を役員会が承認した。3000億円強を投じる過去最大級のプロジェクトは、失敗が許されないという至上命題を抱えながら最終局面に突入する（写真）。 次期勘定系システムについては、開発の遅れを指摘する声もある。元みずほ関係者は、「テスト段階で相当な手戻りが生じ、今年に入ってスケジュールの見直しが必要かを検討したこともあったようだ。感覚的には3カ月は遅れている」とする。 こうした声に対して、みずほフィナンシャルグループ（FG）の加藤朝史執行役員システム推進部部長は、「一部のサブプロジェクトで苦しい局面があったのは確か。そのため、（開発が遅れているという）話が出るのかもしれないが、今はオンスケジュールで進

技術最高職が語る「トヨタはこう人を育てる」、部下をきちんとフォローした故・大野耐一氏の育て方を継承せよ トヨタ自動車 林南八 技監 トヨタ生産方式（TPS)は、製造業をはじめ様々な業界に業務改善手法として広く取り入れられている。そのTPSを確立した故・大野耐一氏（元副社長）に直接教えを受けて学び、次代に伝えられる人材は今やトヨタ社内でも経営幹部クラスの一握りしか残っていない。 一方では、グローバル化や労働管理のコンプライアンス強化など、生産現場を取り巻く状況が大きく変化している。ともすればTPSの表面的な部分だけが受け継がれ、根本的な思想の伝承がおざなりになる可能性も増している。 そこでトヨタ自動車で技術・生産を極めた人だけに与えられる技術最高職「技監」を務める林南八氏に、大野氏の思い出を振り返りつつ、人材育成の危機感とあるべき姿を語ってもらった。 （聞き手は西 雄大＝日経情報ストラテジー

案の定というか、最近のSIビジネスの需給関係の好転により、ITベンダーの新規事業への意欲が急速に低下してきた。クラウドの普及などでハードウエア事業に赤信号の灯るメーカーは依然として意欲は高いが、大手SIerは人月商売のうま味を満喫し、「ビジネスモデルの転換」「新規事業の創出」は中期経営計画という“IR資料”の中にのみ存在する空虚なスローガンに戻りつつある。 こう書くと、多くのSIerの経営者から「まだ十分な実績が出ていないので公表できないが、以前に設置した新規事業推進チームを通じて、クラウド関連などの新サービスの創出に取り組んでいる」といった反論を受けそうである。確かに、大手SIerならどこでもそうした組織やチームがあって、SIという人月商売のビジネスモデルから脱却を図るため、新たなビジネスのネタを探している。 こうした新規事業推進チームのメンバーは、大概が驚くほど優秀な技術者や営業担当者

以前この「記者の眼」で、日本のIT業界のビジネスモデルと業界構造、つまりSIの人月商売と多重下請け構造が、どれだけ多くの問題点をはらみ、IT業界のみならず日本全体に害毒をいかに撒き散らしているかについて、45の問題点を示した（関連記事：IT業界の人月商売、多重下請けがもたらす45の害毒）。 この記事はIT業界で働く多くの技術者やITベンダーの経営幹部、そして発注元のユーザー企業のIT部門の皆さんの琴線に触れたようで、実に多くの読者に読んでいただいた。ソーシャルメディアでも、Facebookでのシェア数が2100以上に及ぶなど、この記事を“ネタ”にIT業界の人月商売と多重下請け構造の問題点について活発な議論が行われた。 私もTwitterでの読者のつぶやきなどを丹念に追いかけて、皆さんの意見に触れた。そうすると、記事に対する共感や賛同とともに、「ずっと前から言われてきたこと」「問題なのは分か

現在のシステム開発プロジェクトの状況を見ると，いわゆる生産管理，経理といった従来からある業務のシステム化といったプロジェクトに加えて，Webシステムに代表される，従来無かったような新業務に対するプロジェクトが増加しています。 そうした業務のシステム構築は要件を固めにくく，予想もしにくい状況にあります。また，ビジネスの変化に伴ってシステム自体も非常に変化が激しいという特徴を持つことが多いようです。 そのような現状において変化に強い「アジャイル開発」は非常に魅力的です。本稿では，顧客サイドからの視点で「アジャイル開発」を総括し，「アジャイル開発」を行うときの，「要求開発」の可能性を検討してみたいと思います。 アジャイル開発とは XP（eXtreme Programming）に代表される繰り返し型の開発方法論をさします。特徴としては現場サイド（プログラマ）から出てきた開発方法論であり，変化に柔軟

読者の中には，「DOA（Data Oriented Approach：データ中心アプローチ）なんて過去のもの。今から学ぶならオブジェクト指向では？」と思っている人も多いのではないだろうか。確かに現在では，プログラミング言語も開発プロセスも，「OOA（Object Oriented Approach：オブジェクト指向アプローチ）」が前提になっていることが多い。このため「まずオブジェクト指向を学ぶべき」と考えても無理はない。 しかし筆者は，ITエンジニアがDOAや，その中核を成すER図（Entity Relationship Diagram）によるデータ・モデリングを学ぶ意義は極めて大きいと考える。その第1の理由は，現在のデータベースの主流であるRDBMS（リレーショナル・データベース管理システム）を使うときは，データ・モデリングが必須であることだ。詳しくは後述するが，ER図で作成したデータ・

サービス開発手法としての「リーンスタートアップ」という言葉が、日本でもはやり始めたのは2012年頃からだろうか。また、この言葉とよく比較される「アジャイル」については、もう少し歴史が長いようだ。 リクルートでもアジャイル手法については、それなりに早い時期から着目してきた。独自のアジャイル開発スキームを「SWAT（Speedy Willing Alliance Teamの略）」として確立し、今なお運用している（図1）。 このアジャイル開発スキームを効果的に実践するには、開発サイドのIT部門だけではなく、ビジネスサイドである事業部門の理解や協力が欠かせない。今回はこの、開発サイドで発案・構築したアジャイル開発スキームを、ビジネスサイドに浸透させていった話をしたい。 リクルートがアジャイル開発の実験を開始したのは2006年頃である。当時はまだウォーターフォール型で確実に、時間をかけてサービスを開

今やソースコード管理システムの標準となっている「Git」（関連記事）。作者のLinus Torvalds氏から指名され、メンテナーとして責任を負っているのが現在米国のGoogle本社に勤務する濱野純氏だ。濱野氏に、メンテナーを引き継いだ経緯、Googleでの仕事などについて聞いた。 Gitコミュニティはどのように活動しているのですか。 本体の開発は、デザインからコードレビューまで、すべてGitメーリングリストで行っています。最近のリリースには、それぞれ60人から80人程による変更が入っていますが、常に活動している主要な開発コミュニティ参加者、と言えるのは10人程度です。 開発者でない人たちで#git IRCチャネルとか、stackoverflowなどでエンドユーザーのサポートをしてくれる人たちの数はもっと多いと思います。この人たちも、Gitコミュニティの重要な仲間です。 Gitコミュニティ

中電CTIのように、エンタープライズアジャイルを実践する企業が急増している。もはや次の“主流”と言っても過言ではない。実践手法や関連するコミュニティー活動も世界中で相次いで登場。その代表的な四つの最新動向を紹介しよう。 エンタープライズアジャイルを実践する企業は急増している。東京海上日動あんしん生命保険、関西電力、楽天などだ。 メインフレームとオープン系を基に、生命保険の契約支援の基幹系システムをエンタープライズアジャイルで開発し、2013年10月に稼働させた東京海上日動あんしん生命保険。「動くシステムを早期に確認できる手法なしに、システム開発の成功はあり得なかった」と、同社契約企画管理部の佐藤良章担当課長は述懐する。 エンタープライズアジャイルをスムーズに進めるためにプラクティス（タスクやノウハウ）をまとめた開発手法も、2012年ごろから登場している。アジャイル開発に、要件定義や予算計画

2013年後半から「グロースハッカー」という言葉をときどき聞くようになった。きっかけとなった書籍『グロースハッカー』の著者ライアン・ホリディは、「グロースハックとは、プロダクト自体を自己永続的マーケティングマシンにすること」と説明している。 またグロースハックに関連したキーワードとしては、 ・PMF（プロダクトマーケットフィット） ・仮説・検証・改善サイクルの高速回転 ・AARRRに基づくデータ解析 ・バイラル効果 などの手法が語られる。 しかし、すでにデジタルマーケティングの世界では、リーンスタートアップ、定量的テストマーケティングに基づく仮説・検証・改善、バイラルマーケティングなどは盛んに行われている。 にもかかわらず、なぜ「グロースハック」が注目されているのか？従来のデジタルマーケティングとの違いは何なのか？そのヒントをコトラーの「マーケティング3.0」が与えているように思われる。

アプリケーションの最も基本的な部分を支える開発基盤が大きく変わろうとしている。主役は「二つのJava」だ。Javaを基に、関数型という先進技術を導入した「Scala」。Scalaに触発されて関数型のアイデアを取り入れたJavaの次期版「Java 8」。この二つが互いに影響を及ぼしながら、本来ならトレードオフの関係にある「高生産性」「高品質」を両立できる新たな基盤を実現しようとしている。三菱UFJフィナンシャル・グループのように利用を始めた企業も出てきた。情報システム部門として二つのJavaを生かさない手はない。 （進藤 智則） 本記事は日経コンピュータ7月11日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集」の全文は、日経BPストアの【無料】特別編集版（電子版）で、PCやスマートフォンにて、7月18日よりお読みいただけます。なお本号のご購入はバ

by Gartner イヴォンヌ・ジェノベーゼ　VP兼最上級アナリスト デニス・ゴーハン　マネージングVP 片山 治利　リサーチディレクター 業務アプリケーションのユーザーであるビジネス部門と情報システム部門の間でギャップが広がっている。ビジネス部門のリーダーは、ビジネスの問題を解決し、市場の変化に即応でき、近代的で、使いやすいアプリケーションを求める。システム部門は、セキュリティを最大限に高めコストを削減するために、限られたアプリケーションの組み合わせのなかで標準化に取り組んでいる。これでは、両者の目標が相反することになる。 ガートナーが提唱する「ペースレイヤリング」とは、業務アプリケーションをユーザーの使用状況と変更頻度（ペース）で分類し、異なるガバナンスのプロセスを確立する新しい方法論である。ガートナーはアプリケーションを分類するにあたり、三つの層（レイヤー）を定義した。 （1）記録

三菱東京UFJ銀行が、アジャイル開発と従来のウォーターフォール型開発を組み合わせた企業向けシステム開発手法である「エンタープライズアジャイル」を導入する。2014年9月にも社内の標準プロセスとして取り入れ、“攻めのIT活用”の実現を目指す。メガバンクが正式に採用することで、日本でもエンタープライズ分野におけるアジャイル開発の導入が加速する可能性が高い。 3種類の開発プロセスを定義 エンタープライズアジャイルは、数週間の短いサイクルでシステムを段階的に開発してプロジェクトリスクを低減するというアジャイル開発の良さを生かしつつ、全体計画の策定や要件定義、設計といったウォーターフォール型開発の要素を加えたもの。三菱東京UFJ銀行は、システムの段階的な開発に計画、設計といった作業を組み合わせて、エンタープライズアジャイルの社内標準プロセスを策定する。従来は、ウォーターフォール型開発の開発プロセスし

（ユーザー企業にて） 情報システム部 S部長：先週カットオーバーしたばかりなのに、もうバグが出たそうじゃないか。 開発会社のPM：軽微なものでしたし、そんなに心配いらないと思います。 S部長：100％テストするはずじゃなかったのかね。 PM：その通りです。100％テストしたと報告を受けています。 S部長：おかしいじゃないか？　100％テストしたのなら、なぜテストでバグを見つけられなかったんだ？　実は「ちゃんとテストしていない」なんてことはないだろうな。 PM：そんなことはないと思いますが、確かに説明が欲しいところですね。 （開発会社にて） PM：今回は100％テストするということだったのに、「なぜバグを見逃したのか説明しろ」とS部長が言ってきている。本当は100％やってないんじゃないかと疑っているふうだった。 ITエンジニア：そんなことないですよ。約束通り新規の機能はちゃんと全部テストしま

プロジェクトに成功する企業と失敗する企業の二極化が進んでいる――。 本誌が5年ぶりに実施したシステム開発プロジェクトの実態調査から、 こうした現状が浮かび上がってきた。 全体の成功率は31.1％で5年前より4.4ポイント上昇。 しかし、率以上に変化したのはその内容だ。 成功企業と失敗企業の明暗を大きく分けたのは「測る」ことだった。 併せて調査したシステム部門の実態と共に、最新の分析結果を報告する。 （矢口 竜太郎、吉田 洋平） 本記事は日経コンピュータ12月1日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集1」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。 なお本号のご購入はバックナンバーをご利用ください。 本誌は5年ぶりに、ユーザー企業の情報システム部門を対象としたシステム開発プロジェクトの実態

アジャイル開発で著名なエンジニアの筆者は、アジャイルの流儀で英語学習のメソッドをまとめ、自ら実践。英語がほとんどできなかった状態から7カ月後には、海外のカンファレンスで講演とQ＆Aをこなすまでになった。その奥義の一端を披露するとともに、その後、海外での留学や講演などで得た気づきを紹介する。 目次

大手ICT企業の2013年度上期（2013年4～9月）の連結決算は、景気回復への追い風もあり、おおむね好調だったと思う。だが一方で、なぜか不採算案件の発表が相次いだのも特徴だった。