2/12、13とDeveloper's Summit 2009へ参加してきました。
ここ数年の恒例で、去年に引き続きのなのですが、今年は時間の関係で、それほど多くのセッションへは参加できませんでした。残念。
それでも、相変わらず内容は示唆に富み、特に角谷信太郎さんの
「時を超えたプログラミングの道への道」は大変心に残りました。XPを手始めに既に7、8年ほどAgile開発プロセスに取り組んでいますが、このプレゼンは、その過去と現在を大きく俯瞰させてくれ、立ち位置を見つめ直すチャンスを頂きました。本当に感謝しています。
また舘野祐一さんの「株式会社はてなの開発戦略」では、開発戦略というよりも、開発環境を現実的にどのように構築し、deployさせてゆくのか、という点で自らが積極的にカイゼン推進している点に感銘を受けました。
まつもとゆきひろさんの「未来へつながる言語〜ある言語おたくの視点から」は純粋に、熱く、楽しい話題でした。ミーハーなので、出店していた O'REILLY で『プログラミング言語 Ruby』を購入し、まつもとさんと、卜部さんにサインをしてもらいました (^^;
総じて、Developper's Summit は、無料でありながらも質が高く、若い方々の素晴らしい活躍を目の当たりに出来る点で有益な場だと感じています。
プレゼン資料が公開されはじめているようですの、興味のあるかたは、ぜひ。
2009/02/24
2008/10/05
積ん読から2冊
積ん読から2冊
数年前に購入し、他の本に下敷きになっていた本を2冊ほど読みました。少し部屋の片付けをしたのがきっかけです (^^;両方とも既に古典とされつつある、大変有名な本です。
1冊目は『イノベーションのジレンマ』。
最近、『イノベーションへの解 実践編』が発売になりましたが、そのシリーズ第一弾といった位置づけでしょうか。
最終章から論旨を引用させていただくと、こんな感じ。
これ対する本書での提案は「邪魔せず、支配する環境を作り出す」ということですが、これは『XP エクストリーム・プログラミング入門 第2版』の
で問題は、これら独立部隊が独立性を保ちながらも、全体として、一本、確とした筋を通すにはどうするのか、という点なのですよね...。
もう一冊は『会議が絶対うまくいく法』。
ファシリテーションに関する本で、ポイントがサクサク読めます。会議を主催する側になった人には、勿論、多くの論点がぼけた会議に業を煮やしている人にも、自分が同じことをしない為の注意点を知る為に、お薦めです。
さて、この本では「問題解決のコツ」として、
自分の周りで起こっている、上手く行っているプロジェクトや、残念ながら、少し空回りしているプロジェクトなどを見ると、ファシリテータの存在やビジョンの提示、スーパーエンジニアの存在性などに各種特徴が見られ、あぁ、やっぱりプロジェクトって面白いな、と思うのでした。
数年前に購入し、他の本に下敷きになっていた本を2冊ほど読みました。少し部屋の片付けをしたのがきっかけです (^^;両方とも既に古典とされつつある、大変有名な本です。
1冊目は『イノベーションのジレンマ』。
最近、『イノベーションへの解 実践編』が発売になりましたが、そのシリーズ第一弾といった位置づけでしょうか。
最終章から論旨を引用させていただくと、こんな感じ。
見事な成功をおさめてきた企業の有能な経営陣が、ひらすら利益と成長を求めるうちに、最高の経営手法を使って、企業を失敗に導く場合があることを学んだ(p.293)。
マネージャはまず、これらの衝突がどのようなものかを理解する必要がある。つぎに、各組織の市場での地位、経済構造、開発能力、価値が、顧客の力と調和し、持続的イノベーションと本格的イノベーションという全く異なる仕事を邪魔せず、支配する環境を作り出す必要がある(p.297)。やっぱり、こういう話を読むと、自身に関係の深いソフトウェア開発プロセスとの関連で考えてしまうわけで、例えば、成功する為のパターンを模索して手に入れたソフトウェア開発のチームが、その成功故に、維持するものが大きくなり、だんだんと機動力と言うかAgilityが失われてしまう、という悲しいパターンに近いのかなぁ、と。
これ対する本書での提案は「邪魔せず、支配する環境を作り出す」ということですが、これは『XP エクストリーム・プログラミング入門 第2版』の
小規模なチームでプロジェクトを始め、自立したチーム間で作業を分割する(p.116)と、同じ思想に根差しているのだろうな、と感じました。
で問題は、これら独立部隊が独立性を保ちながらも、全体として、一本、確とした筋を通すにはどうするのか、という点なのですよね...。
もう一冊は『会議が絶対うまくいく法』。
ファシリテーションに関する本で、ポイントがサクサク読めます。会議を主催する側になった人には、勿論、多くの論点がぼけた会議に業を煮やしている人にも、自分が同じことをしない為の注意点を知る為に、お薦めです。
さて、この本では「問題解決のコツ」として、
集団で評価をするときには、判断を下す前に、共通の判断基準をつくり、合意しておかなくてはならない(p.216)という記述が出てきます。そして恐らくこれこそが、「全体で筋を一本通す」ことの肝なのだろうな、と。
自分の周りで起こっている、上手く行っているプロジェクトや、残念ながら、少し空回りしているプロジェクトなどを見ると、ファシリテータの存在やビジョンの提示、スーパーエンジニアの存在性などに各種特徴が見られ、あぁ、やっぱりプロジェクトって面白いな、と思うのでした。
2008/06/17
腰リールメモ
ふとした事から、一時期流行った腰リールメモを作ることにしました。
腰リールメモで良くある失敗は「ペン本体がキャップから抜け落ちて無くなってしまい、いざというときに書けない」というもの。
もちろん、私はそんなヘマはしません! ちゃんと抜け落ちないペンを吟味し(しかも、愛用しているDr.GRIP のミニチュア!)、紐でリールに装着! これで、ペンが抜け落ちることもありません。
って、これじゃ、メモ、書けないじゃん... orz。
腰リールメモで良くある失敗は「ペン本体がキャップから抜け落ちて無くなってしまい、いざというときに書けない」というもの。
もちろん、私はそんなヘマはしません! ちゃんと抜け落ちないペンを吟味し(しかも、愛用しているDr.GRIP のミニチュア!)、紐でリールに装着! これで、ペンが抜け落ちることもありません。
って、これじゃ、メモ、書けないじゃん... orz。
2008/06/15
ファシリテーション技術の本
仕事関係で、『ワークショップ・デザイン』と『ファシリテータの道具箱』を読みました。
どちらもノウハウ集であり、記述も平易なので、併せて数時間もあれば読めてしまうほどの軽めの書籍です。
今までプロジェクトマネジメント等で使ってきたいろいろなアクティビティが、その効果と目的とに応じて綺麗に整理されており、頭の中がスッキリした感じです。過去、悩んで来た場面で、このアクティビティを適用すれば良かったのかな、と感じたものもありました。
別にテクニック本を読んだからと言って、ファシリテーションが上手くなるわけでは決してありません(やっぱり、臨機応変さなど、最後は経験数だと思います)。逆に、経験を積んでない方が、色々な本を読んでしまうと、頭でっかちになって、心が落ち着かなくなってしまうのでは、とも思います。
もしこれからファシリテータを努めてみたい、という方は、自分が臨む会合に関して軽めの知識を入れた後、何度か身内で体験を重ねてみるのが良いのではないでしょうか?その上で、このような各種手法に関する書籍を読むと、自身の血となり肉となると言う点で、効果的なのではないかな、と思います。
どちらもノウハウ集であり、記述も平易なので、併せて数時間もあれば読めてしまうほどの軽めの書籍です。
今までプロジェクトマネジメント等で使ってきたいろいろなアクティビティが、その効果と目的とに応じて綺麗に整理されており、頭の中がスッキリした感じです。過去、悩んで来た場面で、このアクティビティを適用すれば良かったのかな、と感じたものもありました。
別にテクニック本を読んだからと言って、ファシリテーションが上手くなるわけでは決してありません(やっぱり、臨機応変さなど、最後は経験数だと思います)。逆に、経験を積んでない方が、色々な本を読んでしまうと、頭でっかちになって、心が落ち着かなくなってしまうのでは、とも思います。
もしこれからファシリテータを努めてみたい、という方は、自分が臨む会合に関して軽めの知識を入れた後、何度か身内で体験を重ねてみるのが良いのではないでしょうか?その上で、このような各種手法に関する書籍を読むと、自身の血となり肉となると言う点で、効果的なのではないかな、と思います。
2008/04/04
ソフトウェア開発者雇用ガイド(Joel Spolsky)
Joel Spolskyの「ソフトウェア開発者採用ガイド」読了。
Joel on Software 等でも語られている「チームには、本当に納得できた有益な人物しか雇用してはならない」という理論で、語られた書籍。また、その為に雇用者が開発者をどのように扱わなければならないか、という視点でも述べられています。
この「納得行かなければ雇用してはならぬ」というのは、雇用する側も雇用される側も、大変厳しい姿勢だと思います。一方で、このようなプロセスを経て作られたチームは、パフォーマンスの面でも信頼性の面でも、大きな優位性が得られるかと思います。
で、何時もの話になりますが、これはGoogleが使ってきた採用プロセスなんですよね...。これが、GoogleやFrog Creekなどの優秀なIT企業が当たり前と認識している採用プロセスであるならば、日本の企業は、相当厳しいのではないでしょうか? それとも日本のベンチャーなどは、積極的にこうした方式を採用しているのかな?
現在の勤務先でも、派遣さんにお手伝いいただく際には、「派遣さんとは面談したら、特に理由が無い限り断れないからね」「面談ではコードを書かせるなんて、言語道断だよ」などの指示がなされます。勿論派遣さんの場合、正社員の雇用とは、取り巻く法律などは全く違いますが、履歴書だけで判断するだけでなく、もう少し自由に語らせて貰えると嬉しいな、と思います。
Joel on Software 等でも語られている「チームには、本当に納得できた有益な人物しか雇用してはならない」という理論で、語られた書籍。また、その為に雇用者が開発者をどのように扱わなければならないか、という視点でも述べられています。
この「納得行かなければ雇用してはならぬ」というのは、雇用する側も雇用される側も、大変厳しい姿勢だと思います。一方で、このようなプロセスを経て作られたチームは、パフォーマンスの面でも信頼性の面でも、大きな優位性が得られるかと思います。
で、何時もの話になりますが、これはGoogleが使ってきた採用プロセスなんですよね...。これが、GoogleやFrog Creekなどの優秀なIT企業が当たり前と認識している採用プロセスであるならば、日本の企業は、相当厳しいのではないでしょうか? それとも日本のベンチャーなどは、積極的にこうした方式を採用しているのかな?
現在の勤務先でも、派遣さんにお手伝いいただく際には、「派遣さんとは面談したら、特に理由が無い限り断れないからね」「面談ではコードを書かせるなんて、言語道断だよ」などの指示がなされます。勿論派遣さんの場合、正社員の雇用とは、取り巻く法律などは全く違いますが、履歴書だけで判断するだけでなく、もう少し自由に語らせて貰えると嬉しいな、と思います。
2008/03/19
トラックナンバーと特異な才能
友人と飲み屋での会話。
「トラックナンバー」を大きくすることは、プロジェクト運営で重要な要素である。一方で、例えばスタートアップやベンチャーでの人材採用基準は、可能な限り才能を重複させないことで、それ故に成功を収めている。実際、大きな会社でも、プロジェクト主要な位置で支えてくれているのは、一定の分野で特異な能力を持つ、とてもではないが代替の利かない有益な人だったりする。
人材の能力交流と、特異性の発揮。企業規模や安定性、取り扱っているビジネス案件で違うとは思うけど、このバランスって、どこにあるんだろうね。
なかなか、難しい問題ですね...。
「トラックナンバー」を大きくすることは、プロジェクト運営で重要な要素である。一方で、例えばスタートアップやベンチャーでの人材採用基準は、可能な限り才能を重複させないことで、それ故に成功を収めている。実際、大きな会社でも、プロジェクト主要な位置で支えてくれているのは、一定の分野で特異な能力を持つ、とてもではないが代替の利かない有益な人だったりする。
人材の能力交流と、特異性の発揮。企業規模や安定性、取り扱っているビジネス案件で違うとは思うけど、このバランスって、どこにあるんだろうね。
なかなか、難しい問題ですね...。
2008/03/17
Best Software Writing
Joel Spolsky編の『Best Software Writing』を、読了しました(ちなみに、原書は、
Googleブック検索で参照できます)。
『Joel on Software』でも語られていましたが、私はJoelの採用に関する話が、大変好きだったりします。本書でも、Joelと同様の視点に基づいた採用に関する話が編まれていて、興味深く読みました。
チーム開発とソフトウェア開発プロセスでも書きましたが、「チームで作業をする」というのは、なんであれ、一人で作業をするよりは制約が増えることになるわけです。そして、当然それに向く人、向かない人、というのがいるわけで、そこの所を上手く汲み取って、現実にそくして考えないと、どうしてもチームが崩れます。また、チームの色、というのもありますから、例えチーム作業に向く人でも、そのチームに合う、合わない、という問題も出てきます。
学生時代、ツルんで莫迦話に時間を過ごす気の置けない友人、って、ある程度固定化していました。この話をするのはこいつらだな、という感じ。そのような中で連帯感が生まれたり、共通のビジョンが育まれていったり。で、チームの本質って、それと変わらないと思うんですよね。
よく「仕事だから、公私混同するな」とか、「子供じゃないんだから、オトナの付き合いで対処しろ」とか言う人が居ますが、意外にそういう人ほどチームワークを分かっていなかったりするのは、うーむ、とか思ったりしてしまいます。わはははは。
馴れ合いの仲間内で固まるのが良い、と言っているわけではありません。ナーナー(ツーカーじゃないよ!)で進むチームは眩暈がしますし、そもそも進歩なんて望めません。
適宜新しい人材を取り入れて、水の淀みは無くすべきだと思いますし、個性は衝突しあってこそ、だと思います。そしてこれを可能にするのが、「オトナのウワベのツキアイ」ではない、チームワークなんだと思います。頭脳労働なプログラムを優秀な人材の集団で作り上げるためには、どうしても最後は人と人とのぶつかりあいになりますから、心を割って話せなければ、どうやったって、思想もアーキテクチャも実装もゆがんでしまいます。衝突しっぱなしでは、チームになりません。それ故、相手の話を聞くことが出来て、意見を議論できて、最後は皆が笑って納得できるチームを作らねば!
と、こんな視点でチームを見ている自分にとって、採用を大変重視しているJoelの考え方は、大変参考になるのでした。
相変わらず青木さんの訳は(当然)読みやすく、お薦めの一冊です。
Googleブック検索で参照できます)。
『Joel on Software』でも語られていましたが、私はJoelの採用に関する話が、大変好きだったりします。本書でも、Joelと同様の視点に基づいた採用に関する話が編まれていて、興味深く読みました。
チーム開発とソフトウェア開発プロセスでも書きましたが、「チームで作業をする」というのは、なんであれ、一人で作業をするよりは制約が増えることになるわけです。そして、当然それに向く人、向かない人、というのがいるわけで、そこの所を上手く汲み取って、現実にそくして考えないと、どうしてもチームが崩れます。また、チームの色、というのもありますから、例えチーム作業に向く人でも、そのチームに合う、合わない、という問題も出てきます。
学生時代、ツルんで莫迦話に時間を過ごす気の置けない友人、って、ある程度固定化していました。この話をするのはこいつらだな、という感じ。そのような中で連帯感が生まれたり、共通のビジョンが育まれていったり。で、チームの本質って、それと変わらないと思うんですよね。
よく「仕事だから、公私混同するな」とか、「子供じゃないんだから、オトナの付き合いで対処しろ」とか言う人が居ますが、意外にそういう人ほどチームワークを分かっていなかったりするのは、うーむ、とか思ったりしてしまいます。わはははは。
馴れ合いの仲間内で固まるのが良い、と言っているわけではありません。ナーナー(ツーカーじゃないよ!)で進むチームは眩暈がしますし、そもそも進歩なんて望めません。
適宜新しい人材を取り入れて、水の淀みは無くすべきだと思いますし、個性は衝突しあってこそ、だと思います。そしてこれを可能にするのが、「オトナのウワベのツキアイ」ではない、チームワークなんだと思います。頭脳労働なプログラムを優秀な人材の集団で作り上げるためには、どうしても最後は人と人とのぶつかりあいになりますから、心を割って話せなければ、どうやったって、思想もアーキテクチャも実装もゆがんでしまいます。衝突しっぱなしでは、チームになりません。それ故、相手の話を聞くことが出来て、意見を議論できて、最後は皆が笑って納得できるチームを作らねば!
と、こんな視点でチームを見ている自分にとって、採用を大変重視しているJoelの考え方は、大変参考になるのでした。
相変わらず青木さんの訳は(当然)読みやすく、お薦めの一冊です。
2008/03/13
XP 1st Ed.
チームでソフトウェア開発をする場合、チームビルディングが最も重要になります。
「え、スケジュール間に合わないの? 何人追加すれば終わるの?」等と聴いてくる管理職が多いのではないか、と偏見まじりに想像しますが、これが機能しないのは、例えば人月の神話等で、もう30年以上前から言われている事で、ちっとも新しい事ではありません。各人の能力を最大限に発揮させられるチームをマネジメントすることは、大変難しく、奥深いものです。
一方で、ソフトウェアを開発するには、勿論、個々人の開発スキルが重要です。開発系のプラクティスも、達人プログラマーなどで美しくまとめられています。
今振り返ると、XPは、2000年初頭という時期にありながら、この両者で必要となるプラクティスの選択バランスが、最高に絶妙だったと思うわけです。
当時の開発プロセスと言えば、CMMを筆頭とする管理者向けの内容が多かった中、「開発の中心は人間だ」という大前提をまず冷静に認めた上で、管理に必要なプロセスと開発に有益なプロセスとを、チーム全体で目的を達成する為に、一つの流れに組み込んだバランス感覚は、今振り返ってみても、大変素晴らしいな、と感じています。
ScrumやLeanなどの実践が、ブームから日常へと一歩一歩、着実に歩みを進めるのは非常に心強く感じています。この進歩を、更に確たるものとするために、
XPの持っていたバランス感覚を大事にして行きたいな、と感じています。
なお、XP 2nd ed.は多少方向性が変化しましたが、それでも心にとどめて置くべき内容は(勿論)満載で、お薦めです。
「え、スケジュール間に合わないの? 何人追加すれば終わるの?」等と聴いてくる管理職が多いのではないか、と偏見まじりに想像しますが、これが機能しないのは、例えば人月の神話等で、もう30年以上前から言われている事で、ちっとも新しい事ではありません。各人の能力を最大限に発揮させられるチームをマネジメントすることは、大変難しく、奥深いものです。
一方で、ソフトウェアを開発するには、勿論、個々人の開発スキルが重要です。開発系のプラクティスも、達人プログラマーなどで美しくまとめられています。
今振り返ると、XPは、2000年初頭という時期にありながら、この両者で必要となるプラクティスの選択バランスが、最高に絶妙だったと思うわけです。
当時の開発プロセスと言えば、CMMを筆頭とする管理者向けの内容が多かった中、「開発の中心は人間だ」という大前提をまず冷静に認めた上で、管理に必要なプロセスと開発に有益なプロセスとを、チーム全体で目的を達成する為に、一つの流れに組み込んだバランス感覚は、今振り返ってみても、大変素晴らしいな、と感じています。
ScrumやLeanなどの実践が、ブームから日常へと一歩一歩、着実に歩みを進めるのは非常に心強く感じています。この進歩を、更に確たるものとするために、
XPの持っていたバランス感覚を大事にして行きたいな、と感じています。
なお、XP 2nd ed.は多少方向性が変化しましたが、それでも心にとどめて置くべき内容は(勿論)満載で、お薦めです。
2008/03/09
チーム開発とソフトウェア開発プロセス
まずは昔話から。
一人でソフトウェアを完成させるのは、大変クリエイティブで楽しい作業です。実際、昔のゲームプログラマは、プログラミングは勿論、キャラクターデザインから音楽、パッケージの制作まで一人でこなしてしまう、素晴らしい方々がたくさんいらっしゃいました(今でも、きっと、いらっしゃることでしょう)。
ソフトウェア制作は一種の創造作業ですから、どんな内容であれ、明確な方向づけが欠かせません。その点で一人ですべての方向づけを行う、と言うのは理にかなっていると思っています。
その後、自分のあまり得意でない分野の作業や、一人では時間のかかってしまう作業を、気心の知れた知人等と共同で進める開発スタイルが登場してきました。オープンソースソフトウェアや同人ソフトウェアの開発はこの流れの延長線上だと言えるでしょう。同じ志をもつ人々が集まって、一つのソフトウェアの開発に携わり、一人では難しい規模のソフトウェア開発を実現してきました。
複数人で作業を行う場合、一人で作業を行う場合と異なり、何らかの規約が必要になることが多いです。この規約は、目指す方向や、チーム自体の性格、また参加者の思いで大きく異なります。例えば「声をかけ合って、二人で同じファイルを編集することがないようにしよう」という程度な緩い規約だったり、「発売日に向けて、毎日互いの開発進度を報告しあい、進捗を明確に管理しよう」というような真面目な規約だったり。
こんな感じで作られたチームの規約が、そのチームの有益な「ソフトウェア開発プロセス」なわけです。チーム内での合意なわけですから、チームに適した、チームが進みやすい、チームの目的を達成するための規約でなければならないのは当然のこと。プロセスの規模やその適用範囲は、チームの合意として選択されるに過ぎません。
ここまでこの記事を読んで下さっている方には言わずもがな、なわけですが、いつの間にやらこの前提がひっくり返り「急造混成チームへ一本の軸を与えて運用する為、既存のプロセスを組み合わせたベストプラクティスとやらを適用するのだ」という、大変不思議(?)な現象が蔓延するようになってしまいました。
例えば悲しい話として、無理矢理混成チームを与えられてしまった方、例えばチームリーダが「僕の立ち位置では、この与えられたチームを存続させ、どういうやり方であれミッションをこなすことが重要なのだ」等と思い詰めてしまった挙げ句「よく分からないけど、チームに軸を通す為には、チームへプロセスを適用しなきゃいけないらしい」と右往左往している状況を目の当たりにすることがありますが、意味のすり変えられてまった「プロセス」という悪魔の言葉に躍らされ、なぜ故、皆が不幸になっていってしまうのだろうか、と考え込まざるを得ません。
本来、チーム自体が「統一された目的無きまま強制的に集められた人員で作られたチーム」ですから、その時点では多かれ少なかれ、メンバの心が各々違う方向を向いていたりします。ほんの一瞬立ち止まって考えれば、まずはチームの一体感が重要だよね、と考えが進むのでしょうが、心の焦ってしまっているチームリーダがまかり間違って「強固なプロセス」を、そのチームへ適用してしまったりすると...。
お寿司をたべたいなー、とか思っている人と、今日は絶対中華だな、とか思っている人を、無理矢理引っ張ってフランス料理屋へ連れて行き、あげく「こら、音を立ててスープを飲むな」とか叱ってみても、誰も食事本来の目的である「美味しいものを楽しむ」という心は満たされないですよね、なんて話をすると、誰もが、うんうん、と笑ってくれます。でも、企業のソフトウェア開発の現場って、こんなことが、それこそ毎日、真面目な顔で行われているのですから、どこかで何かボタンの掛け違いが起こっているに違いありません。
この問題を解きほぐし、開発者が個人の能力を最大限に発揮できるチームを創造でき、しかもビジネスとして成功できるには、という視点で、以後、少しずつ模索して行きたいと思います。
一人でソフトウェアを完成させるのは、大変クリエイティブで楽しい作業です。実際、昔のゲームプログラマは、プログラミングは勿論、キャラクターデザインから音楽、パッケージの制作まで一人でこなしてしまう、素晴らしい方々がたくさんいらっしゃいました(今でも、きっと、いらっしゃることでしょう)。
ソフトウェア制作は一種の創造作業ですから、どんな内容であれ、明確な方向づけが欠かせません。その点で一人ですべての方向づけを行う、と言うのは理にかなっていると思っています。
その後、自分のあまり得意でない分野の作業や、一人では時間のかかってしまう作業を、気心の知れた知人等と共同で進める開発スタイルが登場してきました。オープンソースソフトウェアや同人ソフトウェアの開発はこの流れの延長線上だと言えるでしょう。同じ志をもつ人々が集まって、一つのソフトウェアの開発に携わり、一人では難しい規模のソフトウェア開発を実現してきました。
複数人で作業を行う場合、一人で作業を行う場合と異なり、何らかの規約が必要になることが多いです。この規約は、目指す方向や、チーム自体の性格、また参加者の思いで大きく異なります。例えば「声をかけ合って、二人で同じファイルを編集することがないようにしよう」という程度な緩い規約だったり、「発売日に向けて、毎日互いの開発進度を報告しあい、進捗を明確に管理しよう」というような真面目な規約だったり。
こんな感じで作られたチームの規約が、そのチームの有益な「ソフトウェア開発プロセス」なわけです。チーム内での合意なわけですから、チームに適した、チームが進みやすい、チームの目的を達成するための規約でなければならないのは当然のこと。プロセスの規模やその適用範囲は、チームの合意として選択されるに過ぎません。
ここまでこの記事を読んで下さっている方には言わずもがな、なわけですが、いつの間にやらこの前提がひっくり返り「急造混成チームへ一本の軸を与えて運用する為、既存のプロセスを組み合わせたベストプラクティスとやらを適用するのだ」という、大変不思議(?)な現象が蔓延するようになってしまいました。
例えば悲しい話として、無理矢理混成チームを与えられてしまった方、例えばチームリーダが「僕の立ち位置では、この与えられたチームを存続させ、どういうやり方であれミッションをこなすことが重要なのだ」等と思い詰めてしまった挙げ句「よく分からないけど、チームに軸を通す為には、チームへプロセスを適用しなきゃいけないらしい」と右往左往している状況を目の当たりにすることがありますが、意味のすり変えられてまった「プロセス」という悪魔の言葉に躍らされ、なぜ故、皆が不幸になっていってしまうのだろうか、と考え込まざるを得ません。
本来、チーム自体が「統一された目的無きまま強制的に集められた人員で作られたチーム」ですから、その時点では多かれ少なかれ、メンバの心が各々違う方向を向いていたりします。ほんの一瞬立ち止まって考えれば、まずはチームの一体感が重要だよね、と考えが進むのでしょうが、心の焦ってしまっているチームリーダがまかり間違って「強固なプロセス」を、そのチームへ適用してしまったりすると...。
お寿司をたべたいなー、とか思っている人と、今日は絶対中華だな、とか思っている人を、無理矢理引っ張ってフランス料理屋へ連れて行き、あげく「こら、音を立ててスープを飲むな」とか叱ってみても、誰も食事本来の目的である「美味しいものを楽しむ」という心は満たされないですよね、なんて話をすると、誰もが、うんうん、と笑ってくれます。でも、企業のソフトウェア開発の現場って、こんなことが、それこそ毎日、真面目な顔で行われているのですから、どこかで何かボタンの掛け違いが起こっているに違いありません。
この問題を解きほぐし、開発者が個人の能力を最大限に発揮できるチームを創造でき、しかもビジネスとして成功できるには、という視点で、以後、少しずつ模索して行きたいと思います。
2008/02/24
プレイングマネージャ
「部下と張り合うようでは上司失格」(NBonline/後半を読むには無料会員登録必要)。本インタビューはソフトウェア開発のロールについて語ったのではありませんが、大変興味深く感じました。
プレイングマネージャ(本記事では、「プロデューサー兼マネジャー」と書かれています)は、トム・デマルコの『ゆとりの法則』でも述べられていたとおり、非常に難しい立場だと思います。
ソフトウェア開発の分野で頑張っている方々は、元もと、自らソフトウェアを書くことが好きな人が多い為、適性が考慮されることなく、この役割が押し付けられた場合、ややもすると、
一方、この状況を回避する目的でプレイヤを専任管理者と定義した場合、または専任管理者を外部から据えた場合、その方の「嗅覚」によっては、
少なくともソフトウェア開発の分野に於いては、「管理者」と呼ばれる「自身以外の人材を有効活用する立場にいる方」には、2種類の帽子をかぶった方々が必要だと、私は考えています。
一人は技術指導者の立場でチーム育成を行う方で、所謂「棟梁」のような方でしょう。このあたり『ソフトウェア職人気質』で定義するところの「マスター」的な位置の方かもしれません。
一方で、プロダクトやチームを横断的に見る方も必要で、こちらは一般的な定義での管理者に近いのかな、と思います。何らかの方法で完成物に関する定義をする方は、この立場に居る方でしょう。
この両者は、「MSF」に於いては、前者を「プログラムマネージャ」(のロールの一部)として、また後者を「プロダクトマネージャ」として分離しています。
この視点で、Developper's Summit2008での参加セッションをを振り返ってみると、平鍋さんが「海外におけるアジャイルの現在」で語った「ソフトウェア開発に必要な学習する組織のリーダー」は、一人の人間としてこの両方の帽子をかぶることが求められますし、また「TPSのChief Engineerこそ、その人だ」と定義していたのだと思います。
また、「David Intersimoneと日本のRubyのコミュニティが、オープンソースの現在と未来について語る会」での話では、まつもとさんを頂点とするプログラムマネージャ群は成立しているので、今後はプロダクトマネージャが必要となる、という話だと捉えることが出来るでしょうか。
何れにしても、このようなロールを一人で新規に負うのは多くの努力が必要であり、
という通り、組織全体でサポートすることが必要なのだな、と切に思います。
ちなみに、現在Googleの人材募集ページを眺めると「リード エンジニア/アーキテクト」を募集しているのですが、その業務内容は、
プレイングマネージャ(本記事では、「プロデューサー兼マネジャー」と書かれています)は、トム・デマルコの『ゆとりの法則』でも述べられていたとおり、非常に難しい立場だと思います。
ソフトウェア開発の分野で頑張っている方々は、元もと、自らソフトウェアを書くことが好きな人が多い為、適性が考慮されることなく、この役割が押し付けられた場合、ややもすると、
プレーヤーとマネジャーのどちらの役割を疎かにするかというと、後者の方が多い。という傾向になってしまいがちで、チーム全体が不幸になってしまいます。
一方、この状況を回避する目的でプレイヤを専任管理者と定義した場合、または専任管理者を外部から据えた場合、その方の「嗅覚」によっては、
管理職がプレーヤーとしての役割をあきらめた場合、ビジネスの感覚が失われます。との指摘通りになってしまいます。ソフトウェア開発は比較的進歩の早い分野ですので、この点がより致命傷になりかねません。
少なくともソフトウェア開発の分野に於いては、「管理者」と呼ばれる「自身以外の人材を有効活用する立場にいる方」には、2種類の帽子をかぶった方々が必要だと、私は考えています。
一人は技術指導者の立場でチーム育成を行う方で、所謂「棟梁」のような方でしょう。このあたり『ソフトウェア職人気質』で定義するところの「マスター」的な位置の方かもしれません。
一方で、プロダクトやチームを横断的に見る方も必要で、こちらは一般的な定義での管理者に近いのかな、と思います。何らかの方法で完成物に関する定義をする方は、この立場に居る方でしょう。
この両者は、「MSF」に於いては、前者を「プログラムマネージャ」(のロールの一部)として、また後者を「プロダクトマネージャ」として分離しています。
この視点で、Developper's Summit2008での参加セッションをを振り返ってみると、平鍋さんが「海外におけるアジャイルの現在」で語った「ソフトウェア開発に必要な学習する組織のリーダー」は、一人の人間としてこの両方の帽子をかぶることが求められますし、また「TPSのChief Engineerこそ、その人だ」と定義していたのだと思います。
また、「David Intersimoneと日本のRubyのコミュニティが、オープンソースの現在と未来について語る会」での話では、まつもとさんを頂点とするプログラムマネージャ群は成立しているので、今後はプロダクトマネージャが必要となる、という話だと捉えることが出来るでしょうか。
何れにしても、このようなロールを一人で新規に負うのは多くの努力が必要であり、
そもそもプレーヤーからマネジャーになること自体が簡単なことではないのに、ましてやプレーヤーであり続けることも求められる。管理職が円滑にマネジャーの仕事をこなせるようになるように、企業はできる限りのサポートをしなければなりません。
という通り、組織全体でサポートすることが必要なのだな、と切に思います。
ちなみに、現在Googleの人材募集ページを眺めると「リード エンジニア/アーキテクト」を募集しているのですが、その業務内容は、
と説明されてあり、プロダクトマネージャとプログラムマネージャの役目が明確に分離されていて、流石だな、と思うのでした。
- 実際の開発業務の中心となると同時に、リーダーとして、少人数で構成されるプロジェクトの進捗管理や、調整作業を行う
- プロダクトマネージャーなどと連携をとり、優れたサービスを開発する
- プロジェクトにおいてコンサルタント的な役割を果たし、コードレビュー、デザインレビュー、技術講演や社内教育などを通じてチームメンバーの指導にあたる
2008/02/17
Developer's Summit 2008参加
2/13、2/14の両日Developer's Summit2008へ参加してきました。
聴講したセッションのゾーンは以下の3つ。
例年通りAgile関係の開発プロセスの話を主体に聞きに行きました。平鍋さんの概説や、関さんのプロセス実践の話は、例年のように大変参考になったのですが、今回はそれに加えて、元トヨタChief Engineerである片山信昭さんのお話を伺えたのが、大変勉強になりました。
なんやかやで、業務上、既に6年ほどAgile開発プロセスのプラクティスを各プロジェクトで使っているのですが、そうした視点で見ても本場TPSのExtremeさには、目から鱗がボロボロです。
後半のパネルでもそうだったのですが、「やるときには妥協なく、過去のデータを下敷きにして徹底的にやる、しかし一方で、人のつながりがビジネスを進めている、ということを忘れてはならぬ」という一点へ、軸足を必ずしっかりと置いている点は、常に目指すべき方向性でありたいと思います。
もう一点、今回はSCMに関して、SubversionとPerforceの2つのセッションがあったので、共に参加しました。
Subversionに関しては長期に使っているのですが、もう少し merge管理を上手く扱ってくれないかな、という点に期待しています。今は log メッセージで管理していますが、「このchangeset は、明示的に、以後の merge 対象から外したい」などの処理がやりにくいの
も事実です。この点でSubversionの1.5系に期待はしていますが、他に方法はないかな、と。
この疑問に対し、デブサミ名物である AskTheSpeaker で、幸いにも、講演者である
株式会社 ヌーラボの縣さんにお伺いすることができましたが、やはり、縣さんも merge 情報に関しては、log メッセージで管理されているということで、1.5系のmerge-infoに期待、とのことでした。やっぱり同じところに行き着くのですね(って、当たり前か)。
Perforceは今回初めて見ることが出来たのですが、さすが商用だけあって各種機能が充実しているな、と感じました。画像データをリビジョン毎にサムネイル表示できる点や、merge 状況をグラフィカルに表示できる点などには、心が揺れます。Google が perforce を使っているのは、この為なのかなぁ? FreeBSD チームも merge が交錯するtask branch では、Perforce を使っているとのことですし。
今回残念だったのは、個人的に興味ひかれた幾つかのセッションが同時間帯に開催されてしまったこと。例えば、Joel と、平鍋さんと前田さんのセッションがかぶったり、片山さんと青木さんがかぶったり、Agileパネルと、言語セッションがかぶったり...。むー、悔しい。
デブサミは、優秀なコミュニティメンバ参加のお陰で、無料とは思えないほど、充実したセッションを受講することが出来ます。ぜひ、来年以降も続けていただきたいな、と思いました。
聴講したセッションのゾーンは以下の3つ。
例年通りAgile関係の開発プロセスの話を主体に聞きに行きました。平鍋さんの概説や、関さんのプロセス実践の話は、例年のように大変参考になったのですが、今回はそれに加えて、元トヨタChief Engineerである片山信昭さんのお話を伺えたのが、大変勉強になりました。
なんやかやで、業務上、既に6年ほどAgile開発プロセスのプラクティスを各プロジェクトで使っているのですが、そうした視点で見ても本場TPSのExtremeさには、目から鱗がボロボロです。
後半のパネルでもそうだったのですが、「やるときには妥協なく、過去のデータを下敷きにして徹底的にやる、しかし一方で、人のつながりがビジネスを進めている、ということを忘れてはならぬ」という一点へ、軸足を必ずしっかりと置いている点は、常に目指すべき方向性でありたいと思います。
もう一点、今回はSCMに関して、SubversionとPerforceの2つのセッションがあったので、共に参加しました。
Subversionに関しては長期に使っているのですが、もう少し merge管理を上手く扱ってくれないかな、という点に期待しています。今は log メッセージで管理していますが、「このchangeset は、明示的に、以後の merge 対象から外したい」などの処理がやりにくいの
も事実です。この点でSubversionの1.5系に期待はしていますが、他に方法はないかな、と。
この疑問に対し、デブサミ名物である AskTheSpeaker で、幸いにも、講演者である
株式会社 ヌーラボの縣さんにお伺いすることができましたが、やはり、縣さんも merge 情報に関しては、log メッセージで管理されているということで、1.5系のmerge-infoに期待、とのことでした。やっぱり同じところに行き着くのですね(って、当たり前か)。
Perforceは今回初めて見ることが出来たのですが、さすが商用だけあって各種機能が充実しているな、と感じました。画像データをリビジョン毎にサムネイル表示できる点や、merge 状況をグラフィカルに表示できる点などには、心が揺れます。Google が perforce を使っているのは、この為なのかなぁ? FreeBSD チームも merge が交錯するtask branch では、Perforce を使っているとのことですし。
今回残念だったのは、個人的に興味ひかれた幾つかのセッションが同時間帯に開催されてしまったこと。例えば、Joel と、平鍋さんと前田さんのセッションがかぶったり、片山さんと青木さんがかぶったり、Agileパネルと、言語セッションがかぶったり...。むー、悔しい。
デブサミは、優秀なコミュニティメンバ参加のお陰で、無料とは思えないほど、充実したセッションを受講することが出来ます。ぜひ、来年以降も続けていただきたいな、と思いました。
登録:
投稿 (Atom)