昼過ぎに起きて、おでんとか食ってグダァ〜っとしてたんです。
まだまだ思いっきり正月モードです。
高校サッカーみてたら。
すげぇな野洲高校。ほとんどのメンバーがえらいテクニシャン。
間とか、考えてることとかみててすごい面白い。
ただ、あの中でも次のステップに進めるのはごく一部なんだよな
とか思うと狭き門ですね。
今日は1日暇なので、新年はじまりってこともあるし、良い機会だから、
今のプロジェクトの個人的な振り返りをしてみようと思います。
—
今は並行本番用に現行システムと新システムとで
結果が同じかどうか付き合わせる用のツールの製造が間に合わないってことで、
俺がヘルプ要員で入っていて。
実装は1機能担当してて、後はチームの設計/実装での相談役みたいな立ち位置。
実は今回のフレームワークで1からちゃんとモノ作るのははじめてだったりして。
性能対策とか、文字化けとか、ポイントポイントで参加してるもんだから
全体的に最初から最後まで作ったことない。
2日間くらいでできるかしら、なんて思ってたら、全然。
当然他にも突発作業がたくさんあるからってものあるんだけど。
実装自体かなりめんどくさい。
部品を組み合わせてそれを一連の流れでxmlで定義して、
コマンドチェーンっていう名前で、Chain of Responsibilityっていう
デザインパターン。
今までだったら自分でゴリゴリプログラミングしてたところを
部品を探して組み込まなきゃいけない。
コレ結構とストレス感じる部分で。
xmlファイルをeclipse上で開いたときに、そこで定義してあるクラスに
リンクでピョイっていけるような仕組みがあればなぁとか。
xmlみて定義してあるクラスのソースみて、
そこで使ってるプロパティファイルみて、
インポートしてるクラスのソースみて、
SQL文を定義してあるファイルみて、、、
そんな作業です。
せっかくいいとこまでいったのに、
eclipseがヒープメモリが足りないとか言い出したり。
まぁ、極力、部品化して、再利用するってのは
オブジェクト指向的にもそうだし、
でかいシステムになればなるほど、そうなっていくと思う。
そんな中でフレームワークがでかくなればなるほど、
アーキテクチャおよび実装方法の教育が大事だなと思いました。
Javaができても、永続化に長けてる人でも、
いきなりここのフレームワークを1日、2日じゃマスターできっこない。
自分でやってみて、それがよくわかりました。
今のプロジェクトは自力でフレームワークのソース読んで
いろいろ試行錯誤しながら這い上がってきた人が中心になって開発してる。
そこにかかったコストの事を考えると、相当だっただろうなぁって思います。
ただ、こういう人たちにはほんと頭下がるし、他にプロジェクトに行ったとしても
本気で一緒に働きたいと本気で思います。
(おかしな話ですが、この業界、こういう人が高い給料貰ってるわけではありません。)
ひがやすを氏のBlogに、こんなことが書いてあった。
・お前らごちゃごちゃ言わずにソースを読め。
・そしてソースを書いて体で覚えろ。
・成功したければ先ず行動しろ。
確かにその通り。間違いない。
だけど、ソースを読むためのポイントとかヒントとかが
あるとないのとじゃ全然違うかなって。
もし、その場で言った事を理解できなかったとしても、
後々あの人はあの時、こういうことを言ってたのか!
なんてことにつながる足がかりになることだってある。
そうやって体得したことは、なかなか忘れない。
個人的にも、1年以上前に、当時の師匠に言われた事が
最近になってようやく分かって、ジャンジャン使いこなしたりしてます。
今度でかいプロジェクトのアーキテクチャ部隊に入ることがあるとしたら
どんだけ時間かかっても、デモンストレーション形式で
フレームワークの講義をやろうと思います。
できるだけいろんなパターンの。
今回はエクセルのドキュメントを作って、説明会ってのに留まっちゃったから。
まぁ、その為には、何よりも自分で相当数の実装をしなきゃダメなわけで。
それってそれなりの時間も人的リソースも環境も必要です。
上司にコストはかかるけど、それ以上に効果があるってことを
ビシっと説得できなきゃいけないってことです。
アーキテクチャまわりを担当するには
・教育に対する手間を惜しまない
・周りをジャンジャン巻き込みながらフレームワークを作る
・他の人がアーキテクチャに疑問点がなくなるまでプロジェクトを離れちゃダメ
(ちなみに今のプロジェクトで俺らは第3世代目･･･。)
こんな感じかなぁと思います。
んで、ちょっとアーキテクチャから離れて、コミュニケーションについて。
今、久しぶりにプログラマやってて。
やっぱり仕様が不明確な部分とか、コレってどうなの？
とか思うところがでてくるわけです。
俺のいるプロジェクトは、最近こそ、所属チームに関わらず
誰にでもすぐ話かけられるような雰囲気があるけれど。
俺が入った頃は、設計チームとか、なんたらサブシステムチームとか、
不明瞭な部分はA3のエクセルのなんちゃら確認リストとかでやりとりしてた。
んなもん全部ドキュメントに起こしてたら、それだけで時間かかるし、
レスポンスだってなかなか得られない。
俺はメールのやりとりもあまり好きじゃない。
メール読んで、書く手間がものすごいから。
話せはすぐ済む話ってあると思うんです。
もちろん言った、言わない、みたいにならないような工夫は必要だと思うけど。
言った/言わないで揉めるのは、
金が絡んだビジネスなわけだから当然っちゃ、当然かなぁと思ったりしますが。
ただ、この業界、やっぱり人と話すのがちょっと苦手って人が多いのも事実。
どうやってそれをひっぱり出すのかってのも大事で。
ゲームの話や、テレビやドラマの話や、サッカーの話や。
そういうとこからできるだけ話しやすい雰囲気を作る努力は欠かしたことない。
その甲斐あってか、今回のプロジェクトでは、
縦割りになってる組織の横串の役割として、
結構大きく貢献できたんじゃないかと思っていて。
アーキテクチャの建て直しウンヌンよりも個人的にはこっちを評価して
もらえたらなぁなんて思ったりもしてます。
実際、俺より、このシステムを実装面からよくわかってる人が
業務アプリケーションの実装チームに何人かいて。
その人たちが持ってるノウハウを共有、展開ってところを
もっと早めに推進できたらよかったなって思う。
そういうのも含めて最近ではアーキテクチャまわりのことも、
技術基盤チーム内で閉じないで｢ここどうしたらいいと思います〜?｣なんて
他のチームの人に相談したりすることも多くなってきた。
こうなっちゃったら、楽だし、楽しいです。
ついでに、今度飲みいきませんか〜？とか。
コミュニケーションがうまくいくかどうかで
開発効率とメンタル面は大きく変わってきます。
おそらく無駄話は無駄ではなく、困った時に相談できる
足がかりになります。
—
世の中には、本当に頭が良くて、頭の回転速くて、言葉巧みで。
こいつには敵わないなぁ〜なんて人がいる。
そういう人は泥臭い業務システム構築の仕事は向いてないかもしれない。
時には日本語も英語も通じない海外の人に根気よく説明して
作業をしてもらわなきゃならないことだったある。
結局、俺は頭が良いわけでもなく、人と話すのが苦手なわけでもなく、
小さなことであんまりイライラしないってのもあって、
“すさまじいプレッシャー”を除けば、
自分に合ってる仕事だなっていう自己分析。
これからの課題は、この”すさまじいプレッシャー”とどうやって付き合っていくか
っていうことになると思います。
この課題に対して自分なりに考えがまとまったら、
その事について書きたいと思います。
コメント