読者です 読者をやめる 読者になる 読者になる

IT業界で気づいたことをこっそり書くブログ

何とかする系アプリエンジニア(SE)が、日々気づいたことの中で、役に立ちそうなことを綴っていきます(受託→ベンチャー→フリー→大企業、ベンチャー)

アジャイルとは結局何だったのか?

www.infoq.com

 

simplearchitect.hatenablog.com

 

ledsun.hatenablog.com

 

 

アジャイルについての話題が盛り上がってるみたいだけど

相変わらず議論が宗教論争じみているなあと思う

 

個人的にも少しまとめてみたい

 

アジャイルってなんなの?

未だに全て分かった気になれない

だが分かることもある

 

アジャイルソフトウェア開発宣言 を見て理解できる人がどれくらい居るだろうか

 

理解は出来なくても、何となくこれらはこれまでの経緯があって、その反省を元にして作成されているのではないか、くらいはわかると思う

じゃないと宣言なんて言わないだろうし

 

反省の対象はもちろんウォーターフォールだろう

つまりここから分かることは

ウォーターフォールで痛い目を見た人たちが提唱している

ウォーターフォールを理解していないとアジャイルが理解できない

ウォーターフォールの反省がないとアジャイルの良さが分からない

そういう性質のものだということくらいだ

 

第一の間違い:アジャイルが解決するもの

最初にアジャイルに触れた時に抱く印象はこんな感じじゃないだろうか

・ドキュメント書かなくていいらしい

・計画しなくていいらしい

・でもアジャイル使うと上手くいくらしい

→やった、面倒くさい作業しなくていいし、工数削減できるし、すごい!かっこいい!

 

こんなの普通は誰でも疑う

しかし人間の気持ちは状況次第で簡単に揺らぐ

 

・ドキュメントと計画の重要性が理解できず作業的にやっていた人

・スケジュールが間に合わなくてどうにかしなきゃならない人

・工数削減したい上司

なんかは薄い知識で思わず「アジャイルで」などと言ってしまい

ただの無計画プロジェクトを生み出し、結果後悔し、アンチアジャイルと化すことがあるのではないだろうか

 

そもそも冷静になってみると

あくまでウォーターフォールじゃ飽き足らない人たちが生み出した手法なわけで

誰もQCDが改善する上に簡単に導入できるなんて言っていないし

彼らプロ中のプロができるからといって自分ができるとも限らない

 

じゃあ何を解決するのかといえば、宣言の原則に書かれている通り

要求変更による柔軟性、リスクの最小化、ビジネスへの対応という、主にクオリティ面のみ

 

第二の間違い:日米の事業モデル

無計画に対して、ウォーターフォールは何なのかと考えると

きちんと計画してきちんと納品するための方法論だろうと思う

この考え方は、請負ビジネスにピッタリあてはまる

 

そこで、「アジャイルは次世代の開発手法らしい」と言われたら、もちろん請負ビジネスをしてる人たちはウォーターフォールの延長線上でいいモノを想像する

つまりQCDの改善や、簡単化だ

(ここで言うQはバグがなく仕様通りという意味での品質)

 

しかしシリコンバレーの最先端の文脈はむしろ、自社サービスなんだろうと思う(予想)

そこで言うより良い手法は、より良いプロダクトを作ってより儲かる手法なはずだ

 

ここで日米に非常に大きな勘違いという溝が生まれる

請負ビジネスではぶっちゃけ、シリコンバレー程良い物を作ろうだなんて思っていないはずだ

 

第三の間違い:エンジニアレベルと体制

アメリカの事業モデルは、ゲームや漫画、映画などのコンテンツ業界に似ていると思う

天才レベルのスーパーマンが少数精鋭でいいモノを作り、ヒットすればたちまち世界レベルで大金を稼ぐという業界

シリコンバレーには、ITでソレがしやすい状況が揃っている

例えば起業のしやすさやリスク、投資家、人が世界中から集まること、解雇しやすいなど

 

だからアメリカのエンジニアの地頭の良さは非常に高いらしい(調べた限り)

日本で医者や弁護士やコンサルになる人たちが、ITの道を選択すると考えればしっくり来ると思う

 

その頭のいい彼らが少数精鋭で回すために生み出したのがアジャイル

 

コミュニケーションをしながら、より良い物(ITプロダクト)を作っていくためには非常に頭を使う

おそらくシリコンバレーの彼らにはできても、日本の請負ビジネスに居るようなエンジニア(それでも平均よりは頭がいい)には難しいと思う

せめて大手コンサル会社に居るような人たちくらいの地頭がほしい

 

しかし、第二の間違いにより、日本の請負ビジネスでは「我々でもできる」などと思い違いをしてしまったと思う

「だって同じエンジニアなのだから」と

 

そもそも、シリコンバレーのエンジニアは活躍しすぎだ

そのためエンジニアの担保する範囲が広すぎて誤解を与える

あれこそ彼らが優秀だからできるわけであって、真似しようとすると痛い目を見ると思う

(特にプロダクトやビジネスに関する提案、すなわちサービスの創作部分は専門家を当てるべきだと思う。企画やプロデューサーやディレクターのような場所にエンジニアが入っていってるのはシリコンバレーだからこそだと思う)

 

ちなみに誤解のないように言うと、プロダクトに対するセンスがある人はエンジニアの中にもそこそこ居る

しかし、チーム全員の平均値を取ってしまうと難しいはずだ

当たり前だが「皆で」「話し合って」やるということは、自ずと質は平均値に近づく

 

その上、経験も必要になる

アジャイルを回すには最低限、チーム全員が小規模ウォーターフォール開発のSE~PLくらいをこなせるスキルが必要になると思う

だって、全エンジニアがコミュニケーションの場に立って、要件定義~リリースというサイクルを回すわけで

そこに上流未経験者や、話を進められないメンバーが入ると足手まといでしかなくなるから

 

そんなバカなと思うなら、アジャイル宣言を思い出して欲しい

別に優秀な彼らは「どのエンジニアでも」なんて言ってない

 

体制の問題もある

アメリカの少数精鋭チームくらいの規模感なら何とか回るものの

SIerのような人数になるとコミュニケーションコストが爆発して使いものにならない

 

結果的に日本でアジャイルが使えるのは一部のWeb系やITベンチャーしかなくなってしまう

 

DevOpsは流行るのか?

忘れ物

シリコンバレー流行ってるDevOpsは日本で流行るのか?」

 

流行らない!! 

 

アジャイルとどう付き合えば良いのか

アジャイルは色々な提案をしてくれている

それはあたかも一つのプロダクトのようだと思う

 

エンジニアはプロダクトのコードを見て

そのクラスやメソッドが何のためにあるか読み解き

それを参考に、別の解決のために使うことができるはずだ

その、いつも通りの方法を適用するだけで良いのではないかと思う

 

1.現状の把握

2.問題の発見

3.参考コードの読み解き(何を? 何のために?)

4.再利用

 

この手順を間違わなければ、様々な手法は己の武器にできると思う

 

また、もちろんITベンチャーだとか、請負ビジネスでも小規模案件だったり、プロダクトの質をよくしてクライアントに気に入られようと思う攻めっけのある人達には有効だと思う

ただその際も「全員がスーパーマンではない」という前提に立ってアレンジする必要があるだろう

 

日本のIT業界はどうするべきなのか?

何故か「日本とシリコンバレー」で比べる自意識過剰が多いが

実際は「シリコンバレーとその他」だと思う

 

喩えるならイケイケの週刊少年ジャンプに対し、我々地味に売れてる月刊誌はどうするのか、みたいな

 

よく言われるのが「第二のシリコンバレーを目指す」みたいな意見だが

シリコンバレーには世界中から優秀な人が集まってるし金もあるし、どう太刀打ちするの? という印象だ

 

もし国策として特区を作るならまだチャンスは有るかもしれないが、現状の雇用形態と雇用文化では手も足も出ないと思っている

自分がシリコンバレーに言ったほうが全然早い

 

もう一つ「日本は開発手法が遅れていて、海外からIT業界がやってきて仕事を奪われる」みたいな意見もあるが

誰がシリコンバレーを尻目に日本に来るのかと疑問でしかないし

そもそも開発手法の道具としてはそのまま適用できないことは上で書いたとおりだ

もちろんパッケージ分野ではひたすら吸われるだろうが、そんなの今に始まったことでもない

 

結局、よそはよそ!うちはうち!で日本にあった手法を開拓していったほうが幸せに慣れそうだと思う

 

とは言え今のITサービス業界をコンテンツ業界と考えれば、少数精鋭さえ集まればちょっとはチャンスがあるので

打倒シリコンバレーを個々の優秀な人達が画策するのは良いことだと思う

 

結論:アジャイルとは結局何だったのか?

・プロダクトを少数精鋭で作る際にうまく動く方法論

シリコンバレーのエンジニアがスーパー過ぎていろいろ誤解を招いた

・参考程度にはなる