怒りを通り越してあきれるOracleユーザー
「Oracle Database（DB）は信頼性や可用性が高く、当社のシステムには欠かせない。しかしここ数年、保守料が右肩上がり。IT予算に占めるOracle DBの保守料金の割合が増えて困っている」。 製造業A社のシステム部長は悩んでいた。会計や販売管理、生産管理など社内の主要なシステムは全てOracle DBを利用している。しかし開発時期はバラバラで、システム構築を依頼したITベンダーもシステムごとに異なっていた。Oracle DBのライセンスはシステム構築に合わせて、その都度購入している。システムごとに同じOracle DBとはいえ、バージョンは異なり、システム部門の保守作業も手間になっていた。 「Oracle DBを使っているシステムの維持費用を削減したい」。こう考えたシステム部長は、安定稼働していて、今後も大きな業務機能の変更もないと想定できるシステムのデータベースの保守契約を止
［Erlang］分散システムに特化し耐障害性に優れた言語
Erlangの最大の特徴は、分散システムの構築に特化している点だ（表1）。Erlangを採用する企業は、Erlangに付属するライブラリー「OTP」が99.9999999％（ナイン・ナイン）の稼働率を誇る点を評価して採用することが多い。 Erlangは動的型付き言語であり、HaskellやScalaなど現在の関数型プログラミングの主流をなす静的型付き言語と比べると、関数型的な要素は少ないといわれている。このため、関数型であることを理由にErlangを選定したという企業はむしろ少ない。ただし、Erlangもコードを短くできるなど関数型の特徴は一定程度備えており、採用企業はその利点を実感している。 楽天は分散ストレージシステム「LeoFS」をErlangで自社開発し、2012年7月にオープンソースとして公開した（LeoFSのサイト）。狙いは自社サービスのユーザー数増加に伴うデータ量の急増に対処
第3回 プロセス・スケジューリング
Linuxは複数のプロセスを同時に実行できるマルチタスクOSです。第2回目で紹介したように，プログラムはプロセスという単位で管理されており，それぞれが独立したメモリー空間を持つことで複数のプロセスが干渉しないように動作できます。 しかし，通常のパソコンにはプロセッサが1つしか搭載されていませんので，同時に1つのプログラムしか実行できないはずです＊1。なぜ，Linuxではマルチタスクを実現できるのでしょうか。その答えはカーネルにあります。 今回は，カーネルがどのようにマルチタスクを実現しているかを解説します。 時分割でマルチタスクを実現 最初にプロセッサがプログラムをどのように実行するかを見てみましょう。 プロセッサの基本構造は至って単純です。プロセッサは「Program Counter（PC）」と呼ばれるレジスタが指し示すメモリー・アドレスから命令を読み込んで実行します。実行後は再度PCの
シンプルで分かりやすい「変化対応」への処方箋「ペースレイヤリング」
今から約10年前の2002～2003年ころに、「EA（Enterprise Architecture）」という言葉が、はやったことがある。EAとは、情報システムに関する企業全体のアーキテクチャーのこと。現状（As Is）とあるべき姿（To Be）について、テクノロジーアーキテクチャー、アプリケーションアーキテクチャー、データアーキテクチャー、ビジネスアーキテクチャーの4つのアーキテクチャーを作成し、As IsからTo Beへの移行計画を作成する。 日本では、経済産業省が2002年から本格的な取り組みを開始し、2003年に「業務・システム最適化計画（EA）策定指針（ガイドライン）」を策定。民間企業にも、その考え方は徐々に浸透していった。 当時、EAのメリットとしてよく指摘されていたのは、全体最適化により重複部分がなくなりITコストを最適化できる、という点だが、実は、情報システムがビジネスの変
第2回 基本設計工程のITアーキテクト
ITアーキテクトが作成する成果物に注目し、何のために作るのかを明らかにします。システム開発のライフサイクルを軸にし、今回は基本設計工程を対象にします。基本設計工程では、主に次の5つの成果物を作成します。 （1）論理データモデル図 （2）パッケージ図（永続化視点） （3）パッケージ図（機能視点） （4）アーキテクチャー設計ドキュメント （5）アーキテクチャー評価ドキュメント ITアーキテクトのはこの工程で、アプリケーションの構造を創出し、その構造を評価します。基本設計工程ではサブシステムごとに設計作業を進め、要件定義の深堀や、要件の変更（改善）が発生しているはずです。そこでITアーキテクトのタスクとしてポイントになるのは、並行する設計作業間で矛盾が生じないようにサブシステム間の依存関係を整理し、また、そのアプリケーション構造を支えるインフラを含めてアーキテクチャーを設計することです。 ITア
熱狂してすぐ冷める日本でどう続けるか
「日本人とは」と一般論を述べるのは避けようと思いつつ書いてしまうが、我々は熱しやすく冷めやすい。何かに関して盛り上がる時の集中ぶりはすごいが、いったん冷めてしまうと一切捨てて省みない。執念深く何かを続ける人もおられるが少数派である。 情報システムの世界に限っても、盛り上がり一気に冷めた例はたくさんある。一例として今回は「EA」を取り上げる。EAとはエンタープライズアーキテクチャの略で、10年ほど前に日本で大きな話題になった。日経コンピュータは2003年9月8日号で40ページもの大特集『EA大全 企業情報システムの救世主』を掲載した。 いくらなんでも「救世主」とは大げさだと思うものの、筆者は2002年に『プロジェクトマネジメントが日本を救う』という特集を作ってしまったので、同じ穴のむじなである。日経コンピュータの報道通りなら日本は二度も救われているはずだが、どうもそうではない。 当時はEAに
議事録のプロ
システム構築の現場は，人と人とのコミュニケーションの場でもあり，ヒアリングや報告などさまざまな目的の会議がたくさん開かれる。そこで問題となるのが「議事録」だ。会議の議事録の取り方を観察していると，実に様々な流儀・方法を目にすることができる。 時々見かけるのが会議をすべて録音して，後日，誰かがほとんど1日費やして聞きなおしてすべて書き出すというもの。出来上がった議事録は数ページに及び，それを関係者に配ったとしても誰も見ようとはしない。それほどに冗長な議事録ではなくても，議題ごとに誰が何と言ったかについて克明に記述された議事録はよく目にする。 第一話で登場したIさんは要求定義ヒアリングのプロであるだけでなく，議事録のプロでもある。Iさんに「議事録の書き方はどうしたらいいか」と尋ねると，「決まったことだけ書いてください。それ以外は基本的にいらないといっていいでしょう」と言い切る。 会議の場では様
第10回 次につながる議事録づくりを！～チームを動かすための書き方～
今回は「次につながる議事録づくりを！」と題して，議事録をどう書けばいいのかを解説しよう。 議事録には，会議での決定事項や決定に至るプロセス，残件などを明確にし，チームメンバーに行動を起させる，という大事な役割がある。議事録が配布されなかったり，配布が遅かったり，議事録の内容に問題があったりすると，会議での決定事項が実行されない恐れがある。それくらい，議事録は重要なのだ。 早速，前回のケーススタディの続きから，スタートしよう。 情報システム室主任の山田さとしがリーダーを務める，あけぼの産業の次期基幹システム再構築プロジェクト。プロジェクト・メンバーはまず，各部門の業務・システムの問題抽出に取り組み，自部門の問題・課題をなんとか整理できた。山田は，問題・課題を全メンバーで共有し，他部門の観点から意見を出し合うための検討会議を開催。長時間にわたった検討会議もようやく終わろうとしていた･･･。 情
第69回 たかが議事録、されど議事録
会議の進行どおりに発言を記録していくような議事録は、あえてムダだと言いたい。それぞれの会議には、それぞれの目的がある。その目的達成を助けるような議事録を作れなければ、議事録の作成時間は大いなるムダとなるはずだ。 後藤 年成 マネジメントソリューションズ マネージャー PMP 皆さんの仕事場では、議事録を残しているでしょうか。PMOとして仕事をしていると、会議のファシリテートと同じぐらい、会議の議事録をとる機会（仕事）が多く、筆者も議事録の作成をどのように効率化しようかといろいろ悩みました。 特に最初は、「どの程度まで議事を記録すればよいのか？」「何を言っているのか分からず議事録がとれない！」「議事録にしたくとも、結局、何も結論が出ていない！」など、議事録の作成で苦労した経験があります。今回はPMOとして議事録にどのように向き合い、どのような議事録を作成すればよいか考えてみたいと思います。
［コミュニケーション編］議事録を相手に任せてはいけない
議事録を一度も書いたことのない読者はいないだろう。おそらく誰もが新入社員時代に書き方を教わる文書で、誰もが書くのに苦労する文書である。一所懸命時間をかけて作成した議事録を上司や先輩に持って行ったら、真っ赤になって返ってきたという経験をした読者も少なくないはずだ。議事録とはビジネスに無くてはならない文書の一つで、それはシステム開発プロジェクトにおいても同様である。プロジェクト内で作成する数多くの文書の中で、議事録ほど数多く作成される文書はない。 初めてPMに抜擢された中堅社員Sさんの経験 Sさんは大手通信企業の情報システム部門で働く中堅社員である。若い頃はプログラマとして働き、数年前に社内SEとなり実績を重ねてきた。そして今回、自社のシステム再構築に当たり、初めてPMとして抜擢されたのだった。 今回のプロジェクトは開発規模が比較的大きいので、大手SIベンダーのB社と一緒に開発を行うことになっ
受託開発／議事録の証拠能力のウソ・ホント
システム開発をめぐる契約は、年々複雑さを増している。クラウドを使ったシステム開発やアジャイル開発のプロジェクトなど、開発手法や技術の変化で契約の仕方が分かりにくい場面が増えている。開発契約に携わる法務担当者や現場担当者、弁護士などへの取材を基に、今現場が知っておくべき開発契約の知識を、「ウソ」と「ホント」で解説する。 今回は、受託開発と裁判における議事録の証拠能力についての「ウソ」と「ホント」を取り上げる。 請負でも委任でもない受託開発がある 受託開発で個別にシステムを開発するが、その開発費を請求せず、SaaSの利用料で稼ぐ開発ベンダーが登場し始めた。 受託開発でありながら、請負契約でも準委任契約でもない契約形態のサービスを提供する企業が登場している。永和システムマネジメントの「価値創造契約」、ソニックガーデンの「納品のない受託開発」がそれだ。 両社のサービス内容は共通している。まず、発注
エクシード、DevOpsツールのクラウドサービス「cloudrop」を開始
エクシードは2013年2月13日、システム開発者を想定ユーザーとしたシステム運用管理ツールのクラウドサービス「cloudrop」を開始した（図）。運用担当者ではなく開発者を想定ユーザーとした運用管理ツールのことを、最近「DevOpsツール」と呼ぶ。cloudropはDevOpsツールとして著名な「Chef」をベースにしており、システム運用の「ひな形」を使ってOSやミドルウエアの運用管理を自動化できる。 米オプスコードが開発するChefの特徴は、リレーショナルデータベースソフトの「MySQL」や分散バッチ処理ソフトの「Hadoop」、Webサーバーの「Apache」などの設定を変更するスクリプトを、プログラミング言語の「Ruby」を使って記述できることである。Chefでは運用管理用のスクリプトを「レシピ」、特定のソフト用にレシピをまとめたものを「クックブック」と呼ぶ。 エクシードはChefの
やり方の工夫、少し変わった使い方
アイスブレーカー実践編の最終回となる今回は、やり方の工夫や少し変わった使い方をご紹介します。前回までのいろいろなアイスブレーカーが、やり方次第でまた違ったものになり、効果も楽しさも変わってきます。また、会議の場所や人数によっては、いつもと同じやり方だと時間がかかりすぎたり、やりづらかったりもします。やり方1つにしても考えだすといろいろとありますので、その中の幾つかをご紹介します。 まずは問いかけのお題選びです。問いかけのアイスブレーカー自体は連載初回でご紹介した通り、いろいろな問いかけの種類がありますが、やり方としては、1つの質問について参加者皆さんに順番に答えていただくというのがものでした。 お題選びはそれを少し変えて、会議の参加者皆さん各々に別々の質問を選んでいただき問いかけるというものです。以下の絵のようなイメージですね。 テーマを書いたカードを幾つか用意し、1枚選んで質問に答えてい
［6］改善活動継続の可否は、会議の上手な運用にかかっている
前回では改善活動の展開を自身だけでなく、部下や後輩などにも広げる方法を紹介しました。空間軸での効果の拡大を目指したわけです。最終回である今回は時間軸の観点、つまり将来にわたって効果を継続させることを目指していきます。それでは以下のチェックシートをやってみてください（図）。 改善の効果を定着させるためには、属人的な能力に頼り切りにしないための「仕組み」が非常に重要になります。以下では、まず仕組みが担う「役割」を最初に解説し、それから仕組みを作る際のポイントを具体的に伝えていきます。 「人が気をつける」というルールは御法度 「仕組み」の役割の1つ目は、人間の能力を補完し、常に100％の能力を出せる状態に近づけることです。人間は非常に高い能力を持っていますが、それを常に発揮できるわけではありません。その不確実な部分を仕組みで補うことで、より確実に成果を上げられるのです。 例えばトヨタ自動車の安全
［報連相編］報告を受けておしまいにしてはいけない
PM（プロジェクトマネジャー）はとかくメンバーから報連相されるのを当然だと思いがちだ。しかし忙しいさなかに報連相をし続けるのは、メンバーにとって、それなりのエネルギーが必要だ。特に書類で報告する場合、手間も労力もかかる。 書類による報告をしたときにメンバーが気になるのは、「報告した内容をPMは読んでくれたのかどうか」「読んだ結果、PMはどう思ったか」だ。このとき、PMから的確な指示やアドバイスといったレスポンスが全くなく、報告がただブラックホールに消えていくような状況だと、あっという間に送り手のエネルギーは尽きて、正確な内容の報連相は途絶えてしまう。 「コミュニケーションはキャッチボール」という言葉がある。投げられたボールをつかんで投げ返す。ただそれだけのことなのだが、これができるかどうかで報連相がうまく機能するかどうかが決まるのである。 読んでいることを伝えなかったDさんのケース あるS
プロジェクトの失敗パターン
今回は「世の中のプロジェクトの典型的な失敗パターン」をご紹介したいと思います。 私自身、これまでに数多くのプロジェクトを見てきましたが、うまく行っていないプロジェクトにはやはり共通したパターンがあります。これまでのおさらいも兼ねて、皆さんのプロジェクトにも同じようなパターンが見られないか、代表的なパターンと比較しながらチェックしてみてはいかがでしょう。 「プロジェクトのゴール」が曖昧 まずはコレ。「何のために行うのか」、「何が実現されれば良いのか」が曖昧なままにプロジェクトが進められるパターンです。 このパターンでは、プロジェクトに多くの影響が現れることになります。例えば、ゴールがないと最短ルートが見えずに非効率となりますし、プロジェクトのスコープを追加したいなどという要請があった場合の判断が難しいため、プロジェクト範囲拡大の要因となります。もっと言えば、プロジェクトの成功度合い（求められ
部下の作業遅れ、PMやリーダーはどう行動する？
開発プロジェクトで部下の作業が遅れたとき、プロジェクトマネジャー（PM）やリーダーは、どんな行動を取るべきか――。先日、日経SYSTEMSの取材で訪れた方々と、こんな話題で議論を交わした。 驚いたのは、過去と現在でその行動に変化が表れていることだ。かつて多かったのは「叱責」である。「今のままでは納期に間に合わないぞ」「早く終わるようにもっと頑張れ」。作業の遅れを挽回してもらうために、メンバーの気持ちを引き締ることを狙ったものだ。 しかし現在は、この方法が通用しないばかりか、かえって遅れを大きくすることがあるというのだ。世代間ギャップだという面はあるだろうが、それだけで片付けるのは乱暴かもしれない。昔と違って今のプロジェクトは、メンバー数がかなり絞られている上に、納期もより厳しくなっている。そうした中で「頑張れ」「早くやれ」という一方的な叱責は、メンバーのやる気を削ぎ、さらに遅れを大きくする
ジェミナイ、分散KVS「Cassandra」を使ったリアルタイムログ解析システムをOSS化
ジェミナイ・モバイル・テクノロジーズは2011年3月3日、リアルタイムログ解析システム「Flume-Cassandra Log Processor」をオープンソースソフトウエア（OSS）として公開した（配布サイト）。大量のシステムログを瞬時に分析して、グラフィカルなレポートを作成できる。ログ保存には、OSSの分散キー・バリュー型データストア（KVS）「Cassandra」を使用する。 Flume-Cassandra Log Processorでは、監視対象のサーバーで発生したイベントのログを、1秒以内にストレージであるCassandraに保存する。Cassandraは書き込みが高速な分散KVSで、サーバーの台数に比例して、ストレージ容量とI/Oを拡張できる。そのため、クラスターのサーバー台数を増やすことで、数百Tバイトのログの格納が可能になるとしている。ログの分析機能やレポート作成機能のほ
［1］格安ボードでエアコンを操ろう
安価なマイコンボード「Arduino」とLinuxサーバーを組み合わせ、家電を制御します。出先でスマートフォンなどから手動でエアコンをON/OFFしたり、部屋の気温が高くなったとき自動でエアコンをつけたりします。ECサイトの特売情報もチェックして、目覚ましを鳴らします。 2000円台からと安価なマイコンボード「Arduino」は、色々なセンサーを付けて周りの状況を調べたり、赤外線LEDを取り付けて家電のリモコンとして動かしたりできます（写真）。 今回は、このArduinoボードとLinuxサーバーを連携させ、日々の生活をちょこっと便利にするシステムを作りました。目覚まし時計も兼ねる、インテリジェントな学習リモコンとして動作します。好みに合わせたカスタマイズも可能です。 エアコンを自在に制御 今回のシステムは、大きく3つの機能を持ちます（図1）。1つ目は、出先からエアコンを制御する機能です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Java技術最前線 櫻庭祐一 連載目次 ：ITpro