Hebikuzure's Tech Memo

2015年10月11日

Office 365 Solo は契約者しか利用できない

Filed under: Microsoft Office — タグ: , — hebikuzure @ 4:36 PM

サポート フォーラム「Microsoft コミュニティ」で「Office 365 solo は新しいパソコンへ移行してインストールできるか」というスレッドがあり、その回答の中で「Office 365 Solo は個人用のライセンスなので、家族と共用するようなパソコンでは使用できません」という記述があり、気になったのでライセンス条項 (EULA) を調べてみました。

Office 365 のライセンス条項はこちらからダウンロードできます

ライセンス条項には以下の記載があります。

お客様が日本国内に居住している場合、また は日本国内に居住したときに Microsoft Office Premium もしくは Office 365 Solo 製品を入手した場合、本追加契約のすべての条項に従うことを条件として、マイクロソフトは、ライセンスを取得したデバイス (最初にライセ ンスを取得したデバイスを含みます) に本ソフトウェアの複製をインストールして実行する以下の権利をマイクロ ソフトのライセンス許諾の下、お客様に許諾します。

  • Office Personal Premium、Office Home & Business Premium、および Office Professional Premium。
    (1) Office ソフトウェア。
    本ソフトウェアがプレインストールされている 1 台の PC 上で使用できます。
    (2) Office 365 Consumer Subscription。
    1 台のタブレットにインストールして、ライセンスを保有するサブス クライバーのみが使用できます。
  • Office 365 Solo
    2 台の PC または Mac と 1 台のタブレットにインストールして、ライセンスを保有するサ ブスクライバーのみが使用できます。(下線筆者追加、読みやすくするため改行追加)

ライセンスを保有するサ ブスクライバー」というのはその前で、

マイクロソフトは、マイクロソフトのライセンス許諾の下、お客様が本追加 契約のすべての条項に従うことを条件として、一度に 1 人のユーザーが 1 台のライセンスを取得したデバイス (最初にライセンスを取得したデバイス) に本ソフトウェアの複製 1 部をインストールして実行する権利を許諾し ます。Microsoft アカウントが最初にライセンスを取得したデバイスのソフトウェア ライセンスに関連付けられて いるユーザーは、「ライセンスを保有するサブスクライバー」です。

と定められています。分かりやすく言えば Office 365 の購入手続きを行うときに使用した Microsoft アカウントの所有者が「サブスクライバー」になります。

これによれば、Office 365 Solo でインストールされた Office ソフトウェア (Word, Excel, PowerPoint, Outlook など) は購入手続きを行うときに使用した Microsoft アカウントの所有者以外は使用できないことになります。例えば家族と共用の PC に Office 365 Solo から Office ソフトウェアをインストールした場合、Office 365 Solo の契約者が利用する分には問題ありませんが、他の家族がその Office ソフトウェアを使用するとライセンス条項違反になります。もし他の家族も Office ソフトウェアを利用したいのであれば、それぞれに Office 365 Solo のライセンス契約が必要になります。

これは企業向けの Office 365 でも同様で、Office ソフトウェアの使用権はユーザー単位で付与されるので、PC にインストールされ起動可能であっても、ライセンスを付与されていない人は Office ソフトウェアを利用することができません。

Office 365 Solo の場合も企業向けの場合も、実際にライセンスを持っていないユーザーが (サブスクライバーとは別のユーザー アカウントで Windows にサインインしている場合でも) Office ソフトウェアを起動すると何の警告もなく起動でき、使用できてしまいますが、これは明確なライセンス違反となり、特に企業の場合は違法な使用として告発されたり損害賠償を請求されたりすることに繋がりますので、十分に注意が必要です。

サブスクライバーと別のユーザー アカウントで Windows にサインインしている場合でも警告なく Office ソフトウェアが利用できてしまうのは、管理者権限のあるユーザー アカウント (Microsoft アカウント) で Office 365 のライセンスを取得して、通常はユーザー権限の別のアカウント (Microsoft アカウント) で Windows を利用する (またはその逆) という利用形態を考慮しているのだと考えられます。

なお PC に付属して提供される Office Premium 製品の場合は、上記で引用したライセンス条項の通り、PC にインストールした Office ソフトウェアはサブスクライバー以外の人でも利用可能です。

まとめると

  • Office 365 Solo や企業向け Office 365 で提供される Office ソフトウェアを利用できるのは契約者だけ (家族でも社員でも使用できない)
  • 家族と共用する PC で全員が Office ソフトウェアを使いたい場合は Office Premium 付属の PC を購入する

という事になります。くれぐれもご注意ください。

なお、日本以外で提供されている Office 365 Home では、同一家族内での Office ソフトウェアの使用が認められています。この形態のライセンスが日本でも提供されると選択肢が増えて良いでしょうね。

2014年12月11日

12月の Office 更新プログラムインストール後、VBA でエラーが発生する

Filed under: Microsoft Office — hebikuzure @ 5:02 PM

2014年12月にリリースされた Office の更新プログラム MS14-082 をインストールした後、例えばマクロが有効な Excel ブックを開いた時に「Microsoft Visual Basic」の実行時エラーダイアログが表示され、シート上に挿入されているコントロールが操作できない状態になる場合があります。

手元ではエラーが発生しなかったので、どのようなエラー ダイアログが出るのか確認したい方は「山市良のえぬなんとかわーるど」の記事を参照してください

この現象は、次のようなシナリオで発生します。

  1. シートにフォームのコントロールを挿入した Excel ブックを作成します
  2. フォームのコントロールが挿入されると、コントロールのモジュール (MSForms、プログラム名としては fm20.dll) が呼び出されます
  3. 次回の挿入に備えてコントロールのモジュールのキャッシュが作成されます。このキャッシュは %temp%\Excel8.0 フォルダーに、拡張子 .exd で作成されます
  4. 更新プログラム MS14-082 をインストールすると、MSForms (fm20.dll) が更新されます。しかし作成済みのフォームのキャッシュは削除も更新もされません
  5. MSForms のコントロールを操作する VBA が呼び出されると、実際のコントロール (更新済み) とキャッシュ (未更新) の間でバージョン不整合となり、エラーが発生します

回避策

コントロールのキャッシュは手動で安全に削除する事ができるので、フォームを利用できる Office アプリケーションをすべて終了してから .exd ファイルを削除すれば、問題は回避できます。以下の手順で削除してください。また更新プログラムのインストール前に事前にこの手順を行っておくことで、エラーの発生を予防できます。

  1. フォームを利用できる Office アプリケーションをすべて終了します。またはコンピューターを一度再起動します
  2. [Win キー] + R で [ファイル名を指定して実行] を呼び出します
  3. [名前] ボックスに %temp% と入力して [OK] をクリックします
  4. %USERPROFILE%\AppData\Local\Temp\ フォルダーが開くので、Excel8.0 フォルダーを探します
  5. 見つかったら Excel8.0 フォルダーを開き、その中のファイルをすべて削除します (Excel8.0 フォルダーごと削除しても問題ありません)

参考

2012年7月16日

Excel で削除権限のないUNC パスフォルダに保存できない

Filed under: Microsoft Office — hebikuzure @ 11:06 AM

"Access Denied" error message when you save a workbook to a UNC share in Excel 2010
http://support.microsoft.com/kb/2589410/en-us


Windows PC のネットワークで、UNC パスを使ってアクセスするネットワーク共有にファイルを保存して複数のクライアントから利用するケースは多いでしょう。その場合、不用意に既存のファイルを削除してしまう事が無いよう、利用するユーザーのアクセス権で「削除」権限を与えない事も多いでしょう。

フォルダのプロパティの [セキュリティ] で、”フルコントロール” を有効にせず “変更” 以下を有効にすると、この図のように [削除] 権限は与えられません。

image

ところがこの設定で運用した場合、共有フォルダに保存している Excel ファイルを Excel 2010 で開いて編集し、上書き保存しようとするとエラーが発生して保存できません。この現象と回避策について以下のサポート技術情報が公開されています。

"Access Denied" error message when you save a workbook to a UNC share in Excel 2010
http://support.microsoft.com/kb/2589410/en-us

こうしたエラーは他のバージョンの Excel でも発生するのですが、Excel 2010 にはこれを回避するための修正プログラムが用意されたので、この技術情報が作成されています。他のバージョンでの現象については、以下の技術情報も参照してください。

Description of the way that Excel saves files
http://support.microsoft.com/kb/814068/en-us
(日本語版 Excel のファイル保存方法について http://support.microsoft.com/kb/814068/ja)

You receive an error message when you try to save a file in Excel
http://support.microsoft.com/kb/214073/en-us
(日本語版 Excel でファイルの保存時にエラー メッセージが表示される http://support.microsoft.com/kb/214073/ja)

You may receive a "Your changes could not be saved" error message when you try to save a file to a network drive in Excel
http://support.microsoft.com/kb/813973/en-us
(日本語版 ネットワーク ドライブにファイルを保存する際に "変更を保存できませんでした" というエラー メッセージが表示される http://support.microsoft.com/kb/813973)

Excel では保存の際に、元のファイルとは別に編集内容を反映した一時ファイルを作成し、元のファイルを削除した上で一時ファイルを元のファイル名に変更するという手順を取ります。そのため保存先のフォルダに対して削除の権限が無いと、正常に保存のプロセスを行うことができないのです。

この動作に対して、削除権限が無いフォルダに対しても保存できるようにする回避策が技術情報 2589410 で説明されています。回避策は以下の通りです。

  1. Description of the Office 2010 hotfix package (Mso-x-none.msp): August 30, 2011
    http://support.microsoft.com/kb/2553034/en-us
    の修正プログラムを入手し、インストールする
  2. レジストリのキー
    HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\General
    に以下のレジストリ値を作成する
    名前 : EnableSimpleCopyForSaveToUNC
    種類 : REG_DWORD
    データ : 1

修正プログラムはページ左上の [Hotfix Download Available] をクリックし、フォームに必要事項を入力して送信すると、ダウンロード案内のメールが届きますので、それに従ってダウンロードします。
これで削除権限のない UNC パスの共有フォルダに Excel 2010 からブックを保存できるようになるのですが、制限事項もあります。

  • 削除権限のない共有フォルダには一時ファイルが残ります。共有フォルダは <英数文字8文字>.tmp という形式の名前です。これは何らかの方法で定期的に削除する事が望ましいと考えられます。
  • 保存の際に UNC パスへのネットワーク接続が失われていると、ファイルが破損します。

いずれも副作用としては問題の多い動作なので、この回避策の適用は慎重に検討した方がよさそうです。
この回避策を適用しない場合は、ブックはいったんローカル フォルダなどの削除権限のある場所に保存し、その後で共有フォルダにコピー(または移動)する運用での対処が良いでしょう。

関連記事

サーバー上の共有フォルダで Excel ファイルを上書き保存するとファイルが失われる

2012年1月24日

Excel の数式バーを拡大する

Filed under: Microsoft Office — hebikuzure @ 9:08 PM


たいした話でもないのですが、何かの時に役立つかなあという覚書です。

Excel 関係のトレーニングなどで、Excel の画面をプロジェクタで表示してる際、数式バーに表示されている関数などの内容を見せたい時があります。ワークシートの内容であれば簡単に Excel の機能 (表示 –> ズーム) で拡大できますし、拡大鏡ツールや Zoomit などを使って画面自体を拡大表示する事もできますが、数式バー自体の表示を大きくして見せた方が分かりやすくスムーズに進める事ができる事もあるでしょう。

そこでちょっと確かめてみたところ、数式バーの表示 (表示するフォントのサイズ) は Excel のワークシート標準フォントのサイズと連動している事がわかりました。これを大きいサイズにすると、その分数式バーのサイズと表示フォント サイズが拡大します。Excel のワークシート標準フォントのサイズは Excel 2010 の場合、[ファイル] タブでバックステージ ビューに切り替え、[オプション] をクリック、[基本設定] の [新しいブックの作成時] セクションの [フォント サイズ] で変更できます。(Excel 2007 なら Office ボタン –> [Excel のオプション] から)

実際に標準のフォント サイズを 24pt にすると、数式バーはこんな風に表示されます。これなら数式バー内の関数などを説明しやすいでしょう。

image

ちなみにこの方法で標準フォント サイズを変更すると、新規に作成されるワークシートのフォント サイズも大きなサイズに変更されますが、以前に作成したブックを開く場合には何の影響もありません。必要な時だけ標準サイズを変更し、後で元に戻せば良いでしょう。

2011年7月17日

Office 365 の Outlook Web Access に Google カレンダーを表示する

Filed under: Microsoft Office — hebikuzure @ 3:22 PM


サービス インした Office 365 を試しているのですが、これまで Web カレンダーとして Google カレンダーを重用しているため、Office 365 の Outlook Web Access (OWA) の予定表でも Google カレンダーを表示させたいと思い、試してみました。

ローカルの Outlook には Google Calendar Sync を利用して、Googel カレンダーを表示/同期させています。

  1. まず OWA に表示したい Google カレンダーを開き、オプション ボタン (左上の歯車アイコン) をクリックし [カレンダー設定] をクリックします
    (カレンダーの左側で [マイ カレンダー] の下の [設定] をクリックしても良いです)
  2. [カレンダー設定] で [カレンダー] タブをクリックします
  3. OWA で表示したいカレンダー名 (赤で囲んだ部分) をクリックします
    image
  4. カレンダーの詳細情報の画面になります。[限定公開URL] 欄の [ICAL] をクリックします
  5. カレンダーの iCAL アドレスが表示されますので、これをコピーましす
  6. OWA で予定表を開き、[共有] をクリックし、[予定表の追加] をクリックします
    image
  7. [名前] ボックスに適当な名前を入力し、[予定表の URL] ボックスに先ほどコピーしたアドレスをコピーします
  8. [OK] をクリックしてしばらく待つと、Googel カレンダーが読み込まれます。
    そのままではカレンダーの名前が iCAL のファイル名 (Basic など) になってしまうので、左側の [他の予定表] 欄の下の名前を右クリックして [名前の変更] を選び、分かりやすい名前に変更しておきましょう。
    image

ただしこの方法で表示した追加のカレンダーが、OWA をいったん閉じて開きなおすと非表示になっている現象が手元では起きています。時間のある時にさらに調べてみたいと思いますが、Office 365 の OWA で他の予定表を常に表示させる方法をご存知の方、ぜひ教えてください。

2010年10月30日

基本認証の HTTP サーバーから Office ドキュメントを開けない

Filed under: Microsoft Office — hebikuzure @ 11:03 PM

MSKB 212563
You cannot open Office file types directly from a server that supports only Basic authentication over a non-SSL connection
http://support.microsoft.com/kb/2123563/en-us


Web サーバーに Office ドキュメントを置いてクライアントの Office アプリケーションで開く、というシステムはイントラネットでよく見られる。またドキュメントを閲覧したり編集したりできるユーザーを限定するため、HTTP サーバーに基本認証をかけている場合もあるだろう。
ところがこうしたシステムで今まで使っていた Office 2003 (またはそれ以前のバージョン) をOffice 2007 または Office 2010 にアップグレードすると、Web サーバー上の Office ドキュメントを開くのに失敗してしまうようになる場合がある。Office ドキュメントへのリンクをクリックしても何も起こらなかったり、あるいはドキュメントを開くアプリケーションは起動するのにドキュメントが表示されない、などの現象が起きる。
この現象はいくつかの原因が重なっているのだが、根本的にはセキュリティーの強化によって発生している。これについて解説しているのが上記のサポート技術情報 212563 だ。

まず Office アプリケーションが Web サーバーから直接ドキュメントを開く場合の挙動が Office 2003 以前と Office 2007 以降では変わっている。Office 2003 まででは Web サーバー上のドキュメントを開く際、Office のコンポーネント (MSDAIPP : Microsoft Data Access Internet Publishing Provider) のみを使って Web サーバーにアクセスしていたが、Office 2007 以降ではこれに加えて Windows のコンポーネント (WebCleint サービス) も利用するように仕様が変更されている。

さて現在サポートされているバージョンの Windows の WebClient サービスでは、セキュリティー上の理由で HTTP 接続での基本認証 (Basic 認証) が無効になっている。これは基本認証では資格情報 (ユーザー名とパスワード) が平文で送信されるので、通信自体も暗号化されない HTTP 接続では資格情報が容易に盗聴されるからだ。(関連情報 : マイクロソフト サポート技術情報 841215)
そのため Office 2003 以前のバージョンから Office 2007 以降のバージョンにアップグレードすると、基本認証のかかった HTTP サーバーからドキュメントを開くことができなくなる。
また Office 2010 では Office のコンポーネントでも同様の理由で HTTP 接続での基本認証が無効になっている。そのため Office 2010 では Windows の WebClient サービスだけでなく、Office コンポーネントについても HTTP 接続での基本認証を有効にしなければならない。

つまり Office のバージョンによって以下の作業が必要になる。

  • Office 2007 の場合 : Windows の WebClient サービスで HTTP 接続の基本認証を有効にする
  • Office 2010 の場合 : Windows の WebClient サービスで HTTP 接続の基本認証を有効にする + Office の HTTP 接続の基本認証を有効にする

技術情報に記載されているように、Windows の WebClient で HTTP 接続の基本認証を有効にする方法、Office 2010 で HTTP 接続の基本認証を有効にする方法はそれぞれ以下の通りだ。

WebClient サービスで HTTP 接続の基本認証を有効にする

以下のレジストリ値を作成し、Windows を再起動する。

  • Windows XP / Windows Server 2003

キー : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
名前 : UseBasicAuth
種類 : REG_DWORD
データ : 1 (0 にすると HTTP 接続の基本認証は無効)

  • Windows Vista / Windows 7

キー : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
名前 : BasicAuthLevel
種類 : REG_DWORD
データ : 2 (0 にすると HTTP/HTTPS 共に基本認証無効、1 にすると HTTPS で基本認証有効、2 にすると HTTP/HTTPS 共に基本認証有効)

Office 2010 で HTTP 接続の基本認証を有効にする

以下のレジストリ値を作成し、Windows を再起動する。

キー : HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Internet
名前 : BasicAuthLevel
種類 : REG_DWORD
データ : 2 (0 にすると HTTP/HTTPS 共に基本認証無効、1 にすると HTTPS で基本認証有効、2 にすると HTTP/HTTPS 共に基本認証有効)

いずれもレジストリを編集する事になるので、レジストリのバックアップの作成を行った上で、慎重に作業する必要があるのを忘れずに。

2010年8月2日

バグのトリアージ – それってどういう事?

Filed under: Microsoft Office — hebikuzure @ 10:08 AM

Triaging bugs – what’s that all about?
http://blogs.technet.com/b/office_sustained_engineering/archive/2009/02/12/triaging-bugs-what-s-that-all-about.aspx


この記事は、この Blog の 5/31 の「バグはなぜ無くならないのか – Microsoft Office チームの Blog から」の続きとなる、Office Sustained Engineering Blog の記事「Triaging bugs – what’s that all about?」の私訳です。この続きの記事「What does it mean to be a world class servicing organization?」も時間を見つけて訳して掲載する予定です。Microsoft のバグ修正のプロセスに興味がある方は、ぜひ前の記事と併せてご一読ください。

以下の文章は Office Sustained Engineering の 2009 年 2 月 12 日 の記事 「Triaging bugs – what’s that all about?」 を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation およびマイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


バグのトリアージ – それってどういう事?

Dave B [msft] 12 Feb 2009 1:58 PM

困難な決定を下すということは (覚悟してください) … 困難な作業です。当たり前でしょう! 下す判断のすべてが容易なものであってほしいのですが、私は困難な判断を下すのなら「三人寄れば文殊の知恵」だと信じている人間です。もちろんあまりに多くの人が関わっているのなら、数だけが問題ではありませんから返ってくる声を減らす可能性はあります。これは実に考え方の問題です。より独創的な考え方ができれば、より良い判断ができるようになります。私は悪い判断ではなく良い判断をしたいのです。私の父は常に私には明確なことに対する驚異的な理解力があると言っていました – それは私にとって素敵なことだと思っていました。

以前の投稿で、次期バージョンの Office を出荷する際に行わなければならない困難な決断の性質について述べました。それではそうした決断はどのように行われているのかとお思いなら、この記事が役立つでしょう。私の書き出しでご想像のように、私たちは幅広い視点を含むグループによって行うのが最善だと信じています。

個人的には、トリアージという用語はテレビ番組の “M*A*S*H” で初めて知りました。誰かが見ていた訳ではないですが、正直に言うとこの番組から人生についてより多くの事を学びました。皆さんがご存じのように、トリアージという言葉は典型的には医学の用語で、「多数の患者の診療の順番を決めるため、病人や怪我人に緊急度を割り当てる事」です (私ではなく辞書がそう言っています)。「私たちはいったい何をしたらいいんだ?」という疑問への答えがそれだと私は考えました。

トリアージの考え方にグループ ディスカッションは必然的には含まれませんが、私たちにとってはそれが全てです。繰り返しになりますが、それは単なる数の問題ではありません。洞察力への情熱をもたらすような経験を有する人々が一堂に会するという点が問題なのです。ここに誰をグループに加えるかを考える視点があります。

第一に、機能を開発したチーム – デザイナー、開発者、テスターです。このグループは、その機能に最も努力を注いだ人々です。機能は彼らの言わば子供です。この人たちは機能が完璧である事を願っています。誰も自分の子供が厄介者だとは言われたくないですから。このグループは特に客観的になる事が難しいかもしれませんが、コードと、そのコードの変更に伴う潜在的なトレード オフについて最も広範な知識を持っているグループでもあります。彼らはトリアージで最も上位のメンバーである必要はありませんが、Office の文化において、私たちが新鮮さを失わないようにするためには新人の際立った声が重要です。言うならばこのプロセスにおけるチップクリップ (ポテトチップの袋の口を閉じるクリップ) のようなものです。

次に、カスタマー サポートの専門家 – 私たちの顧客と直に接した仕事をしており、顧客が私たちの製品から何を望んでいるのかしっかりと把握している人たちです。彼らは業界の中で誰よりエンタープライズ ソフトウェアについて理解しており、私たちが顧客のニーズをリストの最上位に保つように気遣っています。その他の専門家も、国際的マーケット、コンテンツ、セキュリティー、アクセシビリティー、その他のいつくかの分野についての特定の問題に対応して、グループに召集されます。

最後に、ソフトウェアの出荷についての広範な経験を持つマネージャーのグループです。彼らは何度も高品質な製品をタイムリーに出荷した体験を有してして、トレードオフについて理解する際に豊富な経験をもたらしてくれます。トリアージ チームはOffice のすべての製品のマネージャーと上級エンジニアで構成されており、一部の人は 20 年以上も Office についての仕事をしています。彼らはこのプロセスに貴重な、円熟した視点をもたらします。

間違いが無いように言っておくと、異なった視点とは異なった意見を意味します。トリアージ ミーティングは、皆が元気になるクンバヤ (訳註 : Kumbaya、歌の名前) を歌うためにキャンプファイヤーの周りに集い、友達同士が抱き合うような大人数のグループとはまったく違う事を保証できます。どちらかと言えば、それは (準備はいいですか?) 自分の見方が正しいと信じている情熱的で博識な人々を魅了する、言葉による格闘試合のようなものです。あなたと違い私はそうした罠におちてしまいそうですが…。結果として、ほぼ間違いなく見解の不一致が生じます。見解の不一致は議論を生じさせ (白熱した論争とも言えますが)、時には議論が激しくなり時間もかかるため、全体のプロセスに価値があるのか疑問に思われるかもしれません。毎回毎回トリアージのプロセスにどれだけの意味があるのか、私たちは気にかけています。複数の考え方は良い決定を下すのに必要であり、よい決定は製品をより良く完成させるのに必要です。大抵の場合、このプロセスは良い議論を 1 回か 2 回 (か、100 回) 行いますが、プロセスの最後では製品の品質に帰結するそうした議論がどれだけ貴重であったか、皆が理解する事になるのです。

トリアージでの決定に魔法の公式はありません。そこには問題の深刻度や、問題の発生するシナリオがどの位出現するのかなど考慮すべき多数の事柄がありますが、これらを一つの公式に還元しようとしてもそれは機能しません。どの問題も特定の顧客のシナリオがその背後にあり、それは人手をかけて問題を評価し決定を行う事が必要な、意思決定のレベルに関係しています。公式に依るのではなく、最良の判断では常に性急な対応に飛びつく前に、優れた質問が得られるまで議論を煮詰めているのです。出荷が近づくと、トリアージ グループは全ての問題と提案されている変更について注目し、最も基本的でかつ重要な問いかけをするのです。「それには意味があるのだろうか?」 私の 9 歳の息子ももっとこの疑問を持つと良いのですが….

毎回のトリアージの議論/論争で舞い上がった埃が治まると、結論はいつも同じになっています。トリアージを行ったグループは「私たちはいったい何をしたらいいんだ?」という疑問に答える際、最終結論が最も理に叶っているものだと信じているでしょう。それは、個々のトリアージのメンバーは、他のメンバーの考え方が特定の問題に対してより有効だと信じるであろう事を意味しています。本当の話、これはなかなかに困難な事なのですが、しかしトリアージ グループは私たちが私たち自身とその考え方について見通す手助けをしてくれます。それは愉快な課題である必要はありませんが、疑い無く必要な課題なのです。

トリアージのプロセスは常に正しい決定を保証してくれるのでしょうか? いいえ、そうではありません。しかし正しい決定を行う確率を劇的に向上する事は保証できます。私たちは、どの決定の一つをとってもそれが数百万の顧客に影響を与えるという事を知っているので、どのリリースの過程においてもトリアージに多大な工数を費やすでしょう。それには間違いなくその価値がありますが、私はそれを毎回毎回そうしなくても良い事を嬉しく思っています。おや、ちょっと待ってください。

製品が出荷されると、トリアージは日常当たり前の事になります。実際、顧客が評価できるプレ リリース版への変更ではなく顧客が利用している、市場に出回っている製品への変更になりますから、意思決定にはより熱心に取り込みます。顧客の実装している手法がバグの存在を前提としており、バグが起きないとうまく動作しないため、問題を修正すると顧客の手法を失敗させてしまうという事例を見てきました。そうした事情もあるので、私たちは世界でも第一級のアフター サービス組織になる事に尽力しています。その理由と方法が私の次回のブログの題材です。引き続きご注目ください。

2010年5月31日

バグはなぜ無くならないのか – Microsoft Office チームの Blog から

Filed under: Microsoft Office — hebikuzure @ 8:04 AM

Why doesn’t Office just fix all of the bugs before they ship it
http://blogs.technet.com/b/office_sustained_engineering/archive/2008/12/12/why-doesn-t-office-just-fix-all-of-the-bugs-before-they-ship-it.aspx


以前にもどこかで紹介したような気がするが、Office Sustained Engineering という Office 開発チームのブログで (ずいぶん以前の記事なのだけど) どうして Office 製品のバグが出荷前に無くせないのかについて論じたとても興味深い記事がある。この記事「Why doesn’t Office just fix all of the bugs before they ship it」を訳してみた。

以下の文章は Office Sustained Engineering の 2008 年 12 月 12 日 の記事 「Why doesn’t Office just fix all of the bugs before they ship it」 を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation およびマイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


なぜ Office は出荷前にすべてのバグが修正されないのか

この記事は、我々が次期バージョンの Office をどのように開発し公開するのかに関する良く寄せられる質問について説明する、関連した 3 つのブログ記事の最初のものです。特に、以下の話題について説明する予定です。

  1. なぜ Office は出荷前にすべてのバグが修正されないのか ?
  2. ‘トリアージ’ の プロセス (どのバグを修正するのかを決定するために行われます) はどのように機能しているのか ?
  3. Office を製品として維持するために今のようなやり方が選択されているのは何故か ?

パート1: なぜ Office は出荷前にすべてのバグが修正されないのか ?

まず明確な事から始めましょう。我々は全てのバグを見つけてはいません。私は周囲に比べて最も聡明ではありませんがそう認識していますし、皆さんにとってもそれは大きな驚きではないでしょう。しかしそれは何故でしょうか。我々の努力が足りないからでない事は保証できます。またバグを見つけるためのプロセスに問題があるからでない事も確かです。我々の開発プロセスではその初日に開発者とテスターが組み合わされ、バグの発見と修正はプロセス全体を通じて他の何よりも優先されます。

実際、根性のあるバグ潰し屋の誰にたずねても、バグを見つけるのは困難だと言うでしょう。幸い我々のテスターはことのほか聡明です。彼らは “簡単な” バグのほとんどすべてを見つけ、さらに “難しい” バグの大部分も見つけ出します。開発チームが予期しないような機能の使い方が必要であるようなバグでさえ白日の下に晒します。しかし何百万人もの利用者が自分の仕事を達成するため想像もつかないような幅広いオプションを設定して Office を利用しています。その結果、我々の製品は、我々が想像もつかないような使い方をされるのです。たとえば我々は新しいスマートなハンマーを作ったつもりだとしても、利用者は結局それを配膳道具のように使い、我々にどうしてこんなフォークを設計したのかと尋ねるのです。シナリオは無限にあり、それを一つずつすべて予測するのはまったく不可能です。これはどんなに優れたテスターがいても同じです。

これに関連して、ソフトウェアのバグは世の中のその他の物に比べて確認しにくいという問題もあります。あるユーザーにとって欠陥のある動作と思える動作が、別のユーザーにとっては完璧で期待通りの動作になります。そのため実際の動作が “意図されたもの” であるかどうかについて開発チームのメンバー間で数えきれないような議論が戦わされることになります。それぞれに観点が異なるための意見の相違もよくあります。我々は、以前のバージョンやベータ バージョン、数多くのユーザー訪問から得られるデータを使い、私たちの見解が最も一般的な利用者の見方となるよう最善を尽くしています。結局の所、そうした視点の表明は気まぐれなもので (心理的に誰かにとっての至宝が別の人にはゴミであるように)、我々の結論も常に正しいとは限りません。

最終的に、すべてのバグは生き残るための巧妙な手口を持っているというのが真実でしょう。バグを潰しても、復活する方法を見つけ出すのです。さらに悪いことに、彼らは異なった、より面倒なバグに変化するのです。ソフトウェアの開発チームでは、これをリグレッションと呼んでいます。バグを修正するにはコードの変更が必須です (私はこの点について明確に理解しています)。コードの変更は別のシナリオでの新しいバグの潜在的な原因になります。リグレッションによっては修正した元のバグより性質が悪い場合もあります。これは ‘アリが良いか、シロアリが良いか’ という問題に似ています。一方は不愉快な邪魔者ですが、もう一方は災厄の原因です。一般的に言えば、災厄を避ける方が良いでしょう。

災厄を避けるようにするということが、我々の製品がバグのある状態で出荷されるもう一つ理由です。これは直感に反するように思えますが、ありていに言って、リグレッションの現実の結果、もし我々がすべてのバグを修正しようとすれば、永久に出荷できないでしょう。これは災厄と言えるでしょう。このように我々は常にこの現実に直面しており、我々が高い品質の製品を期日通りに出荷しようとすると、非常に困難な決断が必要となるのです。

例えば、仮に (実際にはそうではありませんが) 我々がすべてのバグを修正できるとして、それは我々が行うべき最も重要なことでしょうか? またそれは利用者にとって、新機能のメリットを享受できるのが 20 年に一度になるのより重要でしょうか? OEM や ISV やその他の関係者が我々の出荷予定日を計算できるのより重要でしょうか? 競争力のある機能に適切なタイミングで対応することより重要でしょうか? 常に考慮が必要な多数のトレードオフが存在しているのです。

いくつかのトレードオフは明確で、例えば全体的な品質は出荷予定日より重要です。品質に問題があれば、出荷日を引き延ばすでしょう。これは以前にあったことです (覚えていらっしゃるでしょう)。しかし決定しなければならないことの大部分はそれほど明白ではありません。一見明確ではないバグの修正と予定通りの出荷のトレードオフは、告知済みの出荷日が近づくにつれて決断が難しくなります。

こうしたプロセスの実例はこの問題を示すのに役立つでしょう。Office 2007 のリリース後、あるユーザーが多数の問題 (“ゴミ” であり、“お宝” ではありません) を見つけました。特に、Excel ファイルへの複数のリンクを含む PowerPoint プレゼンテーションを開く際、それぞれのリンクを更新する新しい方式 (より多くのメタデータを追跡しています) が原因で、非常に長い時間が掛かることが分かりました。一般的に言えば、これは多数の人に影響を与えるものではありませんが、このユーザーのプレゼンテーションの特性上、これは大きな問題でした。彼らはこのバグを hotfix として修正するようリクエストしました。我々はその修正をしたのですが、少し後になって、そのバグを修正すると外部リンクを含むプレゼンテーションで VBA コードを実行する際にクラッシュしてしまうという新しいバグが発生することが分かりました。このバグは非常に性質が悪く、一つの修正により他のより多くのシナリオが危険にさらされるため、我々は元の修正を破棄し、ユーザーにはパフォーマンスの問題で適切な回避策を取れるよう協力しました。

我々の目標は個々のどの問題についても、可変的な要素に留意しつつ最良の決断を行うことです。こうした目標を達成するため、すべてのバグについて修正をするのとしないのとどちらが最善かを決める ‘トリアージ’ を行っています。この決定を、一貫性をもってうまく行っていくのはいかにも複雑なプロセスです。これにはどのような変更についても賛成または反対の立場から議論を重ねている、多数の経験豊富な開発チーム メンバーの洞察力が必要とされます。多くのの場合、私たちは正しい選択をしています。しかし時に間違いを犯し、一つのバグを修正することでより悪い – 検知できないかもしれない – バグを招いてしまうこともあります。場合により我々はバグの本質を真に捉えているユーザーのシナリオを正しく理解できず、本来修正すべきバグを修正しないと決めてしまうこともあります。このように確かに完全とは言えませんが、トリアージのプロセスは優れたものであり、このブログのシリーズのパート 2 のトピックになるでしょう。

まとめると以下のようになります。我々は品質に問題があれば出荷日を変更しますが、告知済みの出荷日に間に合うようにできる限りの努力をします。また我々はどの Office のリリースでも顕著なユーザーへの影響があるバグはないことを期待しています。しかし残念ながら我々はユーザーが見つけられるバグのすべてを見つけることができず、また一部のバグについて実際にはユーザーに多大な問題を引き起こすものであるのに軽視するという、誤ったトリアージをしてしまうこともあります。これら二つの現実の結果、我々は世界規模の ‘アフター サービス’ 組織となり、過去にリリースした製品に必要なアップデートを提供するため懸命に働いています。こうした努力により、ユーザーに最良の価値ある提案が提供できることを望んでいます。この続きをお待ちください…

投稿: Friday, December 12, 2008 11:09 PM by Dave B [msft]

2010年5月9日

Excel の計算範囲に結合セルが含まれている場合に意図しない結果になる

Filed under: Microsoft Office — hebikuzure @ 11:12 AM

The result of a calculation that uses the data in a merged cell does not match the result that is expected based on the visible data in the merged cell in Excel 2000, in Excel 2002, in Excel 2003, in Office Excel 2007, or in Excel 2010
http://support.microsoft.com/kb/983435/en-us


Excel では複数のセルを結合して複数行/複数列にまたがるセルを作成する事ができる。
Excel 2007 以降の場合は結合したいセルを選択して [ホーム] タブにある [セルを結合して中央揃え] ボタンをクリックすれば作成できるし、また [セルの書式設定] – [配置] タブの [セルを結合する] にチェックを入れても良い。


図1: A2、B2、C2 の3セルが結合されている

結合されているセルが合計などの計算の範囲に含まれている場合、結合セルへのデータの入力方法によっては意図しない結果になってしまうう場合がある。
下の図では、A3 と A4 にはその隣に表示されている数式が入力されており、その結果としてどちらも「10」が表示されている。


図2: 意図通りの計算結果

ところが以下のように同じ見かけ、同じ数式なのに計算結果が「20」になってしまう場合がある。


図3: 意図しない計算結果

これは以下の手順で再現できる。

  1. A1D55 を入力しておく
  2. A3=SUM(A2,B2,C2,D2)A4=A2+B2+C2+D2の数式を入力する
  3. A2B2C2 を選択して [セルを結合して中央揃え] ボタンをクリックする
  4. A1 を右クリックして [コピー] を選択する
  5. 結合したセルを右クリックして [形式を選択して結合] を選択する
  6. ダイアログで [数式] を選択して [OK] をクリックする


図4: [形式を選択して貼り付け] で [数式] を選択する

なぜこうなるのか、その理由は以下の通りだ。

  • セルを結合するとセルが全体で一つになったように見えるが、実際には個々のセルは Excel の内部には保持されていて、書式として隣のセルと結合した状態であるという情報を持っている。結合セルに表示されるのは結合した元の範囲の左上隅のセルに入っていたデータだけだが、実際にはそれ以外の元のセルもデータを持つ事ができる。
  • ただしこれでは分かりにくいので、セルを結合する際に結合範囲の左上隅以外のセルの値はクリアされる動作になっている。また他のセルをコピーして結合セルに貼り付ける場合も、値は左上隅のセルにだけコピーされる動作になっている。
  • ところが上記の操作のように [形式を選択して貼り付け] で [数式] を貼り付けると、左上隅のセル (上記の例では A2) だけでなく他のセル (上記の例では B2 と C2) にも数式がコピーされる。上記の例では数式として A1 に入っている値 5 が A2、B2、C2 の 3 つのセルにコピーされる。
  • そのために、A3 や A4 の数式での計算結果は表示されている数値の合計 10 ではなく、表示されていない B2 と C2 の値も含む 20 になる。

この動作についてはサポート技術情報で Excel の不具合とされているが、修正プログラムなどは無い。もし結合セルを含む集計を行っているシートがあるなら、念のため計算結果が不正になっていないか確認した方が良いだろう。

2009年12月9日

Excel 2007 でセルをクリックすると複数セルが選択されてしまう

Filed under: Microsoft Office — hebikuzure @ 8:38 AM

Excel 2007 の ページ レイアウト ビューでシートを特定の位置に表示させた場合に、任意の 1 つのセルをクリックすると複数のセルが選択される
http://support.microsoft.com/kb/978386


Excel 2007 でページ レイアウト ビューを使って表示している際、上下のページ境界が表示されており、かつ下側のページのヘッダー欄が表示されていない状態だと、セルをクリックした際にクリックしたセルの下にある複数のセルが意図せず同時に選択されてしまう、という不具合がある。 なんともバカバカしいバグで、サポート技術情報に書かれている通りの手順で簡単に再現する。ページ レイアウト ビューは Excel 2007 での新機能なのだから、このモードでのテストが不足していたとしか言いようがない。

回避策はページ レイアウト モードから別のモードに切り替えるか、スクロールして表示位置を変えること。下側のページのヘッダーが表示されるまで少しスクロールすれば回避するので、ページ レイアウト モードを使う場合はこれで回避するのが良さそうだ。

Older Posts »

WordPress.com で無料サイトやブログを作成.

%d人のブロガーが「いいね」をつけました。