タグ: SharePoint

※画像もビデオもファイルも全て同じなので、以下の例は画像にします。

SharePoint2007ではリストのアイテムの本文内に画像を表示したい場合、ちょっと面倒でした。通常のブログサービスのようにリッチテキストエディタからファイルをアップロードすればOKというわけではなく、一旦ライブラリに画像をアップし、そのURLをコピーして、リストのアイテムの複数行テキスト列内に貼り付けるような、投稿者に操作をお願いするにはちょっと酷な感じでした。

時を経て、SharePoint2010からはリストのアイテムの（拡張リッチテキストの）複数行テキスト列の場合、リボンタブ「挿入」→「画像」→「コンピューターから」で行う事ができます。これで通常のブログサービスのような操作感に近づいたのかなと思い、喜ばしい機能でした。

この機能はSharePoint2007の頃のような一旦ライブラリに画像をアップするという操作を、リストのアイテム投稿ページから移動せずにダイアログ内で行えるという機能で、結局、任意のサイト内のライブラリに画像ファイルをアップロードするという事には変わりありません。アップされると同時に本文内に表示されます。（実際にダイアログ内に表示されているコンテンツを調べると、宛先ライブラリに指定してあるライブラリのUpload.aspxをiframeで表示しているんですよね。）

アップロードする際に表示されるダイアログ内ですが、「宛先ライブラリ」という項目があります。つまりアップロード先のライブラリを指定する項目です。ドロップダウンの中にはサイト内のライブラリが一覧で表示されます。

ここは初期値で「サイトのリソース ファイル」ライブラリが選択されています。でも、中にはこのライブラリは利用されたくない場合もあると思います。ただ、初期値として設定されてしまっているので、「宛先ライブラリでは○○ライブラリを指定してください」と投稿者に指導をしたところで、操作ミスや失念でアップロードされてしまう可能性もあり、できれば初期値を別のライブラリに変更したいですよね。しかし、ここの初期値を変更できる設定はリスト内には存在しません。

標準機能では宛先ライブラリの初期値を変更できないのかと思ったら、ちょっと分かりづらい場所にあったので紹介します。

各ライブラリの詳細設定の中に設定項目があるんです。「サイトのリソース ファイル」ライブラリの詳細設定を見てみると、「サイト リソース ライブラリ」という項目が「はい」になっています。（サイトのリソース ファイルライブラリ内のサイト リソース ライブラリ…ややこしいですね。）この説明だけ読んでも宛先ライブラリの初期値に関わってくる項目とはわかりませんね。

「サイトのリソース ファイル」ライブラリのこの項目を「いいえ」に変更した後に、その後作成した宛先ライブラリで初期値にしたい「画像用ライブラリ」のこの項目を「はい」にすると、宛先ライブラリの初期値が「画像用ライブラリ」になりました。

ちなみにこの設定項目はサイト作成時に「サイトのリソース ファイル」ライブラリのみ「はい」になっており、その後作成するライブラリでは既定では「いいえ」で作成されます。

また、この設定での「はい」「いいえ」は上述の通り、宛先ライブラリの初期値の設定のようで、宛先ライブラリのドロップダウンに表示・非表示の設定ではないようです。「いいえ」にしても初期値にならないだけでドロップダウン内には選択肢の値として存在します。ここに表示・非表示という設定があれば良いのですが、今のところ見当たりません。例えば投稿者には選択肢の値として表示されたくない場合は、該当ライブラリのアクセス権限を外すなどの対応になるのかなと思います。

複数ライブラリでこの項目を「はい」にした場合の挙動はどうなるのか？を検証したところ、またまた興味深い結果になりましたので、それは日を改めて記事にしたいと思います。

人によっては今更のネタですみません。

0バイトのファイルをアップロード。まぁ通常運営していてなかなかありえない利用シーンですよね。なので僕も今まで知りませんでした。

先日、限られた環境で検証しようとした時に若干焦った事です。カスタムを施したカスタムリストの投稿を検証した際に、添付ファイルにファイルを添付するテスト事項もあり、いつもならExcelなどでテスト用ファイルを作るのですが、限られた環境という事でテキストファイルでテスト用ファイルを作成しました。いつもの自分の操作ならテキストエディタを開いて、適当に文字を入れてから保存をするのですが、なぜかこの時は無意識にデスクトップで右クリック→新規作成→テキスト ドキュメントという手順で、テキストファイルを作成しました。この場合、ファイルサイズは0バイトなんですね。ということで、偶然0バイトのファイルを作成したんです。これを利用してテスト投稿をしてみたのですが、SharePointのエラーページが出て投稿できませんでした。
エラー内容を見ても意味がわからず、原因不明で困っていた時に、色々やってみるとファイルを添付しない時には問題なく投稿される法則がわかり、その後、一緒にテストした人に「ファイル、0バイトじゃないですか？」と言われ、ようやく原因がわかった感じです。

で、検証してみました。

■ライブラリ
ライブラリに0バイトのファイルのアップロードを試みようとすると、丁寧に理由が記載されるのですぐにわかります。やはり通常の利用では0バイトのファイルを扱わないので、この表示は初めて見ました。

■リスト
添付ファイルの0バイトのファイルを添付しようとすると、添付ファイルを指定する操作は特に問題ないのですが、投稿をしようとするとSharePointのエラーページが表示されます。添付ファイルを指定する操作の段階でエラーになってほしいところです。また、これで投稿がエラーになってブラウザの戻るボタンをクリックしても、入力した情報は消えてしまいます。つまり苦労して入力した内容がパァになってしまうんです。

このエラーページには理由が記載されているので原因がわかりますね。ただ、この環境では理由が記載されていましたが、冒頭で同様のエラーページが出て焦った話の際の環境では、この理由が記載されていなかったんです。なので原因がわからずに焦った感じです。おそらくSharePointのバージョンの違いなのかと思いますが、詳しいことはわかりません。

ということで、冒頭の通り、通常運営していて0バイトのファイルを扱うことはないとは思いますが、こういう事があったぞという備忘録でした。

企業でSharePoint （に限らず）を導入すると、少なからずIT部門に使い方や操作トラブルの問い合わせが入ると思います。利活用促進の一歩だと思えば問い合わせが入る事は喜ばしいこととは思いますが、多くの企業ではサポート業務専任スタッフはおろか、SharePoint 専任スタッフもおらず、だいたい他業務と兼任していることが多く、これらのサポート業務に忙殺され、他業務に影響が出ててしまう事もあります。

IT部門がサポート業務を担う、いや、渋々担わされている企業にありがちなのが、以下の状況。

• 問い合わせは主に電話で受け答え。
• 問い合わせ内容（質問・調査・回答）を保存していない。
• 問い合わせ内容を個人で保存しているがチーム内で共有されていない。

つまり、悪い言い方をすれば「行き当たりばったり」。問い合わせが電話で、それを保存していない場合、実は過去に何度も同じ内容で問い合わせが来ているのに、受けたIT部門のメンバーが違う事で、各自毎回調査をして回答をするという、かなり非効率な状況になっていたりするんですよね。
以前にも書いたとは思いますが、IT部門はサーバー管理など運用面には関心があっても、運営面では無関心な事が意外と多いんです。また、ありがちなのがIT部門自体がSharePoint をあまり活用していないケースもあります。IT部門が主導で各種グループウェアなどを比較検討した結果選んだ製品を導入し、技術面でも詳しいのであれば、その段階では一番積極的に有効活用できる部門だと思うんです。でもそのIT部門が相変わらずメールやファイルサーバーを使っていて、導入したSharePoint を利活用していない。これじゃ社内展開がうまくいかないですよね。

そこでIT部門が積極的にSharePoint を利活用しつつ、社内サポート業務の効率化を図る、一石二鳥な方法があるんですよね。それが社内向けにSharePoint に関する情報発信をすることです。

• 自発的にTips的な情報をブログなどで発信する。
• ユーザーからの問い合わせはIT部門内で蓄積する。（IT部門内公開）
• 問い合わせから良質な問い合わせを抽出しFAQとして社内公開する。

別に目新しいことではないんです。これだけでも十分なんです。

先にブログなどでTipsなどを発信する事で利用者のSharePoint スキルの底上げを図れます（読まれているかどうかは置いといてですよ）。
ユーザーからの問い合わせをIT部門内で共有する事で、チームメンバーのスキル底上げにもつながるし、同類の問い合わせに関しての調査・回答工程を省けます。
FAQとして公開する事により、ブログと同じくユーザーが自発的に問い合わせる前に自己解決できる可能性が出てきます。また、既出で解決済みの問い合わせを新規で受けたとして、該当するブログ記事やFAQを参照してもらうだけで済むので対応の時間効率化にもなります。これが1年2年…とコツコツ増える事によりナレッジは蓄積されます。

これもありがちですが、中小企業でIT部門のメンバーも少なく、SharePoint 担当者が一人で対応していた場合、この方が急に退職されたりして残されたIT部門のメンバーが途方に暮れる…みたいな。属人化させないためにも、日々ナレッジは蓄積し、できる限り共有されている仕組みは大事ですよね。

私は実際に運営で問い合わせを受けるサポート業務も兼任していたのですが、まぁ問い合わせ内容もピンキリで、時にはマイクロソフト社に助けを求める事もありますが、多くの場合は簡単な説明で解決できる内容でした。

このように実際にSharePoint を有効活用している事例を自然と見せる事により、少なからず社内全体の利活用促進に貢献できるのではと考えます。

一石二鳥どころかそれ以上だとは思いませんか？

このような提案を上長や組織内にする際に、自ら情報発信をするのに抵抗を感じる人がいたり、そもそも業務を増やしたくないと思われたり、抵抗勢力があるので厳しかったりもしますが、大事な事だと思うんですよね。もう一度言いますが、別に画期的な方法でもなく、誰でも思いつく事。だけどそれを実現できていない企業も少なくはないはず。

【結論】

• Enterは段落、改行はShift+Enter

これまた、SharePoint 知っている人にとっては常識なのかもしれないけど、投稿者レベルの利用者は実は結構知らない事だったりします。実際、過去に「行間なんとかならないですか？」というユーザーからの問い合わせが何度かありましたし、教えると初めて知ったというユーザーが多かったです。

先日の記事では投稿者・閲覧者レベルでの教育が必要と書きましたが、例えばこのような小さい事まででも社内ブログなどでTips的に発信すると、良いのではと思います。

本題に入ります。

ページのコンテンツエリアやアイテムの複数行テキスト列のように、Word感覚で文章を装飾できるリッチテキストエディタがあります。

この文章を作成中に改行をしようとEnterキーを押したところ、思った以上に行間が空いてしまって困ったことはありませんか？

改行の操作は「Shift+Enter」なんです。このくらいの行間になります。

じゃ、「Enter」はというと、段落扱いです。比較してみるとこんな感じ。

あれ？行は「改行」なら段落はなんだろう？改段落？？？次段落？？？ま、いっか…。

通常の文章でも改行と段落では段落間の方がスペースは広いですよね。なので改行をする場合はShift+Enter、次の段落にしたい場合はEnterと覚え、意識して使い分けをしましょう。

これ、実はSharePoint のクセじゃなくて、WordもPowerPointも同じなんですよね（ちなみにこのブログで利用しているWordPressも）。そのくらい常識でしょ？と思った方は、その常識は一旦拭った方が良いかもしれません。冒頭の通り、意外と知らない人は多いんです。（正直、僕だって SharePoint で仕事をする前は知りませんでしたもん。）たった少しの説明でコツコツと社内のコンテンツのクオリティが上がるのなら、その手間は「常識だろ…」と惜しまない方がみんなが幸せになります。

さて、ここまでで読み終えても良いですが、ここから先はHTML的な挙動についても書いてみます。

Shift+EnterとEnterはソースコード的にはどのような違いがあるか？リッチテキストエディタ内には「ソースの編集」というボタンからソースを見る事ができます。

1行目のソースはひとつの段落である事を示す<p></p>で囲まれます。つまり1行目でもあり、1段落目でもあります。

Enterを押して2行目を書くと2行目も<p></p>で囲まれます。なので2行目ではなく、2段落目です。

Shift+Enterを押して2行目を書くと改行を示す<br/>が追加され、全体では1段落目のまま、2行目は1段落目の2行目です。

SharePoint2007の頃はリッチテキストエディタで生成されるHTMLは非常に汚く見るに堪えないものでしたが、バージョンアップするごとにだいぶ良くなってきました。