Archive for 7月, 2016

こちらの本を献本してもらい記述しています。

私は、本番サービスをAmazonのサーバを自分で管理する事はほぼない。
アプリ開発環境やデモ環境としてちょっと、使う程度である。
どうしても、AmazonのAPI(S3なんかは特に)で確認しないといけないからである。

しかし、いつもAmazonのコンソール画面とにらめっこしている自分でないので、
あの画面は非常にわかりにくいなーと思う。
種類が以上に多いのもそうだが、設定画面なども決してわかりやすいとは言えないと思う。

そのため、AWSのコンソール画面の説明をしながら、手順を記してくれるのは非常に助かる。
私は、「新米プログラマ」ではないが、AWSコンソール画面を使う時には実際助かった。

「プログラマのためのAWS入門」
ともいえる気がする。

自分たちのプロジェクトは、
「アジャイル型」にすべきか? もしくは 「ウォーターフォール型」にすべきか?
こんな事をたまに相談される。

そして、答えは「ウォーターフォール型」がとれるなら、絶対に、「ウォーターフォール型」だ。
なぜって、それは、「ウォーターフォール型」の方が、不確定要素が少ないからだ。

ただし、勘違いしないでほしい、「ウォーターフォール型」にすると不確定要素がすくなくなるわけではない。
不確定要素が圧倒的に少なく、計画可能なほど、十分に練られた、そして、実現可能性、人員確保、いろいろと計画できるので、「ウォーターフォール型」が採用できる。

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い
という記事もあるほど、ウォーターフォールモデルがたたかれている。

しかし、一方で、アジャイルはなぜ失敗するのか?という記事もよく見かける。
なぜアジャイル開発はうまくいかないのか 〜 Don’t just do agile. Be agile.

そもそも、ウォーターフォールというモデルがあるのに、新たなアジャイルという手法が必要なのか?

よく、言われるのが、「変化が可能」、「すべてを実装しない」などの用語が「アジャイル」にはよく見かける。
また、アジャイルを紹介しているサイトでは、以下に「ウォーターフォールモデル」がだめで、「アジャイルモデル」が優れているか?の紹介か、
または、「アジャイルモデル」の勘違いなどを紹介している。
一方、「ウォーターフォールモデル」を紹介しているサイトなどで、いかに「アジャイルモデル」がダメでなんて紹介しているサイトはない。
(すくなくとも私は知らない。大抵はあるのは、アジャイル手法自体ではなく、その運用面での人的リスクなどだろう。)

ここでわかることは・・・・
1)ウォーターフォールモデルを取っている人は、別に、ウォーターフォールがよいか?アジャイルがよいか?なんていう、議論にあまり興味がない。(興味をもつモチベーションがない)
2)ウォーターフォールモデルの方が、アジャイルより優れているなんて宣伝していない。

ようは、ウォーターフォールモデルでプロジェクトが回せているならば、そこから出なくてもよいわけだ。
つまり、ウォーターフォールモデルでは回せないプロジェクト前提が出てしまったために、新たなプロジェクト管理手法を確立させなければいけなかっただけで、必要ニーズに対する結果である。

ちょっと、話がそれるが、
「あなたは、「鉄道」と「自動車」どちらの方が優れた移動手段だと思いますか?」
という質問に、どこにどのような目的で行くかを決めずに答えを出せるだろうか?

「ウォーターフォールモデル」と「アジャイル」はこの質問に似ていると個人的に思う。
イメージ的には、「鉄道」が「ウォーターフォール」で、「自動車」が「アジャイル」だ。

たまに、俺は、あの人の場合は「ウォーターフォール」で問題ない。もしくは「アジャイル」で問題ない。そういう人がいるのも事実。
みたいな記述を見かけるが、ちょっと、違和感がある。
先ほどの、「鉄道」と「自動車」に置き換えると、その違和感がわかってもらえると思う。

あの人は「鉄道」を使っても、あらかじめ目的が決まっていないゴールに行ける人だ。
あの人は「自動車」を使うとあらかじめ、時間と目的地(とその駅)にゴールに行ける人だ。

あり得ない・・・・・・・・
人ではない。大切なのは、出発時点でのゴールだ。

よく、「変化する」システムの場合には、「アジャイル」というかが、それもちょっと違う。

要は、「出発時」にいろいろと決め切れていないが、途中途中で、全員で判断し、軌道修正しながらゴールへと向かうしか方法がないから、「アジャイル」なのだ。
変化も含めて、計画できるならば、「ウォーターフォール」でよい。

例えば、鉄道ならば、変化できる点は「駅」となる。そして、次の工程などの人員は「駅」で乗ってくる事ができる。
そして、時間もかなり正確によめるので、必要ない人材は一緒に載せなくても、移動ができる。
(もちろん、自動車でも途中で乗せる事はできるが、バスでさせも、鉄道よりも時間の確実性は低いし、距離換算ではコストが高い。このように、対コスト、対確実性では鉄道にはどうしても劣るのだ)

ウォータフォールモデルも一緒だ。最初に決めた事を忠実に守る事ではない。例え見えない変化が将来合っても、立案時には、それは考慮せず、見えているゴールまでを設計する。
その繰り返しが基本的な考え方だ。
それが、できるのは、ある程度まとまったゴール、つまり、「駅」がある事と、その駅に到着する正確な時間が見込める事だ。
この2つができないと、後で参加する人員が乗り遅れてしまい、プロジェクトは失敗する。
しかし、これができるならば、効率的なプロジェクト管理方法だ。もっというと、このような運行をする為のノウハウがウォーターフォールモデルだ。
必要な人員を必要な時に参加し、そして、必要がなくなったら解散できる。

しかし、現在の旅行欲求は変わってしまった。

「いつ出て行くかもその日の調子によって決めたい」
「天気によって行く場所を変えたい」
「混み具合によって場所を変えたい」
「あまり人が入ったことがない穴場をさがす旅をしたい」

これらの需要に応えるには、どうも「鉄道」では都合が悪そうだという事は多くの人が理解できるだろう。
それでも「鉄道」で生きたければ、「駅」はどこに作るか?鉄道は、何時から、何時まで、何分間隔で運行させるべきだ。
鉄道を引くための、場所はどうやって確保するか・・・・・・

ウォーターフォールモデルも一緒だ。
走り出してからしか「決めない」、「決められない」前提があるのに、走る前に計画が必要だなんて、ラチがあかない。
(今は、スイカなどになってしまったので、切符の時代には、目的を決めない切符というのは買えなかった。)
このように、ゴール、実現性、(今後の)人員の確保、いろいろと不確定要素があっても、出発する必要があるから「アジャイル」なのだ。
なので、「アジャイル」が良い方法だから採用するわけではなく、「アジャイル」を採用するしかないのだ。

だから、「アジャイル」という、一緒に目的地にいく人は、最初から参加する。
途中乗車はできない。合流地点が決められないのだから・・・・・・

でも、その「旅行」自体が満足する「旅」になるのかは、また、実は別の問題だ。
これは、穴場を探して、自動車でいろいろと探し回っても、鉄道が整備されている観光地の方が、より多くの人が満足を感じやすいという事と似ている。

だから、「鉄道」で問題ないならば、わざわざ、「自動車」に乗る必要はない。
どうしても、「自動車」で行きたいならば、それは「趣味」の範囲だ。仕事の移動だったら、「鉄道」だろうと。
「鉄道」でなく、「自動車」に乗るのは、「自動車」でないといけない「理由」があるからだと。

ウォーターフォールとアジャイルもそんな感じだ。

「アジャイル」の危険性は、その手法よりも、本当にそのたびが「成功する」リスクが高い事だ。行く前に十分、検討した方がいい。と。
「ウォーターフォール」の危険性は、決め切れていない、または、実現可能性など、未確定要素が多いならば、最終ゴールまでを計画するなと。

で、結局、「アジャイル」と「ウォーターフォール」ではどっちのほうが、成功するんだい?

それは、わからないなー。
「ウォーターフォール」型でまわせないプロジェクトで「ウォーターフォール」で回そうとしても、確実に失敗するし、
「アジャイル」でしか回せないプロジェクトは、そもそも、手法の成功・失敗にかかわらず、成功が難しいプロジェクトな訳だから・・・

あとは、大して計画するほどの必要性がないプロジェクトも「アジャイル」のが向いているかもね。
(でも、それをアジャイルというのかは知らないが、多くの人がそれは、【ウォーターフォール」か「アジャイル」かのどちらか?と言えば、「アジャイル」と言われるだろうというものだけどね)
車で15分のイオンショッピングセンターに行くのに、計画はいらないよね。例え、渋滞で30分遅れてもいいでしょ。電車で行けば、それ以上余計に時間がかかることは、確実なのだから・・・とか。
あんまり、時間がかかりそうならば、イトーヨーカ堂にするとかね。

でも、それでも初めて出かける時には、誰しも計画をした方がいいよね。別にイオンに行くに無計画なわけではなくて、
もうほぼ予測できないことはないくらい知り尽くしてしまっただけで、あたまの中では無数の「計画」と無数の「駅(中継地点)」が存在していて、それを選択してるんだけどね。

あとは、人の移動手段でより目的に沿うのは、車のケースと電車のケース。どっちが多いかな?
そりゃ車だよね。みんなの家の前に、それぞれ駅があるなんてないしね。
当然、自動車だけど。大抵のケースは・・・・・

でも、わすれないで、「自動車」を運転するには、最低限の知識が必要で「免許」が必要だって事を。

お仕事のご依頼・相談
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら
ソフトウェア&ライブラリ




ライブラリ
airxmail(en)
AIR版メール送受信ライブラリ
airxzip
AIR版ZIP圧縮・解凍ライブラリ
執筆書籍
本、雑誌等

WEB記事:CodeZine
執筆記事はこちら
カレンダー
2016年7月
« 6月   8月 »
 123
45678910
11121314151617
18192021222324
25262728293031

カスタム検索
RSS
Add to Google < !–adsense–>
アーカイブ
カテゴリ
にほんブログ村 IT技術ブログへ