新人向け部門研修で Word について 2 時間程語った話

新人が自分の部門に配属されて早一週間。部門研修の一環として、新人に対して Word の使い方を説明する場を設けた。とは言っても 2 時間程度なので、Word の膨大な機能を全て説明し切れるわけでもない。いろいろ考えて、次のような内容で説明した。

• 文書を作成する上で大切なこと
  • 1 が見栄え。
  • 2 がメンテナンス性。
  • それらが揃った上で、初めて内容。
• Word を使う上での最低限のマナー
  • Word は段落指向のソフトウェアだ。段落とは一つの改行文字までだ。
  • スペースやタブでインデントをしてはいけない。インデントはルーラーを使って行え。これは絶対だ。
  • スペースで間隔調整などを行なってはいけない。間隔調整が必要ならタブを使え。スペースで間隔調整を行なうために等幅フォントを使うのは愚の骨頂だ。
  • 箇条書きを「・」で代用する、段落番号を手で振るといった愚を犯すな。箇条書きや段落番号は、Word のそれ用の機能を使って行え。
  • 見出しが必要な場合は「見出し」スタイルで。そうすれば自動的に目次を生成することが出来る。目次を手で作成するような真似はするな。
• Word の正しい初期設定
  • オートコレクトはほぼ全て切れ。
  • オートフォーマットもほぼ全て切れ。
  • 全ての特殊文字を表示しろ、ブックマークも表示させろ。
  • 他のアプリケーションからのペースト時には書式が保存されないようにしろ。
• スタイル
  • 一からスタイルの設定方法を説明するのは 2 時間では不可能なので、「この文書テンプレートを使え」と説明。
  • 文書テンプレートを使えば、Word によるドキュメント作成は「書いて、スタイルを選ぶ」だけの作業となる。それ以上、外観に頭を使う必要はない。
  • 冒頭で説明した「インデント付け」や「箇条書き」なども、この文書テンプレートを使うだけなら忘れてもらって構わない。
• フィールド
  • フィールドを使えば文書のメタ情報を文書内部に取り込める。
  • 最低限「Author」「Title」「Subject」程度は覚えてね。
  • 「DocProperty」を使えば自作のプロパティを取り込むことが可能。
  • フィールドは基本的に自動更新されない。更新したければ F9。
• ブックマーク
  • ブックマークを使うと、特定の範囲を「ref」で取り込むことが出来る。
  • ブックマークをうまく使えば、DRY が実現出来る。DRY 重要。超重要。

見ての通り、『エンジニアのためのWord再入門講座 美しくメンテナンス性の高い開発ドキュメントの作り方』の内容を 2 時間に無理に圧縮したような感じ。恐ろしく偏った内容だが、2 時間で Word を正しく使えるようになるためには、これ以外の方法はないように思う。本当はスタイルの設定方法をきちんと説明したいところなのだが、それだと少なくとも丸 1 日は必要なんじゃないかな。「見出し」スタイルに連番を適用する方法だけでも、ちゃんと説明すると結構大変だし。

でも、意外と好評だった。特にフィールドやブックマークについては、実際に試してもらうと「これは凄い!」と思ってくれたみたい。良かった良かった。

今回の内容に更に何かを追加するとすれば、こんな感じになるのかな。

• 図表番号の振り方
• 脚注の入れ方(「※」を使って本文中に注を入れてはいけない)
• 相互参照
• 描画キャンバス

実際には組織内でちゃんとスタイルを意識した文書テンプレートを用意していれば、Word は使うのも教えるのもごく簡単なツールになるのにね。それが出来ていないところは、目先のお手軽さで Excel 方眼紙に流れるんだろう。

ちなみに上記の通りに Word の説明をした後、Excel 方眼紙の実例を見せたら、全員が全員強烈な拒否反応を示してくれた。当然だよな。

「オブジェクト倶楽部 2009 夏イベント」LT のスライド

初めて slideshare でスライドを公開してみたので記念パピコ。

Oblove2009summer Lt.Key

View more presentations from riue.

「オブジェクト倶楽部 2009 夏イベント」参加してきました!

(酔っぱらって書いているので、後で書き直すかもしれません)

表題の通り、オブジェクト倶楽部 2009 夏イベントに参加しました。

参加するのは今回で多分 12 回目(これだけ参加していると、中の人になっていてもおかしくないのですが)。個別のセッションの話はまた後で書きますが、今回は LT に挑戦したので、そのことだけでも忘れないうちに書いておこうと思います。

LT「『に』と『で』の間」

「『に』と『で』の間」というタイトルで LT に挑戦しました。オブラブのイベントで LT をやるのは 3 回目なのですが、やっぱり何回やっても緊張しますね。

これまでは毎回 PowerPoint でスライドを作成していたのですが、今回は初めて Keynote を使ってみました…が、これが大失敗。何せ Mac でのプレゼンは 2 回目、しかも Keynote でのプレゼンは初めてだったので(その前は Parallel Desktop で PowerPoint + Word というプレゼンだった)、勝手がよく分からない。プレゼンの巧拙以前に練習不足が露見して最低のことになってしまいました。

何が最低だったかというと、Keynote のリハーサル画面をスクリーンに映してしまったらしいんですよね。5 分間一本勝負だったので確認とか調整の間もなくそのまま LT に突入したのですが…まぁ、かなりアレゲな感じになってたんじゃないかなー、って想像します。懇親会では「未来が見えるプレゼン」って評されましたが、あれは狙ったわけじゃなく、純粋に事故だったというわけで(社内では「字が小さすぎて、後ろのほうでは見えなかった」との評も…ごめんよう)。

…が、結果としては予想以上に好評で、ベストトーカーには届かなかったものの、2 着につけることが出来ました。id:fkino がベストトーカーの賞品を辞退されたので、賞品の Eye-Fi カードは私が頂くことに。ネタ系ではなく、淡々とお話をさせて頂くスタイルだったにも拘らず、投票して頂いた皆様には感謝の言葉もありません。

今回のテーマは、純粋に「いつも使っている日本語が、実はとっても奥が深いものだったんだ」「日本語を母国語としている俺達が、実は日本語のことを少しも分かってないんじゃないか」ということを再認識したという事実を伝えたかっただけだったので、会場の皆様にもその想いが伝わったのだとすれば、これ以上の喜びはありません。今回の評価が、もしその結果であったのだとすれば、LT に挑戦して良かったなと思います。

現地で MacBook を貸してくれた id:haru01(JSpec、改めて気になりました!)、そして今回の LT を全面的に仕切ってくれた id:k_chiba には本当に感謝します。そして 7/7 を素晴らしい日にしてくれたスタッフの皆様、ありがとうございます。

スライドは、しばらくしたらアクセス可能なようにします。たぶん、今回のイベントの公式ページからアクセスできるようになるんじゃないかなって思ってます。

その後

イベント後に、日本中二の会で呑みに行きました。そこでもまた「に」と「で」についての新たな知見を得られたのですが、それはまたおいおい。

掛け値なしに面白い! 『英語の冒険 (講談社学術文庫)』

本当に久しぶりに日曜日の午後をのんびりと過ごせたので、手に取ったのが本書。かなり以前に購入してたのをようやく読むことが出来た。

英語の冒険 (講談社学術文庫)

ヨーロッパの片隅のちっぽけな島国で生まれた「英語」という言語が、如何にして現在のような巨大な存在へと成長していったのか…を、圧倒的なスケールで描ききった書籍。英語史としての本書にも十分な価値があるのだが、本書が素晴らしいのは、英語史を「英語そのものを主人公とした冒険潭」としていること。その物語がとても面白く、気がついたら休みなしに一気に読み切っていた。

イギリスだけではなくアメリカ大陸やインド、西インド諸島やオーストラリアに広がった英語のその後について取り上げているのも興味深い。また、ジョン・ウィクリフやウィリアム・ティンダルによる英訳聖書誕生までの苦難などは、恥ずかしながら本書で初めて知った(KJV が 8 割方ティンダルによる訳そのものだ、っていうことも)。

『エンジニアのためのJavadoc再入門講座 現場で使えるAPI仕様書の作り方』

9 冊目の著作となる本書は、ある意味私らしい「ややズレた」スタイルの書籍となりました。6/29 発売ですが、池袋ジュンク堂では本日先行入荷したそうです。

ちなみに、サブタイトルは「現場で使える API 仕様書の作り方」。Javadoc をテーマとした書籍は、恐らく世界初ではないかと。

エンジニアのためのJavadoc再入門講座 現場で使えるAPI仕様書の作り方

本書は、意味のある Javadoc(ドキュメンテーションコメント)をほとんど見たことがないという現実を何とかしようと思って書きました。確かに、多くの Java のソースコードにはドキュメンテーションコメントが記述されています。しかし、その多くは「メソッド名の日本語訳」「引数名の日本語訳」といったもので、本当に意味があるものではありません。メソッド findCustomers() に「顧客を検索する」というドキュメンテーションコメントがあったところで、それが何だというのでしょう。findCustomers() というメソッドを見れば一目瞭然なのに、なぜわざわざメソッド名の日本語訳をつけるのでしょう。

ドキュメンテーションコメントが必要なのは、ソースを読んだだけでは分からないことを補足するためです。ソースコードを読めばわかることは、わざわざドキュメント化する必要はありません。しかしソースコードを読んだだけでは分からないことは、ドキュメントとして表現するしかないのです。そのようなスタンスで書いたとき、ドキュメンテーションコメントは初めて意味を持ちます。

そうは言っても、いきなり意味のあるドキュメンテーションコメントを書くというのは難しいと思います。そこで、本書ではチェックリスト形式で、「何を書けばよいか」「何を書かなければならないか」を説明することにしました。チェックリストといっても、そんなに細々としたものではありません。メソッド引数に対しては 7 つ、メソッド主説明に対しては 8 つ、クラスに対しては 13 程度です。いきなり全部を意識する必要はありませんので、分かるところ、納得できるところから使って頂ければと思います。

また、読みやすい API 仕様書(javadoc コマンドで生成した HTML ファイル群)を作るための基礎知識についても説明を加えました。javadoc コマンドを使って単純に API 仕様書を生成した場合、引数や返却値の型として「java.lang.String」といったものが登場してしまいます。この程度ならまだ許せるかもしれませんが、「org.springframework.context.ApplicationContext」のような長ったらしい型名が記述されていると、あまりの読み辛さにイライラしませんか? ほんの少し手間をかけるだけで、もっと読みやすい API 仕様書は生成できます。その「ほんの少し」のお手伝いをするのが本書です。

最終章では個人的な趣味に走って、Java で「契約による設計」を実現するためのライブラリ Contract4J5 を取り上げてみました。細かい説明が多く、紙幅の割に具体的な話には入れなかったのですが、一つの考え方として楽しんでいただければ幸いです。

iPhone ってこんなアプリケーションもあるからいいよね…「SuicideGirls」

昔、ノベルティとしてこういうペンがあったということなんだけど、残念ながら見たことがないので何とも言えない。

• 起動すると、セクシー(?)なおねぇちゃんが出てくる
• フリックでおねぇちゃんを選べる(現時点では 3 人)
• iPhone を上下に反転させると、おねぇちゃんが下着姿になる

…く、下らねぇ!

一回起動したら削除、の代名詞的アプリケーションだけど、無料なので取り敢えず一回は見とけ、って感じか。

で、このアプリケーションで Suicide Girls っていうサイトの存在を知った。「Alternative beauty and Alternative culture」を愛でる系の SNS。私はどうでもいいけど、こういう系の娘に興味があるヒトは是非。

コイツは若手に読ませたい! 『システムはなぜダウンするのか』

売れに売れているらしい、日経 BP の「なぜなのか」シリーズ。今日、書店でたまたま目にして即買い。

システムはなぜダウンするのか

大人気連載「動かないコンピュータ」のエッセンスを、誰にでも読みやすく分かりやすく纏めたような内容となっている。「誰にでも読めるように」という部分が過剰で、正直なところ説明がクドくて辛い部分も多かったが、52 ものトラブル事例を一気に読めるというのが素晴らしい。システム設計はもとより、運用設計局面でも傍らに置いておきたい。

ハードウェアインフラストラクチャの派手な障害 / 故障事例というのは意外と目にすることがないのだけど、そのような内容もしっかり取り上げてくれているのも有り難い。変な説教臭さがなく、事例を淡々と解説している姿勢にも好感が持てる。