« gitbucketに移行した。 | トップページ | ビジネス要求とサービス開発 »

Mr.山下の「入って早々大暴れ!」?(大活躍)

5月の定例会では、山下さんアーキテクトであり、要件定義フェーズの支援や顧客間の各種調整、リーダー業務、
更にはメンバーの教育などもこなすスーパーマン!
)から、
20160513170854 新たに参画した顧客先プロジェクトのビジネス的特徴や、開発の体制とか進行上の特徴、技術的な基本特性などに関して
お話をしてもらいました。
 
山下さんとしては未経験の技術要素として、
RoR、Rubyそのもの、AngularJS、CoffeeScript、RedShift(その他Amazon系の各種サービスと連携)と盛りだくさん。
 
これだけのものが有るのに加えて、
山下さんが顧客先で作業を開始するに当たって
「山下さん、作業用のPC、Windowsがいいですか?、Macにしますか?」と聞かれて、
思わず馴染みのない(でも機会があれば使ってみたかった)「Macでお願いします!」と答えてしまったのだそうな。
 
さすがにMacには直ぐに慣れた(?!)と言ってました。
「基本的にはUnixだし、コマンドラインでサクサク使えるのは快適ですねー」って、うーん、そうですか。
 
既存のソースコードもあり、品質改善や不具合改修から入るという、有りがちなパターンの導入だったのですが、
「さすがに、これだけ未経験の要素が幾つも入り込むと、全然ソースが読めなくて困った」
とのこと。
 
...とか言いつつも、入場してから1.5か月。
「今回の不具合に関してですが、フレームワークの側にまで踏み込んで改修した方が今後の為にも良さそうなので、
手を入れても良いでしょうか?」
とサブリーダーに進言
 
問われたサブリーダーも判断に窮してリーダーに相談。
結局、3者で検討した結果、山下さんの提案通りに踏み込んだ改修をする方向になりました
 
20160513173030 所属しているチーム内では最も新しいメンバーであるはずなのですが、既にソースコードのレビュワーになったり
レビュー自体の習慣が無かったところに、「品質改善が課題にもなってますし、やりましょう!」と提案して、
チームとしてレビューを行うようになった
)、
 
色々とワケありで全体仕様を正確に把握している人がいない中にあって、既に仕様の問い合わせとか相談を受ける側に
回ってるとか
普通じゃないでしょ??
 
上記のリーダーさんからも、「山下さんって、ヤバイよ!、ヤバイ!」との反応(評価?)だそうです。
 
しかし、本人が言うには、
「だいたい何処に行っても、ソース位は読めるだろう。という自信があったのだが、今回はさすがにダメだった」
「やっぱり、主要キーワードの概念やポイントを押さえるだけでなく、ある程度手を動かしてキャッチアップしていかないと、追従ができない」と。
 
そりゃ普通そうだろう?!
...と思いますが、これまでのお客様評価を含め、社内開発も含めて、その成果を目にして来ている他のメンバー達から
見ると、「あー、山下さんでも、やっぱりそうなんだあ」となってしまいます。
 
上記した以外にも、技術要素は多く存在し、
システムの構成も「よくメモとか資料見ないで白板に描けるなあ...」と思うほど複雑。
このシステムのオリジナルをデザインしたアーキテクトは、相当の頭脳とやる気の塊だったのだろうと思わずにいられません。
 
とは言え、「採用されている技術要素群は、最新のトレンドと言うよりは、その1つ前」(by 山下さん)とのこと。
 
.....難しいですね。
 
20160513173137 AngularJSも、やっとバージョン2に上がろうとしているところ。
React.JSがメインストリームになろうかという勢いで、この辺は学習も、プロジェクトへの適用も、判断の難しいところ
なんじゃないでしょうか。
 
何れにしても、顧客先のプロジェクトに入っていく、俗に言うSESという形態ですが、
能動的に新しい/トレンドの技術を追っていかないと対応ができません
 
メタなスキルがあれば、実務経験のない技術要素を含む案件であっても参画のチャンスは掴めますし、活躍もできます
(少し会話をすれば、分かる相手には通じるようです)
 
逆に、経験の範囲に収まってメタスキルが育っていない人。
吸収力の弱い・遅い・無駄が多い人は、Web系で(特にフロント側は)生き残っていくのは難しいかも知れません。
 
フルスクラッチを選ばず、既存サービスのカスタマイズや拡張・組合せを主として行き、
顧客のビジネスや業務を知る・理解する・価値のあるシステムへと方向付けることを自らのミッションとすれば、
技術を追い続けるのは他の誰か(サービス提供者)に任せる、という選択肢もあるでしょう。
 
アスペアは基本的に技術志向が強いメンバーが多いです
 
ある程度は意図的にそうしてきた面もあるのですが、「技術だけ」ではダメ。
チームとして、プロダクトを、或いは顧客のビジネスの為のシステムを、価値の高いものにすること。
 
その為の必要要素の1つに「技術」が含まれているということですよね。
ちなみに、今回の話をしてくれた山下さんも、その辺はとても理解してくれている
 
だからこそ、チームが良い方向に変わっていけるように、お客様側の上長(結構上の階層だったり...)の方が相手であっても
忌憚なく様々な提案・相談をしてくれることが非常に多い
んですね。
 
有り難いことです。


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

|

« gitbucketに移行した。 | トップページ | ビジネス要求とサービス開発 »

定例会、勉強会など」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: Mr.山下の「入って早々大暴れ!」?(大活躍):

« gitbucketに移行した。 | トップページ | ビジネス要求とサービス開発 »