2017-09-22-デブサミ九州参加報告-その2
Updated Date: 2024/01/01 14:47
2017/09/22のデブサミ九州にのレポートその２ですを書く。意外と長くなってしまったので2つに分けた。
そして年が明けてしまったｗ 明けましておめでとうございます。今年もホソボソと更新続けますのでよろしくお願いします……。
前回に引き続いて、僕の参加したセッションを載せておく以下。（敬称略）
- 【B-1】「スクラム」で、多様な背景を持つメンバーをチームにする 発表者： 吉谷 愛 [フロイデ/フロイデール]
- 【A-2】Webフロントエンド、改善の積み重ね 発表者： 穴井 宏幸 [ヤフー]
- 【A-3】なんちゃってUX、なんちゃってサービスデザインにならないために 発表者： 吉川 伸彦 [UX FUKUOKA]
- 【A-4】アジャイルウェアがスクラムを？！スピード成長するパッケージ製品の開発とサポートに、アジャイルプロセスで立ち向かったお話 発表者： 川端 光義 [アジャイルウェア]/平川 隆仁 [アジャイルウェア]
- 【A-5】SKYDISCのIoTを支えるテクノロジー 発表者： 大谷 祐司 [スカイディスク]
- 【A-6】スケーラブルエンタープライズアーキテクチャという挑戦 発表者： 横路 隆 [freee]
- 【A-7】九州スタートアップ事例最前線 発表者： 春山 慶彦 [ヤマップ]、カズ ワタベ [ウミーベ]
今回は5番のアジャイルウェアの発表から。
【A-4】アジャイルウェアがスクラムを？！スピード成長するパッケージ製品の開発とサポートに、アジャイルプロセスで立ち向かったお話
まず思ったことは、やっぱり関西の方の語りは面白い。オチがちゃんとあるんで、話を聞いてても伏線きた！とか思って笑ってしまう。 ただ九州民は比較的おとなしいので、乾いた笑いくらいしか起きないのが一般的なんじゃないかと思った。
中身としては、アジャイルウェアと言う会社であるがゆえ、当たり前のようにアジャイルやっているふうに捉えられがちだが、実際エンジニアはそうであっても、バックオフィスはなかなかそうなってないという話。スライド探してもなかったので、内容をどこまで言っていいのかわからないため、ちょっと隠しながら所感を書く。
僕がアジャイルウェアを知ったのはこの講演より先で、Twitterかなにかで出てたRubykaigi2017の「アジャイルウェア五カ条」という画像が最初だった。何をしている会社かは知らなかったけど、ようするにアジャイルでソフトウェアを開発しているんだろうなというのをそこで知った。個人的にこの5ヶ条はすごく気に入ったんで、画像を自分のPCに保存してたまに眺めるようにしている。
(この5カ条そのものはアジャイルソフトウェア開発宣言という形で存在していた)
- プロセスやツールよりも 個人とコミュニケーション
- 包括的なドキュメントよりも 動作するソフトウェア
- 契約交渉よりも 顧客との協力
- 計画の死守よりも 変化に対応できること
- 完璧なソフトウェアよりも 最高のソフトウェア
ソフトウェアの動きはドキュメントに書かれた仕様ありきだと思ってるんで、そこの整合性は正しく保つ必要はあるかなぁと思う点を除けば、この５ヶ条は、僕の信条にだいぶ近い。
参考：アジャイルにおけるドキュメント：いつどれくらい書くべきか - InfoQ
でも多くのSI・ソフトウェアベンダーの場合、エンジニアは顧客との折衝から切り離されるし、計画(予算)の数値を指標に扱われるので自組織の評価を下げないためにも死守しようと頑張る必要性が生まれる。こういうときは社内で変革を起こすしかないんだけど、基本はみんな同じ問題を抱えているので、多分それは問題ない。問題なのは、本当にお客先に行くことのないであろう社内の人間たちである。
彼ら(例えば管理部門やサポート、社内SE、プロダクトチームなど)は、基本自分らの仕事さえこなしておけば社内では評価されると思っているので、往々にして自分らの「守備範囲外」と認識した問題や課題などの物事について、見て見ぬふりをする。
お客先に出向くことのないエンジニア組織がそこに加わると、もはやフロントに立つ営業と経営層以外は、
自分らの仕事意外に価値を見出さないため、投げられたボールはずっとフィールドに置かれたままになる。
たまーに、気の利いた人やそのボールを拾い集めて回る世話焼きな役割を偶発的に担った人が、
一生懸命それを回収するという始末。もちろんそれは善意から生ずる行動であり、社内では「あの人よく動くねー」とか「助かるなぁー」という評判は出てきても、会社での数値的な評価には結びつかない。
この問題を解決する手段としては、個人的には2つあると思っている。
1つめは社内での評価制度を改めることだ。
少なくとも善意での行為が「当たり前」でない以上、そこにはプラスとなる評価要素があって然るべきで、
さらに数値化されていなければならない。また、それが仕事としての評価に直結するようなものでなければならない。
例えば、プロジェクトのリーダーの仕事としては、多くは予実の正確性や利益の確保、プロジェクトの成功が挙げられるが、数値的な目標だけでなく、内情としてはメンバーの育成や生産性の向上など、どちらかといえばリーダーシップという数値化の難しそうな行動・マネジメントに労力を割くことが多い。
優れたリーダーには人がついてくるというのは、感覚論ではなく数値化された評価を用いなければ、
結局それは「人」に依存する仕事の進め方にしかならない。その人が何かの都合で退職したり異動したりすれば、
すべてが最初からである。
この、なんとなくうまく行ってるを、いかにして他のチームや組織単位で増やせるかが重要である。
2つめは、役割を与えることだ。
誰もしないのであれば、それを遂行するための役割を社内で作って、仕事にしてあげればよい。
そこに、1つめで挙げた評価制度を適用することで、誰も損することなく会社に寄与できる仕組みができあがる。
アジャイルウェアでは、この役割において「スクラム」を用いることで、
組織間の連携を高め、目標を1つにすることにしたらしい。
……と、ここで2017/09/22 デブサミ九州参加報告 -その１に繋がる話で、ついにスクラムが出てくるのである。
スクラムは正直手順や作法が多く、元々業務フローのばらばらだった組織を1つに束ねるには難しい点が多く、あまり向かないのではないかと心配になる人もいるだろう。実際、そうである。
ただ、アジャイルウェアでの取り組みとしては、現在の業務フローに沿う形でスクラムを徐々に導入していくという方法を取ったそうだ。
そうしてスプリントを幾度か繰り返していくと、自ずと組織のメンバーからの提案や問題点の共有などの影響で、
スクラムの本来の進め方に業務フローが寄ってくるという。
つまり重要なのは、「やる」から「評価する」のPDCAを根気よく続け、少しずつ仕組みが浸透するよう繰り返し基本を忠実に実行していくことということである。
当たり前だけど、これがやってみると難しいんだよなぁ……。
僕としては現在チームリーダーとしての役割を担っていることもあり、続けていくことの難しさを実感しているところである。
というのと、やっぱボトムアップのやり方じゃ無理があるよなと最近思う。こういうのってトップダウンで社内の評価や制度の仕組みをガッツリ変えるための意識付けが必要だと思うからだ。
その動機となる指針を、ボトムアップで上まで届けるには、見えない指標やチーム・組織の問題点を洗い出して報告することが必要になるんだけど、それに対して全力で取り組もうとした一般社員が業務そっちのけで頑張るってのは、なんか違う気がする。手っ取り早くすすめるには、やっぱりトップダウンによる全社への展開と、それに付随する外部からの有識者による啓蒙活動を推し進めたほうが絶対良い。
ボトムアップの速度が遅すぎたり報告が各所に点在し審査査読フローの多い場合は尚更。
大体、トップからそういう声が挙がらないっていうのは、結局「必要ない」と思っているか、
現場に任せっきりで何も把握してないかのどちらかだし、それではもはや救いようが無いとも思う。
まぁそれでも、やる気のある人は頑張るんだろうけど、僕の場合は、そこに何かしらインセンティブがあるの？という感情が邪魔をする。好きな人ならともかくだが……。
5. 【A-5】SKYDISCのIoTを支えるテクノロジー
SKYDISC社の話。登壇者が変わったやつ。
資料はこちら：
https://www.slideshare.net/yujiotani16/skydisciot-81643586
センサデバイスを自社で作って、そこにIoTをかましてWebからデバイスのデータを収集し、 いろんなことに活用しようというサービスを展開している。
このセンサデバイスは、自社で作っているらしく、つまりハードウェア・ミドルウェア・ソフトウェア・IoTインフラすべてをSKYDISC社単独で1つのサービスとして提供できるところが強みらしい。いやーすごい。
その他、分析基盤やAI(機械学習)もやってる。
昨今3DプリンターやらRaspberry Piなどのマイコンのようなパソコンが誕生したことで、比較的簡単にデバイスも作れるようになったという風潮ではあるが、実際お遊び以上の実運用に耐えうるデバイスを作るのにはやっぱり努力とトライアル・アンド・エラーが必要だという。
例えば、高温多湿の環境で1年間無停止での稼働を求められるデバイスという制約をクリアーするにはとか、
電波の悪い場所でどれだけ安定してデータ通信を確保できるかーとか。その他振動、液体、冷凍などなど。
環境それぞれにおいてセンサーデバイスの精度が変わるようでは、安定したサービス供給にも疑問符がついてしまう。もはやシステムの域を超えている。プログラミングしかできないエンジニアにはお手上げだね。
そういう背景もあり、サービスを提供するには結構顧客によって個別対応が必要になることが多いとのこと。
なので、システムのカスタマイズの柔軟性を上げるために、多くのシステム基盤も自社で自作構築しているという。
これは、確かにすごいんだけど、後から方向転換するときとか、何かしらのセキュリティ脆弱性や、システムそのもののレガシー化が進んだとき、果たしてすべてをメンテナンスしていくことのできる土台があるかどうかが、他人事ながら心配になる。
MySQLのバージョンを上げたら、トリガーが動かなくなって後続処理のすべてが止まってしまった！とか、マジで怖い。がんばってください。
後半は通信規格の話。Wi-Fiしか知らない情弱にはなんのことだかわからんかった。とりあえず電波法は守りましょう。
あと他はデータ分析の話。Python、TensorFlowあたりは知ってたけどその他初耳のものも有り。
最近機械学習もやらなきゃ気味になってきてるので後から色々学べたらな～と思う。
(直近ではブロックチェーン技術が個人的な旬)
なお、この仕組はやっぱり大変だったのか、その後セッションに立ってくれたCTOの大谷さんは、CTOじゃなくなった……。
6. 【A-6】スケーラブルエンタープライズアーキテクチャという挑戦
このセッションは、今回僕が一番おもしろいと感じたものである。(僕がRubyやってたり大規模SaaSとの格闘をやってたりする関係上)
内容も技術者寄りで、さらに成長企業のエンジニアリングの進め方についても触れてあって、有意義だった。
なお、Webに公開されたスライドがないので記憶で書くところもあるため、ご容赦いただきたい。そしてここまで長文書きすぎて疲れたので適度に端折る。
freeeといえば現在も飛ぶ鳥を落とす勢いの成長企業。ツバメの躍進。起業5年目にしてエンジニア数は余裕の100人超えというなかなかすごい成長っぷりである。キラキラ感パない。
さて、進化の早いJavaScript・Rubyの環境下において、5年という歳月で置いてけぼりにされたレガシーシステムは数知れず、freeeもまた例外ではなかった模様。話をまとめるとこんな感じ。
- Ruby(Rails)を1年かけてバージョンあげた
- フロントエンドは2年で全面改修(React)？だった気がする
- できるだけモノリシックではなくマイクロサービス化
- 適材適所で(処理速度を要求される部分はgolangを使うとか）
- Railsも遅いけどArelを駆使してがんばった（SQLの知識もいるんでそこは折衷）
- アンケートがQRコードだた
僕が常日頃やりたいなぁ、やったほうがいいよなぁ……と思ってることを、freeeではことごとく実現してきていることが目に見えてわかる発表だった。
例えばマイクロサービス化についてはKAIZEN Platformも同じことをやってるし、時代の流れがそうなんだろうなという印象が強い。そもそも単一障害点を作るのもやめたいし、大規模システムだからってチームを細分化し、情報共有も行き届くこと無く巨大なモノリシックをちまちまと修正・改修していくのはもはやコストを削減するという面においても時代遅れだし。
そんなことをつらつら書こうと思ったら、大抵のことが下記にまとまってたので後は参照先を読んで下さい。
マイクロサービス化が進む背景について考えてみた - gist
1つだけ気になるのは、Arelってそんないいかなーってとこだけ。とはいえ、SQLではうまくいかないリレーションは、 可能な限りメモリキャッシュを使ってループを回したり評価したりしたほうが結果パフォーマンスが良かったりするので、 そのあたりは適材適所だろう。
あと、マイクロサービスで必ず目にするのはやっぱりGolang。Golang出来ないと今後死ぬのかな・・・。 (gRPCは未だ勉強不足なのでちゃんと学ぶ)
RPCといい、マイクロサービスといい、Java6の時代にSOAPだ！SOAだ！と騒いでいたあの頃が、ついに本当に必要になってきたという、時代が俺たちに追いついてきた感がほんと強い。
7. 【A-7】九州スタートアップ事例最前線
ヤマップ
BtoCのサービスとは、人の数だけ使われ方が違うんだなと思った。 メルカリだって、別にメルカリ側が決めたわけでもないのに、「XXさま専用」とかいう出品物をだすことで、 ある程度競争を省いた特別な取引を別途用意することにカスタマー自信が成功させている。 ヤマップも同じで、同社のサービスを利用しているカスタマーが編み出した使い方のお陰で、コミュニティー文化の形成を企業が手助けするという新しい形に落ち着いてきている。
この仕組を「馬鹿な客が勝手に始めた」と思うか「サービスの本当の在り方を客が教えてくれた」と思うかで全然その後の話が変わるよね。もちろんヤマップは後者。僕は人情味あふれる話が大好きだし、自分もそっちの感情が強くでるタイプなので、利益とかビジネスより、大切にしたいのはお客の心だと思っている。ビジネス的な成功よりも、特別な誰かに対して与えた幸福感の大きさ、そしてその無償の見返りは、かけがえのないものだ。感動した！
ただ、企業の成長と理論の遂行にしか頭のない投資家や起業家には一切理解してもらえないだろうけどね。
ビジネスでは本当に必要なのは企業を成長させることのできるほどの資金力だし、結局それは金である。
もちろん働く社員のモチベーションやスキルもあるだろうけど、それを具現化するには環境を整えるためにもお金が必要だ。そこをどうリスクマネジメントできるかが、起業後の戦略になるんだろうなと漠然と思う。経営者楽しそう。
ウミーべ
東京と福岡の起業の比較は面白かった。 やっぱり地方で起業するとなると「東京では出来ないサービスや待遇をアピールして、オリジナリティを出すことが重要」に帰着するんだろうな。僕なら福岡で、アジアを対象とした戦略を取るかな？ありきたりか……。
財務に関しては半分くらいしか分からなかったけど、将来起業しようと思ってる人にとってはかなり貴重な話だったと思う。僕も若干まだその野心はあるので、最後のセッションで疲れてたけどかなり真面目に聴いた(笑)
エクイティファイナンスからの資本性ローンの良さを説かれても正直ただのエンジニアには何を言っているのかさっぱりわからないｗ とりあえずおすすめ書籍として挙げられた起業のファイナンス(磯崎哲也)と、起業のエクイティ・ファイナンス(磯崎哲也)は、早速欲しいものリストへ突っ込んだ(読むとは言ってない^^;)
