ソースをレビューして…
あるプロジェクトのSCMにソースが入り始めたんですが、色々と問題があるなぁ…(´・ω・`)
特にレイヤ構成が意識されていない部分があるのがヤヴァイかも。
あちこちの人をかき集めて逐次投入というデスマまっしぐらなやりかたなので、まあ、ありがちな状況ですが。
＃いくら人を集めても守れないスケジュールなのは置いておいて(´Д`;)
コーディング規約とかはともかく、レイヤ構成とかアーキテクチャに関する資料は用意できていないし。
周りの人達には作りも指示できるけど、.NET初のパートナーさんとかオフショアとか色々あって。
あらかじめアーキテクチャに関する準備が出来ていないと、カオス化は必至なわけです。*1
プロジェクトの初期からこういったアーキテクチャの整理をするのも「アーキテクト」とかの仕事なんでしょうけど。
いわゆる「アーキテクト」の中でもアプリケーションアーキテクトの仕事かな？
まあ、「アーキテクト」っていろんな意味で使われるので、ここではアーキテクチャの整理に絞っての話ですが。
で、本題なんですが「アーキテクトが必要か？」みたいな話。
こういう状況を見ていると、アーキテクト(ロールの人)っていうのは絶対必要だと思うんですが(´・ω・`)
例えば経験が無い技術でも、自分で調べて正しいやり方を選択できる人達ばかりがメンバーならアーキテクトなんていらないかもしれませんが。*2
ある程度の規模の物件でいろんなレベルの人が混在する様な状況では、「最低限の品質を確保する」ために明示的なポジションとしてアーキテクトを用意して、プロジェクトの初期から立ち上げに関わらせるべきだと思うんですよね。
実際、現場のPM、PLさんの中には、明示的ではなくても特定のメンバーをアーキテクトロールに割り当てるっていうやりかたをしている人も多いでしょうし。
小さいプロジェクトだと、
を一人で兼ねてしまっていることもあるので気がつかないかもしれませんけどね。
後、「丸投げだからアーキテクチャなんて気にしねーよ」なんて本音の人もいるかもしれないですけど、そういうのって、とりあえず機能要求は満たすところまではなんとかなっても、とても保守はできない代物ができあがるというケースをよく見ていますしねぇ(´・ω・`)
ビジネスとして、対顧客的にそんなやりかたで将来があるのかとは思いますけど。*3
で、世間一般的にはどんなもんでしょうか？
人のBlogとか雑誌とか読んでいると、みんな立派だな〜と思ってしまうんですが、自分の周りを見渡してみると同じ世界だとは思えなくて。*4
「そんなにレベルの低いヤツなんていねーよ、アーキテクトなんていらねーよ」っという方が主流だと良いんですが…(´ω`)*5
