RAKUS Meetup OSAKA 大阪開発チームの”チャレンジ”紹介に参加した
2018年11月27日、楽々清算で有名なラクスさんのイベントに参加しました。
恥ずかしながら最初は社名にピンと来なかったのですが、調べてから横澤さんが出演されているCMの企業さまか...!と思い出した過去があります。
さて、そんなこんなで勉強会参加メモです。
今回は次の３セッションを聴講しました。
チャットディーラーの高速開発を支えるLaravel
Why Mob Programming? - モブプロという働き方 -
トウダン・ジャーニー
全体を通して様々な発見・学びがありました。例えば、Why Mob Programming? - モブプロという働き方 -の中のモブプロ を参考にして普段の仕事の効率化を計ってみました。
私の場合、普段の業務ではAdobe IllustratorとPhotoshopを使用していますが、個人によって用いるツールや持っているスキルも異なるので人によって、「これ使っている」「あれ知らなかった」など出てきてしまうのですが、それを解消する手助けになりました。
残念ながら急に全員巻き込むのは難しそうだと思ったので、隣の席の人と「この作業を一緒にやってどっちが早くできるか勝負しましょう！！」と話して楽しみながら取り組んでみました。まだ活動としては全く普及できていませんが、これからも学んだ内容を取り組んで行きたいと思います。
さて、それでは登壇内容についてのメモです。
まずは
チャットディーラーの高速開発を支えるLaravel
吉元和仁（よしもとかずひと）さん
今年夏に開催された PHPカンファレンス関西 2018 の登壇内容をベースにお話しします。10年以上PHPでノンフレームワークで開発・運用されてきた主力サービス（メールディーラー）の開発チームが、新規に姉妹サービス（チャットディーラー）を立ち上げる際に Laravel を選択をしました。 開発期間半年というスピードが求められる中で、Laravel での新規サービス立ち上げのチャレンジをご紹介します。
とのことです。PHPカンファレンス関西2018で別の方がお話されており下記に掲載のスライドはその時のものになります。
ラクスさんのサービスにメールディーラーというサービスがあるのですが、2001年にサービスの提供を開始してPHPを用いノンフレームワークで開発されたとのこと。
15年以上改修を続けられ、グローバル変数が数千個あったり、何を返すかわからない共通関数がたくさんあったりとしたそうです。
そのような状況で課題感を持つチームが新規開発にチャレンジされた時の話を教えていただきました。
チャットディーラーはWebページに専用スクリプトを埋め込んで利用するWebチャットシステムで、PHP,Laravel,Node.js,Express,Socket.IOを用いて開発されています。
＊ここから箇条書きメインです。
バックエンドとフロントエンド３名ずつ
２０１７年要件定義 開発基盤整備
新サービスの立ち上げに関しての課題
フレームワークを選定するにあたって
長期サポートと機能性を選定
シェア率が高くて人気がある、活発なコミュニティなど
ルーティング、テンプレートエンジン、ミドルウェアやライブラリなど
機能性もあり選択
Laravelでよかったこと
オールインワンでスピード開発に向いていた
バンドル？準備コストがかからなかった
簡単設定でどんなものにもつながる
PosrgreSQL,Redis,Postfixをミドルウェアでしよう（一例）
標準ライブラリが使いやすい
ルーティング
URLとコントローラの紐付けが直感的にかけてわかりやすかった
Middleware
事前・事後処理を追加したい ルーティング設定をgroupメソッドで加工だけ
バリデーション
-Requestクラスに追加するだけ
ノンフレームワークではそうはいかない
ノンフレームワークではcronが増えていく
ドキュメントが充実していた
Laravelで困ったこと
Vue.jsは思ったより難しかった
{{}} マスタッシュ記法という
$nameがマスタッシュ記法で囲まれている
Bladeはマスタッシュ記法をエスケープできず
{{ }}の文字間に半角空白を挿入
一見簡単そうだが、プロダクトで使うにはコンポーネント化が必須とのこと
jQuery熟練者への配慮 慣れ親しんだ人には左手で箸を持てといっている様なもの
質問
今振り返るとVue.jsで作っておいてよかったのか？ もう一度作り直すならjQueryで作った方が？
Vue.jsはゴリゴリDOMの操作をする必要がなかった。
SPAでなければVue.jsで作った方が良いがシングルページならjQueryの方が良いとのこと。無理に使う必要はないのでは？という結論だった（気がします。。。）
Why Mob Programming? - モブプロという働き方 -
大平直宏（おおひらなおひろ）さん
大阪の楽楽精算の開発チームでは、スクラム開発を取り入れて新機能の開発に取り組んでいます。急成長するサービスの開発を支えるためこの1年間で4人のメンバーが増えており、メンバー同士の知識共有が課題となっています。アジャイルな開発を推進するために取り入れているモブプログラミングのチャレンジをご紹介します。
終わらないタスク
経理知識などがないとダメ
文書化されておらず暗黙知 すぐに聞ける相手がいない、実装してレビュー待ち、
モブプロへの期待感
開発メンバーの増員に対応
技術スキルだけでは足りない、、、
モブプロとは？
モブ（集団）でのプログラミング
ペアプロの複数人バージョン
同じ時間に、同じ場所で、複数人でPCを使う
ナビゲーター（指示を出す人達）とドライバー（PCを触る人）に分かれる。
よかった点
1,意思決定の高速化
確度の高い意思決定を小さく繰り返す
-全員その場にいるので「あとで相談」がない
-設計・実装方針の合意が早い
2.リードタイムの短縮
・待ち時間がなくなる
-質問や相談するのを待っている時間
レビューしてもらうのを待っている時間
・レビューの大きな差し戻しがなくなる
タイムロスがなくなる
3.暗黙知の共有
・文書化されていない業務知識
会社やチームの開発ルール
CIツールの設定や外部連携SDKなど属人化しがちな知識
マニュアルチェックのフロー
・自分の知らない便利ツールやショートカット
-IDEの便利機能
REST APIの動作確認ツール
Gitコマンド
人がやっているのを見て、あ、こんなのあるんだってわかる
チームの価値基準を合わせられるなど他にもメリットがあった
よくなかった点
1.他人のPC辛い
キーボード配列、InteliJのキーマップ
自分のPCを持ち込む様にしたが、ドライバーの変更があまりなされなくなった
2.心理的プレッシャー
見られている/終わらせなくちゃという焦り
→一時間ではなく二時間枠にトライ
3.費用対効果
リソース効率は悪い
ウォーターフォールとは相性が悪い
同じ期間のトータルの生産量は下がる
効率より効果
アジャイルとは相性が良い
トータルの生産量よりもリードタイムを重視したい
まとめ
定性的には効果がある
モブプロという手段の獲得
モブプロ力はまだまだ
トウダン・ジャーニー
川並裕（かわなみゆう）さん
今年の夏に開催された PHP カンファレンス関西 2018 で、会社として初めて技術イベントに協賛し、2 名のエンジニアが登壇しました。開発組織を横断した登壇推進チームが業務として登壇プロジェクトを推進したチャレンジをご紹介します。
@kawanamiyuu
PHPが好き
業務はJavaを利用
PHP Kansai 2018に登壇するまでの流れ・裏側
背景
組織として
人材の育成
車外へ情報発信していく文化の情勢
車外へのエンジニアリングのアピール
採用活動の強化
個人として
業務として取り組むために
プロジェクト化し、横断チームで推進
３サービスから合計５人が集結
題材サービスの開発メンバー３人
工数を見積もってスケジュールか
経験がないので「えいや！」で見積もり
今後のモデルケースにする
インクリメンタルな資料作成
発表練習
３回 + 公開リハを行い、そこで事前に質問を聞いたりした。（最後の事前質問ではそれまでの３回で上がらなかった様な疑問が出てきたとのこと）
所感
担当サービスを横断したメンバーで業務として取り組みを推進できた
自社のエンジニアが登壇している姿を見て感動した
我々はもうできる。やるか、やらないか、あとは我々次第だ。
（登壇に関する）
Q.各メンバーがどのくらい乗り気だったのか？
A.はっきりとは言えないが、いやいやな人はいなかった様。
このような感じでチャレンジをご紹介いただきました。
最初に述べましたが、業務に取り入れられる点など学びも多く参加して良かったです。他にもLaravelのメリットの確認であったりカンファレンスに登壇するまでの裏側（？）だったりと知ることができました。今後も勉強会、またもくもく会も開催予定とのことで機会を作って参加したいと思いました。
