ある開発会社の生存戦略 Developers Summit 2016 FUKUOKA

Transcript

1. ある開発会社の⽣存戦略 -技術の変化に適応できる企業であるために。そしてこれから- Fusic ⼩⼭健⼀郎 2016.9.26 1 #devsumiB7
2. Who 2 #devsumiB7
3. k1LoW   Kenʼichiro Oyama   @k1LoW   Fusic Co.,Ltd. エンジニア   基盤ユニット テックリード   初代新卒   GitHub organizations   fukuokarb / dotcake / emacs-jp / etc.   awspecというAWS⽤のテストツールを作っています   https://github.com/k1LoW/awspec 3 #devsumiB7
4. Fusic   株式会社Fusic   社員36名、うちエンジニア24名   最近マーケティングチームの動きが活発です   「マーケティング」といいつつ何でもこなす   「Fusicってなんしようと？」を是⾮ご覧くださ い   http://fusic.co.jp/doings   受託開発と⾃社Webサービスの2軸 4 #devsumiB7
5. CM 5 #devsumiB7
6. #devsumiB7 6
7. CMおわり 7 #devsumiB7
8. ある開発会社の⽣存戦略 8 #devsumiB7
9. ある開発会社のおさらい   エンジニア30名弱   プロジェクト規模はだいたい1⼈〜3⼈、多くて 5⼈の開発メンバーと1⼈のテスター   Webシステムが多い   受託開発のほうが数は多い   エンジニアはクライアントと直接顔を合わせて 要件定義から運⽤まで主導する 9 #devsumiB7
10. 10年 10 #devsumiB7
11. 10年で社内で⾒かけた技術（⼀部   HTML   CSS   PHP   JavaScript   Ruby   CakePHP   Ruby on Rails   iOS   Android   Subversion / SVK   Git   開発サーバ   coLinux   VMware   Vagrant   FTP / SFTP   Capistrano   Ansible   RDBMS   NoSQL   Socket.IO   レンタルサーバ   物理サーバ   VPS   AWS   Docker #devsumiB7 11
12. 技術の種類が多い問題   10年前の技術要素は数える程度   HTMLが書ければ重宝された時代   素のPHPで書いて正しく動けば良かった時代   今は、エンジニアとして働くためだけでも習得 が必要なものが多い   逆に「これさえやっておけばいい」ということもない。次の年には変わ ることも   スタンダードの寿命が短い   10年前のHTMLと今のHTMLは違う   求められるレベルも⾼い   レスポンス、UI、セキュリティ、etc 12 #devsumiB7
13. 時間や機会は有限 13 #devsumiB7
14. 技術の選択を間違えると死ぬ 14 #devsumiB7
15. Fusicが選択してきた技術要素   PHP   CakePHP   Ruby on Rails   iOS / Android   AWS   VirtualBox (Vagrant)   Infrastructure as Code 15 #devsumiB7
16. うまく選択してきた(つもり 16 #devsumiB7
17. Fusicは どのように選択をしてきたか 17 #devsumiB7
18. 例えばCakePHP 18 #devsumiB7
19. #devsumiB7 19
20. Ruby on Railsに挫折した結果 20 #devsumiB7
21. 例えばAWS 21 #devsumiB7
22. 「絶対に落ちてはならない」 という無茶なありがたいお⾔葉を 期限内に実現しようとした結果 22 #devsumiB7
23. どちらも あまり良い形での選択ではない 23 #devsumiB7
24. ただ、選択はしてきました 24 #devsumiB7
25. 致命的な選択ミスも 選択をしない緩やかな死も 今のところ、ない 25 #devsumiB7
26. Fusicの⽣存戦略 のキーワード 26 #devsumiB7
27. 多様性 27 #devsumiB7
28. 多様性   実は⾔語やフレームワークを固定していない   ただ、マジョリティがあるだけ   Ruby on RailsやiOS/Android   固定することで⼀時的に開発効率が上がること は理解しているが実施していない   固定すると全滅の確率が上がる   担当するエンジニアに技術要素の決定権を渡している   当然過ぎて、多分誰も意識していない   （固定だとエンジニアがおもしろくない） #devsumiB7 28
29. 適者⽣存のための多様性 29 #devsumiB7
30. 適者⽣存   種内のある個体の遺伝しうる形質が最も環境に 適しているなら、その個体より増えた⼦孫は、 その種の中で、より増え広がる確率が⾼くなる。 結果的に現在⽣存している種は、環境に適応し 増え広がることの出来た「最適者」の⼦孫とい うことになる。（Wikipediaより） #devsumiB7 30
31. Fusicの技術選択 1.  誰かが、どこからか新しい技術を持ってくる   そのエンジニアが担当するプロジェクトで価値を出す ため 2.  その情報は社内情報共有ツールで共有される   他のエンジニアの選択肢が増える 3.  良いと思った他のエンジニアが別のプロジェクトで採 ⽤する 4.  採⽤数が増えればマジョリティを獲得する。そうでな ければ、マイノリティのまま。   Fusicのプロジェクトの性質やエンジニアの性質により 選択されていく #devsumiB7 31
32. 社内で技術の⽣存競争を起こす 32 #devsumiB7
33. マジョリティを獲得したもの   CakePHP   フレームワーク。使いやすくするためにプラグインを50以上作ったがフ レームワークのバージョンアップで全てパー。それでも根強い。リード するエンジニアに世代交代が発⽣。   Vagrant   プロジェクトごとに環境が様々なので重宝。   Ansible   サーバ設定のコード化。YAMLでシンプルにかけるので採⽤。   Capistrano   デプロイのコード化。PHPでもデプロイはCapistrano。 #devsumiB7 33
34. 今、まさに 各所でマジョリティを狙っているもの   Docker   CIから導⼊して、社内勉強会で啓蒙しつつ、簡単に使ってもらうための 整備をしている模様   Terraform   ⼀部のプロジェクトでは導⼊されたが、まだ知らないエンジニアもいる かも   Ridgepole   べき等性を保てるマイグレーションツールとして推しているが、本番環 境にRuby環境を整えるのが難   Laravel   好きなエンジニアは多いが、CakePHPよりもレールが緩いのでなかなか 推し進められず #devsumiB7 34
35. なぜ多様性を保てるのか 35 #devsumiB7
36. なぜ多様性を保てるのか   各プロジェクトごとで価値最⼤化を⽬指してい るから   プロジェクトごとでは常に最適解。会社最適はあとま わし。   あえて新しい技術、あえて枯れた技術   EOLな技術を選択しないように   会社として枷となるルールはできるだけなくす #devsumiB7 36
37. 良いと思う技術選択   ⾃分なりに解釈してプロジェクトに採⽤する   トレンドの技術をただそのまま採⽤したらダメ   適⽤は最先端のWebサービス企業から数ヶ⽉から1 年程度遅れているイメージ   時にはもとのアイデアをベースにFusicに適し た別の実装を作り上げることも   本当に必要な技術分野に集中する   プロジェクトごとの最適解を求めることは忘れないよ うに #devsumiB7 37
38. Fusicがまだ選択していない技術要素   フロントエンド   React、Reduxなど   まだCSSフレームワークレベルで⼗分なため   サーバアカウントの統合管理   LDAP、STNSなど   プロジェクトごとでクライアントも要件も異なるため、 縦割りが必要   Windows 38 #devsumiB7
39. これからも多様性を保つために 39 #devsumiB7
40. 現状の課題   社内へ技術のインプットをするエンジニアが限 られている   今後、さらに多くの技術要素が出現してくる現 状において、全エンジニアの活動が重要になっ てくる   インプットが多いほうがアウトプットの精度 も増すはず   多様性を強化したい #devsumiB7 40
41. エンジニア評価制度 41 #devsumiB7
42. エンジニア評価制度   スペシャル職位としての”テックリード”   評価指針は「技術⼒」「プロジェクト遂⾏能⼒」「発 信⼒」の3つ   半期ごとの⽴候補及び評価（評価フローは全て公開）   今期はじまったばかり   全てのエンジニアに、技術の⽣存競争に参加してもら うために   「技術の⽣存競争に参加することを評価する」ことを エンジニアに⽰す #devsumiB7 42
43. 特性をもったチーム編成 43 #devsumiB7
44. チーム再編成   いままで平均値をとった形だったチームを再編成   完全にいびつ   それぞれのチームにそれぞれの特性にあったミッショ ンを課している   そのなかでより技術のインプットを増やすためのチー ムとして基盤ユニットが編成されている   技術に特化   チームミッションがはっきりしたことでエンジニアの モチベーションにつながっている #devsumiB7 44
45. 10年 45 #devsumiB7
46. なぜFusicは開発会社として ⽣き延びてこれたのか 46 #devsumiB7
47. なぜ（⽣存戦略の⼿法として） 多様性を実現できているのか 47 #devsumiB7
48. いちエンジニアの視点から 48 #devsumiB7
49. 経営陣2⼈が エンジニア（エンジニアリング）を 信じているから 49 #devsumiB7
50. 気持ちは伝わっている   エンジニアを信じている（重要なファクターだと感じ ている）トップと、そうでないトップとでは開発会社 としての成⻑軸はまったく違う（と思う。   多様性の実現にはエンジニアの⾃主性が必要。   エンジニアの⾃主性の実現には、環境や評価制度だけ でなく、⽇頃の会社の雰囲気が重要。   その会社の雰囲気の発端はトップの気持ちではないか。   いちエンジニアが変えられるほど⽢くない #devsumiB7 50
51. 技術選択はボトムアップ 51 #devsumiB7
52. 気持ちだけは やはりトップダウン 52 #devsumiB7
53. で 53 #devsumiB7
54. 実際のところはどうなんですかね？ （聞いたことはない） 54 #devsumiB7
55. Thank you! 55 Fusicはテクノロジーが 好きなエンジニアを募集しています https://fusic.github.io
56. 56 #devsumiB7