GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。

作者 Vinay Aggarwal , 翻訳者 佐々木 由也 投稿日 2010年3月9日
どの本もアジャイルのコーチやファシリィテーターの役割は語っているが、マネージャーの役割について語っていません。この記事では最初に一般的に産業界でのプロジェクトマネージャーの役割について説明し、それからアジャイルにおけるコーチ/ファシリィテーターの役割について述べていこうと思います。この議論の中でコーチ/ファシリィテーターの意味の範囲を広げていくつもりです。
アジャイルにおけるプロジェクトマネージャーについて論じる前に、まずどんな業界でもなぜマネージャーが必要なのか検証してみましょう。
人間の心に働きかけるというのは大変複雑なことです。 世界中で同じように物事を考える脳は二つとありません。 同じ指紋がけっしてないように、二人の人間が働くスタイルは90パーセントであっても合致しません。このように多くの個々の人間を作り出し、しかも全て違うという自然の摂理は美しいとさえ感じます。しかしビジネスであh目標は全利害関係者にとって “一つであり同じ”なのです。 ここでいう人々とは (a)プロジェクトチームメンバー(b)ビジネスユーザー (c)経営陣及び出資者など様々な立場でプロジェクトに係わる人を意味します。人々はどのプロジェクトでも管理されることが必要なのです。 というのは
もしプロジェクトの誰もが完璧であれば、どの業界のどんなプロジェクトも失敗することはないでしょう。ウォーターフォールやアジャイルといったソフトウェア開発方法論も不要になります。完璧な人々はいずれにしてもプロジェクトを完璧に仕上げるのですから。
生活の中で普遍の物は変化である。具体的なもの(例えば要求)であっても漠然としたもの(例えば人間)であっても全て変化します。
このような状況下でのマネージャーの役割は以下のとおりです。
プロジェクトマネージャーはかなりの範囲で、コミュニケーションを管理しなければなりません。彼(あるいは彼女)はそのコツをつかんだ時、他のチームメンバーにその責任を託すことになります。
マネージャーは結果に焦点をあてプロセスを心配しすぎないということが期待されます。 “プロセスは私たちのために存在するのであって、私たちはプロセスのために存在するのではありません” –その意味はプロセスに沿うのが最終目標ではなく、結果を出すための道具にすぎないということです。 プロジェクトにとってプロセスのどの部分が一番良いかチーム全体をみてマネージャーはそのひとつを試みるべきなのです。
無規律につながり、プロジェクトに逆の効果を与えるようなどのようなプロセスへの妨害に対しても、マネージャーは間に入り、全ての良いプラクティスのために、規律順守を確実にする。
上の5つの理由が間違っていたとしたらどの業界でもマネージャーは必要ではありません。しかしこの5つは残念ながらどの業界、どの会社、どのプロジェクト、どのスプリントにも存在しています。投資家と株主はどのプロジェクトに於いても投資(RoI投資収益率)でよい結果を出さねばなりません。よってプロジェクトのビジネス目的達成のためこれらのことについてバランスをとれる人が必要です。前述の5つのは本来は技術ではなく管理業務でうまく対処するようになっています。この役割を果たしプロジェクト内で管理業務を行う人がビジネスの世界で「マネージャー」と呼ばれるのです。しかしマネージャーが前述のことを「完璧に」行うことができるような魔法の薬があるわけではなく、メンバーがプロセスに於いて調子を合わせ、観察し、水平思考のマネジメントの概念を当てはめていくことを助ければいいのです。そうすれば前述の5つが、ビジネス目標に大きな影響を与えることなく創造的なソリューションを見つけることができます。この役割りの小セットをアジャイルの言葉でコーチ/ファシリィテーターと表現されます。
アジャイルは‘自己組織化チーム'という新しい言葉を作り出しました。私は個人的に自己組織化チームの大ファンです。人々が公の場面で高い基準の責任感や義務感を表す文化圏では特に何度もうまくいきました。 これはおそらく人々がこれらの高い基準をオフィスにも持ち込み、‘自己管理チーム' とよく合うからだと思います。それぞれの従業員が自己管理モードで働くというのは全ての企業にとっての夢です。しかし全ての人間は異なっており、唯一無二の存在なのでだれもが ‘自己管理'チームに適合するというわけではありません。例えばどの医師でも外科医や歯科医整形外科医になれるわけではありませんが、どの医師も社会にとって有用なのです。同様に誰もが‘自己管理方式 'で働くことを期待するのは不可能です。しかしその同じ人たち(自己管理という定義に適合しない人たち)はまた異なったな扱いを受ければすばらしい貢献をするのです。これこそプロジェクトマネージャーが少しあるいはかなり(個人によって違うのですが)監督すれば大変有用になり、チームメンバーから最高の仕事を引き出すことができるのです。アジャイルはこの種の役割 ‘コーチ/ファシリィテーター' と言う言葉を使います。もう一度述べますが、これは人が自己管理から少しそれたときにうまく作用します。 以下の3つの筋書きでコーチ/ファシリィテーターは彼らの領域を広げることになるかもしれません。
ここでの私の意図は全ての職業人を広く受け入れるべきだと言うことです。しかし、扱い方及びその個人から最良なものを得ることは、人によって異なります。そもそも誰にでも適用できる大雑把なルールなどありません。これこそ企業が内省する余地のある点です。どの国に於いても貢献度は高いけれど、自己管理できていない技術屋さんたちはいます。そこでコーチ/ファシリィテーターがプロジェクトマネージャーとして役割が期待されるのです。彼らは間違いをしたり、指導・監督が必要だったり、ソフト面でのスキルが不足したりしているかもしれません。限られた範囲のコーチ/ファシリィテーターの範囲の中でこれらの人たちをアジャイルで一列に並べ仕事をなしとげさせることは悪夢のようなことかもしれません。私は全てのタイプの人に対し十分尊敬の念を持ち、彼らが大変大きな貢献をすると信じています。しかしそのためにはコーチする範囲の幅を広げ彼らに対して強く「していいこと」と「よくないこと」をきっぱりと言う権限を持たなければなりません。そこでプロジェクトマネージャーの役割が役立つのです。以下の表はプロジェクトマネージャーが必要と感じられる他の分野について示しています。
|
項番 |
現実t |
アジャイルがどのように手助けするか |
アジャイルが手助けできない点 (マネージャーが手助けする!) |
注記 |
|
1 |
人は完璧ではない< |
日々の状況に焦点を合わせるようまたプロダクトマネージャー(PO)はその要件をビジネスと調整する。 |
1. 焦点は正しい方向なのか? |
既成概念にとらわれないマネージャーは不完全さを調整する刷新的な方法を考え出す。 コーチは正しい方法で物事をどう行うか説明する、しかし人々が従わなかったら? 例:デモの後プロダクトオーナーからフィードバックが得られなかった場合。受理されるのか、施行されるのか? |
|
2 |
変化を管理する |
アジャイルはそれぞれのスプリントの初めに新しい要件を歓迎している。スクラムマスターはスコープがスプリントの期間内に入り込むことを防ぐ。. |
1.スクラムマスターは役割を適切に果たしているのか? |
アジャイルは要件の優先順位(それは一面にすぎないのだが)に従い変化に対処する. プロダクトオーナー(PO)は影響力を行使し、スプリントの途中であってもストーリーを付け加えることができるが、もしチームがどう対処して良いのか知らなかったら? 実体のない変化はどんな方法によっても述べられることはできない |
|
3 |
不相応なコミュニケーション |
アジャイルでは毎日立ってコミュニケーションする機会を与えています。回想の時間には気持ちを話す場を設けている。 . |
1.チームに障害が生じたら? |
企業内でのコミュニケーションは大変違ったテーマであり、プログラムについて熟知するのはまた非常に困難である。 マネジメントの研究ではコミュニケーションのすべについて説明している。 ソフト面のスキルについてはどのプロセスに於いても言及されない。 |
|
4 |
プロセスは完璧ではない。 |
ソフトウェアー開発に関してアジャイルの手助け |
どの方法論も制限があり、結局のところプロジェクトを成功させるのは人である。 |
良くないアジャイルでもないよりはマシである。 |
|
5 |
適切にに遂行されなかったプロセス |
アジャイルはその実行は人に依存するプロセスである。 |
1. 人はプロセスに従っているか? |
小さな例 - アジャャイルに於いてチームは過度のペアプログラミングをおこなっていないか? |
もし物事がうまくいかなければプロジェクトマネージャーはコーチ/ファシリィテーターとしての役割を広げることができます。彼(あるいは彼女)は本質的にアジャイルではない(あるいは意図的にそうではない)チームメンバーをコントロールすることができます。次にこの業界で流布している3つの共通の通説(そう思われているが実際は違う)について述べます。これらの通説はアジャイルの背景で特に目立ってそうであるように思います。
通説#1: マネージャーには魔法の薬がある。
現実: 人間の心に取り組むのは大変複雑で難しい事です。科学ではなく、単に「術」があるのみです。あなたが何をしようと、そこには管理不能な人たちがいて、コントロール不能な変化があるのです。私のささやかな意見ですが、良いマネージャーとは
上述の数字に関しては私の経験からの印象であり、科学的実験や研究に基づくものでないことに注意ください。
マネージャーはまたまた人間であり、他の人と同様不完全です。マネジメントは全体論的なアプローチとはコンセプトが違うのです。それとは違った仕事で不完全ながらも人々とプロセスを管理する全体に係わる仕事なのです。豊富な経験とこのテーマについての学習をした人が価値ある物をもたらすことができます。
通説#2:マネージャーは常に自由に制限を加える。
現実: 意地悪なマネージャーにとっては本当かもしれない。しかし、現実はよいマネージャーは実績を上げる環境を作り出す、それによって人々からベストな物を引き出すものです。経験豊富で洞察力のあるマネージャーはチームの自由を一時的に奪うかもれないが、それは結局ただ人々を助けるという目的のためです。時に人々はあまり遠くを思い描くことはできません。その理由として(a)経験不足 (b)大変心地よい圏内で働いているため (c)傲慢の影響で洞察力がなくなってきている(d) 他の表せない理由などが考えられます。
通説3::マネージャーは権限を持つべきではない。
現実: 国や文化によっては最初から公共の場での責任感と義務感をたたき込んでいます。このような場合権限は不必要であり、そのような環境ではコーチ/ファシリィテーターは問題をかかえることはありません。しかし未だに開発途上で成熟したレベルまで達していない国では権限というコンセプトは意味合いをもちます。前述の5つの理由(この記事の最初に述べられている)をコントロールするためこのような状況ではマネージャーは権限を持つ必要があります。権限を持たないマネージャーとは燃料のない車のような物です。研究によると心理学的に言って人間の心(特に大人の場合)は堅い鉄のような物で曲げることは非常に難しいということです。この鉄を美しい容器に形づけるため、権限が必要となるのです。その時、自己管理方式により世界は勤勉になり、責任感を持ち、成熟し、高性能になり、世界中のマネジメント研究所は閉鎖を迎えるでしょう。
アジャルは、従来のウォーターフォールのプロセスの欠点を解決するとてもよくできたソフトウェアー開発方法です。しかしアジャルはプロジェクト成功の切り札ではありません。働いて業務実行するのは同じ人間なのです。人間ということになると取り扱うのは困難を伴います。この世界(従って人間)には問題や不完全さが満ちあふれています。科学者は技術革新することにより社会の助けとなろうと思っています。同様に制約の中で働きながら人々がビジネス目標やプロとしての目標に成功するのを助けるのがマネージャーの仕事です。完璧な人たちによって職務遂行されない限りはマネージャーが不要になるような方法論はありません。プロセスは1つの指針です。プロセスがあればこそそこからの逸脱があり、人々がいるところには問題が生じます。人々と問題を管理し、逸脱と変化をコントロールするためにどのプロジェクトもマネジメント業の助けが必要です。同時にマネージャーもまた人間なのです。彼らも不完全から成り立つ同じ世界に属しています。ある決定が失敗することもあるでしょう。利害関係者たちはその失敗も受け入れねばなりません。ある状況下で、マネージャーはプロジェクト利益の観点からある対策に取り組むために権限も必要になるかもしれません。この対策はチームメンバー間で抵抗を生むかもしれません。だから対策を適用するために、時にはコーチ/ファシリィテーター制度がうまくはたらくかもしれないし、また、別の背景では権限を持ったマネージャーがうまくはたらくかもしれません。
Vinay Aggarwal氏 はインドXebia IT Architectsのデリバリーマネージャーです。彼はIT業界では11年の経験を持っており、エンジニアリングで 学士号を保有しています。PMIが資格を与えたプロジェクトマネージャー(PMP)であり、スクラムマネージャー(SCM)有資格者でもあります。彼は過去にIBMやAccentureといった企業での勤務経験もあります。 またウォーターフォールやアジャル(スクラム)などの方法論でのすばらしい経験もあります。水平思考を信じており、様々なデリバリーの問題に対処するためそれをマネジメントコンセプトに適用しています。
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信