Visual Studioの開発現場から（第9回）p2

これは伝統か——ユーザーの立場に立って使うドッグ・フード作業
　特定のフィードバックをいただいたあとに，内容を掘り下げるため，それを応用し実践する必要があります。私たちは社内で「ドッグ・フード」などと呼びますが，使う側の視点に立ち，自分たちで作ったものを自分たちで使う，料理で言えば味見のような作業が，マイクロソフトの開発では行われます。このドッグ・フードの際に，いただいたフィードバックを基に作業を行うと，バグだけでなく様々な要求シナリオの抜けている部分や，作り込みの甘さが露呈してきます。

イラスト：岡本 敏

　これらは，複雑なものを創る際には，どんなに綿密に計画を立てて能力の高い人が完璧だと思ってやっても，問題が出てきます。実際に作っている側からすると，使えないモノという“らく印”を押されるようなものですから，大変な精神的苦痛を伴います。作っている側は，ややもすれば感情的にもなりますし，「その問題は例外的なものである」とごう慢に決め込んで無視をすることもできます。しかし，ほとんどの場合は「なんとかしよう」と技術者としての責任感を持って，自主的な解決に至ります。「いますぐできなくても，次までには」という前向きな方向へ向かうため，大事には至りません。

　しかし，時々非常に判断に苦しむ場合が出てきます。また，開発につきものの，不安定な機能の実装中止やバグの正否判断に関しても，その判定を行ってよいのか悪いのかに大変悩むことがあります。そういった場合でも，使ってもらう人の顔が見えている場合は，どのようなシナリオが頻度や優先度が高いかの判断が，自分の興味範囲やその作業にかかわっている思い入れのような自己的なものではなく，ユーザーから見てどうなるかということを考えて，判断することになります。

　また，私のようなにユーザーとの接点があると，雨後のたけのこのように出てくる技術に対しても，果たしてどのような利点があるのか，あるいはその技術がユーザーからの要求や社会的な必然性ではなく，独り善がりで不必要なものかどうか，といった批判的な目が養われることになります。その判断をつけるため，調査の段階で実質的に必要となる技術に対する理解度が高まり，バランスの取れた理解が進みます。そして，日々の国際化の作業にかかわっていると，海外では問題にはならなくても，日本では問題になるというような内容や，その逆の日本では問題にならなくても海外では問題になるような内容が出てきます。例えば，基本的な機能では，文字コードや数値日付の表記の違い，カレンダの使用法や文字の並び替えの違い，住所の表記順序やビジネス・ロジックの違い，さらには機能に対する使用方法のシナリオそのものに対しての文化の違い——などなどが存在しているのです。

各国間のコミュニケーションも重要

　共有する手段として電話によるミーティングや電子メールを送るなど，できるだけ距離や時差を縮めることを目標に頻繁にコミュニケーションを取ります。しかし，簡単なことでしたらメールを書くだけでよいのですが，さらに系統的に分類管理するために，社内では問題追跡用データベースを使っています。このデータベースを中心にして，フィードバックや要求をため，それらに対してどのような作業を行うかミーティングを定期的に開いています。私は，定型化できない走り書きのような情報は，OfficeのOneNoteなどにメモを残すようにしています。

　不定期的ですが，私たちはこういった内容をまとめあげ，他の国や地域の人たちと一堂に会して，情報を共有するミーティングなどを開いています。お互いの違いを比較したり，よいと思われる点を発展させたりしています。将来の製品計画を立てる機会があるときは，全体のミーティングを開きますので，その場で関係するチームや，リーダーと直接会うなどして，日本市場におけるユーザーの方々の意見や要望を伝えるようにしています。

おわりに
　今回は，日本の開発者の方々から寄せられる意見や要望をどのようにして昇華し，それらをどのように製品仕様への要求に結び付けていくかについて，紹介させていただきました。多分，この後も調布から皆さんの所へ出向くことがあるかと思いますが，ぜひその際には，いろいろなお話をお聞かせください。