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

作者 Roger Brown , 翻訳者 馬場 彩子 投稿日 2010年7月28日
現代の仕事をこなしていくにはマルチタスクで進めていくしかない。従業員は如何に複数の業務を並行して進められるかにより評価される。ITのプロは定常的に複数のプロジェクトにアサインされる。昔からそうだったのだろうか?マルチタスクは本当に機能しているのだろうか? 実際にマルチタスクによる影響はないのか?他のやり方はないのか?
シングルタスクは、われわれがマルチタスク以前にソフトウェア業界でどのように働いていたか表現するために生まれた言葉である。ここでは、マルチタスクとは "複数プロジェクトに従事する"ことを示している。現在はそのようなことをマルチタスクとよび、より効率的成果を出すための戦略と位置付けている。また日常でも、仕事でも仕事以外でも、小さなスケールでわれわれはマルチタスクを実行している。どのようにマルチタスクをこなし、我々がどのような影響を受けるか、ということに関してはタスクの規模によらずいろいろな共通点がある。
新しいオーディエンスとしてアジャイル(またはスクラム)のストーリに参加した場合、もしメンバがチームの仕事にフルタイムで専念できたらチームはもっともっと良くなるという、巨大で厄介な障壁に悩まされることがある。よくあることだ。我々は特別な問題、特に危機的な状況を取り扱うため、 "専門家チーム" や "スワットチーム"として召集される。けれども我々の組織は、独立して業務を遂行することができるスキルを持った人の集まり、というモデルを好むようになり、メンバは複数のプロジェクトに同時にアサインされる。今では、多くのことをいっぺんに実行することがデファクトソリューションになってしまった。これが"乏しいリソース"を最も効率的な使う方法と考えられている。つまり、なんでもこなせるスペシャリストを、少人数(少したりないくらい)でチーム編成するのである。
アジャイルモデルはこれを覆した。 我々は一定時間それぞれの小さな課題に集中できるようチームを構成した。仕事を創造し人をそちらに動かす代わりに、チームをつくりそのチームに仕事を割り当てることにした。そして、仕事を押しつける代わりにチームをその仕事に引っ張りあげたのだ。
変更は困難だった。物事を違うやり方でやるには明確な目的、利益へのビジョンや度胸が必要である。よって抵抗は自然なことであった。人々は変化を不安に感じた。もしリーン方式の考え方にシフトすることができたら、目的を定義し利益を見込み改善のための最初の一歩を踏み出すために、"人々への信頼" と "継続的システムの改善"という2つのアイディアを活用することができるであろう。ほとんどの人々は "リーン"を知っていて、どうしたら今やっていることをもっとよくできるか考えている。 それに、リーンでは 何か価値が低いことをやめたら、完全に無駄を削除するができる、と言っている。
一つ以上のプロジェクトに従事している人は、ひとつのプロジェクトから別のプロジェクトに移るとき、その都度コストが発生している。主なコストは仕事内容を変更するのに必要な時間である。我々は電話などの単純な割り込みが発生した場合、そこから復帰するのに15分程度必要であることを知っている[1]。タスクがもっと複雑であれば、切り替えるのにもっと時間がかかる[2]。
もし2つ以上のプロジェクトに従事しているならばそのコストはより大きくなるだろう。一方のプロジェクトで長く働くと、離れていたプロジェクトを思い出すのにひどく苦労する。あるいは、頻繁にプロジェクトを行き来しているのであれば、仕事内容の切り替え時間が労働時間の大部分を占めることになるだろう。
小さなタスクを切り替えながら作業をする方が若干効率が上がるという研究もある[3]。短期間では右脳、左脳それぞれの機能と関係して効率が上がることもある。確かに我々は2つの独立したタスクを並行して処理できる。ただより大きな切り替えを行うには、切り替えによるコストを計算しておく必要があるだろう。Jerry Weinberg氏[4] は、それぞれのタスクが10%程度不利益な条件を持っていた場合、仕事内容の切り替えコスト発生することを示した。そして現実にはコストは想定より高くつく。

図 1
チームの一員である場合、伝統的な疎結合のプロジェクトチームであれ、ミッションに特化したアジャイルチームであれ、そこには切り替えによる複合的なコストが存在する。もしチームメンバがチームに関係ない仕事をするためにチームを離れた場合、チームはメンバの欠員を埋めなければならない。離れていたメンバが戻ってきたら、チームはその間の開発に追いつき復帰できるよう、メンバを手助けすることに時間を費やすだろう。
でもちょっとまって、と思うかもしれない。アジャイルチームとは機能を横断して存在するものだし、毎日、要求の詳述や分析、設計、テストとコーディング、などさまざまなアクティビティを絶え間なくこなしていくものではないか、と。これはマルチタスクと言わないのか?答えは「仕事内容の範囲による」である。各作業対象や技術間に大きなギャップがあると切り替え時間は長くなる。切り替わりの内容が小さければ脳は効率的に働く。またチームに焦点をあてると、すべての日々のアクティビティは、狭い範囲の機能や技術に絞られているのである。一度にほんの数個のストーリのみとりかかるのだ。こなすアクティビティの幅は広いかもしれないが仕事内容は限定されている。さらに、アジャイルは集中するためのいろいろなデバイスを持っている。– 協調、タスクボード、自動テスト、振り返りなどである。逆に仕事内容が大きく変わる場合はトラブルの元になる。 – プロジェクト, 協力者、ステークホルダなどが変わる場合である。
人間の脳は、その内部では効率的にマルチタスクを実行している。1日中マルチタスクで処理しているのである。夜でもそうしている。脳のいろいろな箇所が協調して、あるいは単独で常に動作しているのである。それでもこの脳のマルチタスクを複雑な環境で機能させることはできない。脳のマルチタスクのほとんどは無意識で実行されているからである。 – 感知した入力のフィルタリング、関連する情報の統合、短期記憶から長期記憶へのデータの移動しつつ、 心臓や肺を動かし続ける、というように。
そして、脳の外部でも我々はのマルチタスクで実行している– 道を確かめ交通情報に耳を傾けながら車を運転したり、夕飯を食べながら電話で話したり、庭で草むしりをしながらしながら休暇の予定を立てたりする。このような、洗濯物を畳んだり、散歩に行ったりするタスクは機械的に実行可能なのでタスクを切り替えるコストは発生しないだろう。また、資料を見ながらキーボートを打ったりメソッドをリネームしたり、ということも機械的にされてきたことである。しかし、ソフトウェア開発の仕事はそれほど単純ではない。自動的なマルチタスクのほとんどはよく機能する。けれども限界はある。[5]
日常よく行われる複数プロジェクトへのアサインによる仕事の切り替えは精神に「再仕事」する感覚を潜在的に作り出すことになる。人間の脳の記憶方法は2種類ある。– 短期記憶 (ワーキングメモリ) と長期記憶である。 そしてこの2種類の記憶の間を情報を移動させる機能を持っている。ただし、すべての情報がそれぞれの記憶領域に移動されること、取り出したときとまったく同じ情報が移動先の領域に保存される、という保証はない。我々は記憶を再生するたびに常に編集している。新しい情報は長期記憶に移動される間、短期記憶に属する。例えば、試験前の一夜漬けでいい点は取れるかもしれないが、2週間後にはそのほんの少しのことしか覚えていないだろう。それは、切り替える前に取り組んでいた最後の情報を脳に持ち続けつことができなかったからである。プロジェクトに話を戻すと、つまりこれが皆が知りたがっている答えなのである。
いろいろな研究でマルチタスクは非効率で、害があるということが示されている。例えば:
どのようにしたら、アジャイルを実践しながら個々がマルチタスクで実行する量を減らすことができるだろうか?我々は以前よりさまざまなアプローチについて言及してきた。物理的な環境を整えれば整えるほど、脳の多くの部分がそれに従事し、情報をより早く、より完全に統合するようになる。仕事の焦点を絞ろうと試みることにより、仕事のスコープはより狭くなる。人間の相互作用とその相互作用をファシリテートするスクラムマスターは的を絞った状態を保つよう働きかけるべきである。
いくつかの現代の技術的な実践は的を絞って実行する手助けとなる。例えば:
マルチタスクに関する議論は長い間されてきている。しかし現代の会社の文化では、人員"リソース"を最大現効率的に使用するための手段として、このような "ロードバランシング"の形が習慣化している。我々はチームを召集する場合、それぞれがあまり密に協調することなく、それぞれのスキルを提供し、一度に複数のことを実行しながら、パートタイムでで働く。 パートタイムのメンバで高いパフォーマンスを生むチームを作ることができるか? あるいは、いつも皆が忙しそうに見えることの方が重要、だろうか?
学ぶときに一番難しいのは、現状の振る舞いを捨てるということである。これは個人よりも、組織の方が顕著である。今しているやり方を、もっと効率がいいだろうと思う方法に変えるのは、精神的に急激な変化になるので実施するのが困難だ。そこで、変化を受け入れやすくするために、シンプルな図を示そう。この図はわかりやすいだけでなく、経済的な意義もよく示している。
図2で示しているのは、4人の人が3つの短いプロジェクトで働くシナリオである。このような動きは人やプロジェクトが増えても変わらない。最初のシナリオで人々はマルチタスクで4つのプロジェクトで働いている。

図 2: マルチタスクで働く場合
図3は第2のシナリオを示す。同じ人々が同じひとつのチームを構成し、個々のプロジェクトを順番に完成させていった場合である。このシナリオはチーム構成や仕事の切り替えの数を減らしても生産性の向上は見られないというとても保守的な仮定に基づいている。注目してほしいのは、プロジェクト完了日である。すべてのプロジェクトが完了する日は両シナリオで同じである。しかし、図3のシナリオでは3つのうち2つのプロジェクトは早く完了しているのである。この結果がもたらす経済的効果は容易に想像できるであろう。

図 3: プロジェクトを順番に実施するようチームを構成した場合
仕事の切り替えとチーム協調による生産性のささやかな向上を考慮にいれた場合、図4であらわされるように、3つのプロジェクト全体でももう少し早く完了する。

図4: チームが協調しシングルタスクで実行したため工数が短くなった場合
Johanna Rothman 氏は "プロジェクト・ポートフォリオ管理"の中でこのテーマに関してより詳細に論じている
以上により、マルチタスクは明白に非効率で決して実施してはいけない、ということをおわかりいただけただろうか?ならば、"変化は人生のスパイス"という考え方とはどう向き合ったらいいのだろうか? 脳科学では目新しいものは魅力的に見える、という研究結果がある – 新奇性はドーパミンという神経伝達物質を放出する。ドーパミンはそれをもっともっとほしいと促す効果がある[11]。よって、質問の答えは「活動の焦点と範囲による」である。もし仕事内容の切り替わりが大きい場合、マルチタスクは個人とその仲間に犠牲を強いることになる。切り替えが小さければ、考える通りに仕事はうまくいくだろう。アジャイルチームで働いていれば、互いから学び完成や成功によりドーパミンとは違う心地よい神経伝達物質を放出しながら、我々は十分に目新しいことに出会うことができる。
プロジェクト間の仕事の切り替えは、組織の工数とコストを消費する。多くプロジェクト、より複雑なプロジェクトにかかわれば、その分コストも高くなる。長期的には、同時期にはひとつの事に焦点を合わせることにより、個々人は効率的に仕事をすることができる。プロジェクトは順番に片付けているようにチームを構成すれば、切り替えコストを減らし、チームの相互作用により多くの利益を得ることができる。
[1] 速度を落とせ、マルチタスクに立ち向かえ、そして運転中にこれを読むな
[3] マルチタスクへの動機: どのように脳は一度に2つのタスクを記憶するのか (Scientific American).
[4] Weinberg, G.M. ソフトウェア品質管理: Vol. 1 システム思考 New York. Dorset House, 1992.
[5] 運転しながら携帯電話で話した場合に何が起こるのか簡単に説明している"Hang up and Drive" (書籍 "Brain Rules"からの動画) を見よ:
[8] マルチタスクのとんでもない間違い (Psychology Today)
[9] 速度を落とせ、マルチタスクに立ち向かえ、そして運転中にこれを読むな
[10] "仕事脳", David Rock
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
スレッド表示 返信