« 2016年3月 | トップページ | 2016年6月 »

2016年5月の記事

ビジネス要求とサービス開発

今回は長部さんベテランの域だが若く見えてカッコいい!;技術者としての実力も凄いぞ!)が、
比較的最近・新たに参画した顧客:プロダクト(サービス)に関して、現時点で見えている範囲の情報を共有してくれました!

起業の最初っからインターネット上のビジネスをスタートされたお客様とは違い、
元々はアナログ媒体でのビジネスも活発にされていたお客様です。

あまり詳細は書けないのですが、上記の前提がビジネスフローの特徴に必然的に結びつき、
恐らくはシステムや運用にも大きく反映されているんだろうな...、
という事を感じさせてくれる内容でした。

直前まで対応していた別顧客:サービスでは、最初っからネットビジネスだったこともあり、
また、負荷対応に関しても、ちょうど長部さん本人が、案の提示に関わったり、チューニング作業自体・及び検証・測定を行ったりの経験がありましたから、
この辺は経験値の積重ね=厚みを増す=メタ知識・技術の習得にも役に立つのではないかな?!
と思いながら、興味深く話しを聞きました。

こうした、メンバーが関わっているプロダクトやサービスに関しては、社内限定で共有しますが、
質疑を行うことで、より共有度・理解度を上げます
と共に、質問を受ける側も、「回答しきれない」シーンが出て来ます

これを基点にして、更に現場での知識の深堀を行うことが出来ますね。

20160513173750ちなみに、今回の長部さんからの発表内容は(前述した通り)ビジネス・フロー的に特殊な面がありますが、
こういった話題になると、技術者からではなく、会長や社長から非技術の視点からの質問も出て来るので
コンテンツとしての厚みが増すのが面白い
ですね。

余談ですが、"技術者だからビジネスに関する理解は、それほど必要ない"という考え・認識は間違っていますよね!?

特に、我々アスペアもそうですが、ネット・ビジネスを支えるシステム(サービス)を具現化しようというときに、
要求の仕様"=吟味されてブレない、正しいモノ"として対処すれば、手戻りや混迷が深まるばかりです。

エンジニアもビジネス的な要求と、システムという形を取る目的・意義・効果を、ある程度理解していなければなりません。

けれども、"ビジネス要求を正しく把握"と言葉にするだけなら簡単なのですが、これをしっかり意識して

実践し続ける/顧客の投資に対して最大限の価値を提供する、ってのはなかなか難しいです。

要求や手段がかなり限定された場合であっても、「だったら絶対にこうすればOK!、大儲け間違いなしですよー!」
なんて仕様・設計や実装はあり得ません。

想定を膨らまし過ぎて大きな失敗(=大きなコスト損失)を招くより、小さく作って小さい失敗から学びを得る。

その為には、"調査・想定"⇒"仕様決め"⇒"試験的実装"⇒"部分的な公開"⇒"反応を分析"⇒(元に戻る)を、
迅速に確実に回していく必要があります
よね。

今回の長部さんのお話によると、既にビジネス的には結構な成功状態で軌道に乗っており、
今後は更なるブッチギリ方向に向けた施策と、
ビジネスをしっかり支えるバックヤードの仕組みを、より堅牢にする必要がありそうでした。
(まさにその一部のステップに、長部さんが加わったようです)

生きたビジネスとシステムの話しを聞けるのは、本当に面白いです!


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

| | コメント (0) | トラックバック (0)

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

| | コメント (0) | トラックバック (0)

« 2016年3月 | トップページ | 2016年6月 »