BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 人員を増やさず,より多くのソフトウェアを提供するには

人員を増やさず,より多くのソフトウェアを提供するには

ブックマーク

原文(投稿日:2014/06/26)へのリンク

ソフトウェア製品やサービスに対するニーズの増加に伴って,企業の開発能力を向上させるための方法が求められている。多くの企業が選択するのは,人員の追加によるスケールアップだ。このアプローチに対して一部の人々が疑問を持ち,人員を増やすことなく,より多くのソフトウェアを提供する方法を提案している。

Robert Martin氏は"Horders of Novices (初心者の集団)"というブログ記事で,少数の専門家チームによるソフトウェア開発を提案する。

これ以上,初心者を増やす必要があるのですか? 大して能力のない連中をさらに投入したところで,優れたソフトウェアが早く開発できるものでしょうか? ソフトウェアの問題は,本当にマンパワーだけの問題なのですか? コーディングはレンガ工事と同じなのですか? 左官工の数が多ければ多くのレンガを積めるように,コーダが多数いれば,コードも多く書けるでしょう – でも私たちは,大量のコードが欲しいのでしょうか? 少ない方がよいのではないですか? より多くのことを行う,より少ないコード。非常に少ないコードを高品質に書いて,もっともっと,たくさんのことができる方がよいのでは?

そして氏は,自身が飛行機の操縦を学んでいる方法について説明する。最初のレッスンでインストラクタが一瞬だけ,氏に操縦桿を明け渡してくれた後は,書籍で勉強して,地上でスクールレッスンに参加し,宿題を行っている。氏が飛行機の近くにいる時,インストラクタはいつもその近くで飛行機の扱い方を説明し,氏がそれをどのように行うかをチェックした上で,航空日誌にサインする。ソフトウェア開発者にも,これと同じようなアプローチが取れないものだろうか – そう考えた氏は,トレーニングやメンタリングにもっと重点を置くべきだと提案している。

私たちの業界で行われていることは,ソフトウェア開発志望者たちを無償で飛行機に乗せてパイロットと称し,何千人も飛行機に投げ入れた上で,彼らがクラッシュし,炎上するのを黙って見ているのに等しいのではないでしょうか? その証拠にはかなりの説得力があります。クラッシュや炎上は日常茶飯事ですから。航空日誌に誰もサインしていないからなのでしょうか? 彼らが本当のパイロットとしての訓練を受けていないからでしょうか?

"unscaling agaile (スケールしないアジャイル)"というブログ記事でPawel Brodzinski氏は,スケールアップ戦略が疑問視されることはめったにない,と述べている。

(...) まるで疑問の余地のないパラダイムであるかのように,それに反することを決めた人は,すべての人たちからエイリアンとして見られてしまうのです。時として私には,組織全体にアジャイルやリーンを導入する巨大プログラムのロールアウトが,大企業のための唯一のものであったように思われるのです。

そして氏は,アジャイルをスケールアップせずに,小さなチームのままで作業可能にするためのアプローチをいくつか提案する。

ひとつはスカンクワークス(秘密プロジェクト)です。その基本的なアイデアは,他の組織から高い独立性を持って運営されるグループを社内に作る,というものです。これにより,広範なコンテキストでは実行が難しいことを何度も試行できる機会が得られると同時に,極めて小スケールの作業環境を作り出すことができます。

巨大組織にリーンスタートアップを適用する場合でも,方針としてはこれと同じです。製品開発戦略の上に,小規模での運用が可能な,自立した作業環境を作り出すのです。

作業の一部をアウトソースするパートナを探そうと決めたのであれば,アプローチはこれとはまったく違います。このような状況でも,コンテキストのスケールダウン自体は難しいことではありません。問題なのは,正しい価値観を持って適切な行動を行うことのできるパートナを見つけ出すことです。しかしながらここにおいても,スケールアップしない戦略を適用することが可能かも知れません。

Janet Choi氏は,"The Science Behind Why Small Teams Work More Productively (小チームが生産性に優れていることの科学的根拠)"という内容のブログ記事を書いている。その中で氏は,チームの増員にはいくつかの問題点があると言う。

何か事をなすために人が結集したグループにおいて,人数が増加すれば,すべてのものが増加します – よいものはもっと素晴らしく,悪いものは最悪になるのです。人員増はリソースプールを拡大しますが,一方で,その調整や管理に必要な作業量も大きくなります。それがある一点に達したとき,人数の多さが障害へと変わるのです。

さらに氏は,大規模なチームで個人の効率性が損なわれる理由として,個人間の連絡性の喪失を挙げている。

チームが大きくなればなるほど,個人間の関連性が失われ,受けられるサポートの範囲も小さくなります。これには精神的なサポート,作業進行や障害克服に対する支援,問題解決を支援する情報サポートなどが含まれます。あなたの最悪の週日を思い浮かべてください – もしも寄り掛かるべき肩や,苦境からの脱出を手助けしてくれる人がいないとすれば,それがさらに,どれほど困難になったことでしょう。

規模に関わる問題に対処するために氏は,大規模なチームをあたかも小チームのように運用する方法を示してみせている。それは次のようなアイデアだ。

チームが小さく感じられるようにする: 同僚たちと親しくなって,お互いをもっと知るようになってください。休日のパーティやハッピーアワーなどは,つまらないイベントに思えるかも知れません。ですが仕事上の外出や出張でも,打ち解けて楽しい時間を過ごすことは可能です。

根本から透明になる: 透明性は"社会的怠惰(social loafing)"や"ただ乗り(free riding)",あるいは"権力行使(power play)"といった行為を防ぐ役割をします。社会的怠惰やただ乗りは,隠ぺいできる場所が存在するという事実に基づくものですし,権力の行使は,情報の守銭奴とも言えるような知識隠匿に基づくものだからです。

頻繁なフィードバックを相互に行う: フィードバックを年2回の指導的行事として孤立させないことです。意欲の損失を通して群衆に飲み込まれていくような,各個人の努力とパフォーマンスの間の結び付きを強固なものにするためにも,会話がグループ全員の間を流れるようにしてください。

"Scaling Down Agile: The perfect Agile setup"と題したブログ記事では,筆者のErwin van der Koogh氏が,自身の考える"理想的なチームソリューション"として,小チームで作業する方法を提案している。

タスクではなく,問題を与えてください (...) 問題を解決する上で,彼らの創造性を発揮させることが簡単にできるはずです。このような自立性を持った問題解決は,メンバの意欲と熱意を引き出す上で最良の方法でもあります。

必要な人材がチームに揃っているようにします (...) 問題を真に理解する,ユーザや利害関係者と対話する,データを解析する,ユーザエクスペリエンスをデザインするといったことは,氷山の一角に過ぎません。

必要なリソースをチームに提供するのです。

チームに実験をさせてください (...) もっともリスクの低い方法は,利害関係者やユーザ,顧客を参加させることです。

2週間のイテレーションが支えになります (...) ツールはすべてありますし,ほとんどは無償です。これらを使えば毎日,あるいはそれ以上の頻度でのリリースも可能になります。

この記事に星をつける

おすすめ度
スタイル

BT