Hebikuzure's Tech Memo

2018年2月28日

Excel でセル中に文字と数値を共存させて文字だけ左詰めにする

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

Excel ではデータの合計や平均を集計する場合が多いでしょう。その場合、こんな表を作ると思います。

image

この表の場合、集計対象となるデータには「氏名」というラベルがあるので、B 列に「氏名」の列を作っています。そのため10行で集計している平均値にも B列に「平均」というラベルを表示できます。

では例えば箱の中に入っている沢山のみかんから任意の何個かを取り出してその重量を図って平均し、みかんの標準的な重さを調べよう、というような場合だとどうなるでしょう。この場合、個々の重さのデータには特にラベルとなる情報はありませんから、次のような表を作ってしまうかと思います。

image

しかしよく見ると B 列は「平均」を表示するためだけに用意されていて、もったいないですね。できれば C10 セルに「平均   119.43」とまとめて表示できれば良いでしょう。

こういう場合にユーザー設定表示形式を利用すれば良いことは、Excel のレッスンで必ず習います。C10 セルの現在の書式は

image

このように(0.00)なっているので、これをこのように(”平均 “0.00)

image

変更すると、先ほどの表は以下のようにできます。

image

ここまではたいていの Excel の教科書にも出ていますが、ここからもうひと手間かけることができます。この表示形式はセルの値の数値の前に「平均 」という文字列(「平均」と空白文字)をくっ付けていますが、これだと表示される数値の桁数が異なると「平均」が表示される場所も変わってしまいます。そこで「平均」という文字を疑似的に常に左詰めにするユーザー定義表示形式を作ります。

先ほどのユーザー定義表示形式を以下のように変更します。

image

新しい表示形式は「”平均”* 0.00」です。「*」は直後の文字を全体がセル幅一杯になるまで繰り返す、という意味の記号です。これによって先ほどの表は

image

このようになります。B 列の幅が変わっても、また B10 に表示する数値の桁数が増減しても、「平均」の文字は常にセルの左端から表示されます。

参考情報

広告

2018年2月2日

Office 2019 は今年後半登場、クイック実行版のみ提供

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

2月1日(米国時間)付で「Changes to Office and Windows servicing and support」という記事が公開され、この中で Office 2019 のリリースとサポート期間についての情報が示されています。

Office 2019 のリリース

以下、Office 2019 のリリースに関するアナウンスの引用です。

  • Office 2019 will ship in H2 of 2018. Previews of the new apps and servers will start shipping in the second quarter of 2018.
  • Office 2019 apps will be supported on:
    • Any supported Windows 10 SAC release
    • Windows 10 Enterprise LTSC 2018
    • The next LTSC release of Windows Server
  • The Office 2019 client apps will be released with Click-to-Run installation technology only. We will not provide MSI as a deployment methodology for Office 2019 clients. We will continue to provide MSI for Office Server products.

日本語に訳してみると

  • Office 2019 は 2018 年後半に出荷される。アプリとサーバー製品のプレビュー版は 2108 年の第2四半期に開始される
  • Office 21019 アプリは以下でサポートされる
    • すべてのサポートされている Windows10 半期チャネル(Semi-Annual Channel – SAC)リリース
    • Windows 10 Enterprise LTSC 2018 ※
    • Windows Server の次期 LTSC
  • Office 2019 クライアント アプリはクイック実行インストール テクノロジーでのみリリースされる。Office 2019 クライアントで MSI をデプロイ手法として提供する予定はない。サーバー製品については引き続き MSI を提供する

という内容です。
※Windows 10 Enterprise LTSC 2018 は未提供製品、今年秋にリリース予定と記載されています

Office 2019 のサポート期間

また Office 2019 のサポート ライフサイクルについて、以下のように示されています。

  • Office 2019 will provide 5 years of mainstream support and approximately 2 years of extended support. This is an exception to our Fixed Lifecycle Policy to align with the support period for Office 2016. Extended support will end 10/14/2025.
  • There is no change to the support term for existing versions of Office.

日本語にすれば

  • Office 2019 では 5 年のメインストリーム サポートと概ね 2 年の延長サポートを提供する。これは通常の固定ライフサイクル ポリシーの例外であり、Office 2016 のサポート期間と揃えるためのものである。延長サポートは 2025年 10月 14日に終了する。
  • 既存のバージョンの Office のサポート条項に変更はない

となります。

Office ProPlus のサポート ポリシー変更

この発表では併せて Office 365 ProPlus のサポート ポリシーの更新も以下のように示されています。

  • To clarify our current support practices for ProPlus running on Windows 10, ProPlus will not be supported on Windows 10 Semi-Annual Channel (SAC) versions that are no longer being serviced.
  • Effective January 14, 2020, ProPlus will no longer be supported on the following versions of Windows. This will ensure that both Office and Windows receive regular, coordinated updates to provide the most secure environment with the latest capabilities.
    • Any Windows 10 LTSC release
    • Windows Server 2016 and older
    • Windows 8.1 and older

こちらも日本語訳すると

  • Windows 10 上の ProPlus のサポートの実情を明確にするため、ProPlus は(訳注:Windows として)サポートされなくなった Windows 10 半期チャネル バージョン(SAC)をサポートしない
  • 2020 年 1月 14 日以降、ProPlus は以下のバージョンの Windows をサポートしない。これにより Office と Windows が調和のとれた定期的な更新を受け取ることができ、最新の互換性の下で最もセキュアな環境が提供される
    • すべての Windows 10 LTSC リリース
    • Windows Server 2016 およびそれ以前のバージョン
    • Windows 8.1 およびそれ以前のバージョン

という内容になります。

企業内管理者へのインパクト

Office 2019 については、提供時期はともかくとして、企業の管理者向けでインパクトが大きいのは、Windows Server でサポートされるのが次期 LTSC(Windows Server 2019?)で Windows Server 2016 はサポート対象外になること、クイック実行(C2R)版のみで MSI 版がなくなることの二つでしょう。

前者は特に Windows Server のリモートデスクトップ サービスやそれを利用した RemoteApp の形でユーザーに Office を提供していた組織では、Office の更新(2019 への移行)ではサーバー側の更新も必要となるため、インパクトが大きいと思います。これに関しては “Later this year, Microsoft will deliver new Remote Desktop and desktop virtualization capabilities within the SAC release cadence of Windows 10 Enterprise and Windows Server.”(今年の遅い時期に、Microsoft は新しいリモートデスクトップとデスクトップ仮想化の機能を、Windows 10 Enterprise と Windows Server の半期チャネル リリースのサイクル内で提供する予定です)とされており、実際のプランはこの「新機能」が明瞭になってから考えた方が良いかもしれません。早期に新機能を確認されたい場合は Windows Server Insider プログラムを利用しましょう。

後者については、組織内での Office アプリケーションのデプロイを Active Directory グループポリシーのソフトウェア インストールに依存していた場合、その方法では Office 2019 はデプロイできないということを意味します(グループポリシーでのインストールには MSI パッケージが必要)。そうした組織で Office 2019 への移行が必要となる場合、新たなデプロイ方法(および MSI インストールされている元のバージョンの Office のアンインストール方法)について検討・検証が必要になります。

今後の姿

今回の発表を通じて Microsoft が考える Office アプリケーションと Windows クライアントの将来的なありかたが明確になってきたように思います。

個人的な予測ですが、Office 2016 と Office 2019 のサポートを共に 2025年 10月 14日で終了させるということは、パッケージ製品であれボリュームライセンスであれ、永続的ライセンス(ライセンス買い切り)型の Office 製品は Office 2019 で最後になるのではと思います。それ以降は個人向けも企業向けもすべて Office 365 / Microsoft 365 のようなサブスクリプション製品に統一されるのでしょう。

また Office ProPlus が「すべての Windows 10 LTSC リリース」をサポートしなくなることもポイントです。Microsoft はかねてから LTSB/LTCS は一般的なオフィスワーク環境での利用を想定していないと説明していましたが実際には Office アプリケーションのインストールも可能なので、Windows as a Service による機能更新を避けたい組織などでオフィスワーク環境として利用されるケースもあるようです。サブスクリプション版の Office ProPlus が LTSC をサポートせず、また Windows 10 Enterprise LTSC 2018 をサポートする Office 2019 も 2025年にサポートを終了すれば、LTSC 環境で Microsoft Office を実行したくともサポートされる製品がない、という状況になります。

ProPlus のサポート ポリシーの更新の中でも触れられていますが、2025 年以降はオフィスワーク環境にあるすべての Windows クライアントを Office クライアントが常に最新の機能と更新の状態で動作する(それ以外の状態はサポートされない)という世界がやってきそうです。

企業・組織としては色々な選択肢と独自のスケジュールでのソフトウェア更新のニーズもあるかと思いますが、少なくとも Microsoft のクライアント製品ではそういう選択肢や独自性は排除される方向です。これから Windows と Office の更新の計画をたて、実行する管理者としては、2025年 10月 14日以降は

半期チャネル リリースの Windows とサブスクリプション版(当然 C2R 版)の Office』

という組み合わせ以外の環境にすることはできない可能性がある、という点を念頭に置いて検討されることをお勧めします。

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]

Older Posts »

WordPress.com Blog.

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