「クラウドとAPIの真の力は制約からの解放」、セブン銀行の平鹿氏2018年10月19日まで開催中の「日経 xTECH EXPO 2018」で、セブン銀行 システム部ITプラットフォーム室フェローの平鹿一久氏が「ビジネス変化に迅速対応するシステム、クラウドとAPI連携でどう実現するか」と題して講演した。
自分のコードを嫌いにならない、そのためにやるべきこと
「異能」ともいえる際立った能力や実績を持ち、まわりから一目置かれるエンジニアを1カ月に一人ずつ取り上げ、インタビューを掲載する。今月取り上げるのは、テスト駆動開発（TDD）の日本での第一人者として知られる和田卓人氏。JavaScriptのテストフレームワーク「power-assert」の作者でもある。最終回である今回は、power-assertの開発やテストに対する考え方などを聞いた。 （前回から続く） 自社製品を開発しようとワークフローエディターを自作して得たJavaScriptのスキルセットは、ぼくの大きな財産になりました。ワークフローエディターはかなり複雑なソフトウエアなので、テストコードなしでは開発は困難です。そこでJavaScriptのテストについてもいろいろ調べてみました。しかし、JavaScriptのテストの仕組みは当時はまだ全然発達しておらず、ほぼ手探り状態でした。 201
PMBOK大幅改訂、スキル転換を迫られるプロマネ
米PMI（Project Management Institute）はプロジェクトマネジメントの知識体系「PMBOK（Project Management Body Of Knowledge）ガイド」の第6版を、日本語を含む12カ国語で2017年9月6日（米国時間）に発表した。日本語版の書籍販売は2017年10月を予定している。 第6版では、ビジネスの視点を強化したのをはじめ、様々な内容を改訂した。以下で改訂のポイントを分析していくが、その前にPMBOKガイドの成り立ちや位置付けを簡単に紹介しておく。 PMBOKガイドの第1版は1996年に登場した。同ガイドの前身である「PMBOK」（1987年発行）をPMIが大幅に改訂。その名称をPMBOKガイドに改めて発行した。日本では日本語版の第1版が1997年に登場すると、大企業を中心に徐々に広まっていった。当初は建設やエンジニアリングの企業の採用
ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン
同期処理が失敗した原因は、4台をつなぐスイッチの不具合。具体的には、スイッチが故障状態であるにもかからず、故障を知らせる「故障シグナル」を発信しなかった。国内線システムは故障シグナルを検知するとスイッチを予備機に切り替えるが、今回はその機能そのものを作動できなかった。 スイッチは完全に停止したわけではなく、「不安定ながらも動作していたようだ」（同）。そのため、DBサーバー間の同期は順次失敗し、停止していったと見られる。 ANA広報によると、スイッチは米シスコシステムズ製「Catalyst 4948E」という。「2010年6月の発売開始以降、世界で4万3000台、うち日本で8700台を販売しているが、今回の不具合は初めての事象と聞いている」（ANA広報）。なぜ「故障シグナル」が発信できなかったかは分かっていない。 1台での縮退運転を決断 4台の完全停止から37分後、ANAは1台のDBサーバー
知っておきたい！システム障害時に使う英語：ITpro
年の瀬も迫ってきました。クリスマスへのカウントダウンも始まりましたね。今年は電飾が流行りなのでしょうか，家々の飾りつけが例年よりも賑やかなようです。クリスマスショッピング狂想曲を避けるため，早くからプレゼントの買い置きを計画する私ですが，今年も計画倒れ。今になってインターネットで注文するも，「バックオーダー受付中」のメッセージにパニックになっています。 7年前，大晦日を返上して待機していたY2K問題は，もう遙か遠い記憶の彼方に遠のいてしまいましたが，それでも毎年，年末年始は，ソフトウェアの更新，ネットワークの切り替えなど大きな作業が計画されるが故にノンビリできません。 ネットワークのダウンは“Outage” さて，GWや年末年始など多くの人々が連休を謳歌する時に限ってシステムの「障害」が発生し，ITプロの皆さんは呼び出しを喰らうことが多いのではありませんか？しかも大きな障害では2次サポート
「iPhone」がもうかる本当の理由 | 日経 xTECH（クロステック）
イノベーションを生み出し続ける米Apple社は、業績面でも超が付くほどの優良企業だ。直近の2014年度（2014年9月27日を末日とする会計年度）では、売上高が約18兆円、営業利益率が約30％と驚異的な数値をたたき出している。 革新的な製品である「iPhone」が、莫大な売り上げをもたらしていることは理解できる。しかし、30％もの営業利益率を実現している理由は、あまり知られていないのではないか。一般に、販売台数が多いからといって、必ずしも利益率が高いとは限らない。Apple社には、もうかるための仕組みがある。そして、それは1970～1980年代の古き良き日本のメーカーが実践していた設計手法と極めて似ているのだ。 現在、日本のメーカーは、「技術力はあるのにもうからない」「コンペで負ける」といった課題を抱えている。そうした状況を打破するためにも、Apple社のもうかる仕組みを学び、自社に取り入
スピード感で日本は惨敗、グローバルではやっていけない
スピード感で日本は惨敗、グローバルではやっていけない テラスカイ ダニエルソン氏の辛口日本論から何を学ぶか Force.comベースのシステム開発を手掛けるテラスカイで海外事業を担当するジェイソン・ダニエルソン氏はIT企業で働く傍ら、お笑い芸人として活動している。米国にいる頃にお笑い番組で日本語を学び、日本に来てからは週末にお笑い学校で学び、ITとお笑いの二足のわらじを履くに至った。 同氏のここまでのユニークな経歴は、インタビュー「2年勉強しても日本語を話せなかった悔しさが“お笑い”の原動力に」をご覧いただきたい。ITとお笑いのほか、国際的なビジネスコンペやMBAのビジネススクールに参加するなど、多彩な活動ぶりが分かる。 この記事はインタビューの続編に当たる。「記者の眼」としたのは、ここでダニエルソン氏が語った内容は、日本でITに関わる人間として、さらに日本人として非常に考えさせられるもの
IT業界のタブー「偽装請負」に手を染めてませんか：ITpro
最初に断っておくと，今回のテーマである「偽装請負」と，全国を震撼させている「耐震強度偽装」とは，ほとんど関係がない。共通点を挙げるとすれば，「違法行為だが，もしかしたらどの企業もやっているかもしれない」という疑惑が持たれている点だ。ちなみに偽装請負の詳細は，日経ソリューションビジネスの2005年12月30日号に記事を掲載している。読まれた方には，内容に重なる点もあるがご容赦願いたい。 さて，話を戻す。まず最初に，システム開発・運用現場の例をいくつか挙げる。 （1）ユーザー企業のシステム開発・運用業務で，2次請け・3次請け企業のIT技術者が常駐し，ユーザー企業のシステム担当者から直接指示を受けている （2）元請けシステム・インテグレータに，3次請け・4次請け企業のIT技術者が常駐して，元請け企業のマネジャーやSEから直接指示を受けて開発している （3）常駐している3次請け，4次請け企業のIT
（第1回）ここがヘンだよ！ 日本のIT業界
ITproの人気コラム「木村岳史の極言暴論！」ではこれまで幾度となく、日本のIT業界に蔓延するいびつな多重下請構造の問題を取り上げてきた。一方、海外での豊富な就業経験・起業体験から、硬直化した国内のIT業界に対し同様の警鐘を鳴らしてきたのが、元マイクロソフトのチーフアーキテクトであり、UIEvolutionファウンダー／会長兼ブロガーの中島聡氏だ。 かたや「ITゼネコン」（中島氏）、かたや「SIガラパゴス」（木村）と、呼び方こそ違えど、両者の問題意識には通じるものが多い。日本の内と外それぞれの立場から業界が抱える問題点を考察し、ITproの主要読者であるITプロフェッショナルたちが今後どう身を処していくべきかを存分に語ってもらった。（司会・進行は石井 智明＝日経コンピュータ編集委員） ――中島さんのメルマガ「週刊 Life is Beautiful」には、しばしば「ITゼネコン」という言葉
質問：藤本さんがCTOとして悩んでいることは？
回答本編に入る前に勝手ながらお知らせをさせていただきます。突然ではございますが、16回を数えました「エンジニアよろず相談室」は、今回を持ちまして連載終了となります。長らくのご愛顧・ご愛読ありがとうございました。次回作にご期待ください（あるかどうかわかりませんが...）。 ということで、最終回はどんなテーマがいいかな、と悩んでいましたら編集部の担当者の方が「この質問はいかがでしょうか？」と提案してくださいました。「相談室」をうたいながら最後は筆者の悩みを書き連ねることにします。確かに趣がありますし、ということでちょっと筆者苦悩の歴史を振り返ってみようかな、と思います。ただスペース足りないので一つだけに絞ってみます。 タイトルにも書きましたが、「CTOとして」ということになると、常に悩み続けているのはまさに「CTOとして何をすべきか」ということなのです。「何をしないか」で悩んでいると言い換えた
第7回・よりよい技術マネージャーに求められる“行動特性”とは？
製品開発において、技術マネージャーの果たす役割が重要である事は論をまたないであろう。一人で完遂出来る製品ならばともかく、高度な専門作業の集合である現在の製品開発は、設計開発をハンドリングする技術マネージャーが機能しなくては成立しない。 技術マネージャーには、日々進歩する技術、変化する市場環境に対応するため、常に自らの知識と考え方を進化させていく”柔軟性”が求められる。また、新技術について自分以上の知識を持つ部下に対し、確かな論理性と理学・工学理論知識及び過去の経験から、矛盾点や問題点を指摘できる”経験による確かな軸”という、一見相反する要素も求められる。 技術マネージャーの重要性は認識しながらも、では求められる資質・能力とは何なのか。“名選手名監督ならず”と言うが、エンジニアと技術マネージャーはどうなのかは、なかなか明らかに出来ていないのが実態ではないだろうか。 今回は、製品開発における技
使い道2 本番環境の一部に利用
本番環境でDockerを使うとなると、開発環境での活用に比べ慎重にならざるを得ない。何かトラブルが起こった際に、サービス提供に支障を来してしまうからだ。リスクを抑えるには、まずは再実行によってトラブルを回避できる処理などに限ってDocker上に実装するアプローチが現実的といえる。 ここでは、レシピコミュニティサイト「クックパッド」とWebサイトのテストサービス「ShouleBee」の事例を紹介する。 クックパッド セットアップが面倒なソフトを動かす クックパッドは、スマートフォンのWebブラウザーへ動画広告を配信するシステムでDockerを活用している（図1）。Dockerを使うのは、動画をスマホのWebブラウザー向けに自動変換する部分だ。
SIerの余命は5年、オオカミは本当にやって来る
どうも私はIT業界の人たちから、オオカミ少年だと思われているらしい。随分前から「SI（システムインテグレーション）ビジネスの終焉」を騒ぎ立てていたが、SIビジネスは幾多の不況期を乗り越え、しぶとく生き残ってきた。だから私がオオカミ少年だと言われるのは、まあ仕方が無い。だが、あえてまた言う。「今度は本当にオオカミがやって来る」。SIerの余命はあと5年である。 SIビジネスはユーザー企業などからシステム構築を請け負う人月商売だが、日本では“SIガラパゴス”と呼ぶ、世界に類を見ない多重下請け構造のエコシステム（生態系）を発達させてきた。このSIガラパゴスには、零細ベンダーも含めると約1万5000社がひしめき、元請けのSIerを頂点に、顧客である企業や公共機関のシステム構築に関するあらゆるニーズ（≒わがまま）に対応してきた。 これは、システム構築ではERP（統合基幹業務システム）をそのまま使った
Yahoo! JapanのHadoopは6000台、今後はOSS開発にも貢献
Yahoo! JapanのHadoopは6000台、今後はOSS開発にも貢献 ヤフー データソリューション本部 小間基裕本部長 など 世界最大の「Hadoop」クラスターを運用している企業と言えば、Hadoopの開発を始めた米ヤフーである。同社は2014年6月の「Hadoop Summit 2014」で、3万2000台のHadoopクラスターを運用していることを明らかにした。では日本で最大級のHadoopクラスターを運用しているのは誰か。それもやはり、ヤフー（Yahoo! JAPAN）だ。 Yahoo! JAPANが運用するHadoopクラスターの規模は6000台で、同社のビッグデータ専門組織であるデータソリューション本部には、220人のエンジニアやデータサイエンティストが集結する。同社データソリューション本部の小間基裕本部長、同本部の岡本慎一郎プロジェクトマネージャー、システム統括本部の
仕事を成功させる思考術（14）「社内調整が甘い仕事」はダメである
この連載では、「仕事を成功させるための思考術」を扱っている。前回は「自分の考えに酔いしれる仕事」とは何か、なぜダメなのかを述べた。「失敗をもたらす10のダメ仕事」は次の通りである。 （1）目的が曖昧で作業手順がいい加減な仕事 （2）情報が不足し鮮度も悪い仕事 （3）他人をないがしろにする仕事 （4）素人の浅知恵で判断する仕事 （5）発想が貧困でつまらない仕事 （6）自分の考えに酔いしれる仕事 （7）社内調整が甘い仕事 （8）資料が非論理的で分からない仕事 （9）説明の辻褄があってない仕事 （10）思想も志も見えてこない仕事 企画立案時だけでなく、日常での「ちょっとした仕事のアイデア」を考えるときでも「自分の考えに酔いしれる」ことなく「考えをいじめ抜く」ことが仕事の成功に欠かせないことを説明した。 また、「考えをいじめ抜く人」になるには、マインド面のアプローチとテクニカル面のアプローチの両方
質問：マネジャーを続けるかエンジニアに戻るかで葛藤しています
チームのリーダーとしてマネジメントを任されるようになりました。自分としては一エンジニアとして頑張りたいという思いもあり、このままマネジャーを続けるかエンジニアに戻るかで葛藤しています。藤本さんのご意見をいただければ幸いです。 まず最初に大事なことは、いわゆるチームマネジメントは決して片手間でできるようなものでも、やっていいものでもない、ということです。なので、結論を先に書いてしまうと、葛藤している暇があったら早めにどちらか決めてしまいましょう。まぁ言うのは簡単なんですけどね。 ものすごく単純な例えですが、エンジニアとして10台のサーバーで一つのタスクを分散処理したり一つのシステムを動かしたりするのと、マネジャーとして10人のチームメンバーを一つのゴールに向かってまとめ上げて走り続けることの、どちらが簡単でしょうか？ 前者を簡単と言うつもりは全くありませんが（前者も十分に難しいことが多いので
Part4 IOPSを理解する
ディスク単体の性能を，1秒当たりに処理できるI/O数で示したものが「IOPS」である。DBサーバーなど頻ぱんにディスクにアクセスする用途では，IOPSが高いディスクほど性能が良い データ転送時間には，ディスクから磁気ヘッドがデータを読み書きする平均メディア転送速度やインタフェースの転送速度，ドライブの信号処理とデータ転送を制御するCPUの処理時間などが加味される。 実は，これらの値は公開されていないため，正確なデータ転送時間は分からない。ただし，4Kバイトや16Kバイトなど，OSの読み書き単位程度の大きさであれば，数10マイクロ秒から長くても1ミリ秒程度であり，誤差の範囲である。 仮に，4Kバイトのデータを書き込むために必要なデータ転送時間を1ミリ秒とする。平均アクセス時間6ミリ秒のディスクにデータを4Kバイト単位で書き込むとする。このディスクのIOPSは，「1/（6ミリ秒+1ミリ秒）=1
プロジェクト・マネージャの「やってはいけない」---目次 - プロジェクト・マネージャの「やってはいけない...：ITpro
プロジェクト・マネジメントのアンチパターンを徹底解説 プロジェクト・マネジメントにはセオリーがある。セオリーを知らずに，あるいは軽視して，失敗するプロマネは少なくない。現場でたたき上げたベテランの凄腕PMが，現場でプロマネがやってはいけないことを解説する。 関連サイト： ■メール編 ■やる気編 ■要件定義編 ■会議編 ■報連相編 ■協力会社対応編 ■品格編 ■課題管理編 ■変更管理編 ■コミュニケーション編 ■外注管理編 ■姿勢・資質編 ■計画＆進捗管理編 ■品質編 ■姿勢編 理由無き要求は機能化してはいけない プロジェクト事務局を軽視してはいけない 過去の成功体験にとらわれてはいけない 自己研鑽を怠ってはならない 目的を忘れてはいけない ■プロジェクト完了編 完了条件をあいまいにしてはいけない 完了報告会を省いてはいけない 成功・失敗要因を不明確なままにしてはいけない フィードバックを忘
IT業界の人月商売、多重下請けがもたらす45の害毒
私は自分のコラム「極言暴論」で、ユーザー企業のIT部門とITベンダーの問題点や課題を極言し、暴論してきた。だが、特にITベンダーあるいはIT業界の話を書くと、空しくなることがある。私が指摘する問題点は、ITベンダーの経営幹部なら随分前から自覚している。それでもITベンダーや業界は何も変わらない。 「極言暴論」の読者にも「以前に何度も聞いた話」とシニカルに受け止められてしまったりする。「このままでは日本のIT業界に未来は無い」と叫んだところで、「またですか」とオオカミ少年扱い。やはり“ゆでガエル”状態になっている人には、湯の温度が多少上がったぐらいでは危機感を持って受け止めてはもらえない。 それでもクラウドの世となり、ITベンダーを丸ごとゆでる湯の温度は急激に上昇している。今起こっているパラダイムシフト、パワーシフトは以前のダウンサイジングやインターネットの爆発的普及のときの比ではない。シス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
［PostgreSQLウォッチ］第26回 ボトルネックをビジュアルに分析するログ解析ツールpgFouine