GoogleDocsで本を書く方法のメモ訳

本当にやるのかは別にして、参加しているコミュニティでちょっとしたドキュメントを作成する話題が出ています。今まではWordなどで文書を作成してそれをメールに添付してやりとりする、というスタイルだったのですが、これを変更してGoogleDocsにすればいいと個人的に考えていました。
と、ちょうどWebを眺めていたら、「Writing a Book in Google Docs」というエントリ(英語)を発見したので、和訳しながらメモをとってみました。

なお、内容の保証は無いので気になる方は原文をご参照ください。
というわけで、以下本題。

GoogleDocsで本を執筆する(オリジナルは「Writing a Book in Google Docs」です)のメモ訳

• アウトライン
• 「アウトライン文書」を、作業のベース文書として作成する。
• 各項へのリンクと作業状況、抜粋(要約)を記載する。
• 作業状況は色分けして表示する
• 緑：初稿
• 黄：校正?済みの初稿
• シアン：第二稿
• 灰：確定稿
• アウトラインから右クリックで各文書を開く
• 個別のドキュメント
• 各ドキュメントは同じテンプレートを使って作成する。
• デフォルトのGoogleドキュメントのStyleはイマイチなので、"HTMLの編集"で書き換えてしまう。
• 画像は非減色のPNGにして貼り付け、各章別にローカルで管理する。
• 画像を貼り付けたら"HTMLの編集"で1pixelの黒枠を追記する。
• 利用するフォーマットは限る。Ctrl+B(ボールド)とCtrl+I(イタリック)
• ワークフロー
• Googleの機能でスペルチェック
• HTML(Zipped)でエクスポートしてバックアップしてから、共有タブで共同執筆者に通知する。
• 共著者が校正作業を終えたら、「アウトライン文書」のステータスを変更する。
• 作成者は変更内容を"変更内容"タブで確認する。
• 文書の命名
• 短縮名 + 章タイトル + 項目名 のような形で。
• Googleドキュメントに新しいフォルダを作成して、そこで管理をすると良い。
• とはいえ、Googleドキュメントのエクスプローラでは画面の表示量が少ないので、「アウトライン文書」を活用したほうが良い。

メモ書きここまで。
ちなみに、元ネタBlogではこの方法で「Google Office Hacks」を執筆しているみたいなので、この本自体も楽しみですね。
最近すっかり、職務以外の文書書きはGoogleドキュメントを使っています。たぶん有料になっても金を払う。このあいだ自宅のPCをリプレースしたのですが、当然ストレスフリー。この便利さは、個人的には気に入っています。

Blogged with Flock

OpenEventのリスク

197xつながりなGoTheDistanceさんのところの「コミュニティ運営の難しさ」というエントリについて。
ちなみにBPMイベントは参加したかったのに諸般の事情で参加できず。ちょっと悔しい。

私も要求開発アライアンスの幹事をすることが多いのですが、オープンコミュニティを運営するリスクはいろいろあります。

• 参加者をコントロールし難い (会場とか人数とか、会費とか)
• 天候とか時期とか偶然によって、人数が大きく変化した時に金銭的リスクが発生する (懇親会とか)
• 内外からDISられる (何やってんだお前、とか、お前何様だ、とか)
• 全般的な運営コスト
  

というあたりは、避け難い壁としていつか直面するものだと思います。
このうち「運営コスト」や「参加者コントロール」についてはある程度ツールやサービスを活用して負荷軽減ができる(参考→「OpenEventの運営メモ」)ので極力これを活用した上で、残ったモヤモヤは、自分がコミュニティを運営することで得られるメリットと天秤をかけるしかないんだろうと思います。

「仕事のための12の基礎力～「キャリア」と「能力」の育て方～」という本にも書いてありましたが、やはり197xともなるとそろそろ人材開拓力を伸ばす時期なわけで、そんな中でオープンコミュニティの運営というのは比較的に金をかけなくてもできる(時間さえ投資すればどうにかなる)わけです。ある意味やっていることを個人的なキャリア形成の一部として考える事ができるのであれば、DISられても平気。

最後に金銭的なリスクが残るわけですが、これはまぁ基本的には参加者から若干多めに徴集してリスクテーク＋残金は次回に廻す、という基本的な戦略が一番である気がします。もちろん着服してはいけないので、残金はMLや何人かに伝えておく良心は必要ですけど。残金が残ると、次回開催へのモチベーションにもなるのでお勧め。

私はまだ経験がありませんが、全員バックレ とか、日程連絡ミスにより全損になった場合でも、50人程度の動員であれば最大でも30万くらいの損害しか出ないので、その時は勉強だったと割り切るんで良いんじゃないかと思っています。そういう意味で自分の中ではローリスクな投資だと思ってます。

Blogged with Flock

RfS（Ruby for Specifications）

牛尾さんが日経IT Pro Watcherに投稿していたオフショア時代を乗り切る明確な要求仕様作成術について。
ちなみに、牛尾さんは要求開発アライアンスの執行委員つながりです。というわけで、昨日も「大ネタを書いたんですよー」と事前に聞いていたのですが、こりゃ確かに大ネタです。

　Rubyという生産性の高い言語とフレームワーク，そしてアジャイル開発があれば，「仕様書としてのアプリケーション構築」が現実のものとなる。このようなRubyの使い方を，RfS（Ruby for Specifications）と名付けよう。そもそも要件定義フェーズは，作るものが決まっていない「準委任契約」のフェーズである。このフェーズで，動くか動かないか，または正確なのかが わからない紙ベースでの仕様を作るかわりに，Railsを使ったアジャイル開発で，迅速に「仕様書としてのアプリケーション」を構築する。要求開発でプロ ジェクト企画を行い，その後アジャイル開発を使って，実際に動くアプリケーションという「仕様」を作成していくのだ。

オフショア時代を乗り切る明確な要求仕様作成術

興味深いテーマです。基本的にシステム開発プロジェクトが失敗する(もしくは、リスクが高い)原因の一つとしては、

• 計画(設計)が間違っていて、後でこの誤りを修正しようとしてクチャクチャになる。
• 計画(設計)通りに作ってみたら、顧客のイメージと違い使えない。

これを防ぐ為に、ユースケースシナリオを書いてみたりしますが、やはりドキュメントは所詮ドキュメントであり、ユーザと開発者の認識があっていなかったり(解釈が違う)、ユーザが設計ドキュメントのレビューに慣れておらず、誤りを見逃してしまう可能性もあるわけです。(話が横道に逸れますが、ユーザは当然のことながら業務のスペシャリストであって、設計のスペシャリストではないわけです。よくレビューで見逃された不備を「仕様通りです」と押し切ろうとする人がいますが、ステークホルダーがそれぞれ何のプロフェッショナルとして参加しているのかの分析誤りであることがあります)

というわけで、RfSのアイデア及び、「動くものを早めにつくり、確認する」という発想はアグリーです。
とはいえ反論(やアイデア)もあります。

たぶん、Ruby(もしくは似たような何か)で構築されたプロダクトとコードを引き渡して実装に突入するのはさすがにリスキー。データモデルやオブジェクト構成、業務テストシナリオなどを引継ぐのは良いと思いますが、コード等までやってしまうと色々な問題が出てきそうです。
ソフトウェア開発の古典 「達人プログラマー　システム開発の職人から名匠への道(アンドリュー・ハント／デビット・トーマス著)」から引用しますが、

ヒント16. プロトタイプの真の目的は学びにある
プロトタイピングとは、学習経験のことである。その価値はできあがったコードにあるのではなく、学習した教訓そのものなのである。

という意味では、RfSで作成したプロダクトについても、きちんとした評価を行い教訓を導き出した上で開発に適用すべきなように思います。例えばこんな感じだとどうでしょう？

• RfSプロダクトについての、良い点と悪い点(評価レポート)
• RfSプロダクトで試した事、試さなかった事(評価レポート)
  
• 実際のユーザの使われ方(Flash Movieなどで)
• データモデルやオブジェクトモデルの設計(設計書/UMLやDDLなど)
• シンプルな業務テストシナリオ(RfSプロダクトを元に作ってドキュメント化する)
  

このあたりで断ち切ってしまえばちょうどよいかなぁ。
勢いで書いているので、間違ってたらごめんなさい。

ちなみにさっそくSeasar2のひがさんからツッコミが来ていますね･･･。両方知っているのでちょっと微妙な立ち位置･･･。

Blogged with Flock