NAgileメモ

メモ。

NAgileで始める実践アジャイル開発

第1回 .NET＋アジャイルなら本当に幸せになれるのか？

Ruby関西勉強会に行ってきた

　第6回 Ruby勉強会＠関西へ行ってきました。
　面白かったー。

　関西でもRubyやっている人は多いんですねえ。
　京都女子大で開かれたせいなのか、松江、東京、広島から駆けつけた人もいて、50人も集まって大盛況でした。
　内容は、Rubyでゲームアプリを作る話とRubyのTestUnitを使う話で、業務系システムの話やRuby on Rails、BioRubyに興味を持っていた僕にはちょっと物足りませんでしたが、勉強会の雰囲気がいいし、懇親会も女子大生とか京大生も来て元気だし、楽しかった。

　場所を提供した小波先生と、懇親会でずっと話し込みました。

「Rubyを大学教育で使っているのは、うちしかない」
「以前はPascalを使っていたが時代遅れになった。Rubyならオブジェクト指向にも触れられるし、ソースの可読性が高い」
「プログラミングには、コンピュータの仕組みを知らないと書けない部分と、書きたいロジックそのものの部分の2つがあるが、Rubyなら、後者に意識して書くことが出来る」

　小波先生は教育熱心な先生で、僕も大学時代はこんな先生の研究室へ行きたかったな、と思ってしまった。。

.NETよりもJavaの方が面白い

　.NETは面白くないなー、と違和感を感じつつやってます(m_m)
　オブジェクト指向設計とか、AAfNによる3層構造とか、Webサービスとか、技術的には面白いのですが、Javaと違うなーという点がすごく多すぎな気がしてます。

【１】オブジェクト指向をやっているという感覚よりもWindowsAPIを必死に覚えている感じ

　C#、ASP.NET、VB.NETをやると、確かにプログラミングはオブジェクト指向っぽいけれど、何か感覚が違う。
　昔C++をやっていた頃、C++をやっているのではなく、MFCライブラリを必死に覚えているのと同じのと同じ感覚に近い。
　プロパティ、イベント、デレゲート、属性、など、Javaよりも優れている部分は確かにある。
　でも、フォームを作って、コントロールをペタペタ貼り付けて画面を作っていく操作に、オブジェクト指向設計を意識している人は多いのだろうか？

【２】.NETは、昔のVBで作ったC/Sシステムの置き換えの延長にあるから、ややこしい

　レジストリに登録したり、COMを使ったり、仮想ディレクトリを設定する時にセキュリティレベルを考慮したり、Windows特有の環境構築が面倒なことが多い。
　つまり、昔の遺産（VB資産）があるので捨てられないのではないか？　実際の案件でも、過去にVBやAccessでやっていたシステムを.NETで置き換えるシステム開発は多い。。
　.NETを使う最大の理由は、VB資産を再利用できる所にあるからだろう。
　でも、ネックになるのは、COMじゃないだろうか？　.NETで作ったDLLは、Javaのjarのように自然に使えるのに、COMだと使いづらい。
　Javaなら、過去の古い資産はないから、簡単なのかもしれない。

　MSツールの理想系は、C/Sシステムではなかろうか？
　リッチクライアントはその流れにあるのではないか？
　C/Sシステムは、本質的に２層構造にならないか？
　以前のASP（VBScript）のシステムは、開発者が設計を意識しないと２層構造のアーキテクチャになり、ぐちゃぐちゃになる。
　ASP.NETは、AAfNのおかげで3層構造を意識させられるけれど。

【３】何故、いちいちコンパイルするのに、必ずビルドボタンを実行しなくてはならないのか？

　Eclipseを使っていた人から見ると、保存（Ctrl＋S）でコンパイルしてくれなくて、いちいちビルド（F5）を幼くてはならないのは、違和感がすごくある。
　プログラミングは、やっぱり書きながら、ああだこうだと考える部分が多い。だから、リファクタンリングをよくするけれど、その作業はサクサクやってほしい。考える作業を邪魔する作業はなくして欲しい。
　こんなことを感じるのは、かつてVBでえらい目に遭った僕だけだろうか？

　僕がJavaに惹かれるものは、「なぜJavaにこだわるのか」の記事と全く同じ。
　Javaを突き詰めることは、IT業界の最新技術を追いかけるのと同義。オブジェクト指向をマスターすることにつながるし、更には、開発プロセスやオブジェクト指向設計、デザインパターン、ビジネスモデリングまでつながる。すごく面白い。
　Javaには「愛嬌」がある。全くその通り。興奮させられる所がある。
　オープンソースを探してみれば、Javaの方がはるかに多いし、ERPやプロジェクト管理など、とてもフリーとは思えない業務システムも転がっている。
　全ては、プログラマがJavaの潜在力を知っていたから。

　.NETやJavaを比較すると、開発環境もプログラミング・スタイル以上に大切であるように思う。
　丁度、SmallTalkでも、ガベージコレクションなどオブジェクト指向開発環境が表裏一体であったように。

プロジェクトリーダーやマネージャに問われる能力は何か？

　今日の昼に50代のマネージャと昼食しながら、プロジェクトリーダーの仕事に関して考えることがあった。

【１】プロジェクトリーダーの特徴
　5人ほどのチームで開発する時、プロジェクトリーダーの能力には特徴がある。
　一つは、システムの設計や技術を細部まで知り尽くして技術者としては殆ど完璧なタイプ。この場合、基本設計や仕様確認ではお客さんよりも詳しいので信用できるが、プロセス管理や交渉にあまり長けていない。2次請け以下の会社に多い。

　他方は、仕様や技術は詳しくないが、お客さんとの交渉やプロセス管理に長けているタイプ。この場合、サブリーダーが技術統括者の役割を担う。1次請けの会社に多い。この人達は基本的に手配師。

　プロジェクトリーダーは現場監督そのもの。ソフト会社で最も戦力となる人達だ。
　手配師はプロジェクトリーダーと言うよりも、もう一段格上のマネージャに近いように思う。

【２】技術者と管理者の役割を使い分けて、問題解決にあたる

　プロジェクトリーダーの仕事は、トラブル解決にある。それができなければ必要ない、と言い切っていた。
　よく考えてみれば、作業担当者が責任を果たせなかったり、進捗が遅れたりする諸々のトラブルを解決する役割をプロジェクトリーダーは持つ。
　その時の解決方法として、技術でカバーするのか、プロセスを変更して攻めるのか、リソースを増やすのか、色々手段がある。

　はぶさんの本にも書いてあったが、困難な場合に陥ったら、意識的に自分の立場を変えてみることも、手段を思いつくヒントになりうる。
　技術者で駄目なら管理者になって、人の入れ替えやプロセス変更で対応してみる。
　管理者で駄目なら技術者になって、自分でカバーするとか、アーキテクチャを見直したりしてみる。

　彼がやるべきことは、どんな手段を選択してもいいから目的を果たすこと。
　彼が考えるべきことは、問題解決によって目的を果たすことであり、手段にとらわれすぎることではない。

【３】手配師に必要な能力は何か？

　僕の少ない経験から見ていると、手配師はリソースの補充・管理の能力が優れている。優れた技術者を引っ張ってきたり、スケジュールの調整をしてバッファを持たせたりするのが上手い。

　マネージャから聞くと、プロジェクトリーダーとマネージャは仕事の質が違う。
　僕はチーム運営が仕事の殆どとイメージしていたが違っていた。
　チーム運営は1割に過ぎない。むしろ、コスト管理、リスク管理、スケジュール管理が3割ずつぐらいの割合でどれも大事ということだった。
　コスト管理とリスク管理は、プロジェクトリーダーが見落としやすい所かもしれない。

　今のIT業界は、中国でオフショア開発し、日本で設計とプロジェクト管理をするように役割分担する流れにある。
　でも、ビジネスとしてうまく成り立っているのだろうか？
　XP祭り2005でMSの萩原さんが

「日本人は個人や小集団では優秀だがマネジメント能力に欠ける」

と言ったことが気になって仕方ない。

【追記】
下記の記事にリンクがある。

サブリーダーの役割 - 世界線航跡蔵