ANDPADは新社屋に引っ越ししましたよ!

はじめに

ANDPAD工程管理チームの藤井です。

本日は記念すべきオフィス移転初日でした!

 

今回は、新オフィスのご紹介をしようと思います!

 

当日の朝

slackでも連絡があり、注意が促されていました。

f:id:yohei-fujii:20191007193832p:plain


やはり習慣というのは怖いもので、無意識に前のオフィスに行った人もいたようですw

 

駅から徒歩1分そして、ヨドバシカメラの横ということでとてもわかりやすく全然迷いなく到着することができました。

 

f:id:yohei-fujii:20191007184019p:plain

どーーーん!! 

大きいな・・・。そして入口へ行くと見つけました!

「お、うちの会社の名前だ!」

 

f:id:yohei-fujii:20191007183618p:plain

この前の8月に竣工した新築ビルということで、まだ一社しか入っていないみたいですね。

 

エントランスも広くて、ビルを貸し切っている気分・・w

場所はどこなの?

秋葉原です!ヨドバシカメラの北側です!

前のオフィスよりも駅近になり、とても便利・・。

買い物も色々便利そうです!

 

中はどんな感じ?

ひとまずエレベーターを降りてもらうと廊下があります。

f:id:yohei-fujii:20191007183601p:plain

そして受付に行ってもらうと、タブレットがあるのでそこから担当者を呼んで下さい。

f:id:yohei-fujii:20191007184915p:plain

 

執務室側から見るとこんな感じ↓↓

f:id:yohei-fujii:20191007183608p:plain

 

会議室は前は4つほどでしたが、こちらの新オフィスでは10まで増え、会議室難民はいなくなると思われます!

 

f:id:yohei-fujii:20191007183605p:plain

なかなかシャレとるのぉ。

 

ちなみにトイレもパシャり。

f:id:yohei-fujii:20191007183557p:plain

男子トイレもかなり綺麗ですね!

*女子トイレも撮影したかったのはやまやまなのですが、引っ越し初日にトラブルを起こすわけにはいかず、自粛しました。

 

そして執務室!広いな、おい。

f:id:yohei-fujii:20191007183614p:plain

営業部まで遠いぞw 開発部なのでそこまで向こうの場所に関係はありませんが、せっかくワンフロアになったので、ちょくちょく雑談やちょっかいをかけに・・・いや、仕事や打ち合わせのために行きたいと思います。

 

さいごに

今日は少しゆっくり出社したのですが、既に会社に来ていたメンバーは涼しい顔して仕事に取り組んでいました。

 

私だけでしょうか。ソワソワしていたのは。

 

急に広いオフィスだから違和感はハンパなかったですww いずれ慣れるとは思いますが、しばらくは広いオフィスにワクワクしながら仕事してみようと思います。

 

それでも、1年もしたら人も増えて狭く感じるのかなぁとも思ったり。

 

実は8階だけでなく、9階もイベントスペースとして借りているので、エンジニアイベントなど行えます! (後日別で紹介記事書きますねー)

 

エンジニア採用もしているので、ぜひぜひ遊びに来たりもしてください!

 

 

社内でテスト勉強会を始めてみた

はじめに

ANDPADのiOSアプリの開発を担当しているzigeninです。 機能追加や不具合修正のかたわら、モバイルアプリのテスト基盤の整備やテストコードの追加をしています。 今月から、社内でテスト勉強会を始めてみました。

経緯

最近、Octでは、サーバサイド、モバイルアプリで、 自動テストを充実させていく活動が活発になっています。

ただ、自動テストをするといっても、 自動テストは品質保証の銀の弾丸ではありませんし、 闇雲にテストコードを増やしても効果は小さいです(却って負債にもなりかねません)。

ですので、単に自動テストのことだけを学ぶのではなく、 自動テストの限界、様々なテスト技法も含めて学ぶことが重要と考えました。

テスト関連の技術顧問として来て頂いているDeNAのSWETの平田さんにお願いし、 勉強会を開催して頂くことにしました。

勉強会の当日について

初回は「テストの重要性」「テストとは」、といったそもそも論がテーマでしたので、 5〜6名くらしいか集まらないと思っていたのですが、意外にも20名以上集まりました。 エンジニアだけでなく、カスタマーサクセスの方なども参加して頂けたことも意外でした。

f:id:zigenin:20190910191850j:plain
テスト勉強会(1回目)の様子
※紛らわしいですが、画像の左側のディスプレイ手前の方が講師の平田さんです。

今回の内容で印象深かったのは、テストの分類です。

  • Verificaiton
    • 仕様書のとおりにソフトウェアが作成されているかを確認すること
  • Validation
    • ユーザーの要求どおりにソフトウェアが作成されているかを確認すること

QA系でないエンジニアにとってのテストは、VerificaitonであってValidationではないと思います。 ただ、仕様どおりに動けば品質が良いという訳ではありませんので、Validationの考えはとても重要だと思いました。

現状のOctでは、QA専門の社員がいないこともあって、 Validationという観点のテストはあまりできていない印象です。 (筆者がValidationという観点のテストをしていないだけで、他の方々はテストできているのかもしれません)

最後に

思っていたよりも社内で需要がありそうでしたので、 勉強会は隔週〜毎月感覚で継続して実施することにしました。

この勉強会によって、プロダクトの品質保証を支援できればと思っています。

後、上にも述べましたがOctではQA専門の社員がいません。 そのため、QAの領域が弱く感じることがあります。 0からQAの体制を立ち上げてみたいという方がいましたら、一緒に働けると嬉しいです。

施工管理チームも真のスクラムを目指して

はじめに

開発部で施工管理チームのフロントエンド 開発をしている藤井です。

施工管理チームは主に、新築施工・リフォーム施工において、着工から完工までの「実際の工事が完了するまで」を効率的に管理するための機能を担当しています。

具体的な機能には、工程表・報告・検査などがあります。

 

施工管理チームの開発フローは、これまでウォーターフォールに近いものでした。

ウォーターフォール的な開発が、決して悪い訳ではありませんが、直近の開発においてチーム内でズレが生じてしまったことをきっかけに、スクラムの本格的な導入を検討することになりました。

 

弊社の新規事業チームでは、すでにスクラムが導入されており、それに倣ってみようと考えたのです。

(新規事業チームとは、ANDPADでまだサービス化できていない建築業界の新たなニーズに対応する部隊です) 

 

 チームが抱えていた課題

私たちのチームには2つの課題がありました。

 

1つ目は、開発工数がうまく見積もれなかったことです。

その結果、ある機能のリリースを延ばす事態になってしまいました。お客様に直接影響が出ることはなかったのですが、ビジネスサイドやカスタマーサクセスメンバーに迷惑がかかってしまいました。

 

2つ目は、開発メンバー自身も負担がかかかり「上から降ってきたタスクを消化しているだけに感じてしまう」という声が上がったことです。これまでも部分的に朝会などを取り入れてコミュニケーションを図っていましたが、正直、形だけになっていた感が否めません。 

 

これを機会に、本当に良いチーム・開発とはなんなのか、チームみんなでスクラムを通して考えることにしました。

スクラムを導入してみて、施工管理チームがやったこと・良かった点などを紹介します。

 

まずチームでしたこと

開始当初、「スクラム」のことをなんとなく分かっていても、具体的にどうしたらよいか真に理解しているメンバーはいませんでした。

そこで、まずチーム内で認識を合わせたことが2つあります。

 

1つは、「誰か1人がスクラムに責任を持つのではなく、メンバー全員が理解して取り組む」ということです。

そしてもう1つは「最初から完璧に理解して行うのではなく、やりながら全員で勉強していこう」ということです。

 

スクラムマスター1人が頑張って啓蒙しても、メンバーが協力しなければ、その人が疲弊して終わるだけです。何も改善には繋がりません。

この「共通認識の構築」が非常に良い効果をもたらしました。

 

あるメンバーはスクラムの図解イラストを引っ張ってきて共有したり、またあるメンバーは本を読んできて内容を共有したりといった、学び合う雰囲気が自然とできていったのです。 

 

参考にしたもの

今回我々が参考に使ったものは、とても少なく、イラスト1枚と本1冊です。

いろんな参考資料や書籍がありますが、全てを読み込んでからやるのではなく、やりながら理解していくために、あれこれと手を出しませんでした。

イラスト

www.ryuzee.com

スクラムの全体像を再確認するために、上記に掲載のイラストを何度も見て、参考にさせて頂きました。プランニング、レビュー、レトロスペクティブをどのタイミングでやるのか、メンバー全員で都度チェックしました。 

 

書籍

スクラムに関する書籍はいくつかありますが、そんな中で今回こちらの本が参考書となりました。

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

この本が自然と選ばれた理由は、読みやすさにあります。

スクラムの基本的な解説とあわせて、実際の開発を想定したストーリーが漫画で描かれており、とても読みやすく参考になりました。大事なところは丁寧な説明も入っており、何度も振り返りながら使っていく上で、使いやすさも感じました。

分厚い本だと全員が読むまでに時間もかかってしまいますが、スクラムに対して強いモチベーションがないメンバーでも簡単に読むことができたと思います。

 

新たに使う物品

付箋

今までJira上で管理していたissueチケットですが、付箋も使うことにしました。

付箋のメリットとしては、今何をやっているか、何が残っているかひと目で見えるということにあります。

f:id:yohei-fujii:20190909185040p:plain

付箋には、Jira番号、タイトル、担当者、そしてストーリーポイントを書きました。Jiraとの併用は面倒ではないかとも懸念がありましたが、メンバーそれぞれが分担して管理すればそうでもないことに気づきました。

また、タスクを完了した際に、物理的に付箋を移動することで、「終わらせた」という感覚が強く持てることもメリットです。大したことではないかもしれませんが、意外とこれがゲーム感覚になって達成感をより感じれます。

 

ホワイトボード

これまでもホワイトボードはメモ書き等で使っていましたが、今では物理カンバンとして利用しています。

f:id:yohei-fujii:20190909185037p:plain

またプランニングの際は、裏側を使用して、機能追加や修正の際には、タスクを小分けにするため書き出したりもします。

f:id:yohei-fujii:20190907160609j:plain

(タスク書き出し中の写真)

 

プランニングポーカー

ストーリーポイントをつけるために、さっそくこちらを経費で購入してもらいました。

 

 f:id:yohei-fujii:20190909185043p:plain

https://www.amazon.co.jp/dp/B0746T9LXW/ref=cm_sw_r_tw_dp_U_x_Ct0DDb6D2MC1T

 

カードにはフィボナッチ数列が振ってあり、タスクに対して自分が思う工数を出し合って、見積もっていきます。

もちろん、全員が同じ数字にはなりません。しかし、これは良いコミュニケーションをもたらしました。

 

Aさんはある理由で「5」だと考えるが、Bさんは別の理由で「13」だと考える。その違いを話し合うことで、PM・デザイナーも含め、メンバーの認識を合わせていきます。

この作業が白熱し、一見カードでわいわい遊んでいるように見えますが、真剣にそのタスクについての議論ができ、懸念点や難易度などの理解を深めることができました。

 

f:id:yohei-fujii:20190907160628j:plain

(スプリントプランニング中の写真)

 

効果はどんな感じ?

まだ初めて1週間ちょっとですが、メリットをすでに感じています。

それは「コミュニケーションが増えて、相互理解が深まった」ことです。

(ここでいう相互理解とは、PMと開発メンバー、そしてデザイナー間でという意味です)

 

これまでお互いに「彼はこんなタスクがあるんだろうなぁ」となんとなく把握している曖昧な状況でした。

しかし、一緒にスプリントプランニングを行い、他のタスクも洗い出すことでそれぞれが持っているタスクが明確になったのです。また物理ボードを使うことで今誰が何をやっているのかが一目でわかるという状況になりました。不思議とお互いの信頼度も上がったように感じます。

 

朝会の進め方も変わってきました。それまでは、1人の疑問点から議論が発展して、関係者だけが話し続ける、といったことがあったのですが、「それに関係あるのはAさんとBさんだけだから、朝会後に話そう」と場を切り分けるようになりました。 

 

さいごに

スクラムが走り出してわずかですが、今後もチームメンバーで話し合いながら改善を進めていきます。

また別の記事で、デイリースクラムにおいて工夫していることなどをまとめたいと思います。

 

 

 

フロント側エラー対応にBugsnag活用

はじめに

フロントエンドチームの藤井です。

今回は、Bugsnagの導入について紹介します。

 

Bugsnagとは

アプリケーションのエラー監視ツールですね。

 

www.bugsnag.com

 

以前よりANDPAD本体には導入してされておりましたが、フロント側の一部分をVueに置き換える過程で抜けておりましたので、そちらにも導入することになりました。

 

f:id:yohei-fujii:20190720022125g:plain

(↑写真出力ドラッグ&ドロップページ)

 

f:id:yohei-fujii:20190720021952g:plain

(↑新工程表の画面)

 

導入してみる

こちらのページを参考にしながらすると、サクッと終わります。

docs.bugsnag.com

 

本番環境でのみ通知を飛ばしたいので、bugsnag.jsでこのように書いて読み込ませました。

import Vue from 'vue'
import bugsnag from '@bugsnag/js'
import bugsnagVue from '@bugsnag/plugin-vue'

if (process.env.NODE_ENV === 'production') {
const bugsnagClient = bugsnag('hogehogehoge') // APIKEY
bugsnagClient.use(bugsnagVue, Vue)
}

 *hogehogehogeは登録時に割り振られたAPI keyをご利用下さい

 

実際に導入が完了すると、コンソールにこのように表示されます

f:id:yohei-fujii:20190718110035p:plain

 

運用してみる

現在、基本的にフロント側では、1. Weekly Summaryを参考に、そして2. Dashboardを詳しく見るという流れで確認しています。

 

1. Weekly Summary

こちらは週次でサマリーがメールで届きます。新規発生件数や、どのページで起きているのかなど概要を確認することができます。

 

 

f:id:yohei-fujii:20190718101301p:plain

 2. DashBoardから

その次に、BugsnagのDashboradへ行き、そこに出ている一覧を眺めます。本来は、全て対応したいのですが、時間も限られていますので、最低限自分の担当している箇所を探して対応するようにしています。

 

f:id:yohei-fujii:20190718101949p:plain

 

上記のように今週も「新工程表」と「写真出力」のバグを発見しました。

 

対象の項目をクリックすると以下のことがわかります。

- どのような操作をした時に起きたのか

- どのデバイスで起きたのか

- どのファイルのどの行が起因になっているか

 

あとは、対象のバグ起因になっている箇所に行き、修正してPRして完了です。

 

まとめ

実装時に気をつけてはいるものの、漏れやブラウザによる差異の吸収ができていないために、何かしらのエラーが出ることが多いです。

 

完璧なエラーの出ないプロダクトは理想ではありますが、なかなか難しい現実でもあります。ですので、Bugsnagなどを用いることで、いち早くエラーに気づき、対応を行うという体制にしています。

 

本当に便利なツールですので、活用してみることをオススメします。

最後に

一緒にANDPADを作って行ってくださる方を探しております。

 

会社の雰囲気やどのような開発環境かもわかるかと思いますので、ぜひ以下のインタビュー記事をぜひご覧ください。

 

 

 

社内ランチLT会始まったぞ!月1開催

はじめに

フロントエンドチームの藤井です。

今月から「社内ランチLT」を開催する運びになり、そのレポートになります!

経緯

以前からちょくちょくと、もっとカジュアルにLTする機会が欲しいと社内で声が上がっていました。

 

そんな中、いつもANDPADの開発を手伝ってくださっている、からまげさん(@kara_mage) からslack上で提案があり開催する運びとなりました。

f:id:yohei-fujii:20190711152210p:plain

 

賛同の声が上がると、その後の企画力は早かったです。概要をポストにまとめてslackで通知。何週間も前から何度もこのポストがチャンネルでシェアされました。(楽しみにしてる感が伝わる・・w)

f:id:yohei-fujii:20190711201019p:plain



 

(ただ、当日ギリギリまで場所を確保していないという致命的ミスが発覚し、開催が危ぶまれましたが、無事フリースペースで行いました)

ランチLTとは

気軽にLTしたい人や参加したい人が、ランチをとりながらカジュアルに行うLTです。普段人前で話す機会がない人や、「外部イベントでの登壇にいきなりはちょっと・・」という人にとって心理的なハードルを下げ、チャレンジするための場にしたいと考えて企画しました。社内限定での開催で、緊張せずに気軽にディスカッションする場です。

やってみた

 まずは、発起人のからまげさんから開催のご挨拶。

f:id:yohei-fujii:20190711152332p:plain

みんな昼飯を準備して参加してます。 リスナーもたくさん集まり、ワイワイとして雰囲気の中開催しました。

 

初回となる今回は、3名によるLTでした。

 

まず、デザイナーの後藤さんから、「これだけ守ればみやすくなるデザインの基礎」解説LT。株式会社Xemonoのとりいめぐみさんの公開されていらっしゃるスライドを使っって「デザインとはなんぞや」というところを説明してくださいました。

 

次に私の「1人1人が楽しくより成長するために ~ 『エンジニアの生産術』を読んでみて」という内容での紹介。

 

そして最後に、SREからフロントに越境している須恵さんによる「Dockerの基本概念」の紹介でした。

 

f:id:yohei-fujii:20190711152342p:plain

 

ゆるくアウトプットの場ということでしたが、私も須恵さんもスライドを作って準備してきたことで、ガチなLTになってしまいました・・。でも、インタラクティブなLTになったし、笑いありと楽しい時間となりました。

 

f:id:yohei-fujii:20190711152346p:plain

 

フリースペースで行ったのですが、途中からエンジニアだけじゃなく、営業さんや他の部署の人たちによる立ち見もできて、盛大なイベントになり嬉しい限りです。

最後に

こんな感じで、初回がうまく行きましたので毎月行うことに決定しました。早速次は8月22日ということです。

 

いろんな人がこういう機会を利用して、アウトプットの練習の場として使っていけるといいですね!

 

もし興味ありましたら、以下のインタビュー記事をぜひご覧ください。会社の雰囲気など分かるかと思います。

 

 

 

ALB Ingress Controllerの使い方

はじめに

SREチームの須恵です。

前回の記事ですこし言及しましたが、今回は続編としてALB Ingress Controllerについて書こうと思います。

これは何?

Amazon EKSでIngressリソースを機能させるために使えるIngress Controllerの一種です。Ingressを作成すると、自動的にALBが作成・設定されます。

github.com

Ingressって何?

公式ドキュメントから引用します。

Ingress - Kubernetes

Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

Ingressは、クラスター外からクラスター内のサービスへのHTTPおよびHTTPSルートを公開します。トラフィックルーティングは、Ingressリソースで定義されたルールにより制御されます。

Ingress Controllerって何?

An Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.

Ingress controllerはIngressを満たす責任を持ちます。通常はロードバランサーを使いますが、トラフィックを処理するためにエッジルーターや追加のフロントエンドを設定することもできます。

ここからは実際の使い方を紹介します。

IAMポリシー作成

後述のロールにアタッチするためのポリシーを作成します。

サンプルがあるので、とりあえず使い始めてみるときはこれを使わせてもらうとよいと思います。

※リンク先はバージョン1.1.2のサンプルです。使用するコントローラのバージョンとの差異に注意してください。

IAMロール作成

ALB Ingress Controllerに使用させるロールを作成します。

ここで、まずPodに任意のロールを使用させられる環境が必要となります。 手前味噌ですが、以前書いたこちらが参考になると思います。

kube2iamの仕組みと使い方 - Oct Tech Blog

ロールのアクセス権限に関しては先ほどのポリシーをアタッチするだけですが、加えて信頼関係の編集が必要です。以下を追加します。

    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/kubernetes-worker-role"
      },
      "Action": "sts:AssumeRole"
    }

"AWS": "arn:aws:iam::123456789012:role/kubernetes-worker-role"の部分は、使用するワーカーノードに合わせてください。

RBAC用リソース作成

ClusterRole, ServiceAcocunt, 両者を結びつけるClusterRoleBindingを作成します。

サンプル通りで構いません(例によってバージョンには注意、リンク先は1.1.2用)。

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/name: alb-ingress-controller
  name: alb-ingress-controller
rules:
  - apiGroups:
      - ""
      - extensions
    resources:
      - configmaps
      - endpoints
      - events
      - ingresses
      - ingresses/status
      - services
    verbs:
      - create
      - get
      - list
      - update
      - watch
      - patch
  - apiGroups:
      - ""
      - extensions
    resources:
      - nodes
      - pods
      - secrets
      - services
      - namespaces
    verbs:
      - get
      - list
      - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app.kubernetes.io/name: alb-ingress-controller
  name: alb-ingress-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: alb-ingress-controller
subjects:
  - kind: ServiceAccount
    name: alb-ingress-controller
    namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app.kubernetes.io/name: alb-ingress-controller
  name: alb-ingress-controller
  namespace: kube-system
...

Deployment作成

コントローラをクラスターで動作させるためのDeploymentを作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: alb-ingress-controller
  name: alb-ingress-controller
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alb-ingress-controller
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      annotations:
        iam.amazonaws.com/role: さっき作ったロールのARN
      creationTimestamp: null
      labels:
        app: alb-ingress-controller
    spec:
      containers:
        - args:
            - --ingress-class=alb
            - --cluster-name=クラスターの名前
            - --aws-vpc-id=クラスターVPCのID
            - --aws-region=クラスターのリージョン
            - --aws-api-debug
          image: docker.io/amazon/aws-alb-ingress-controller:v1.1.2
          imagePullPolicy: Always
          name: server
          resources: {}
          terminationMessagePath: /dev/termination-log
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      securityContext: {}
      terminationGracePeriodSeconds: 30
      serviceAccountName: alb-ingress-controller
      serviceAccount: alb-ingress-controller

docker.io/amazon/aws-alb-ingress-controller:v1.1.2 ここは適宜必要なバージョンを指定してください。

PodがAPIサーバーにアクセスする際、先ほど作成したサービスアカウントalb-ingress-controllerを使用するように設定しています。また、アノテーションでは同じく先ほど作成したロールを指定しています。

コントローラは以下の権限でリソースにアクセスを行います。

  • Kubernetesリソースへのアクセスは先ほどのClusterRole
  • AWSリソースへのアクセスは先ほどのIAMポリシー

Deploymentの作成が完了し、Ingress Controllerが動き出したので、Ingressを作成することによりALBを自動設定してアプリケーションへルーティングする準備ができました。

ここからは、簡単な例でアプリケーションへのルーティング方法を紹介します。

ルーティング先アプリケーションの例

重要なのは、タイプをNodePortにするという点です。ALB Ingress Controllerを使用する場合、ServiceはNodePortタイプで作成しましょう。

apiVersion: v1
kind: Service
metadata:
  name: hoge-app
spec:
  selector:
    app: hoge-app
  ports:
  - name: http
    port: 3000
    protocol: TCP
    targetPort: 3000
  type: NodePort

DeploymentやPodのYAMLは割愛しますが、上記の例ではselectorapp: hoge-appとしているので、そのようなラベルが付いている必要があります。

Ingressの作成

下記の例では、80番と443番ポートにリスナーを作成し、80番へのリクエストは443番にリダイレクトするようなルールのALBが作成されます。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress ←複数立てる予定なら区別しやすい名前を付ける
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/subnets: クラスターのサブネットID3つをカンマ区切りで書く
    # HTTPSリスナーを使うなら必要
    alb.ingress.kubernetes.io/certificate-arn: 証明書のARN
    # リスナーのポート番号はここで決める
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    # リダイレクトを使うなら必要
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
spec:
  # ALBのリスナールールと対応
  rules:
  - host: hogeapp.hoge.com
    http:
      paths:
      - path: /*
        backend:
          serviceName: ssl-redirect
          servicePort: use-annotation
      - path: /*
        backend:
          serviceName: hoge-app
          servicePort: 3000

アプリケーションがインターネットに公開され、ブラウザからアクセスできるようになりました。

おわりに

ALB Ingress Controllerを使ってEKS上のアプリケーションへルーティングする方法についてご紹介しました。

採用サイトにて、テクノロジースタックや環境について公開しています。Kubernetesに限らず、ご興味をお持ちいただいた皆様のご応募をお待ちしております。

engineer.88oct.co.jp

デブサミ2019夏の登壇を終えて

はじめに

フロントエンドチームの藤井です。

この度、「Developers Summit 2019 Summer」に行ってきました!4月のRuby Kaigiに次いで、開発部にとっては今年度2回目の大きなイベントへの参加となりましたね。

 

event.shoeisha.jp

 

スポンサーでもあり、登壇セッションもありましたので、数週間前から色々と準備もしておりました! 会場となったのはこちら

 

f:id:yohei-fujii:20190703132159p:plain

 「御茶ノ水ソラシティ」

 

今回のデブサミのテーマは「エンジニア組織とソフトウェアのアーキテクチャを再考する」ですね。オクトもエンジニア組織として拡大しており、ちょうどマッチしたトピックでありました。 

 

f:id:yohei-fujii:20190703105843j:plain

ドドン!

ロゴも上の方にデカデカと掲載して頂きありがたいです!

 

Job Boardなるものもあり、配布資料も貼らせて頂きました。

f:id:yohei-fujii:20190703150537p:plainf:id:yohei-fujii:20190703132147j:plain

(↑ちゃっかり、セッション案内まで書く人事のじっちゃん)

 

セッションの合間合間には、ブースまわりに多くの人が訪れていました。

f:id:yohei-fujii:20190703150849j:plain

 

人気のセッションは、開始前から行列がすごいですね。 

f:id:yohei-fujii:20190703150841j:plain

 

さてそんな中、B会場で15:50からオクトの登壇セッションです。

event.shoeisha.jp

当日までバタバタしならも資料準備でき、いよいよこの日を迎えました。  

f:id:yohei-fujii:20190703105440j:plain

(↑控え室で登壇する3名と共に)

いよいよ登壇の時間

今回は、3名で違った内容を紹介することに。

f:id:yohei-fujii:20190703150835p:plain

(↑セッションで配布した資料と開始前の会場)

 

それぞれがオクトにジョインした時期も違いますし、そのことにも触れてご紹介

f:id:yohei-fujii:20190703153300p:plain

(↑登壇資料p5より抜粋)

 

 1人目:CTO 金近「&ANDPADとは。創業期と世界観

f:id:yohei-fujii:20190703132122j:plain

 

どのような経緯で、施工現場の問題を解決しようという流れになったのか、なぜANDPADが作られることに至ったのかなどです。

 

これは多くの新しい社員にとっても知らなかった内容があったりしたので、資料を社内共有した際に良い反響がありました。こういうイベントがあると言語化して資料にまとめるので、やっぱりいいね!ってなりました。

 

テクノロジーを武器に、社会変革にチャレンジする」というビジョンを掲げていますが、そのためにも「プロダクト構造的マイクロ化」と「組織構造的マイクロ化」というキーワードに触れました。

 

2人目:CMO 山下「エンジニアが開発を最高に楽しむ場を作る」 

f:id:yohei-fujii:20190703132135j:plain

 

「エンジニアにとって『楽しい』とは?」というポイントから入り、オクトにジョインしてから取り組んだこと、そしてその過程で何が楽しいと感じ、何が楽しくないと感じたかなど紹介を紹介しました。

 

普段から個人でもアプリなどの開発を行っておりますし、新規チームでは新しい技術の導入を進めている本人ですので、そのことに触れながら、どういった個人もしくはチームであるのが理想なのかということです。

 

その中で、「フルサイクルエンジニア」に触れました。

実装だけではなく、要件定義やデザイン、テストまで1人で回せるメンバーが集まるチームはお互いカバーしあえますし、サイクルをどんどん回していけるからですね。

 

3人目:PM彌冨「少数精鋭開発から 大人数開発組織への移行」

f:id:yohei-fujii:20190703132129j:plain

 

ここ最近エンジニアの数がどんどん増えている中で、実際にどのような組織づくりをしていっているのかの紹介です。

 

オクトの開発部では「最小マネジメントで自走する組織」かつ「フラットでオープンな組織体制」を目指しております。そのために、活用しているツールであったり、個々人に持ってもらいたい行動規範というものがあります。

 

平常時はティール型組織でありながらも、緊急時にはピラミッド型組織で柔軟に対応するという組織ビジョンもあります。

  

ここまで 簡単に概要のみ紹介しまいたが、こちらが実際に登壇で使用した資料になります。より詳しく知りたい方は、ぜひ目を通してみてください。

 

 

 

登壇後には

登壇が終わると、Ask the speakerという場所に移動して、参加者と名刺交換や交流がありました。「さいきょうのチームをつくる」ということに触れていたので、そのことについて興味を持ってくださった方がいたのは嬉しいですね!

 

f:id:yohei-fujii:20190703132152j:plain


立ち寄ってくださった方々、ありがとうございました!

 

終わってみて

登壇の最初に、「ANDPADをご存知の方いらっしゃいますか?」と質問をしましたが、手が上がったのは数名でした。この事実に、まだまだ認知度低いなと我々みんな感じたのですが、それとともにすぐに「これは伸び代だ!」とポジティブに捉えられていたメンバーはさすがでしたw

 

今後もオクトは様々なイベントに参加して行きます。もし、どこかで見かけたら気軽に声をかけてみてください。

 

積極採用中

弊社では、業務拡大中でエンジニアを積極採用しております。みなさまのご応募お待ちしております!!エンジニア採用サイトに募集職種や、会社の雰囲気の分かるインタビュー記事があります。是非ご覧ください。