コミュニケーションと田舎暮らし
XP(Extreme Programming)では、コミュニケーション、シンプル、フィードバック、勇気の4つの価値(最近は尊重を加えた5つの価値)が根幹であると言われます。今回は、このうちコミュニケーションについて考えて見ます。
コミュニケーションはウォーターフォールモデルでの開発でも、仕様書がきちんと作成されなかったり、利害関係者に渡っていないと、無駄な開発が行われたり、必要なものが開発されない、重要なデシジョンを誤るなどの問題が生じます。しかし、ここではそのようないわばマスコミ的なコミュニケーションでなく、アジャイルソフトウェア開発に特有なコミュニケーションを考えてみたいと思います。
アジャイルソフトウェア開発におけるコミュニケーションの必要性は、田舎暮らしを考えると分かりやすいと思います。田舎では、ある特性を持つ地域に、少ない人間が住んでいて、特産品や郷土料理などを作り、お互いに協力し合って生きています。そんな田舎では、情報交換をうまくやらなければ生きていけません。
1.独特の問題・情報がある
あの山に雨が降ると川が増水する。XXに熊が出た。など、マスコミに流れないその土地特有の問題や情報があります。
2.熟練・知恵が必要
他所ではできない特産品を作るには、熟練工を育てなければなりません。口では簡単に伝えられない技術を作業を通して伝える必要があります。原材料が不作になるなど、これまでになかった問題には、知恵を出し合って解決します。
3.一人の問題が全体に影響する
お互いに協力しあって生活しているので、誰かが病気になればすぐに助けます。火事が出れば協力して消火します。そのような緊急の情報は地域全体に知らせる必要があります。
なんとなく、アジャイルと似ていませんか?
1.独特の問題・情報がある
業務に固有の問題があるので、オンサイト顧客(全員同席)によって、ユーザの情報をきちんと理解する必要があります。
2.熟練・知恵が必要
よく考えられたプログラムを開発するには、熟練者を育てなければなりません。ペアプログラミングによって技術を伝える必要があります。また、困難な問題が生じた場合には、二人で協力してアイデアを出します。
3.一人の問題が全体に影響する
計画ゲームを行い、全員で手分けして開発しますので、どこかに問題が生じると全員に影響します。日々の問題をスタンドアップミーティングで把握します。
このようにアジャイルのコミュニケーションは、田舎暮らしのコミュニケーションとそっくりです。コミュニケーションの重要性が、少し分かったような気になりませんか?
これを元に、アジャイルでない開発方法をとる条件を考えこともできます。以下が満たされていないといけません。
- 業務知識を形式知にできる。あるいは、手分けするには形式化が必要である
- 力技で解決できる程度の複雑さである。あるいは、効率よく分担することのほうが主たる問題である。
- 規模が大きいので、小さな問題は全体に影響しない。あるいは開発期間が長いので、問題が発覚してからでも対策が取れる
アジャイルのコミュニケーションを田舎暮らしのメタファで考えてみました。いかがでしょうか?
« Rubyの魔法と動く標的のためのアジャイル - XP祭り関西2006 - | トップページ | Firefox 2.0とfoxyproxy »
「日記・コラム・つぶやき」カテゴリの記事
- [Windows10]コア限定で古いソフトを動かす- Wave SplitterでLPのCD化 –(2021.05.05)
- イマドキのレコードプレーヤー SONY PS-LX310BT(2020.05.04)
- 答えだけを聞いて満足するな!(2018.06.03)
- SRA Advent Calendar 2016 に参加します(2016.11.20)
- セミオープンという選択肢!ヘッドホン PHILIPS Fidelio L2BO(2016.10.16)
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「プログラミング」カテゴリの記事
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 論理的に考え伝える – SEA関西「開発現場で役立つ論文の書き方のお話」 -(2021.05.09)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会(2019.01.27)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
この記事へのコメントは終了しました。
« Rubyの魔法と動く標的のためのアジャイル - XP祭り関西2006 - | トップページ | Firefox 2.0とfoxyproxy »
コメント