惹きこまれる

　ややっ！かの案件は、mayaa+ikushipe +s2buri+s2dao でFAか。かの案件どころかあっちもいけるなぁ…だいたい全部やってみてはどうだろう。ま、今ikushipeを語るには早すぎるので、あとで書く。てか今日コミッタに追加されたのであとでコード書く。
　今まで一番重要なところを適当な人海頼りにし過ぎていたんじゃないかと猛省。フレームワーク組み合わせりゃ後は楽なもんだという考えが自分一人ならともかくもチームでやるにゃ甘すぎだということは、その人海のアウトプット見て泣きながら判る羽目になるわけで。あの時もこの時もDBから再構築しなきゃ根本的に良くならんことに気付きながらもお客さんの予算やら時間の都合やら、もっと正直に言えば面倒を抱えたくないために触れないでスルーしたり、各自が各自のルールで作りこんじゃってて、わやくちゃになったり。１人のプログラマが携わるレイヤーが多いのに、その複数レイヤのワンセットを、複数人に分配するから、それぞれが既にあったり誰かが作っている共通部を大量生産したりするわけで、関わるプログラマが多くなるほど酷くなる一方に。そんなことをずっと繰り返してる気がするってか実際にそう。
　だからこそ、変なことさせないようにライブラリやら共通部やらフレームワークやらをなるべく用意・提供するようにして誰が書いても同じようになるように…って仕事に10余年携わってきた流れだけど、ほんとは誰が書いても同じにはならないし。それってまだまだスキマを埋めるフレームワークが足りていないから？とかじゃなくて、進め方そのものを過去を分析しきって生かせてない自分が居ることに、buriの紹介を読むほどに（てかはぶ日記を読むほどに）改めて気付かされました。
　フローを書く人、プロセスを書く人、バリデーションを書く人、細かにレイヤー分けして、それぞれの担当者は１人ぐらいしか置かないぐらいのチーム構成が実現できれば良いなぁと。それが実現できるようになる、「何か」「SIのゴール」を探しつづけることを提案してくださっているように感じました。日々きちんと自分も考えなきゃなぁと気付かせてもらいました。そうなると各自がしっかりコミュニケーション取ってインターフェースを確認しあわないと進まない日常になりそうだけどむしろそれが大事で、最後の最後でわやくちゃになるより、日々１つ１つ確認して確実に進む方が最終的には良いよねぇ。
　で、その３はまだですか。