腕をさすりながらさっそくビルの中に入り、暖かい応接室に通される。すると、目の前には大きなディスプレイ。その前にちょこんと置かれているのは、リモコンのような形のゲーム機。それは明らかに3月3日発売の話題のゲーム機Nintendo Switchだ。そしてSwitchに差し込まれていたのは、あの話題の新作『ゼルダの伝説　ブレス オブ ザ ワイルド』――。 そう、ここは京都にある任天堂本社の応接室である。今回、ゲームの企画書で「ゼルダの伝説」シリーズを取り上げるにあたり、なんと取材前に我々は、1ヶ月後に発売を控える新作ゼルダのプレイをいち早く許可されたのだった！ さて、今回そんな新作を含む「ゼルダ」シリーズを聞くのは、『時のオカリナ』以降のシリーズに大きく関わり、その“生みの親”とも言える宮本茂氏から引き継ぐ形で、近作のプロデューサーを務めてきた青沼英二氏だ。一方、その対談相手を務めるのは、やはり

UXデザイナーになるということは、ある種の宗教に入信するようなものです。 UXデザイナーの仕事の一つは、他者にあなたの信念を受け入れさせることです。まるで聖職者の鑑のように、UXデザイナーは他者がUXの担い手になることを望みます。 ユーザー体験のような抽象的な概念について理解を得るには説明が必要です。そして、共有したい信念について共通の経験がない限り説明は失敗するでしょう。 「ユーザー体験が何であるかを説明することはできません。できるのは、示すことのみです。」 それでは、良い言葉を広めるためのいくつかの有効な戦略について深堀してみましょう。 最初の信者を構築する The Guide to UX Leadershipで説明したように、エバンジェリストは自分の声が届く範囲までしか影響を及ぼすことができません。 もし組織を拡大したいと考えているなら、信者の面倒を見るあなたの弟子たちのグループを作

レガシーコードをうまく手なずけて、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。レガシーコードをうまく手なずけて 、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。 レガシーコードはリファクタリングで救出可能 耳寄りなお知らせがあります！ リスたちは毎年何千本もの木を植えてくれています 。まあ自分たちが隠したドングリのありかを忘れてしまった結果ですけどね。そしてもうひとつ。 あなたのプロジェクトも救出できる のです。 ボスから任されたプロジェクトが どんなに醜い泥まみれのレガシーコードだったとしても 、そこには 必ず 道があります。道は曲がりくねっていて、木陰にはモンスターが待ち構えていることでしょう。

日立製作所は2016年2月16日、COBOLアプリケーションをJavaアプリケーションに変換するサービスの提供を始める。COBOL技術者の減少は避けられないとみて、COBOL資産からの脱却を顧客に促す。2020年までに累計10億円のビジネスに育てたい考えだ。 レッドハットと協力して作り上げた新サービスの「COBOLマイグレーションサービス」は、ツールを活用してCOBOLからJavaへの移行（マイグレーション）を支援するサービスだ。提供する機能は移行プロジェクトの工程別に三つの内容に分かれる。 プロジェクトの最初に取り組む分析工程において、現行システムの仕様をリバースエンジニアリングする「現行システム資産分析支援」機能を提供する。「ドキュメントが無い、あってもプログラムと乖離しているというのが多くのCOBOL資産の現状」と情報・通信システム社 アプリケーションサービス事業部 サービスソリュー

仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ

わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、

食産業の活性化は全国の地方大学の産学・地域連携の重要テーマの一つだ。室蘭工業大学のプロジェクトでは植物機能性成分の評価に、量子ドットイメージングや人工知能（ＡＩ）など最先端の技術を... マイクリップ登録する

「絶対落ちないシステムを作れ」という要件に、開発者たちはどう対応したのか。東証arrowheadの当事者が語る 「素人的に言えば、絶対落ちないシステムを作れ、というのがユーザーから見た要求条件」と発言したのは、東京証券取引所の株式売買システム「arrowhead」開発のプロジェクトマネージャ 宇治浩明氏。 東京証券取引所は2005年にシステム障害を起こし、取引が一時全面停止するという事態を引き起こしました。そのため2010年に稼働を開始した新システム「arrowhead」の開発では、高性能と高可用性という高い品質を実現することが絶対の目標となっていました。 東京証券取引所と、arrowheadの開発に当たった富士通。両社はどのように開発プロジェクトを通して高いソフトウェア品質を実現したのでしょうか？ 9月9日、早稲田大学 西早稲田キャンパスで行われた日本科学技術連盟主催「ソフトウェア品質シ

Query Optimization with MySQL 5.7 and MariaDB 10: Even newer tricksJaime Crespo

アーキテクトへの道という講習会を依頼されている。 結構なお客さんが予約してくれているようだ。 最近のアーキテクト案件では上手く振る舞えなかっただけに恐縮だ。 ということでアーキテクトの特徴を考えてみる。 アーキテクトは、 実装と業務設計のクロスチェッカーである ルールとポリシーの番犬である ソフトウェアとミドルウェアのチューナーである 担当者の不在領域の掃除人である トラブル対応の生きたデータベースである 斥候（先回りする人）である 古い慣習を覆して、新しい慣習をつくる老害予備軍である 期待と失望を一番最初に受ける窓口である よくわからないことを、よくわからないと言っちゃえる特権階級である スポークスマンである 講師である 独裁者である 自動化ツールの製造工場である Google検索役である 環境構築のパシリである 本番環境バグが出た時のしかられ役である 常に被告人側（バグを埋め込む側）の

僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという

マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

今まで数々のERP開発に携わってきたけれど、正直楽しかったと言う印象はあまりない。 開発者が想像するソフトウェア開発とは何か違う。 そんな時に梅田弘之さんの「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」を再読して、ERPについて色々と感じるものがあった。 ERPの落とし穴やポイントについて考えたことをメモ。 【1】ERP開発はソフトウェア開発ではない。要求開発だ！ ERPは基幹系業務システムのためにある。 その開発スタイルは正直ソフトウェア開発ではないと直感している。 開発者がイメージするソフトウェア開発は、問題やタスクをプログラミングやサーバー構築などの技術で解決していくこと。 その作業は大変だが、やりがいはある。 しかし、ERP開発では、顧客から要求を収集し、要件として定義して後続の設計作業に落とし込む作業期間が非常に長い。 開発でき