BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース モビングの科学を理解する

モビングの科学を理解する

ブックマーク

原文(投稿日:2016/05/31)へのリンク

モブプログラミングについて話したり,使ったりしている人の数は決して多くない。それでも彼らの体験は,コーディングやテストに関する多様化という観点において,非常に価値のあるものだ。

Llewellyn Falco氏は初のMob Programming Conferenceで,モブプログラミングについて,“Understanding the Science of Mobbing”と題する基調講演を行なった。同カンファレンスは2016年の5月1日と2日,マサチューセッツ州ケンブリッジで開催されたもので,そのイベントの様子についてはInfoQでもQ&Aですでに紹介している。

氏によれば,モブプログラミングは科学ではない – そもそもコンピュータサイエンス自体が,かろうじて科学と呼べる程度のものなのだ。そうではあるが,チームによるソフトウェア開発の方法に関しては,いくつかの共通的なプラクティスも存在する。

  • ソロプログラミングは今日最も一般的な方法で,よいコードも悪いコードも,すべてが受け入れられる。
  • ペアプログラミングはその次に知られている手法であり,ふたりの考えがコードになるという意味で,より優れたアイデアだ
  • モブプログラミングはおそらく,最も認知度の低い開発方法であると同時に,氏の意見では - 万人向けではないが,最も優れた方法だ。

どこに科学があるのか?氏はシステム理論にその一線を引く - チームはシステムであり,複雑である。ひとつの部分を分離することは難しい。Dan North氏の言う,“拍手する時の片手の音はどれか?”という質問と同じだ。

システムで何かを始めるというのは,キャンプファイアに点火するようなものだ。孤立したプログラマのチームならば,作業に行き詰まれば,いかに優秀なプログラマであろうとも(ほとんどの場合は)行き詰まったままだ。アイデアを膨らませるには理解者が,それも多くの理解者が必要なのだ。モブの価値はそこにある – 与えられた閃きを共に拡げようとする,多くの人々が存在することだ。さらに氏は別の言い方として,ドラマDr.House(あるいはSillicon Valleyシーズン1の最終話)とまったく逆だ,とも述べている。ひとりが閃くかアイデアを打ち上げて,他のメンバはそれをより良いものにするために貢献する,というのだ。この影響は学習とグループ学習においても同じである。グループ学習は個人学習より効果が高く,モブはマルチメモリを喚起できるのだ。これは問題解決と同じことだ – 人には,Tekeuchi氏とNonaka氏が“多様性(diversity)”と呼ぶものを選択するシステム状態がある。多様性は,物事がうまく運ばない時に有用だ。

氏は次のような,明らかに簡単な質問をする。

チームをどうやって作り上げるのか?

氏の答には,2つの前提条件がある。

·       モブでは,アイデアの出所がどこかは分からない。大きな問題ではないからだ。対照的に我々は,常に生存のバイアスに悩まされている – ある成功条件に注目するものがいれば,その逆が必要と考えるものがいる,という状況だ。例えば,上級幹部のアイデアは一般的に優れていると言われる。実際に使用されているからだ。しかしながら,ほとんどの場合,特に会議においては,これはアイデアそれ自体とは何の関係もない。要するにHiPPO(訳注:上司や上役の意見)なのだ – 上役はチームに話はするが,仕事はしない。成功のメカニズムはそうではない。はっきり言えば,プロジェクトが成功を収めれば,それは上役のアイデアのおかげであり,失敗したならば,それはチームの責任なのだ。

·       氏はここから,もうひとつの効果に関する説明を行なう – ベンジャミン・フランクリン効果である。自分が人々に対して親切で優しく,礼儀正しいと思うならば,そうではない - あなたが親切で優しく,礼儀正しくするのは,あなたが好きな人たちなのだ。

従って,先程の簡単な質問に対する完全な答は,

チームとして行動することによって。[...] あなたという人物は,あなたが付き合った人たちの集大成なのだ。

これは我々がヒューマニズムに立ち返る部分だ - チームが単なる烏合の衆以上の存在であり,我々が 単なる仲間以上の存在であるためには,我々は親切で,優しく,礼儀正しくなければならない。ここはまさに,例で示したリーン原則が有効になる部分だ。

氏が取り上げた最後のポイントは,技術的負債と技術資産の違いだ。負債のみを考えて資産を忘れるのはフェアではない(が,コスト削減に注目して価値の創造を忘れると,陥りがちな部分でもある)。

“10倍できる開発者”という神話を否定するのは難しい。それにしても,10倍できる開発者とはどのような人だろう?数学的な例についてはよく知らないが,10倍という数から期待する程のものではない,というのが氏の結論だ。10倍が遅く見えることも,あるいは超効率的に見えることもある。要は観点の問題なのだ。

この点をより具体的にするため,氏は,2つの変わった概念の違いについて紹介した。

  • 無限タスク – 例えば,ケーキを2つに切る作業を永遠に続けること。
  • 超タスク – 時間的に有限な無限タスク。2分でケーキを2つに切り,その半分の時間で残りを2つに切る。つまりケーキカットを,2分以内に終了させるのだ。

この点から,そして先程の上役の視点に立ち返れば,時間の1%を学習に投資することの是非を唱えるものは誰もいないはずだ。あるいは,もし大企業(あるいは古い企業)に務めているならば,10年間何も学ばないことがどういうものか,理解するチャンスがあるはずだ!

モブプログラミングに関する結論として,最も重要なのは文化である – 移行を達成するには,開放性と誘因がなくてはならない。これはまさに,氏の講演をミザナビーム(mise en abyme, 紋中紋)として引き継ぐものだ – カンファレンスには,この開放性と誘因の文化を備えたチームとして参加する必要がある。そうでなければ,あなたが新しい概念を持ち帰っても,チームの賛同は得られない(そしておそらくは,あなたを追い出す)だろう。

 
 

この記事を評価

関連性
形式
 
 

この記事に星をつける

おすすめ度
スタイル

BT