nDiki : ピアレビュー

プロジェクトマネジメント 開発ガイドライン nDiki 問題発見 ソースコード バグトラッキングシステム ソフトウェア 問題解決 リーダーシップ 思考法 議事録 メーリングリスト 開発 適応型ソフトウェア開発 プリント インストール コーチング 仕様 コードネーム ミッション プロジェクト立ち上げフェーズ 開発プロセスメモ 反面教師 適応型サイクルの計画 プレゼンテーション バージョン管理システム 社内 Perl 勉強会 開発環境 Perl ガイドライン

■ 第1回 社内 Perl 勉強会

この間教材として選定した「初めてのPerl 第3版」を使って第1回目の社内 Perl 勉強会を実施した。

プログラミングのクラスなんて大学(および TA)以来なので、進め方は手探りである。 まずは以下の様にしてみた。

@ 目的

Perl プログラミング、および一般的なプログラミング・開発のスキルアップを目指す。

@ 進め方

• 私が進行役。
• 自由参加 (私の指定プロジェクトメンバは必須)。プログラマでも、コンテンツデザイナーでも。
• 書籍「初めての Perl 第3版」を教材とする。
  • 本は社内に1冊ある。ケンカしないでうまく回して読むように。
• 1週間に1章ずつ進める (最初の回は1・2章)。
• 各自事前に独習すること。業務の支障にならない範囲でうまく進めること。
• 章末の練習問題を課題とし、勉強会の前に解答を作成してみること (書籍末に回答があるが見ないようにすること)。
• 独習の上でわからない点は適宜、誰かに質問してできるだけ解決をはかること。

@ 勉強会

• 毎週金曜日に勉強会を 16:00 - 17:00 で開催。
• 練習問題の解答ピアレビューを中心に行う。その場で本読みはしない。
• 課題がプログラムの場合は、プリントアウトして持参すること (あまりに長い場合はのぞく)。
• 参加希望者は事前に 社内 WikiPage に、参加意思を表明すること。
• 練習問題別に、チェック項目や補足情報を追加した資料を開始時に配付。

@ 実施

第1回は私を含めて6人による勉強会となった。

プログラミングを学ぶのはやはり実践が一番であるので、事前に練習問題に取り組むというスタイルにしてみた。勉強会では他人のコードを見たり意見交換したりすることで理解を深め新しい発見ができればと考えている。

皆それぞれの業務を抱えているので、忙がしい人については事前の課題取り組みについては厳しのではとの不安もあったが、初級者・中級者にかかわらず全員準備してきていた。 びっくりするとともに嬉しかった。 参加者は皆それぞれチャレンジ心を持ち、何かを得ようとという熱意があるようで素晴しい限りである。

今回は練習問題も簡単だということもあり、全員解答できたようである。 今回気がついた点:

• プログラムのプリントアウトについては以下のようにするのが望ましい。
  • プログラム毎にプリントアウトを分ける (1枚に複数のプログラムを掲載しているとレビューしにくい)。
  • フォントは適度な大きさで (小さいと見づらい)。
  • 今後プログラムが長くなってきた時のために、行番号を入れるのが望ましい。
  • 可能ならばプリティプリンティグを (皆にツールを紹介する必要あり)。
  • 今回は皆1セットづつしかプリントアウトしてこなかったが、これだと皆でレビューしにくい。人数分プリントアウトしてしまった方が効果的ではないだろうか。他人のプログラムで興味深いものは持ち帰りたいし。その場合はプログラムの先頭にコメントで問題番号と作成者を書いてもらうのが良いだろう。
• そういえば書籍末の正解の確認をしなかった。今後問題が難しくなってきたら確認した方がいいかもしれない。
• 教材の本は予算で買った1冊とスタッフ私物の1冊で現在2冊。ちょっと足りないかな。もう1冊ぐらいあった方が良いかもしれない。

1時間の予定であったが10分オーバーで70分。 時間的にはこれぐらいか。90分ぐらいあった方がいいのかもしれないけれど、業務とのかねあいもあるし。

@ 本社

そういえば今回は東京オフィスで希望者向けのものだったので特に本社には連絡しなかったんだけれど、1名ここ(nDiki)の記事を見て羨しがっていたらしい。

リモートでの参加までは考えていなかったので今回は準備できなかったけれど、希望があるならなんか方法を考えていきたい。

@ また来週

さて、本格的にプログラミングっぽくなってくる次回からが楽しみである。 目指せ総 Perl プログラマ化。

• 第2回 社内 Perl 勉強会 (2006-04-28)
• Emacs でお好きな言語のソースコードを色付き HTML テキストに変換 (2006-04-21)
• 第6回 社内 Perl 勉強会 (2006-06-05)
• 社内 Perl 勉強会 最終回 (第16回) (2006-09-11)
• 第3回 社内 Perl 勉強会 (2006-05-12)

■ ピアレビューの効果を上げたい

たまたたま重なっているのだと思うが、社内でピアレビューの機会が最近増えている。 ウォークスルー(もどき)のレビューであるが、どうも効果的にできていない気がする。

• 準備不足で、レビューポイントが不明確
• 問題解決や持論展開に流れてすぎて、問題発見が十分できていない

やはり、レビューのしかたもチームで学ぶ必要があるな。

• 「プロジェクトマネジメント」はどうやって勉強すれば良いですか? (2006-11-22)
• 問題とは「あるべき姿」と「現状」の「ギャップ」である (2006-10-13)
• 第1回 社内 Perl 勉強会 (2006-04-21)
• 無印良品のミニ6穴手帳 (2008-01-20)
• 第2回 社内 Perl 勉強会 (2006-04-28)

■ 「プロジェクトマネジメント」はどうやって勉強すれば良いですか?

会社の後輩から問われた。

答えがあればこちらが知りたい。

プロジェクトマネージャには、そういう事を自力で模索し掴みとる能力が必要なのではないか。プロジェクトマネージャは答えの決まっていない問題の解決をしていかなければならないのだから。

もちろん他の人から学ぶというのも重要なので、質問すること自体は悪くない。 ただもう少し自分で考えてみて「○○と△△というのがあり、○○の方が～～で良さそうだと思うのですがどう思いますか?」などと、やるのが良いかと思う。

ちなみに私がどう試行錯誤しているか、何を読んでどう考えたかはココ (nDiki) に書いているから、後輩君なら(反面教師にせよ)見てくれればいいと思う。

ていうか、何か面白いもの見つけてきてドンドン紹介してクレ。

• 技は盗むもの - 早朝会議革命

@ とはいえ自分なりに列挙してみる

ソフトウェアプロジェクトマネジメントで、必要なキーワードを思いつくままに挙げてみた。

• 問題発見力、問題解決力 (思考法)
• 意思決定力
• リーダーシップ力
• コミュニケーション力
  • コーチング
  • ファシリテーション
• プレゼンテーション力
• (リスク管理力)
• 以下に関する知識
  • 開発ガイドライン
  • ソースコード管理 (リビジョン管理)
  • バグトラッキングシステム
  • ビルド管理
  • リリース管理
  • ドキュメンテーション
  • ソフトウェアテスト
  • ソフトウェア見積もり
  • ソフトウェアライセンス
  • ピアレビュー

• やっぱり聞きやすかった大前研一 (2006-10-25)
• ピアレビューの効果を上げたい (2006-05-19)
• 久しぶりに build.xml を書く (2005-11-14)
• ビジネスメールガイドライン案 (2006-05-05)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)