TOP > ブログ > オーム社開発部の方とのやり取り

オーム社開発部の方とのやり取り

2008/1/10

先日、本ブログにて「退職報告及び自己紹介」という記事を書いたところ、マスタリングTCP/IP RTP編を監訳したときのご担当の方からメールを頂きました。 実はこのブログの読者だったそうでが、自己紹介文章を読んでびっくりしたとの事でした。 今回のやり取りに関して書く了承を頂けたので、書いてみました。

何度かメールをやり取りしていましたが、今度おじゃまして色々お話を聞かせて頂くお願いをしました。 今回は、お時間を頂戴してフリーな打ち合わせという形でお邪魔させて頂く予定です。 後日、先方の了解を得られた範囲内で公開したいと思っていますが、まだどうなるかは未定です。

RTP本の監訳をしているときに、昔の技術出版業界と最近の技術出版業界というような話や、出版の流れなどを色々教えていただけて面白かった記憶がありました。 それも、もう5年以上前になるのですが、当時とは多少編集方法が変わってきているようです。 丁度最近、技術書の作り方に関するプレゼンをされてきたということで、そのプレゼン資料を頂きました。

「イテレーティブでインクリメンタルな技術書の作り方」

結構色々挑戦しているんですね。 資料中に「国内の出版社でSubversionを使っているのはたぶんうちだけ。」という文章が入っていました。

ここら辺の話も色々聞いてみたいと考えています。

献本して頂きました

さらに、今回献本をして頂きました！ ありがとうございます！ 自分が関わった、もしくは紹介されている本以外で献本を頂くのは初めてなので非常にうれしかったです。

頂いた書籍は以下の2冊です。 まだ読んでいませんが、とりあえず目次だけ紹介します。 タイトルと目次と中をパラパラ見た感じでは、面白そうだと思いました。 もしかしたら、後日書評も書くかも知れません。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

目次：アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣


“Practices of an Agile Developer”読者の声

第1章 アジャイルソフトウェア開発

第2章 アジャイルの初心
> 1 成果をあげるのが仕事
> 2 応急処置は泥沼を招く
> 3 人ではなくアイデアを批判する
> 4 機雷がなんだ！ 全速前進！

第3章 アジャイルさを育む
> 5 変化に付いていく
> 6 チームに投資する
> 7 時が来たら習慣を捨てる
> 8 わかるまで質問する
> 9 リズムに乗る

第4章 ユーザが求めるものを提供する
> 10 顧客に決断してもらう
> 11 設計は指針であって、指図ではない
> 12 テクノロジの採用根拠を明確にする
> 13 いつでもリリースできるようにしておく
> 14 はやめに統合、こまめに統合
> 15 早いうちにデプロイを自動化する
> 16 頻繁なデモでフィードバックを得る
> 17 短いイテレーションでインクリメンタルにリリースする
> 18 定額契約は守れない約束

第5章 アジャイルなフィードバック
> 19 天使を味方につける
> 20 作る前から使う
> 21 違いがあれば結果も変わる
> 22 受け入れテストを自動化する
> 23 ありのままの進捗を計測する
> 24 ユーザの声に耳を傾ける

第6章 アジャイルなコーディング
> 25 意図を明確に表現するコードを書く
> 26 コードで伝える
> 27 トレードオフを積極的に考慮する
> 28 インクリメンタルにコードを書く
> 29 シンプルにすること
> 30 凝集度の高いコードを書く
> 31 “Tell, Don’t Ask” ――― 求めるな、命じよ
> 32 取り決めを守ってコードを置き換える

第7章 アジャイルなデバッグ
> 33 ソリューションログをつける
> 34 警告をエラーとみなす
> 35 問題を切り分けて攻める
> 36 あらゆる例外を報告する
> 37 役に立つエラーメッセージを提供する

第8章 アジャイルなコラボレーション
> 38 定常的に顔をあわせる
> 39 アーキテクトもコードを書くべき
> 40 共同所有を実践する
> 41 メンターになる
> 42 答えを見つけられるように力を貸す
> 43 コードの共有には段取りがある
> 44 コードをレビューする
> 45 みんなに知らせる

第9章 終章：アジャイルへ踏み出す
9.1 たったひとつの新しいプラクティス
9.2 窮地のプロジェクトを救う
9.3 アジャイルの導入：マネージャ向けガイド
9.4 アジャイルの導入：プログラマ向けガイド
9.5 これで終わり？

付録A 参考資料
A.1 Web上の資料
A.2 参考文献

天使の助言
監訳者あとがき
索引

目次 : アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き


“Agile Retrospectives” についての読者の声
まえがき
序文
日本語版へのまえがき
イントロダクション


第1章 レトロスペクティブ――― チームの点検と改善
1.1 場を設定する
1.2 データを収集する
1.3 アイデアを出す
1.4 何をすべきかを決定する
1.5 レトロスペクティブを終了する

第2章 チーム専用レトロスペクティブ
2.1 チームの環境や歴史について知る
2.2 レトロスペクティブの目標の作成
2.3 所要時間の決定
2.4 レトロスペクティブの構成
2.5 アクティビティの選択

第3章 レトロスペクティブのリード
3.1 アクティビティの管理
3.2 集団ダイナミクスの管理
3.3 時間の管理
3.4 あなたの管理
3.5 次のレベルへ

第4章 場を設定するアクティビティ
4.1 チェックイン（Check-In）
4.2 フォーカスオン／フォーカスオフ（Focus On/Focus Off）
4.3 ESV
4.4 チームの約束（Working Agreements）

第5章 データを収集するアクティビティ
5.1 タイムライン（Timeline）
5.2 555（Triple Nickels）
5.3 カラーコードドット（Color Code Dots） 
5.4 喜、怒、哀（Mad Sad Glad）
5.5 強みを見つける（Locate Strengths
5.6 満足ヒストグラム（Satisfaction Histogram）
5.7 チームレーダー（Team Radar）
5.8 ライクトゥライク（Like to Like）

第6章 アイデアを出すアクティビティ
6.1 ブレインストーミング／フィルタリング（Brainstorming/Filtering）
6.2 フォースフィールドアナリシス（Force Field Analysis
6.3 5 つのなぜ（Five Whys）
6.4 フィッシュボーン図（Fishbone
6.5 パターンとシフト（Patterns and Shifts） 
6.6 ドットによる優先づけ（Prioritize with Dots） 
6.7 まとめレポート（Report Out with Synthesis
6.8 テーマの特定（Identify Themes）
6.9 学習マトリックス（Learning Matrix）

第7章 何をすべきかを決定するアクティビティ
7.1 レトロスペクティブ計画ゲーム（Retrospective Planning Game）
7.2 SMART な目標（SMART Goals）
7.3 質問の輪（Circle of Questions）
7.4 短い話題（Short Subjects）

第8章 レトロスペクティブを終了するアクティビティ
8.1 プラス／デルタ（+/Delta）
8.2 感謝（Appreciations）
8.3 温度計（Temperature Reading）
8.4 役立った、邪魔だった、仮定した（Helped, Hindered, Hypothesis）
8.5 投資時間対効果（ROTI）

第9章 リリースおよびプロジェクトのレトロスペクティブ
9.1 リリースおよびプロジェクトのレトロスペクティブの準備
9.2 組織を横断した視点
9.3 リリースおよびプロジェクトのレトロスペクティブのリード
9.4 終わりはいつもレトロスペクティブ

第10章 「Make It So」
10.1 サポートを申し出る
10.2 改善の責任を共有する
10.3 大きな変化のサポート

付録A ファシリテーション用品
付録B 感想を聞くアクティビティ
付録C アクティビティのクイックリファレンス
付録D ファシリテーションのスキルを学習するための情報源
付録E 参考文献

訳者ふりかえり

索引

最後に

退職報告エントリを書いたときに、昔の知り合いから色々とメールを頂けました。 「読んでたけど、全く気がつかなかった」という意見が多かったです。

また、最近は様々な方々とお会いする機会が増えてきましたが、知り合い経由でつながっていた事を発見することが多いです。

世の中は狭いと思う今日この頃です。

追記：2008/1/16

取材に行ってきました。「オーム社開発部での開発体制」をご覧下さい。

最近のエントリ

過去記事

過去記事一覧

IPv6基礎検定

YouTubeチャンネルやってます！