エンジニアのみなさん、ペアプロで教材を作りましょう


教材を作る羽目になった
人生は日々様々なことが起きる。プロジェクトマネージャをしていれば、メンバは風邪をひいて休むと言い、プロジェクトマネージャ自身の自分が手を抜いたことが原因で余計な報告書を作る羽目になったり。マネージャなら、こっちのプロジェクトで障害が発生したと言えば、すぐに行ってお詫びをし、あっちのプロジェクトで作業品質が悪いと言われれば、プロジェクトマネージャと対策を相談しに行く。組織の中での良くわからない作業も舞い込んでくるし、やらなくてはならない作業もある。

で、書きにくい経緯があって、ワークショップの教材を書くことになった。
エンジニアなら、毎日、仕様書や導入手順書ハタマタ障害報告書を書いていると思う。そうそう、意外と障害報告書やバグ票を書けないエンジニアが多い。ビックリしたのは、とあるプロジェクトの優秀なエンジニアで書けない人がいたこと。偶々、バグ票が書けない人が集まったプロジェクトだったと信じたいが終わった話だからいいや。

ワークショップの教材を作るということは、“ワークショップ”それ自体を作り上げないと教材のネタがないので書けません。と言うことは、ワークショップをどこから持ってくるか、どこから持ってきてアレンジするか、右から左にパクってくるかするしか方法はありません。

仕様書なら、目次構成が決まっているならそれに沿って、インプットとなる前工程の資料や仕様書を書くために並行して検討した検討資料やパッケージなどのドキュメントと全体のアーキテクチャフレームワークの制約に載せて、適宜整理加工すればよいのだから、ネタはあるわけで。手順書も機能仕様やパッケージドキュメントなどと実機をネタに仕上げればいいわけです。

それらの読み手も、システム仕様なら顧客だろうし、手順書なら実作業者なので大体は身内か自分自身だったり。片や、ワークショップは、その対象が組織内ならインフラエンジニアからWebアプリエンジニアがいるし、ガチガチのウォーターフォールしかやったことがないエンジニアもいれば、「そんなシステム開発方法論なんて知らんぜ!俺流さ、ワイルドだろう?」と臆面もなく言い放つ輩も想定されるわけです。
#ちょっと弱気

ワークショップをするということ自体、教育効果を狙うから、教材にもその効果を担うミッションが伴うし、読み手のダイバシティを考慮した言葉の選択とコンテキストを紡がないといけないわけです。
もし、「エンジニアなら仕様書や手順書を書いているから難しくないでしょ?」と思うなら、その書くものによって求められることが違うから、気を付けましょうね、と。


実は誰でも作れる
「じゃあ、教材書くの難しいの?」
と訊かれたら、
「そんなことないよ。」
と答えます。何に気を付けて教材を書けばよいのかは、先にもう、書いてしまった。

教材の狙う効果を、読み手のダイバシティを考慮した言葉の選択とコンテキストを紡ぐ


教材の狙う効果を明らかにして、整理することが一番骨が折れることかもしれない。大体にして、人は欲張りすぎるから、アレもコレもいろいろ入れたくなるものだ。それを

一番大切なこと


だけにそぎ落とす。断舎利するわけです。
欲張らない。
スモールスタート万歳。
コアコンピタンスを明示的にする。

それを助けてくれるのが、アジャイルで使われるエレベータピッチ。


・[潜在的なニーズを満たしたり、抱えている課題を解決したり]したい
・[対象顧客]向けの、
・[プロダクト名]というプロダクトは、
・[プロダクトのカテゴリー]です。
・これは[重要な利点、対価に見合う説得力のある理由]ができ、
・[代替手段の最右翼]とは違って、
・[差別化の決定的な特徴]が備わっている。

アジャイルサムライ」- 達人開発者への道

はじめのうちは慣れないので、四苦八苦するかもしれないし、実際、片手の内は、四苦八苦した。特に、差別化を表す“[代替手段の最右翼]とは違って、[差別化の決定的な特徴]が備わっている。”と言う件。その前までは、謂わばスペックなのでエンジニアならサクサク書ける。ところが、その件は、提案力なのである。だから、四苦八苦するし悶絶する。何かを捻り出さないと出てこない。

でも、それが教材の“魂”であり、“本質”なので。
#ここ大事。


ペアプロで教材を作る
とは言え、一人で黙々と作ればエレベータピッチがあるから作れることは作れるのです。が、どうも独りよがりな教材になってしまうのは人の性。もう、罪。パソコンで作れば、文字もクリップアートも綺麗だから、内容が薄っぺらでも矛盾があっても綺麗なプレゼンスに隠れてしまって気づかない。これは本当に効率が悪い。エンジニアが作るドキュメントのレビューアをしていれば経験的にわかるが、やはり第三者の目を持った人が書いてもその人自身では、見つけられない不良も潜在的に残るのは仕方がないものだ。
プログラムを書く人なら一度は聞いたことがあるだろう、XP(エクストリームプログラミング)の

ペアプログラミングを教材つくりでやったら???」


と思いつき(これ大事)、やってみたら結構いい。XPはプログラミングばかりじゃない。ドキュメントを作るときも有効でした。
#ドヤ顔
何が良かったというかと言えば、

  • 自分と違うところを指摘してくれる。
  • 自分が暗黙で思っていたことに対して、ツッコミを入れるので、暗黙が明示的になり、それを教材に入れられる。
  • 自分より年下と組んだが、遠慮なくツッコミをしてとお願いしたので、そのツッコミが面白かった。


アジャイルサムライ−達人開発者への道−
Jonathan Rasmusson
オーム社
売り上げランキング: 2318