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

books

オーム社 様に献本いただきました。ありがとうございます。

私は、実際にアジャイルな開発プロジェクトに参加したことがなく、一種の憧れのようなものを抱いていました。本書は、私のようなアジャイル開発って何か凄そうだけど、具体的にはよく分からないという人にとって、とても分かりやすく「アジャイルって何なのさ？」という質問に対する答えになる本だと私は思います。

私が本書を読んで得た答えは、アジャイルって文化なんだと強く感じました。それは他の人にとっては違う答えになるかもしれませんが、そんなことにあまり大きな意味はないということが本書を読むことでよく分かると思います。気になる方は、どうぞ本書を読んでみてください (^ ^;;

期待マネジメント

漫画とかに「戦場は生き物だ」のような台詞がよく出てくる気がします。それは開発プロジェクトも同じようなものだと私は考えています。ただ指示された通りに作業を行い、求められた品質基準を満たし、予定された期日に納めれば良いのですが、実際にはきれいに描かれたプロジェクト管理表のように成功する開発プロジェクトはほとんどないでしょう。

人間が関わる以上、そこに感情的な動きがあって、信頼関係や誤解があり、人間的な成長もあり、利害関係の対立も起こる。

本書では「期待をマネジメントする」という表現がよく出てきますが、私はその言葉をとても気に入っています。機能は満たしたけど使い勝手が悪い、最低限の機能しかなくて何かしょぼいなぁ、開発プロジェクトの中でそう思うことがよくあります。

要件は満たしていると主張する人もいるでしょうし、使いやすいものに改善しようと提案する人もいるでしょう。それは個人の気付き力や想像力に依るものではありますが、もう少し分かりやすい形で「期待」という言葉で明確にしてお互いの認識をあわせていこうとする心の動きを表すうまい表現だなと私は思いました。

インセプションデッキ

インセプションデッキ *1 という、プロジェクトを始める前にプロジェクトの関係者全員に向けて行う10個の手ごわい質問が紹介されています。インセプションデッキというツール (質問) により、顧客も含めた関係者全員の認識を一致させることで、プロジェクトの方針やゴールを明確にしようという意図があります。

質問の内容そのものは、難しいことでも何でもありません。むしろ、当たり前のことではありますが、プロジェクトを始める前に確認しておくべき内容を10個の質問に絞り込めているということそのものが、著者の数多くの開発経験によるノウハウの集大成だと思います。

インセプションデッキという言葉そのものが、アジャイル界隈でも新しめの用語のようです。

リファクタリングの考え方

本書の内容として特筆することではないと思いますが、私が誤解していた内容だったので紹介します。本書では、リファクタリングはどんどんやって、継続することが重要だと書かれています。これまで私は、何か要件や仕様の変更があり、現状の設計がそれにあわない場合にリファクタリングしたり、即席で書いた練られていないコードを余裕のあるときにリファクタリングしていました。

本書は、プロジェクトの最初から「継続して」「少しずつ」リファクタリングに取り組むべきだと言っています。リファクタリングの工数を日々の開発の中に取り組むことで、リファクタリングによる進捗の遅れという考え方そのものをなくすという狙いもあります。つまりプロジェクトの終盤にリファクタリングする余裕がないという状況そのものをなくしてしまうということです。

また、私のように、何かあったらとか、後でまとめてリファクタリングしようという考え方だと、開発期間中に何も機能追加されない時期が発生してしまい、リファクタリングに汚名が着せられるケースがあるとコラムでも紹介されています。

本書を読んで、私は日々リファクタリングするようになりました。小さなコードに対して考えるきっかけが増えたことにより、頭の中に残っているせいか、数日経ってからもっと良いコードを思いついたりするようになりました。

プロジェクトの最初から「継続して」「少しずつ」リファクタリングする。これは良さそうです。

アジャイルサムライ読書会

本書の読書会も活発に行われているようです。たくさんの人たちと議論する中でアジャイル開発の理解度が格段に高くなると思います。ぜひ参加されてみてはいかがでしょうか。

アジャイルサムライの読書会(渋谷道場)をします #agilesamurai | Act as Professional - hiroki.jp

翻訳レビューへの参加

【急募】"The Agile Samurai"の翻訳レビュワーを募集します - 角谷HTML化計画(2011-04-26) の呼びかけに応募して、私もレビューアの1人に加えてもらいました。以前にアジャイルプラクティス *2 を読んでいたので、翻訳が素晴らしいのは分かっていたけれど、レビュー向けの原稿も私が想像した以上に日本語として分かりやすいように工夫され、練られた翻訳だと私は思いました。私のレビューの貢献は微々たるものなので、レビューアの1人と名乗るのもおこがましいですが、そのときの体験談を少し紹介したいと思います。

約20名のレビューア陣による容赦ないレビューがメールで送られます。原文と読み比べてより正確な文意を指摘するレビューアもいれば、日本語の係り受けを詳細に指摘するレビューアもいます。毎日何通ものメールが送られて、毎日原稿を更新してビルドされ、毎日必ずレビューアが指摘した内容に対して返信する角谷さん (@) 。

私は、今回のレビューに参加している期間中、ずっとこう感じていました。オンラインのやり取りのみだけど、何だか信頼感があるな。参加している他のレビューアも楽しんでやってそうだな。そして、きっと本書は良い本になるだろうな。

！？

そっか。アジャイルってきっとこういう文化なんだな。やってて嫌にならない、プロジェクトの方向性に意志があり、きっとこんなものが出来るんだろうと想像できる。その期待感が楽しみになり、自分も何かしら貢献しようと思えてくる。そういう雰囲気作り、チーム作りがアジャイルの最初の取っ掛かりではないかと私は思いました。

また、日常の生活の中で、他人の翻訳を原文とあわせて読む機会は少ないです。翻訳のレビューをやってみると、自分だったらこう訳すけど、この翻訳もすてきだな、この文章はこんな風に訳せるのかと、私自身にとって参考になりました。実際、私はレビューアなのに原文の翻訳内容に感心することの方が多かったです。

楽しい翻訳レビューに参加させてもらってありがとうございました。

リファレンス

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

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

*1:[Agile]インセプションデッキ日本語版 | Ryuzee.com

*2:

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

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

EuroPython 2011 イベントレポート 第3回 (最終回)

event python

1週間遅れてしまいましたが、最後の #4 アプリケーションに関する講演，LT，PSFメンバーミーティング，まとめ を書きました。

イベントに参加した方、一緒に行ってくれた方、レビューしてくれた方、編集してくれた方、みなさん、お疲れ様でしたー。

プログラミングできなくてもマネジメントはできるか？

philosophy

SIer で働く友人から聞きました。その友人は、数年、システムエンジニア (以下 SE) としてキャリアを積み、サブリーダーや新人研修の講師を務め、プログラミングも得意で、自身のキャリアプランとしてプロジェクトマネージャー (以下 PM) を目指しています。プロジェクトがある毎に上司に PM をさせてほしいと要望を出していました。

ある時、とあるプロジェクトに先輩 SE の A さんと一緒にアサインされることになり、いつものように PM をさせてほしいと要望を出しました。その時の上司の回答はこんな感じだったようです。

A さんはプログラミングできないからマネジメントをさせる。君 (友人) はプログラミング「も」できるから実装を担当してほしい。

先輩を立てるという意図もあったのかもしれませんが、この例で言うと、PM はどちらも未経験、プログラミングは友人の方ができるという状況のようです。

友人は、なぜ自分が PM を担当できないんだと愚痴をもらしていました、、、まぁ、当然ですね。

私個人の経験 (SI 業界) では「プログラミングできなくてもマネジメントはできるか？」という問いに対しては、できるかもしれないなぁと思っています。もちろん、これは PM はプログラミングできなくて良いと肯定しているわけではありません。

私の考える PM に重要な要素は次の3つです。

  • 肚が据わってる
  • 決断をする
  • 責任を転嫁しない

できるかもしれないなぁと思う理由はここに「プログラミングができる」が入らないだけです。

肚が据わってる

「このプロジェクトで赤字が出たら会社を辞めます」とコミットして PM をやる人って凄く少ないと思います。別に本当に辞めなくて良いと思いますが、そういう覚悟をもってプロジェクトに臨む人が稀だと思います。こういうことを言うと、熱血な人だったり、変な人だったりして、逆にお仕事がやりにくいんじゃ？と思うかもしれません。

でも、私の周りにいた人では、そういう人は決して評判が悪くなかったです。それは、顧客が悪いとか、環境がアレとか、メンバーの実力がとか、外的要因をあまり気にしない傾向にあるからです。失敗したら次なんてないのだから、今与えられた条件でプロジェクトをどう成功させるかということに専念しやすいのだと思います。

決断する

「全ての条件が揃ってから最も良い選択をする」理想ではありますが、お仕事においてはそんな状況の方が稀だと思います。不確定要素が多々ある中で、要所要所でベストな選択をしていく。あっているかどうか分からないけど、決めなければいけないタイミングで決めないと、残念な結果を招くことになります。

何も決めずに結果的に失敗するのと、決めて挑戦して失敗するのは大きな差があります。前者は次へつながる知見が得られませんが、後者はどの判断の何が問題だったかを反省して、次へつなげることができます。但し、プロジェクトの反省会というのをちゃんと実施しているチームに限る、が大事ですね。

何も決めずに結果的に成功する場合もあるんじゃないか？と思う方もいるかもしれません。これも前述したのと同じで、そのプロジェクトでは成功したかもしれないけど、成功要因が分からないということは、次へつながる知見が得られないことと同義なんだと私は思います。

責任を転嫁しない

私が SE をやっていた頃の、うまくまわっていたプロジェクトの PM は、私がやらかした大きな失敗を報告しても「はい。分かりました。」としか言わなかったのを今でもよく覚えています。

また以前勤めていた会社の経営者が「経営不振の理由の1つは、コミュニケーションの問題だ」と言い出したことがありました。それは確かに正しいのでしょうが、私は当時、何かしっくりこない気持ち悪さを感じました。それは裏返すと「経営者に責任はない」と暗にほのめかしているようにも聞こえるからだと最近、少し分かってきました。

「コミュニケーションの問題」というのは、現場の人が言うのはまだしも、管理する立場の人が言うのは責任転嫁だと私は思います。もっともらしくて誰も何も悪くないという思考停止に陥る危険があると思います。


と、いま書いてみて、マネジメントスキルとか、プログラミングとか能力は後付けで得られるけれど、資質はそうあろうとする本人の心がけ次第なのかなとちょっと思いました。私はプログラマ指向なのですが、こんな PM だと一緒にお仕事しやすいです。

EuroPython 2011 イベントレポート 第2回

event python

先週に引き続き、第2回のレポートが公開されました。

私が執筆した #2 CPythonについてのハンズオン，講演 と id:rokujyouhitoma が執筆した #3 PyPyについての講演，ハンズオン，スプリント の2本立てです。

Python プログラミングのテクニックや (比較的) 新しめのライブラリをいくつか紹介しています。

EuroPython 2011 イベントレポート 第1回

event python

気付けば1ヶ月以上、ブログを書いていませんでした。
先日、Europython 2011 — EuroPython 2013: Florence, July 1–7 に参加してきました。

そのときのイベントレポートを #1 基調講演とカンファレンスの全体像 に書きました。全部で3回書く予定です。楽しんでもらえたら幸いです。

Scientific Linux 6.0 をインストールする

linux

wikipedia:CentOS 同様、wikipedia:Scientific_Linux という wikipedia:Red_Hat_Enterprise_Linux クローンなエンタープライズ Linux があります。CentOS に比べるとマイナーな印象だったのが、CentOS 6.0 の開発が遅れたことから引き合いに出るようになりました。個人的には CentOS の危機みたいなお話は昔からよく聞くので、そうは言ってもなくならないでしょ？と思ってたりはします。

全然、別のお話ですが、最近 Google さんがいくつか API の廃止を発表するニュース *1 を見て、よく使っている何かがなくなっても代替可能なものを知っておく、つまりそういったリスクに備える心構えは大事だなと思い、インストールして環境を設けておくことにしました。

インストール

Scientific Linux - Welcome to Scientific Linux (SL) からダウンロードのリンクを辿ります。私の場合は、SL6.0 の x86_64 iso から SL-60-x86_64-2011-03-03-boot.iso を選択します。名前からレスキューディスクのように思ってしまいますが、ネットワークインストールも兼ねているようです。

インストーラーも Anaconda なので、CentOS のインストールとほぼ同じだと思います。見慣れない SL のロゴも格好良いですね。

特に何の違和感も無くインストールできます。

インストールできました。

ちなみに Python のバージョンは 2.6.5 です。

# python
Python 2.6.5 (r265:79063, Dec 14 2010, 15:24:46) 
[GCC 4.4.4 20100726 (Red Hat 4.4.4-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

EPEL リポジトリ追加

エンタープライズ Linux の1つなので EPEL リポジトリも活用できます。

# rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm
http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm を取得中
準備中...                ########################################### [100%]
   1:epel-release           ########################################### [100%]

通常のアップデートで EPEL リポジトリを使わないように設定を変更します *2 。

# vi /etc/yum.repos.d/epel.repo
[epel]
...
enabled=0
...

リポジトリは自動的に近くのサーバを見てくれないようなので、国内ミラーサーバ に URL を変更した方が良いのかもしれません。

*1:Google、Translate APIやBlog Search APIなどを廃止へ - F.Ko-Jiの「一秒後は未来」

*2:EPEL リポジトリを使うときは yum --enablerepo=epel と明示的に指定します

俺のコードのどこが悪い？ -コードレビューを攻略する40のルール-

books

コードレビューは、アプリケーションの品質を向上させる上でとても重要な取り組みだと認識されるようになっています。そんなコードレビューですが、私も以前、叩かれてへこんだりしたこともありました。そうこうしているうちに慣れて、むしろ指摘してもらえることで知らなかったことを知る機会となり、プログラマとして成長する良い機会でもあると、いまは考えています。

例えば、本書の中で、行の折り返し位置の体裁について2通りの折り返し方法を紹介しています。

  1. 横幅最大値を超えた時点で機械的に折り返し
  2. 構文木上の、より上位の要素において折り返し

後者の構文木の上位要素という考え方は、私には全くなかった考え方で純粋にそんなやり方もあるんだなぁとおもしろかったです。知らないことを知る場として楽しめるようになると良いけれど、お仕事だと厳しい意見もちらほら聞くかもしれませんね。

さて、本書の「レビュー準備編」では、コードレビューでへこまないための心構えや、そもそもコードレビューはどんな風にやれば良いの？といった、体系的な方法論とチェック項目を網羅しています。レビューチェックシートのサンプルも掲載されていて参考になります。

主題の「レビュー実践編」ですが、本書はコードレビューのためだけのノウハウ本ではなく、C/C++/Java といった言語仕様まで突っ込んだ特性を、コラムで説明しながら、こういう仕様の落とし穴があるからコードレビューでそこを注意しましょうといった解説になっています。私は C/C++/Java の開発経験がほとんどないので、へー、そういう仕様なのかと興味深く読ませてもらいました。コラムだけでも、著者の培ってきた実業務の経験が垣間見えたりします。

著者自身もあとがきにこのように書かれています。

あらゆる知識はお互い密接に関連しあっています。ということは、「汝、〜〜すべからず！」の裏側にも、コンパイラやインタプリタ、OS、CPU などの愉快な仕掛けが隠されているわけです。プログラマにとってこんな楽しいものはありません。レビュー項目に隠された、そんな楽しさの一端をなんとかして伝えたい、そんな目的をこっそり忍ばせて書き進めた結果、コラムや脚注がやたらと多い、珍妙な本になってしまいました。

いくつか私にとって興味深かったコラムを紹介すると、以下のようなものがあります。コードレビューを、プログラミングに関する背景を教える場と捉えても良いかもしれませんね。

  • switch 分岐の効率

if/else 文は条件指定が増えるほど条件判定を実施するコストが増えるが、switch 文では case ラベルが増えてもアドレス格納テーブルのサイズが増えるだけで条件判定のコストは増えない。

  • スタック渡しによるコスト

x86 アーキテクチャの 32 ビットモードはスタック渡しで、64 ビットモードはレジスタ渡しになる。6引数の関数を呼び出すために引数を準備するコストは、スタック渡しが 6.0 クロックに対してレジスタ渡しが 0.1 クロックだった。

  • 言語として「頼り過ぎ」に舵を切った Python

Python のイテレータは next() で次要素の取り出そうとするが、要素が無ければ StopIteration 例外を発生させる。例外を多様する実行制御をもつ言語特性がある。これは 用語集 にもある EAFP の考え方の違いですね。

  • fork() の使用

fork した子プロセスで execv() などの exec 系システムコールを使用して子プロセスを上書きする

  • 「具象」から「抽象」へ

最初に基底クラスから定義しようとして上手くいかないのは「抽象」は多くの「具象」をもとに「抽象」化されるので、その順番でやってみると良い。

コラム単体を読んでもおもしろそうなので、コラムのインデックスがあると良かったなと思います。

読んでいるとコラムで横道に逸れることも多いのですが、もちろん本文も技術的背景が詳しく説明されています。読み進めていくとコードレビューというよりは、プログラミングのコツを教えてくれるように受け取れます。はまるポイントをコードレビューでチェックしようとしているのですから、プログラミングの深い洞察につながるのは道理ではありますね(^ ^;;

「レビュー実践編」はかなり幅広い内容を網羅していてプログラミングの気を付けるポイントとして実用的な項目がたくさんあります。本書で一通りチェックしてからコードレビューに臨むと指摘される項目がずっと少なくなると思います。とても勉強になりました。

リファレンス:
『俺のコードのどこが悪い？』へのご意見・ご要望・誤記情報 - 彷徨えるフジワラ
技術系執筆情報

俺のコードのどこが悪い?―コードレビューを攻略する40のルール

俺のコードのどこが悪い?―コードレビューを攻略する40のルール