Rubyエンジニア
独学大歓迎!今までの経験を活かしながらRubyに挑戦したいエンジニア募集!
テモナ株式会社
今回は参加者目線で皆様にセミナーの様子をお伝えしたいと思い、パートナー企業の杉山さんに実際に体験した内容を伝えて頂こうと思います!
・・・・・・・・・
杉山です!今回はテモナさん(以下 テモナ)でセミナーが開かれるということで参加させて頂くことになりました。
僕自身エンジニアではないのですが、自社エンジニア達の開発における悩みを毎日聞いていて耳にタコが出来始めています。この悩みを解決するため、参加は即決!有益な情報が聞けることを楽しみにお伺い致しました!
参加してまず驚いたことは会場の気軽な雰囲気です。セミナー会場の後ろにはお酒が並んでおり、皆さん片手にお酒を持ちながらセミナーを楽しむ姿勢のようで、今まで僕が認識していたセミナーの概念をスタートから覆してくれました!これなら普段できない深い質問なども出来て盛り上がりそうですね。
参加者は約30名と19時スタートにも関わらず多くの方がご来場されていました。それも今回ご登壇される方々のお名前を拝見すれば皆さんが足を運ぶことも理解出来ます。
=======================================
スターフェスティバル株式会社 執行役員CTO
楽天市場RMSの開発責任者として従事後、スターフェスティバル株式会社へ参画、CTOとして就任、2015年11月から2017年9月まで同社取締役、2016年7月から2017年6月までごちクル事業長を兼任。現在パラレルワークとしてテモナ株式会社の技術顧問としても参画。
株式会社クラウドワークス CIO
2001年国内大手SIer入社。2011年グリー株式会社に入社。2014年から大手クラウドソーシング会社に参画しCTO,CIOを歴任。現在は業務の傍らパラレルワークとしてテモナ株式会社、株式会社ビーグリーの技術顧問を務める。
テモナ株式会社 取締役CTO兼COO
テモナ株式会社のCTO(ちょっと、たのしい、おじさん)
元教員。上場直後のベンチャー企業にエンジニアとして従事。クラウド事業の立ち上げや国内大手企業のマーケティング基盤構築のプロジェクトにPL、PMとして参画。2014年テモナにCTOとしてジョインし、インフラ整備から技術者採用・教育にまで幅広く携わる。
=======================================
そうそうたる方々のお話が聞けるということでエンジニア達への手土産を持って帰れると期待を高く持って臨ませて頂きました。第一登壇はスターフェスティバル株式会社の加藤さんのお話です。
=======================
要件定義~サービスリリースまでのよくある失敗談と対策についてのお話を頂きました。
■要件定義
・顧客から『なんか売り上げが上がる感じに開発してほしい』と相談を受けた。
・具体的な改修要望を提示される
僕自身、自社エンジニアから話を聞くまではそんなことあり得ないだろうと思っていましたが意外とあるみたいです。このような相談。対策としては鵜呑みするのではなく、改めて要件を整えてあげることが大事なようです。又は一緒に考えてあげること。who what whyを聞くことでお客様に寄り添い、一緒に目的を探して行くことが大事なんですね。
■仕様書作成
・天才的なひらめきから高度な設計が出来た!
・アメリカでも最先端になっているUI/UXでかっこいいデザイン設計に仕上げられた!
僕からしたら『天才的でかっこいいならいいのでは?』と思いましたが技術者目線はそうでもないようです。設計した本人にしか理解できない設計は他の人が見たときに認識が出来なくなってしまうので出来るだけシンプルに設計することが仕様書工程では大切な事。また、お客様の要望を認識した上でのUI/UXでなければ自己満足になってしまうので、お客様にとって使いやすいかどうかを適宜認識することが重要なんですね。
■プログラミング
・汎用的なクラス作成から共通モジュールにして同じ処理方法から呼び出せるように設定した!
これがお客様にとって本当に便利になることなのかという自問を一度してみることが必要なようです。共通モジュール修正時の依存関係が多くなり過ぎていたり、調整が大変になることが懸念点。疎結合にしておくことも非常に重要なようです。
■サービスリリース
・サービスを開始してみたがパフォーマンスが発揮出来ていない、お客様の流入が進まない。
これは頼んだお客様からしたら予想外の事態ですよね。依頼に沿った実績が上がってないので僕自身でも注文した側の気持ちがわかります。エンジニアの対策としては非機能要件で想定PVの確認をすること、負荷試験をしっかりと行うこと、社外からの疎通試験を行うことが挙げられるようです。単純に最初に動かしてみるだけでも対策になるようなので怠ると大変なことになるんですね。
=======================
ちなみに加藤さんはジムやランニングが好きなようで1時間弱かけてランニングで帰ることもあるそうです。文武両道とはまさに加藤さんのことですね!とてもラフな感じでお話頂いたので、皆さんリラックスして聞いていたのが印象的でした。
ここで一旦座談会を兼ねた休憩タイム!加藤さんへの質問と同時に後ろからとてもいい匂いが。
するとそこには、、ピザ!!
ラフすぎて家にいながらセミナーを楽しんでいる錯覚に陥りました(笑)ただラフなだけではなく皆さんの質問数も多く、気軽に意見交換を行う場が出来ていたのでいい意味のラフさです!
参加者の皆様が落ち着いたタイミングで第二登壇は株式会社クラウドワークスの大場 光一郎さんです。大場さんが登場した際の印象はかなり衝撃的でした。理由はご自身のお子様を抱えての登壇だったからです!僕が経験した中でこのような形のセミナーは初めてでしたが、何より癒される(笑)集まっていたエンジニアの皆様も心なしか笑顔でセミナー内容を聞いていたように思います。これもテモナ主催のセミナーならではのラフさある講演ですね!
=======================
大場さんにはサービスについて、名前の重要さについてお話頂きました。
■適切な名前を付けることが出来たら、その設計の大部分が完成したと言っても過言ではありません
※『プリンシブル オブ プログラミング』より
概要としては、正しい名前を付けられることが出来たときは無限の資産になるという大前提のもと、話しを進めて頂きました。根拠としては、”クラス名やメゾット名を見ただけでその先の処理概念が把握できる””名前に導かれて呼び出すときも間違えない””良い名前のおかげで説明的なコードになり読みやすい”等の理由が存在しているようです。上記から認識しなければいけないことは、正しい名前を付けることは難しいということ。エンジニアの皆さんは認識できると思うのだが、僕としては名前を付けることはそこまで難しいとは考えにくかったですが、エンジニア目線で考えてみると、”名前付けを放棄した設計書連番の番号をクラス名にした闇を見た””現時点で理解している課題・事実・要件だけで適切な名前を付けることは難しい””未来のことを予測しすぎても適切な名前にならない”などが挙げられ、開発目線で考えるとサービス成功に繋げられる名前を付けられることがどれだけ難しいのが理解できました。
この中で大場さんが経験した7つの大罪について話を聞いてみました!
1、サービス上の語彙と一致していない名前
2、紛らわしい命名
3、曖昧な命名
4、統一されていない命名
5、する人、される人
6、_
7、命名されていない命名(?)
1で言うとCrowdWorksの開発段階の命名は”employer:employee”というそのままの言葉でした。少し語尾が変化しただけでサービスの本質とは少しずれた命名ですね。4で言うとイギリス英語とアメリカ英語の違いで”cancelled”と”canceled”という些細な変化に開発途中で気づき、すべて書き直しになるという事例もありました。”命名”とはサービスに命を注ぐものという認識を非エンジニア目線の僕自身考えていましたが、開発段階で命名したサービス名が大きく影響してくる事実を初めて知ることが出来ました。
=======================
営業目線で今まで”大丈夫でしょ”と安易に考えていたことが恥ずかしくなります。開発という工程に、こちらが認識している以上の思考を働かせる必要があると考えさせられる講演でした。
そしてまた休憩タイム!
皆さん場の雰囲気に慣れてきたのか会話も増えて、お食事とお酒を楽しむ場面が更に増えてきました!何より空気を和ませたのは大場さんのお子様ですね!
一気に盛り上がってきた所で最終登壇は会場となるテモナの中野さんです。僕自身何度かお食事をご一緒させて頂いたことがあるのですが、本当に知識豊富で周りの人を楽しませることが得意!まさに”ちょっと楽しいおじさん”です。再度中野さんの乾杯の合図を皮切りに第三登壇がスタートしました。
=======================
中野さんには生生しい現場を交えて取り組んできたことをお伝え頂きました!(片手にはお酒です笑)
■アジャイル開発
テモナでの開発スタイルとして取っているのはアジャイル開発です。各機能ごとにスクラムを組んで優先度の高い案件から着手していくことで画面、機能を試せるので仕様間違いや要件漏れに素早く気付くことが出来る点がメリットとしてあげられ、要求とプロダクト間に間違いが発生しても、発生理由を分析することで、ステークホルダー、デザイナー、エンジニアと情報の伝え方や確認の仕方が向上できる点、開発途中で業務プロセスが変更になった場合、実装と修正が素早くできる点も特色としてあるみたいです。開発全体をスプリントに分けて、その中で要件定義、設計、開発、テストを行っていき、各スプリント内で上流工程を素早く制度よくあげることが最重要になっていく。安全な開発ってウォーターフォールじゃないの?と考えていた僕からすれば想定外にメリットがあることを知ることが出来ました。
■過去
テモナでは過去と現在で開発工程自体を変更しています。過去開発の特色としては、”インセプションデッキ””全体戦略””初期全体設計””PLメンバー以外は初めての経験””最新アーキテクチャ採用”等の手法や状況がありました。この状態で開発を進めていった結果、先に定義して予め決めた方が良い定義は”セキュリティ、スケーラビリティ””機能充実レベル””国際対応化””決済””マイクロサービスアーキテクチャ””インフラコスト”などの上記を事前に踏まえて開発を進めることが必要だったと認識できた上で意識する点が複数見えてきたようです。それが下記内容になります。
その上で開発スタイルを下記に変更しました。
■現在
要件定義
PAT(プロジェクトアドバイザーチーム)とスクラムマスターで顧客要望等をまとめ要件定義を詳細に定義するようにしています。
基本・詳細設計
デザインチームとスクラムマスターで要件定義を満たし、デザインと設計を検討する。
開発
スクラムマスターが要件定義と基本設計、ワイヤーを基にチケットをきり、オフショアの開発者が開発を行う。
テスト
それぞれ担当者と担当者以外で要件定義、UI/UX、結合、統合のテストを行う
上記のように現在は過去の経験を活かして開発の工程での役割から変更して各種機能の開発業務を行っています。今までの失敗談から中野さんが伝えたかったことは、
・技術的な負担は絶対悪ではない【技術的な負債を仲良くすることが大事】
・ユーザーも嘘をつく(表面的な事に騙されない)
【本質的に何をしたら幸せか、サービスを前提に考えないことが大事】
・作り手は誰よりも【プロダクトに愛を!仕事に誇りを!】
=======================
僕はテモナと長期に渡りお付き合いさせて頂いていますが、ずっと大事にしている”ユーザーファスト”概念の本質を改めて感じることが出来た瞬間だったと思っています。同時にテモナのエンジニアのPDCAを回すスピード感とKPTを意識した日々の業務体制を強く認識できました。
最後に皆様で座談会を行い、登壇者の三名より赤裸々な失敗談やその時の対策、現在の開発状況などこの場には載せられない話も沢山出てきて盛り上がりました!そして皆さんで集合写真を撮って閉幕!
今まではセミナーとは本来有益な情報を知るために勉強をする場として少し硬い認識をしていました。しかし、今回のセミナーに参加させて頂いたと身としては、このくらいラフな方が本質に近づいた話が出来て、より有益な時間が過ごせるということでした。
僕自身、自社エンジニアに本当に良い情報を持って帰ることが出来ましたし、次回は連れてくることを心に決めました。テモナではこのようなセミナーを定期的に開催しているので皆さんも参加することを強くお勧めします!
そして加藤さん、大場さんが技術顧問として参画していて、中野さんがCTOとして働いているテモナで働けるエンジニアの知識吸収力の高さも認識できました。
皆様、1度セミナーに足を運んでみてはいかがでしょうか。
=======================================
有難う御座いました!皆さん是非セミナーに来てみてください。
合わせて弊社ではセミナーだけではなく、一緒に働くエンジニアの方の募集も行っております。興味のある方は下記募集より連絡お願い致します!気軽にお話しましょう!