何もいえない開発現場の雰囲気が、プロジェクト崩壊につながるのかなあ。。。

で、いままで、なんで、こんな自動生成ネタを書いてきたかというと、
m_pixyさんのブログ「PM見習いの読書日記」のこの記事が、自動生成プログラム作成屋さんのウィリアムのいたずらに気になったから。。。

　気になったところは、

ドキュメント相関図を見て泣きそうになる。みんなこの相関関係が頭に入ってるのかなぁ。すごすぎ。凡人には理解できません。。。

　大きなプロジェクトになると、たいてい、前に書いた「成功の方程式」をたてていて、ドキュメント体系は明確だし、それはみんな理解しているということを前提に動いている。

　でも、それが、何らかのドキュメント体系の修正、あるいは自動生成プログラムの修正によって見えなくなっているということはありえて、そういうとき、理解できなくなってしまうような、相関になってしまうこともありえる。

　で、このとき、自動生成プログラムが複雑になりすぎたのなら、そのプログラムを捨てればいいだけだから問題ないけど、ドキュメント体系に手を加えて、その結果、プログラムとどう結びつくのかわかんなくなってしまったら、「成功の方程式」が揺らいだということで、大問題！

　たぶん、前者の自動生成プログラムが複雑になりすぎたんだろうな。。。

　後者の成功の方程式がゆらいだのなら、プロジェクトやばやばすぎだから。。。

　で、だとしたら。。。

---

プログラムソースの自動生成にどれほどの意味があるんだろ？


今までも書いたように、自動生成にまったく意味がないというケースもありえます。

（メンバーのレベルが変わった、ドキュメントの修正が入りすぎ、自動生成できる範囲がへり、生成するより、手作業でやったほうが早いなど）。

　で、そういうケースがあることは、自動生成屋さんは、たいてい知っていると思うので、ふつう、そういう提案があったばあい提案自体は、聞いてくれる場合が多い気がするんだけどなあ。。。

　でも、ブログに書いているっていうことは、たぶん、上司とかには、いってないんだよね。。。

　うーん、自動生成屋さんにとっては、それは。。。

　ドキュメントの相関が追えなくなっているっていうことは、ドキュメントの仕様変更がおきたとき、やばいっていうことだから、こういうことを、どんどん、いえる雰囲気をつくってもらったほうが、いいような気がするんだけどなあ。。

　こういうことがいえない環境＝＞仕様変更が起こる＝＞自動生成システムが、崩壊＝＞プロジェクト崩壊になるのかなあ。。。

PMが、「成功の方程式を実行すれば、開発が成功する！」と確信できるかどうかで、開発の可否が決まる

前のブログをまとめると、結局、こんなかんじ

　開発の早い段階で、「このドキュメントをつくって、この情報をもとに、プログラムをこう組めば、システムは開発できる！」（ここではこれを、「成功の方程式」とよぶ）と、読みきり、それと、参加するメンバーをもとに、ドキュメントの作成体系と、フレームワークやパターンを作成する。
　（前のブログでは、方式がこれを行うとかいたけど、方式以外の人でもOK。小さいプロジェクトだと、PMか、リーダーが読みきる)

　このドキュメント体系の一部あるいは、ソースを効率的につくったり、早く作りたかったり、部分的にかくしたいから、自動生成プログラムが作られることがある。

　あるいは、現場で便利なんでということで、アドホックに作られることもある。

---

　で、いいたいことは、したがって、「成功の方程式」、つまり、作成するドキュメントの関係と、フレームワーク・パターンとの相関、そして、ドキュメントを、どう埋めて、プログラム作成のとき、どこをどう見れば、プログラムができ、テストケースが切り出せるのかの関係は、プロジェクトマネージャーが理解してるのが、必須！！

　それは、プロジェクトにおける、地図に相当する。

　プロジェクトマネージャーは、プロジェクトのコンダクター（ツアーコンダクター）だとすると、コンダクターは、地図をしっていることがみんな、当然と思ってる。じゃなきゃ、そのツアーのメンバーは、困ってしまう。

---

　一方、自動生成プログラムは、カーナビに相当する。地図を補助し、ツアーコンダクターをはじめ、ツアーのメンバーを支援する役割をもっているけど、地図をよーく知っている人にとっては、意味がない。
　っていうか、そんなのわざわざもっていくだけ無駄。だけど、知らない人には便利。

　自動生成ソフトも、そういう側面を持っていて、便利なこともあるけど、うーん、あんまり意味ないぞ！っていうときもあり得る。そういうときは、（自動生成ソフトを作る仕事が多いウィリアムのいたずら的にみると）使わなくて、いいような気がします。
　（すくなくともウィリアムのいたずらは、利用する人たちに、「使うメリットがないと思う場合は、使わないで結構ですというか、使わないでください」と言ってるけど。。。

　自動生成ソフトというのは、基本的に現場の混乱を防ぐために使っている（生産性の向上も、ちょっとあるけど、現場の混乱によるダメージと比べたら、生産性の向上なんて、せいぜい１００倍程度なんで、そんなに大きいものではない。現場が混乱すれば、生産性ダメージ無限大（開発不能）なんてこともあるし。。。）。
　だから、自動生成ソフトをつかって、現場が混乱するなら、使うべく出はない。

---

　結局、プロジェクトとって、プロジェクトマネージャーが、成功の方程式（ドキュメント体系とフレームワーク、パターン）を実行すれば、開発が成功する！と確信できるかどうかで、開発の可否が決まってしまうと思う。
　自動生成ソフトは、その上で、役に立つと思えば使えばいい。
　所詮、その程度のものだと思うし、
　その程度のものだからこそ、まじになって、ウィリアムのいたずらは、開発してるんだけどね。。。

開発の工程と自動生成プログラムを作るタイミングと種類

　突然ですが、開発の流れの中で、自動生成するタイミングっていうのを考える。

　ふつう、こういう開発をしますということが決まると、かなり早い段階で（業務分析中くらいに）方式決定をしようという話になる。

　方式決定は、以下のことを考慮して行われると思う。
　　・要素技術（Ｗｅｂをつかうとか、セキュリティとか）の決定
　　・入出力の要素の決定（ＤＢの有無、通信の有無など）
　　・開発言語

　で、こんなところから、だいたいのプロジェクトの参加者のこと（費用から集められるメンバーの技術レベル）もかんがえて、まあ、ここの部分は隠したいよねとか、標準化したいよねとか言って、（たとえば、
　　　　ＤＢのトランザクションのコミット部分は、画一化しないと、
　　　　　　ずーっとにぎっちゃうやつがいるから、やばいよね。
　　　　　　とか、オートミットでいいじゃんとか、
　　　　帳票出力は、これでいきたいけど、難易度下げたいよねとか、
　　　　クライアントの利用者によって、サーバー側の起動するクラスを
　　　　　切り替えるため、リフレクションつかう部分は、教えると、
　　　　　わかんないやつがうるさそうだから、隠したいよねとかなどなど）
とりあえず、パターンないしは、フレームワークを作成する。

---

　そして、仕様書の各項目を参照して、フレームワークをつかって、開発できるという「プロジェクトの成功の方程式？？」をたてる。

　つまり、方式の時点で、どのドキュメントをつかって、どう組めば、開発が可能なのかを、読みきっている（ただし、最近のアジャイルまんせーな人が方式にはいると、単体レベルで、開発可能かどうかを読みきらないうちに、方式完了とせざる終えない。アジャイルな人たちに、そこまで規定すると、反感を大いに買うから。

　この場合、マネージャーが、プログラマを管理できない場合、プログラム開発工程でプログラマがプログラムを抱え込まれてしまうと、失敗する）。

　そして、ドキュメントの流れをつくる（どこをどうみて、開発すれば、開発可能かを確認する）。

　自動生成の１つは、この時点で、おこる。
　あるドキュメントから次工程のドキュメント、ソースをつくるのが、大変なとき、あるいは開発工程上、変更が頻繁にありえるのに、時間がないとき、その部分を自動生成する。

---

　つぎに、方式部隊の成果をうけて、共通部隊が開発することになる。

　共通は、１つは、共通ライブラリ、メソッド、クラスの作成がある。そして、もう１つの役割として、共通部分の入出力を開発することもある。

　はじめの共通ライブラリなどの開発は、ほんとに共通なので、これは、ソースをつくってしまえばおしまいの話である。
　問題は、後者の共通の入出力。ＲＤＢなどに対する入出力、帳票出力、サーバーへのデータ飛ばしなどをつくることになるが、これは、機能が共通というだけで、ソースが共通になるとは限らない。

　このように、ソースは共通にならないとき、ドキュメントから、ソースを自動生成するものをつくる。これが、自動生成の２つめのパターン

---

　自動生成の３つめのパターンは、つぎの業務部隊が動く工程でおこる。

　この段階では、業務開発部隊によって、外部設計、プログラミングがはじまる。このときに、データ名の管理、ＤＢの項目管理、（場合によっては構成管理も）において、変更が起きたとき、ソースを変更しないといけないことが起こる。そこで、ソースを自動生成するプログラムを作成する。

　つまり、管理上、変更があったときに自動生成する形のプログラム。

　ＴＤＤを実行する際、ＴＤＤまんせーな人たちでも、じゃあ、テストデータは、どーやってつくるのよ！というと、だまっちゃう人がある（何千件、何万件以上のテストデータが単体でも必要ってなこともあるわけで。。。そういうとき）。

　そんなばあい、「ＴＤＤって、お前言ったんだから、作れよ！」とはいえない。

　そこで、自動生成チームがテストデータを作るなんていうケースもあるね。
　まあ、このようなもんも、自動生成の２、あるいは３にふくまれる。

---

　

　ということで、いままでにでてきた、自動生成のプログラムを作る場合は、こうやると、システムが開発できる、管理できるという業務と、ドキュメントの流れが明確にあり、それを補助する形で、自動生成プログラムができている。

　つまり、ドキュメントの流れさえ理解すれば、自動生成プログラムのやってることも、プログラム内部も、容易に理解できるようになっているのがふつう。

　で、ＰＭは、ドキュメントの流れを理解しないと、つまりこのプロジェクトの成功の方程式がわかっていないことになるので、これは、論外。理解してるでしょう。

　なので、自動生成のやってること、中身も理解してるのがふつう。

---

　ところが、自動生成プログラムには、もう１種類ある。

　開発中に、アドホックに、「ちょっと便利だから」ってつくちゃうやつ。
　自動生成プログラムに入力する手間をはぶくための自動生成プログラムなんていうのもあるとおもう（ウィリアムのいたずらは、作ってことがある）。

　で、わるいことに、これらのプログラムを改良（改悪？）修正したり流用したりしちゃったりする。そうすると、はじめ、「ちょっと便利だから」と深くかんがえず作ったもんだから、修正がかさんでくるうち、わけわかんないというプログラムに、なっちゃう。

　また、上記の自動生成の１から３でも、修正がはいりにはいったり、成功方程式となるドキュメントが変わって、自動生成が変わると、修正の仕方によっては、わけがわからなくなる。

文がながくなるので、とりあえず、ここできります。