update it, Inc.社長のブログ

Google Developer Day Tokyo の鵜飼さんのプレゼンをまとめたメモ（ブログ）へ?たのめも「Google のソフトウェア・エンジニアリング」を読みました。Googleは既にテレビを始め、いろいろなメディアで開発スタイルが紹介されていまずが、実際に中で働いているエンジニアの方自身による、社内での開発の様子というのは非常に参考になりました。

いろんなところで持ち上げられているGoogleの開発スタイルは、実際にこうやって聞いてみてすごいな、と思う部分が多いのですが、一方で、あ、これは実は基本的なことをきちんとやっているのにすぎないのだな、と感じることも多く、そういった意味ではなにか自分のまったく知らない世界があるというわけではないという点で、ちょっと安心した部分もあります。

私が一番感銘を受けたのは、Googleでは偉い人（フェローとか）ほどコードを書きまくっている、という話です。日本とは逆ですね。私の会社でもぜひこれを目指したいです。

メモの中に「Design Doc」というのがあるのですが、これは一般にいうところの「システム概要設計書」（会社によっては基本設計書と呼ぶこともあるらしい）そのものですね。同じじゃん、と思ったのですが、一方でさすがだな、と思ったのは「一般的にはあんまり長くない。」ということ。これです。無駄に分厚いものが良いのではありません。（読んでいない人はぜひ過去の私のブログ?設計書に書くべき範囲を読んでみて下さい）

あと、

・パフォーマンス重視
・スケーラビリティ重視
・信頼性重視

というあたりは、Googleならではのプロフェッショナリズムを感じます。ぜひこうありたいですね。

このブログを見ていただいている方の中には、安中はいったい何をやっているんだ？と思っている人も多いと思います。たまには私の会社でやっていることも書きましょう。タイトルのAPISとは現在開発中のプロダクトのコードネームです。（ちなみに商品・サービス名はこれとは異なる予定です）　

ホームページにも書いたのですが、弊社は現在、「まったく新しい形のコラボレーション・サービス」を目指して研究・開発中です。プロジェクトのチームワークの力を高める手助けとなるシステム・サービスを提供したいと考えています。このシステム・サービスを提供するためのプロダクトのコードネームがAPISというわけです。

APISとはミツバチの学名（正確にはミツバチ属の名前）です。ミツバチは社会性のある昆虫で、それぞれが役割を担いながら巣を作っていくイメージを、チームがプロジェクトを進めるイメージと重ねあわせて、APISというコードネームにしました。

現在、開発は7月末のM2を目指しているところです。その後、8月末にRC1、9月末にRC2とし、10月には1.0をリリースする予定です。RC1もしくはRC2についてはClosed βという形でお披露目できるかもしれません。

で、肝心な中身というか、どんなものなのかについては、今後このブログを通じて少しずつお伝えしていきたいと思います。お楽しみに。

皆さんの会社や組織では、何か定期的な行事のようなものはありますか？　例えば毎週全員参加で部会をやっているとか、そのようなことです。で、その行事やミーティングは何のために行われているのでしょうか？　そして参加している人たちはみんな、その目的を理解し、かつ必要性を十分に認識した上で参加しているのでしょうか？

ただなんとなく集まって、参加意識も希薄なまま時間が過ぎるのを待つ、という人がいるとしたら、おそらくその行事やミーティングはうまく機能しているはいえないでしょう。社内を見渡して、そうなってしまっている行事やミーティングがありませんか？

もしあるならば、今一度、真剣にその行事やミーティングの意義、目的をとことん話し合い、納得できる状態にする必要があるのではないでしょうか？　特に重要なのは、経営サイドから、本音ベースで何をそこに求めているのかをきちんと知ってもらうことだと思います。いいこと、悪いこと全部含めて、お互いにきちんと納得した上でその行事やミーティングに臨むことができるのだとしたら、だいぶ違ったものになるのではないでしょうか？

そして、たまにはその目的と現状の「たな卸し」を行って、見直しを行うことも重要だと思います。個人の評価では期初に目標を立て、期末にはその目標と達成度の比較などを行うわけですが、同じように社内行事やミーティングについても、定期的に目標を立て、期末にその達成度を評価するプロセスがあったほうが良いのかもしれません。

皆さんはアプリケーションが使いにくくてイラついたことはありませんか？　私は根が短気なのか、よくあります。つい先日も会社で使っている、あるバックアップソフトのあまりにもの使い難さに腹を立ててブーブー言っていました。

その時に腹を立てていた理由は、こんなことでした。

１．単純なことをインスタントにやる方法がない。（すべての処理について一旦ウィザードを使ってタスクを生成し、その後で実行する形になっている）
２．処理をしている間のリアルタイムのフィードバックがわかりずらい。
３．エラーが発生したときに、正しいエラー原因が提示されない。
４．処理が失敗しているときに、ログを見てもなんだかよくわからない。

おそらく作る側は、バックアップの日々の運用の自動化を第一の目的として作っているので、１．については仕方ないのかな、とは思うのですが、ちょっとテープのVerifyがしたいな、と思った程度のことでもいちいち同じ手順を踏まなければならない、ということでまずちょっとイラつきました。

次に２．ですが、一応リアルタイムのフィードバックはあるのですが、起動した処理との関連がわかりずらい。この「わかりずらさ」でさらに　イラつき度++（インクリメント）されました。

で、３．ですが、処理が失敗すると画面上に赤いエラーという文字が点滅するのでエラーであるのがわかるのですが、このエラーの原因がおそらく見当違いなエラーメッセージになっているのです。昔、MS Officeで「メモリーが足りません」というエラーメッセージが頻発したときに、知人から実際にメモリーを増設してみたのだけどだめだった、という話を聞いたことがあるのですが、まあそんな感じの話です。エラーが発生しているときに見当違いの原因を提示されると、イラつき度 *= 10（10倍して代入）ぐらいになります。

最後に４．のログを見てもわけがわからん（そもそも失敗していることがでていない、結果には「完了」と出ている、など）に至って、ついに throw new IraIraException() したわけです。

まあ、「またひとつ勉強させてもらった」と考えれば良いのかもしれません。こういった一つ一つのことを反面教師として捉えて、自分が作るシステムがそうならないようにしていきたいと思いました。

昨日、関東甲信地方が梅雨入りしたと気象庁から発表があったようですが、今日は（今のところ）横浜地方、おもいっきり晴れてますね。

公園のアジサイがきれいです。

最近よくSaaS(Software as a Service)という単語を聞くようになりました。基本的には昔のASPという単語の焼き直しなのですが、そのときは騒がれた割に掛け声倒れで終わってしまったためにあまり良い印象がありません。そういうこともあって新しい言葉が造語された、ということもあるのでしょう。もちろん「SaaSとASPではここが違う」とか説明がありますが、本質的な部分は一緒だと思います。ただし社会基盤として高速で安価なネットワークが完備されたことで、ASPのときの失敗の大きな原因が取り除かれているといえるでしょう。

私は、このSaaSは単なるブームではなく、勝ち残るシステム提供会社が進む道だと考えています。SaaSの世界ではシステム開発会社ではなく、システム提供会社となります。この「開発」から「提供」へ変われるか変われないかが、大きな分岐点であり、勝者と敗者の分かれ目になると考えています。

今までシステムを開発することを生業としてきた会社は、基盤的なものを提供する一部の会社を除いて、システム提供会社の下請けに甘んずるか、どんどん狭くなる市場から徐々に淘汰されるか、システム提供会社の提供するサービスに対するコンサルティングで食べていくか、それらのいずれかになっていくのではないかと私は予測します。

そうなるとすると、百貨店的な分野を問わないシステム開発を手がけているベンダーよりも、ブティック的に、ごく専門的な特定の分野についてのシステム開発に強いベンダーのほうが有利になるのかもしれません。というのは、どのようなシステムを提供すべきかがわかっているからです。

以前のブログでも書きましたが、これこそが「製造業」から「サービス業」への転換です。さて、日本のシステム開発会社の中で、どれくらいの会社がこの流れについてこれるのでしょうか？

皆さんはシステムテストを行うときのテストデータはどうやって準備していますか？　全パターンデータを手作りという場合もあるかもしれませんが、むしろ本番データを活用することのほうが多いかもしれません。個人情報などの部分をマスキングした上で本番データを一部コピーしてシステムテストに利用するというのは比較的よくやる話だと思います。

本番データをシステム・テストデータに使う場合、一番問題になるのはテストパターンのカバレッジに関する部分ではないでしょうか？　つまりテストしたいパターンについて十分なカバレッジをもったデータの場合にはそれをそのまま使えばよいわけですが、本番データだけではテストしたいパターンを網羅できていない場合も多いと思います。そのような場合にはなんらかの形で人工的にパターンデータを作り出す必要がでてきます。

場合によってはテストデータを作るためのツールやプログラムの別途開発が必要なこともあるかもしれません。そのためには工数もかかります。いざテストという工程になってからでは間に合いません。

つまり、システムテストへの準備はシステムテスト工程になってからでは遅い、ということです。システム開発と同時にシステムテストに向けたデータ準備を忘れずに。

でも、九州のほうではそろそろ入梅しそうだとのこと。横浜もこの天気は今日まででしょうか？

5月末にかけて、NTT東（西）日本のIP電話サービス「ひかり電話」関連の障害のニュースが続きました。5月23日に起きたのは東西間接続装置のハードディスク交換時に作業ミスで誤ったコマンドを送信したのがきっかけで東西間の通話が普通になったという件。一方5月30日には、ルーターのソフトウェアのバージョンアップに絡んで、着信できなくなる障害が発生した、という報道がありました。

この２つのトラブルは、もちろん直接的には別々の原因から起こっており、たまたまトラブルが続いた、ということだと思うのですが、システム屋の観点から気になったことを書いてみたいと思います。それは、こういったトラブルから何を学ぶか、ということです。

私が一番気になったのは検証環境での事前テストはやったのだろうか、という点です。システムにはバグがつき物です。新しいものを入れたときにトラブルが発生するというのは良くある話です。トラブルの原因は個別にいろいろあって、完璧にトラブルはなくすスペシャルな方法はないと思いますが、本番適用の前に、事前にトラブルを検知することは、ある程度できるはずです。つまり検証環境を用意して、そこで「事前にチェック」することで、本番でのトラブルを回避できたかもしれない、という点です。

検証環境は本番環境そのものではないので、必ずしもすべてのトラブルをあぶりだせるわけではありません。しかし、できるだけ本番環境に近い状況を擬似的に作り出したり、場合によっては本番環境以上に厳しい状況を人工的に作り出すことによって、どんなことが起こるのかを事前に確認することができます。

検証環境においてテストをシステマティックに回すというのも、高度なノウハウが要求される分野です。ただ単に検証環境で動かせばいいというものではありません。トラブルをあぶりだすには、総合的なチェックにとどまらず、やばそうな部分を予め抽出しておいて、その部分については重点的にチェック（ストレステストなど）するということも必要になります。

トラブルを繰り返さないためには何をすべきか。常に考えていきたいと思います。

初夏ですね。というか、今日は真夏ですね。