私は1977年入社。約30年前となる当時と今では、ソフトウェアテストはものすごく大きく変わった。この30年を振り返り、これから30年後にどう変わるか、という予想を紹介したい。 これがソフトウェア開発技術の歴史をざっくりと示した技術マップ。 一番左は1964年。仮想記憶を使った初めてのメインフレーム用OS「OS/360」の開発。これは人類史上最初で最後の超巨大プロジェクト。当時で5000人年、だいたい1200人が4年間働いた。 これはコンピュータが大発展する礎になるのだが、プロジェクトとしては大失敗だった。このときのプロジェクトマネージャがフレデリック・P・ブルックス Jr.氏。 1968年には「ソフトウェア工学」という言葉が誕生した。まだ言葉だけだが。このころ主流はアセンブラ言語。FortranとCOBOLが登場し、サブルーチンという概念が出てきて、これを使うとソフトウェアが格好よくできる

米Salesforce.comは2012年1月31日（現地時間）、電話や電子メールだけでなく、FacebookやTwitterといったソーシャルメディアをカスタマーサポートに活用するクラウド型のヘルプデスクサービス「Desk.com」を発表した。Desk.comはSalesforceが2011年9月に買収を発表した米Assistlyが提供していたもので、既に米Instagramなどが利用している（関連記事：Salesforce.comがヘルプデスクアプリのAssistlyを買収、中小企業市場開拓を強化）。 Desk.comは、FacebookのFacebookページ、Twitterのツイート、電話、電子メールといった複数のチャネルから入る顧客の“声”をリアルタイムで一覧表示し、対応できるサービス。パソコンだけでなく、iPhoneやAndroid搭載スマートフォンからも利用できる。使い始める

アクセンチュアとNTTドコモは1月19日、コンテンツプロバイダーに対して、スマートフォン向けリモートテストサービスを提供することを発表した。提供開始は3月下旬の予定。当初は「dメニュー」に掲載されているコンテンツプロバイダーが対象で、順次拡大するという。 コンテンツプロバイダーがスマートフォン向けのコンテンツを開発する際、アプリなどの実機動作を遠隔地から検証するリモートテストセンターを活用した開発支援サービスを提供する。 アクセンチュアは、公立大学法人会津大学産学イノベーションセンターにリモートテストセンターを設置し、運営と研究活動を実施。NTTドコモは、アプリなどの実機動作を検証するリモートテストサービスをコンテンツプロバイダー向けに提供する。 今回のサービスを活用することで、コンテンツプロバイダーはPCからリモートテストセンターにアクセスするだけで、開発したコンテンツの実機動作検証が可

Cloud Foundryで始めるPaaS構築入門：CloudFoundryで始めるPaaS構築入門（1）（1/2 ページ） この連載では3回に分けて、「Cloud Foundry」というオープンソースパッケージを用いて、Platform as a Service（PaaS）のためのインフラストラクチャを構築する方法について解説します。 Platform as a Serviceとは何か クラウドコンピューティングに対する注目が高まる中、Platform as a Service（PaaS）という言葉をすでにご存じの方も多いことでしょう。これは、元々セールスフォース・ドットコムが2007年に打ち出したコンセプトです（用語説明）。 PaaSのサービスプロバイダは、ユーザーに対して、アプリケーションサーバ、データベースサーバなどの「プラットフォーム」環境を提供します。PaaSのユーザーはこれら

グーグル、Paxosを採用したApp Engineのデータストア「High Replication Datastore」が1年間ゼロダウンタイムだったと報告 いまから約1年半前の2010年6月、グーグルはGoogle App Engineの利用者拡大への対応が後手に回り、深刻な性能低下や障害に見舞われました。グーグル自身が「Google App Engineの利用拡大に追いつけていない」ことを認める記事をブログにポストしています。 その半年後の2011年1月、こうした問題を解決するために登場したのが、新データストアのHigh Replication Datastoreでした。 High Replicatin Datastoreは、それまでのデータストアが採用していたMaster/Slave型でのデータセンター間の冗長性を、Paxosアルゴリズムによる同期に変更し、特定のデータセンターに障害

グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。 そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。 そのバグ予測アルゴリズムとはどんなものなのか。Google Engineering Toolsブログに投稿されたエントリ「Bug Prediction at Google」（グーグルにおけるバグ予測）で説明されています。 ソースコードの修正履歴を基に予測 コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。これはコードを静的に分析して、

ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 gitのレポジトリを分析 bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。 以下のようにインストールして実行（説明ページから引用）。 $> gem install bugspots $> git bugspots /path/to/repo $> git bugspots . # (in current git directory)

京都に拠点を移して3年が経過したはてな。同社は2011年秋頃から矢継ぎ早にサービスリリース、サービスリニューアルを進めている。“ソーシャル”をうたうサービスが注目を集める中で、はてなはどんな立ち位置を狙うのか。代表取締役の近藤淳也氏に聞いた。 --シリコンバレーから戻り、京都にオフィスを移して3年が経ちました。環境はいかがですか。 シリコンバレーに行った頃に描いていた理想のストーリーは、現地でエンジニアを採用し、新しいサービスを世界に向けて出してグローバルスタンダードになることでした。ですが実際のところ、米国でエンジニアはとれなかった。シリコンバレーはやはり競争が激しく、言葉の問題もあります。やろうと思えばやれても、時間がかかると思いました。迷った末に日本に帰るという選択肢を選びました。 当時は20人くらいだった会社も、今は社員で50人。バイトなど含めれば100人規模と増えました。関東では

そう話すのは、ピクシブ株式会社のディレクター中村氏と鈴木氏。 多くのユーザーが自分でイラスト・漫画・小説を創作し投稿するpixivのサイトでは、検索エンジン最適化に関してどんな問題を抱えていて、どんなSEO施策を進めたのだろうか。 今回pixivのSEO施策を担当した株式会社アイレップの担当者とともに、話を伺った。 今回のSEO施策でpixivが行ったのは、次のようなものだ。 サイトコンテンツのインデックス促進 ―― 重複コンテンツなど不要なページへのクロールをなくし、意味のあるページをよりクロールしやすいようにサイト内リンクを最適化することで、検索エンジンが効率的にコンテンツをインデックスできるようにする最適化。検索ボリュームが多くなるキーワードに対応した重み付け ―― 関連するイラスト投稿の多いキーワードに対するサイト内リンクが自動的に増える仕組みの実装。検索エンジンが理解しやすいペー

livedoor Blogなどのサービスで実際に大量の画像データ管理・保存に使用され、「高価な専用ストレージを使用することなく安全、高速に大量のデータを保存・参照することが可能になります。またSTFは既存のオープンソース技術で作られているため専用ストレージに比べ運用に際して新たなノウハウを学習する必要がありませんので、運用にかかるコストが低くなります」というなかなかよさそうなストレージシステム「STF」が公開されました。ライセンスは「Artistic License2.0」です。 livedoor ラボ「EDGE」 開発日誌 : 分散オブジェクトストレージシステム「STF」公開のお知らせ - livedoor Blog（ブログ） http://blog.livedoor.jp/edge_labs/archives/1609981.html 開発までの経緯は以下のようになっています。 以前

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、パラメトリックス法の1つ「SLIM」を取り上げます。上司からのムチャな開発期間の短縮要求をはねのける“究極の反撃法”が、このSLIMによる見積もりです。 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。前回は