こんにちは。QAグループ所属のQAエンジニア松谷（まつや）です。 LIFULLでは新卒エンジニアに27日間の研修を行なっています。 その研修の中で、 丸一日を使ったテストワークショップ も行われています。 今回はそのテストワークショップについてご紹介します。 キーワードは「テストを考えられる」 です。      LIFULLの開発体制とQAグループについて まずは認識を合わせるためにLIFULLの開発体制とQAグループの業務について説明します。 LIFULLでは月に200件ほどの施策がリリースされています。 それら施策は、主に企画者、開発者、デザイナーの三職種のメンバーで構成されています。 ここでお伝えしたいことは、 テスト専門のメンバーは基本的にはいない ということです。 リリースする施策については、 施策のメンバーが責任を持ってテスト計画〜実行までを行っています。 数年前は第三者検証が主流だったため珍しい形でしたが、昨今のスクラムの形ではよくある形かと考えます。 ここでテスト=QAと思われている方は、QAグループが何を行なっているか疑問に思われるかもしれません。 QAグループは社内横断組織であり、各所の品質保証活動のサポートを行なっています。 例えば、施策のテスト計画の手伝い、品質保証についての相談などです。 以下の QMファンネルというモデルの「QAコーチ」「QAコンサルタント」 にあたります。 （テスト=QAの認識の方は、このモデルの「フェーズゲートQA」部分のみにフォーカスしていそうです） （出典 : 品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版) Yasuharu Nishi)   テストワークショップについて テストの考え方を伝えている エンジニア志望の方々は、学校やプライベートで開発については深く学んできています。 ですが、テストについて体系立てて学んできた方は多くないのが現状です。 結果、 実装したものが実装した通り動くかチェックすることのみがテストの全てであるという認識の方もいます。 Unit Testの責任範囲ではそのように言えるかもしれませんが、企業が提供するシステム全体に対するテストとしてはそれでは不十分です。   テストワークショップでは 全体を通してのテストをどのように考えていけばよいかという「考え方」を中心に説明 しています。   教える内容はJSTQBに（基本的には）準拠 教える内容は基本的には JSTQB (国際的なテスト技術者認定資格ISTQBの日本版)に準拠しています。 わかりやすくするためにそのままの定義を伝えるのではなく、例などを用いてわかりやすい言葉に噛み砕いて説明を行います。   またJSTQBの全項目を教えているわけでもありません。大事なところをピックアップして伝えています。 （参考： JSTQB Foundation Level version2018V3.1.J03 ) JSTQBに沿ってお伝えしている理由は以下です。 正しいテストの知識 世界中のどこでも通用するテストの考え方 これらを身につけてから業務に入っていただきたいと考えています。 それにより「JSTQBではこのように言われていることが、LIFULLではこう実践されているのか」とわかりやすくなるためです。   テストプロセスを伝えている テストをあまり知らない方の場合、テスト実行することだけがテストだと思っていることもあります。 また新卒研修の場合、最初にテスト実行をやってもらうのだから実行工程のやり方を細かく教えよう、という会社もあります。 LIFULLのエンジニアとしては、与えられたことを与えられた通りやれるだけではなく、テストを考えられるエンジニアになって欲しい のです。 よってテスト実行のやり方だけではなく、「何をどうテストするのかを考える」ということを伝えるため、テスト分析からテスト実装の流れ、つまりテストプロセスを使ってお伝えしています。 テストプロセスを知ることで、テストについて何をどう考えていけばよいかの道筋がわかる ためです。 (テストプロセスについては JSTQB Foundation Level version2018V3.1.J03 P19〜参照)   各項目ごとに（ほぼ）ワークがある 教えている項目は多岐に渡りますが、 それぞれの項目でワークがあります。 そこで実際に考えてみて手を動かしてもらいます。 個人ワークを行ってもらった後に、少人数グループでのディスカッションを行ってもらいます。 これは、 個人でしっかりと考えた後に周りのメンバーと話し合うことで、他者の意見から新しい気づきを得たり理解を深めやすくなるから です。   ワークの一例を記載します。 以下は「マイヤーズの三角形」と呼ばれる問題です。 （出典：ソフトウェア・テストの技法第２版 Glenford J. Myers） テストワークショップで、テストの考え方を伝える前に行っているワークです。     このワークは一見すると簡単そうです。 ですが 「テストは仕様通り動くことを確認すればOK」と考える方がひっかかる問題 です。 またグループディスカッションでは、入力値以外にも動作環境の観点も挙がりました。 こういった話も踏まえ、 テストで考えるべきことは意外と多いことをお伝えしています。   最終ワーク テストワークショップの最後には おおよそ３時間ほどの本格的なテストの実習 があります。 QAグループが作ったテスト用プロダクトに対して、少人数のグループで実際に以下のことを行なってもらいます。 仕様把握、テスト分析 テスト設計 テスト実装 テスト実行 / 不具合起票 グループ発表 これらは学んだことを総動員しなければいけません。 とはいえ、ただ「やってください」といっても皆さん不慣れですので動けません。 そこで各プロセスをどう考えていけばよいかのヒントは出しています。 ただ大まかなヒントなので、 グループ内で考え、話し合い、協力しながらでなければ決められた時間での進行は難しい ようになっています。 グループ発表では以下の内容で発表してもらっています。 何を重要と考えたか なぜ重要と考えたか どうテストをしたのか 発見したバグ 良かった点 悪かった点 最後に、最終ワークの私の所感を記載して終わります。 ３時間という限られた時間でしたが、作成されたテストケースでは重要なポイントの確認は押さえられており、仕様をなぞったテストだけでは見つけられない問題も見つけられるものとなっていました。 また「◯◯を確認したいから、このように確認する」といったテストの意図が第三者にも伝わるテストケースです。 そういったテストケースを書けていますので、発表でも「こういった理由でここが重要なので、このようにテストを考えていった」と自分たちの考えと実施したテストについて説明ができていました。 もちろん全体的には荒削りなところも多いですが、最初の「実装したものが実装した通り動けばいいのではないか」の状態から、テストを考えられるようになっていることを感じ取ることができました。   まとめ 何をテストすればよいのか、それらをどのようにテストをするのか。 これらが考えられなければ、思考を放棄し仕様をなぞるだけのテスト実施になり、抜け漏れが多かったり非効率なテストになってしまうことでしょう。 それにより企業として信頼を失ってしまうような大問題を発生させてしまうかもしれません。 「テストは仕様通り動くかだけを確認すればいい」という考えから、何をどうテストしていけばよいか考えられるようになるためのテストワークショップの話でした。 LIFULLでは、何をどうすればよいか自ら考えられるエンジニアを育成していきたいのです。 このブログの話はLIFULL主催のLtech#19でもお話しさせていただきました。 ご興味がある方はスライドをご覧ください。   LIFULLでは新卒エンジニアに 丸一日のテスト研修を行なっている from LIFULL Co., Ltd. www.slideshare.net   最後に教えている項目を列挙します。ご参考になりましたら幸いです。 なぜテストをするのか マイヤーズの三角形問題 テストプロセス テストレベル / テストタイプ レビュー コードレビュー テスト技法 ホワイトボックステスト C0カバレッジ C1カバレッジ ブラックボックステスト 同値分割 境界値分析 デシジョンテーブル オールペア リスク バグ管理 テストケースの書き方 テスト実習

こんにちは！Ltech運営チームの引持です。今回は、2021年8月19日(木)に開催した「QA Talk Night~LIFULL HOME'Sを支える品質保証の取り組み~」についてレポートします。 lifull.connpass.com Ltechとは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。特定の技術に偏らず、様々な技術の話を展開していく予定です。 品質保証の取り組み Ltech#19のテーマは、LIFULLでの品質保証の取り組みについてです。LIFULL内で品質保証を担当するエンジニアに、SaPIDの導入についてや新卒エンジニアのテスト研修についてを語っていただきました！ SaPID を導入するまでとそれから 最初の発表はソフトウェアプロセス改善手法「SaPID」の導入までの遍歴と導入してからの工夫についてのお話です。 SaPID を導入するまでとそれから from LIFULL Co., Ltd. www.slideshare.net 自チームへSaPIDを導入するにあたっての背景、課題の洗い出しから実際の導入、導入した結果、そしてさらなる課題まで時系列に沿って話して頂きました。 導入したメリットとして、問題分析の癖がつくことやチームの課題に対する認識共有がしやすくなった等が挙げられており、個人だけではなくチームとしても成長できる良い手法だと感じました。 発表を聞いて私自身もSaPIDにとても興味が出てきたので、本を購入して自チームへ普及してみようかと思っています。 LIFULLでは新卒エンジニアに丸一日のテスト研修を行なっている 続いての発表はLIFULLでは新卒エンジニアにテストの基礎となる考え方をJSTQBというテスト技術者の試験に沿った内容で座学、およびQAグループが開発したシステムを用いての実習による研修を行なっており、その研修についてのお話です。 LIFULLでは新卒エンジニアに 丸一日のテスト研修を行なっている from LIFULL Co., Ltd. www.slideshare.net 弊社ではテストの基礎を理解してもらうために、新卒エンジニア向けの研修としてテストワークショップを丸一日使って行っています。 内容としてはJSTQB（国際的なテスト技術者の認定資格ISTQBの日本版）に準拠した座学、座学で得た知識をもとにワークをいくつか行います。 最終ワークとしては実際のテスト用のプロダクトに対してテスト分析、テスト設計、テスト実装、テスト実施までを行います。 「テストを実行すること」だけがテストではなく、「何をどうテストするのか」まで考えられるようになることを目指しているとのことです。 研修後のアンケートでもその部分がきちんと伝わった感想を得られており、業務でも得られたテスト技術を存分に活かして頂きたいと感じました。 私も新卒の時に受けたかったなと思いました。 まとめ 今回はLIFULLの品質保証の取り組みについて、QAチームのお二人に話して頂きました。 発表した内容以外にもQAチームはLIFULL全体の品質向上のための取り組みを日々行っており、全社的に品質の考え方を根付かせ、LIFULLというブランドで品質が保証されていると世間に認知されることを目指して日々業務にあたっています。 最後に Ltechでは、LIFULLエンジニアが中心となって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。今後も Ltech を積極的に開催していきますので、ぜひ気になった方は、connpass で LIFULL のメンバー登録をよろしくお願いします！ lifull.connpass.com

こんにちは。プロダクトエンジニアリング部でエンジニアリングマネージャーをやっている野澤です。現在LIFULLのプロダクトエンジニアリング部では個人のスキルを高めることを目標の一つとして取り組んでいます。 この記事を読んでいる皆さんもご承知のとおり日々技術は進歩しており、追いついていくのも大変です。当たり前のことかもしれませんが、個人のキャリアのためにも、企業間の激しい競争に負けないためにも、また企業の理念を実現するためにもエンジニアには高い技術力が要求されます。 もちろん自分で勉強して、新しい仕事にも挑戦して、勝手に成長していくエンジニアもいますが、全員が全員そういうわけではないと思います。 前職でも、なかなかスキルアップできないメンバーをどうやって成長させるか私自身思い悩んだ経験があります。例えば、スキルアップ目標を掲げても行動しない、忙しくて時間が取れない、気が向かない、何が嬉しいのか分からない、かつては自己研鑽していたがやらなくなってしまった、など。 こういったことは皆さんの周りでもありえることではないでしょうか。 私が所属するプロダクトエンジニアリング部5ユニットでも、自己研鑽についていろいろ取り組んでいます。多少うまくいったところもあるため、少しご紹介できればと思います。 やったことと結果のサマリー まず、どんなことをやったのかとその結果どうなったのかを簡単にご紹介します。 やったこと なんで自己研鑽が大事なのかディスカッション 自分が行ったInput/Outputの簡単なログを作る slackで書籍や勉強会の情報共有チャンネルを作る 発表機会(LT)を増やす ※後ほど詳しく説明します 結果 4月から3ヶ月間、上記の取り組みをしてみての感想をアンケート形式でメンバーに聞いてみました。 Input Inputの量が増えた(100%) 以前よりも書籍を読むようになった(75%) Inputに対してのアンテナの感度が高くなった(62%) 以前よりも外部の勉強会やセミナーに参加するようになった(50%) Inputが増えて楽しいと感じるようになった(87.5%) アンケート結果: インプットについて Output Outputの量が増えた(25%) 以前よりもブログや勉強会、LTでの発表内容が良くなった(50%) 以前よりも仕事における工夫の幅が広がった(38%) アンケート結果: アウトプットについて Outputには課題はあるものの、Inputにははっきりとした改善の兆候が見られます。では取り組んだことをご紹介できればと思います。 やったこと 1. なんで自己研鑽が大事なのかディスカッション まず「そもそもなんで自己研鑽するんだっけ？」というテーマでディスカッションしてもらいました。 チームの中には「今まであまり考えたことがなかった」という人もいれば、「改めて考えるとなんでだっけ」という人もいました。上から「スキルアップしてください」というのは簡単ですが、まずは自分の頭で「なんでスキルアップしなきゃいけないのか」を考えてもらう必要があります。またチームで話し合うことでフラットに他人の意見を聞くことができるので、「そういう考え方もあるのね」と思考の幅を広げることができます。 例えば技術力が向上すると給料があがる、仕事が選べる、転職のチャンスが広がるといった個人のキャリアに関することもあれば、価値提供のスピードを上げられる、理念の実現に貢献できるといった会社目線での意見もありました。また率直に「技術力が上がるといろんなことができるようになって単純に楽しい」といった意見もありました。 ディスカッションの様子 そのあと、自己研鑽ができている理想の状態についても考えてもらいました。理想の状態とは、しっかり自己研鑽ができている人はどういう行動をしているのか、結果としてその人はどういう状態になっているのかについてです。 これもチームのメンバーと話し合うことで、いろんなあり方・やり方に気づくことができます。「理想の」というところもポイントです。理想的な状況を想像できるようになると、なれるかもしれない自分の可能性に気づくことができます。例えばOSSのコミッターになっているとか、大きなイベントで登壇している、社外からも信頼されていて相談されるなどです。 理想の状態 その後、理想に対する自分たちの現状についても議論もしてもらいました。現実はなかなか理想通りにはいきません。仕事でスキルアップするのが一番効果的ですが、毎回スキルアップにつながる仕事があるとは限らないよね、といった声もありました。 ここで理想と現実のギャップを認識してもらいます。そのことによって、じゃあどんなことができるのか？どうやって変えていくのか？ということをチームが自然に考え始めます。 その上でユニットとして次のようなことを取り組むことにしました。 2. 自分が行ったInput/Outputの簡単なログを作る 自分がどんな本を読んでどんなことを感じたり何を学んだかというのは、サマリーやブックレビューを書かない限り忘れてしまうことが多いのではないでしょうか。参加したセミナーの感想なども同様です。そこで、簡単な表形式でインプットしたことをログとして残すような取り組みをしてみました。 社内ブログで公開している私自身のInput/Outputのログ ログにインプットしたことが蓄積されていくと自身の成長も感じるし、達成感もあって楽しくなってくるようです。アンケートでもそういった回答をした方が多かったです。楽しくなると継続のハードルが少し下がり、自己学習が習慣化されていきます。 また、時々このログを振り返ってみると、どんなことを知りたくてどんなジャンルの本を読み続けていたのか、この時期は何に関心があって、どんなセミナーに参加していたのかを思い出すことができます。その上で自分が何をどこまで理解することができて、何に関心があるのか、あるいは何についてはたいして興味を持てなかったのかが分かるようになります。つまり自分の好みや強みの傾向を分析できるようになります。そのことによって、今後の成長の方向性を考えたりすることができるようにもなります。 また、1on1のときなどに一緒にこのログを見ることで、「この本読んだんだね。どうだった？」みたいな会話が生まれたり、「このセミナー参加してたんだね。私は○○についての話が面白いと思ったけど、どう思った？」みたいな会話が生まれ、理解が広がっていきます。お互いおすすめの本を紹介しあったりすることもあります。 またアウトプットしたことも同様にログをつけてもらうようにしました。この取り組みを始めたのが４月ですので、まだそんなにアウトプットが書けていない人もいます。インプットはできてもアウトプットをするまでの余裕が無いとか、どんなふうにアウトプットしたらよいか分からないと考えるメンバーが多いようです。このとおりアウトプットにはまだ少し課題が残ります。 ただ私自身は普段の業務でもインプットした知識が以外にも活用できていることに気づいたり、せっかくなので業務でアウトプットする機会を作ろうとしていることにも気づきました。アウトプットすることによって、周りからFBをもらって更に理解が深まるという体験もしています。 またアウトプットの蓄積がされてくると、インプットとアウトプットの関係が見えてきたり(5月に読んだ本の知識が6月の業務で役になっているなど)、インプットとアウトプットが循環して、より学びが深くなるといったことが起こります。こうなってくると、自己研鑽がより楽しくなるのではと思います。 3. slackで書籍や勉強会の情報共有チャンネルを作る 私の部署ではslackを使っているのですが、とあるメンバーがおすすめの書籍や勉強会の情報を共有するチャンネルを作ってくれました。それによって、面白そうな新刊の情報や、イベントやセミナーの情報が活発に交換されるようになりました。一緒に同じイベントに参加して感想を話し合ったりというようなことも起こっています。AmazonのKindle本セールなど、お得な情報も共有されて役に立ちます。 一人だとなかなか自己研鑽するのが難しい人でも、他の人と得た知識を共有しあったり、コミュニケーションが生まれると楽しさを感じることができて持続的にインプットすることができるかもしれません。 4. 発表機会(LT)を増やす また月に1回、インプットしたものをアウトプットする機会としてLTの時間を作ってみました。 発表時間は10分と短く、そこまで資料の完成度や準備の時間も求めないことにして、リラックスして発表できることを目指しています。実際にフィードバックをもらえることもモチベーションになったり、LTで話す内容を意識しながらインプットする方もいるようです。 その他の取り組み 以前から行っていた取り組みですが、社内勉強会をメンバーたちが自主的に開催しています。気になる本の輪読会やとある技術についてのハンズオンのような勉強会を、興味のある人同士で隔週くらいで活動しているようです。 また業績評価にはしないものの、アウトプットの目標、例えばQiitaや会社の公式技術ブログ(今ご覧になっているブログです)への投稿数や社内でのLT・発表の回数を設定して取り組んだりもしています。 今後の展望と課題 アンケートや普段のメンバーの動きを見ている限り、このような取り組みを行ったことでメンバーのInput/Outputに対する意識はかなり変わったように思います。私としては以下の2つの理由があったと思っています。 自己研鑽を見える化することで、自分がどれだけ頑張ったか分かるようになり達成感を得られるようになったこと 自己研鑽をその人だけの孤独な取り組みにせず、みんなで取り組めるようにしたこと ご参考になれば幸いです。 今後はInput/Outputのログを全社公開し、お互いにどんなことを勉強しているのかを知れるようにすることで、おすすめの本やセミナー、資格などの情報交換を活発にしたり、理解を深め合うような状況を促進していきたいと考えています。 LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは、データプラットフォームグループの樋口です。エンジニアとしてデータ基盤の構築・運用を約4年ほど担当しています。 今回は私達が「データの民主化」を目指してこれまでに取り組んできた事を振り返りながらご紹介したいと思います。 はじまり（2017年10月〜） 当時社内では以下のようなキーワードがトレンドでした。 データドリブン経営 データの民主化 データウェアハウス しかしデータが十分に活用されているのは一部の部署や施策に限られており、「データの民主化」と呼ぶには程遠い状態でした。 データのサイロ化 データはLIFULL HOME'Sなどのサービスのために最適化されており、セキュリティやシステム保護の観点からデータにアクセスできる人は必要最小限に抑えられています。 また複数のデータベースやクラウドサービスに散在していて、いわゆる「データがサイロ化している」状態でした。 このような中でデータを活用しようと思うと、まずはデータの抽出をエンジニアに依頼する必要があります。しかしデータが容易に見られる環境ではないので、データ抽出の適切な要件を考える事がそもそも難しいのです。依頼を受けたエンジニアとしても特に面白くない作業に時間が取られる事になり、しかもデータを出してみたら「なんか違った・・」「もう一度データ抽出お願いしますー」なんて事がよくありました。 どう考えても効率が悪いです。こんな状態ではデータ活用は進みません。 データドリブンを推進する部署の発足 そんな状況を変えるためにデータドリブングループという部署が新設されました。グループのミッションは「社内のデータ活用を推進する事によって、各種業務の効率化を図り、経営を後押しする」です。メンバーは企画/マーケター×2名、エンジニア×1名（私）の3名体制でした。 ゼロからの手探りの状態でしたが、3人で下記のような事に取り組んでいきました。 社内のデータの調査 社内にある分析に使えそうなデータをリストアップし、データがどこにあるのか？どのような連携が可能か？を調査していきました。LIFULL HOME'Sなどのサービスのデータはもちろん、営業関連のデータや会計システム、既存のBIのツールの中身などを調査していきます。特にバックオフィス系では様々なSaaSや外注しているシステムが存在していて「データのエクスポートには追加の費用が必要かも？」という物もあったりしました。 データ分析のトライアル 営業部門と一緒にデータ分析による営業戦略の立案に取り組んでみました。 仮説を立てる → 関連データを集めてきて仮説を検証 → 筋がよさそうなら営業戦略に落とし込んで実行 → 結果を検証 というサイクルを回していきます。 具体的に作業を進めてみると「キーとなる情報がなくてデータが結合できない」「そもそもデータが無い」などの問題が浮き彫りになってくるので、今後のDWHやデータマート作成時に考慮すべきポイントが見えてきました。 DWHの構築 サイロ化しているデータを一箇所に集めて分析者が利用しやすい環境を作るために、データウェアハウス（DWH）を構築します。DWHにはGCPのBigQueryを採用しました。LIFULLではGoogle Workspaceを導入しており、社員全員がGoogleアカウントを持っているのでBigQueryへの権限付与も非常に手軽に実現できました。 BigQuery自体にも積極的に機能追加・改善が行われており安心感がありますね。個人的には殆ど非の打ち所のないサービスだと思ってます。 2期目（2018年10月〜） 非エンジニア向けの勉強会を実施 データ活用を進めるにはデータを扱える人も増やしていく必要があります。エンジニアへ依頼する事なく誰でもデータを取り扱える状態を目指しているので、非エンジニアの人を対象にSQLの勉強会を行いました。クエリの向き先は分析用のBigQueryなので、SQLに不慣れな人が多少無茶なクエリを実行しても大きな問題にはなりません。実際に実行しながら試せる環境があるのはとてもいいと思います。ただしクエリのコストの面では不安が残るので「ユーザー一人あたりのクエリ上限（Query usage per day per user）」などのキャップを設定しています。 Tableau BIツールとしてはTableauを導入しています。こちらも利用者を増やすための勉強会を実施したり、各部署で追っている指標をTableauで可視化するサポートを行いました。 当初はTableau Desktop × Tableau Onlineの組み合わせで使っていましたが、利用アカウントの増加に伴いこの時期にTableau Serverへの切り替えを行っています。 Tableauは直感的なマウスの操作で綺麗なデータビジュアライゼーションができるのが売りですが、サッとデータを見たい時のビューワーとしても重宝しています。 3期目（2019年10月〜） これまでは非エンジニア部門をメインのターゲットに置いてDWHを中心としたシステムを構築していましたが、エンジニア部門からもDWHのデータを使いたいという声が聞こえてくるようになりました。また各部署ごとにデータの準備にコストが割かれているという問題も表面化してきました。そこでデータの集積はデータ基盤に統合していく方針とし、データプラットフォームグループというエンジニアリング組織で管理していく体制になりました。 データレイクを備えたデータ基盤の構築 LIFULLではAWS上で稼働しているサービスが多いため、これらデータソースの一番近くに位置するデータレイクにはAWSのS3を採用することにしました。これまでもBigQueryの前段にあったCloud Storageが同等の役割を果たしていたのですが、これからは明示的にデータレイクを構築していきます。 同時にETLの実行環境もAWSのECSやStep Functionsを利用した構成にリプレイスしていきました。 これまでの構成 DWHを中心にGCPで構成 現在の構成 データレイクにS3を採用しAWS側にリプレイス 現在（2020年10月〜） 現在、データ基盤では約2,000のエンティティ、約4,000億レコードを管理しています。取り扱うデータ量や種類の増加に伴って運用コストも増加傾向なので、より効率化を図りながら規模を拡大していくことが目下の課題です。 まとめ 今回は「データの民主化」に向けて取り組んできたこれまでの流れを大まかに紹介させていただきました。システムの詳細や運用の仕組み、Tableau Server、失敗談など、個別の具体的な内容についてはまた別の記事でご紹介できればと思います。 最後にLIFULLでは一緒に働く仲間を募集しています。（※データ基盤開発のポジションもあります！） カジュアル面談も行っていますので興味のある方はぜひご応募ください！ hrmos.co hrmos.co

こんにちは、LIFULLのエンジニアマネージャーをやっております。河津です。 私は、2015年の6月〜2018年の6月までの丸3年間をLIFULLグループの会社であるTrovitに常駐しスペインで過ごしました。 帰国してすぐに、スペインでのエンジニアの働き方を書いてみようかとも思っていたのですが書けずに2年が経ってしまいました。 ですが、2年ほど日本での働き方も再度経験したことで、改めて当時の経験で今役に立っているなと感じる部分があったので、筆（キーボード）を取りました。 また、スペインに出向の経緯やスペイン常駐時の苦労話などはいつか紹介できたらと思います。 ※Trovitは企業統合により現在は LIFULL CONNECT となっています。 ※ 世界最大規模の不動産・車・仕事のアグリゲーションサービス を提供するスペインの会社です。 組織と働き方 チームの役割が明確！ 私が所属していたころのチームはエンジニアだけでなく多職種で一つチームを編成しており、担当分野が、アプリケーション、検索エンジン、インフラ、パーサ、SEO、有料集客にチームが分かれていました。 それぞれのチームでのミッションが明確になっており、会社の戦略に明確に紐付いていました。 例えば、検索エンジンとしてSolrを利用しているのですが、クエリ構築を容易にするプラグインを実装することで検索エンジンを使う全てのアプリケーションの開発効率を改善させ、バグの発生率を下げていました。インフラチームでは、Kubernetesを利用目的とした基盤の移行（AWSからGCPへ）を3ヶ月程度で完遂させ可用性を高いものにしていました。 ※例はほんの一部です 学び チームにまで落とし込まれたミッションが明確であることが組織全体の生産性向上に繋がり会社の成長につながる。 日本での取り組み 戦略に則したチーム編成とそのチーム毎にメインミッションを明確に決め、やることへのフォーカスができるようにしました。うまく回っていると実感できるシーンもあれば、フォーカスすべき内容と業務の幅との調整など改善の余地はまだあると感じています。 全社で閲覧するデータの統一と可視化が徹底的！ ミッションが明確でも、状況を正確にモニタリングしたり、施策に対する結果を定量的に見ないと成否の判定が正しくできないという考えから、データの可視化を徹底的に行っていました。 例えば、SEOチームでは日々のセッション数とキーワード数との相関だったり、パーサチームはポータルサイトからパースしたデータの数と品質を可視化して、社内の誰でも見れる状態にしていました。 この社内の誰もが統一されたデータを見るということがとても重要で、統一されたデータを見ることで状況を共通して認識することができ、そこからの質疑応答が社内コミュニケーションを活発にしていました。 ある時、CEOが「個人分析の資料で語るな、分析資料は共通してみることができるものに統一すること」と言っていたのはこのためだったんだなと、改めて思いました。 どのデータを正とするのかといった、無駄な時間と労力も生まれなかったと思います。 学び 全社で統一した指標を見ること、それが全社に公開されていることが無駄な時間を発生させず、意識統一にもつながる。 日本での取り組み すでにLIFULLでも、会社全体で見る数値を統一させる動きを取っていました。 今まで、定期的に参照するKPIのデータ形式やドキュメントがバラバラだったものが一定統一され見やすくなっています。 また、エンジニアチームでは 技術負債の解消を目的としたCodeclimateを利用したコード品質の可視化 を進めていっており、 リファクタリングへの意識 が高まっています。 こちらは、エンジニア全体での動きがすでに取られており、私の思惑にも繋がりました。 www.lifull.blog www.lifull.blog 常にデプロイされる環境！ テストまで完了したプロダクトは随時デプロイされる仕組みになっていました。 プロダクション前の環境では常に品質を担保するテストケースが走り続けていて、リリース可能な状態になったものは逐次デプロイされます。デプロイ後にバグが発生したら、一つ前のタグに戻すだけでロールバックができる仕組みとなっており、エンジニアは常に開発する事に集中できる仕組みが用意されていました。当時の私にはQAが活躍していたのは斬新でした。 学び 出荷可能な状態のプロダクトをすぐに世に出せる仕組みになっている事が、リリース日までのほんの数日ではあるが出荷を待機させるという事との小さな差を生み、その積み重ねが1年を通すと大きな差になる。 日本での取り組み 赴任する前は週に2回程度のリリース日が用意されていたのですが、今では毎日リリースできる仕組みがすでに構築されています。こちらも、赴任している間に仕組み化されていたので、LIFULLでもリリース頻度を課題と捉え着実に改善が進んでいると実感しています。 採用と人事 学んで来たことと仕事のつながりを重視する！ エンジニアの中にも様々な職種があると思いますが、職種と大学での専攻が紐付いている人ばかりでした。中には、必要となるスキルを大学や専門学校で改めて学び直す人や、専門性をより高めていった結果、働きながら大学で講師をしている人もいました。 採用の面でも、大学での専攻や業務での実績が無い人が採用されることはほぼありません。 一般的に日本企業では大学での専攻と関係なくポテンシャル採用を行っていますが、ポテンシャル採用という言葉自体がありませんでした。 技術マネージャーが「特定の理工系大学の新卒を取ることが非常に重要で、卒業したての人材こそ即戦力として期待ができる！」と力強く言っていたのを覚えています。 またよくある話ですが、知識があり素晴らしい結果も出しているのに謙遜するということもありませんでした。あるのは謙遜ではなく、仕事の結果の分析と共有といった一つコミュニケーションのステップが省略されているイメージを受けました。これはエンジニアに限った話ではなく文化的なものかもしれません。 学び 同士として働いてもらうエンジニアを選考する採用に妥協は許されない。 Betterではなく、Bestを採用することが大事である。 日本での取り組み LIFULLのビジョンに共感していただける方を採用することは最重要ですが、社内での活躍が期待できるか、一方社内でも活躍の場をしっかりと提供できるかを一つ一つ丁寧に確かめながら採用活動を進めさせていただいております。 hrmos.co 雇用形態が異なる！ スペインでは雇用契約上、解雇は普通に行われTrovitでも努力しているしていない如何に関わらず、結果が出ていなければ解雇されます。うちの会社にはフィットしなかったので、もっと活躍できるところへ送り出してあげる。それが会社にも当人にも幸せな結果をもたらす、という考えのもと解雇を選択します。 ある日、昼食から帰ってくると、とあるデスクの荷物がまるっとなくなっていることがありました。週末飲みに行く約束をしていたので、余計にびっくりしたのは覚えています。 赴任当初は日本の感覚が強く、解雇や退職と社員が辞めてしまう事にかなり敏感になっていたのですが、徐々にヨーロッパのエンジニア市場だったり転職事情を知り、過度にネガティブに捉えず次のステージを応援するマインドになりました。今でもその感覚は持っています。 学び 市場のニーズを捉え、スキルを磨いていくことが自分の市場価値も上げていくこととなる。 日本での取り組み 今期からエンジニアは職能別の組織となり「強い個人、最高のチームとなることで、価値創造を加速させ続ける」というビジョンを掲げ、 以前よりも勉強会やナレッジ共有会の開催頻度を上げたり 、個人でのスキルアップの発表の場を設けたりと、より高度に求められる市場ニーズに応えられるエンジニアの育成に取り組んでいます。 www.lifull.blog 人生で大事なものはお金よりも時間！時間を大事にする文化 オンとオフの切り替えが上手い！ オンとオフの切り替えを当たり前のようにしていて、すごく上手いなと感じました。 勤務終了後は近くのバーへ行くのが恒例でしたが、仕事の不平不満を話すのではなく、次にチャレンジしてみたい技術だったり、今プライベートで気になって触っている技術について熱く語る人ばかりでした。 Kubernetesがいかにイケているのかをブルーチーズを片手に赤ワインを飲みながら語っていたインフラエンジニアを今でも忘れられません。社内のメンバーだけでなく、エンジニアの友人を呼んでディスカッションが始まることもありました。 仕事の話から一旦離れるが技術の話は楽しくてついやってしまうという、根っからのエンジニアが多かったように思います。 また、サッカーの話になると地元のチームの話や日本から移籍してきた選手の話で盛り上がったりと、仕事を忘れて時事ネタで盛り上がることも多々ありました。 現地の会社対抗のリーガ（フットサルの大会のようなもの）が一定期間で開催されるのですが、仕事の後のちょっとした運動ってレベルではなく毎回みんな本気なので、参加しては毎回死ぬんじゃないかと思っていました。 学び 仕事とプライベートの切り替えや時間の使い方の上手さがストレス解消に繋がり、翌日の業務へのモチベーションを保つ秘訣。 日本での取り組み 直近のコロナ禍ではコミュニケーションのとり方が大きく変わりました。特にオンラインでのコミュニケーションは業務の内容のみになってしまいがちです。そこで特定の時間は気軽に話せる部屋を開放してみたり、あえて雑談しかしない時間を取るなど、切り替えの時間を取るようにしました。これが意外とストレス解消につながったり、メリハリをつける事につながったりと良い影響を及ぼしたと実感しています。これらは、メンバーが自ら実践してくれました。 ミーティングのセッティングも命がけ！ 人の時間を無駄に搾取してはならないという文化がありました。 なにか提案をするとき、特に今あるものを否定するには否定するに至る事実（データ）がなければ、ただの個人の意見であるという考えがありました。 ある日、「このMTGは本当に無駄な時間をすごした！」と激怒され部屋から出ていかれたこともあります。 今は反省をするとともに、ミーティングの本当のあり方を学んだように思えます。自分が人の時間を搾取するということを真剣に考えるきっかけにもなりました。 今思えば、ミーティングではみんな「I think」ではなく、「It says」と言っていたのを思い出します。 学び ミーティングの要不要は必ず検討し、行う場合でも必要最小限で行う。 必ず客観的に判断できる事実やデータを用いて語り、無駄に時間を浪費させない。 日本での取り組み 効果的なミーティングを実践するために色々検討し実行しました。 ミーティングは極力削る 1時間ではなく30分でできるものは30分で終わらせる 早く終われば、終わり次第解散する チャットに書けば終わることは書いて終わらせる 書く方が時間がかかるなら、さくっと5分程度の会話する 必ず一つの指標をみんなで見て協議する などです。 オンラインでのコミュニケーションが必須となったなか、ミーティングが必要な場面は増え、なかなか難しいところはありましたが、今後も継続して改善していきたいと思います。 金曜の夕方をみんなで楽しむ！ 金曜の夕方は「All Hands」という、各グループが自分たちの取り組みを共有する会が開催されていました。 ただの共有会が開催されるのではなく、会場ではビールとおつまみが用意されており、みんなフロアで足を伸ばして座りながらリラックスして聞いていました。そんなフランクな会なので、質問もどんどん飛び交い、聞く方も為になるし、プレゼンする側もテンションが上がるといった楽しい会だったのを覚えています。 また時には、聞いているメンバーがフォローに入ったりして、全社での一体感もすごく醸成できていたと思います。 私も一度、LIFULLでの取り組みである「 クリエイターの日 」を共有しましたが、多くの質問をもらえたり、うちでもやってみようかなと言ってもらえ、大きな達成感を得られたのを覚えています。 ただ、この「All Hands」への準備は運営チームとかなり綿密にやりました。一見フランクに適当に集まって午後の一時を楽しく過ごそうよ！って感じなんですが、全員で集まる意味をしっかり捉え、参加者にとって意義のある時間にすることへのこだわりはかなり強烈でした。 学び みんなで同じ時間を過ごすことも大事、その時間を有効活用することが、より洗練された組織づくりにもつながる。 日本での取り組み LIFULLでは以前から、チームビルディングの一貫で一つの事にみんなで取り組むという仕組みはありました。その多くは物理的に人と人が接し合うことで実現していたのですが、今回オンラインで実現させることが必要となってきました。 そこで今回、 エンジニアのユニット総会を特定のトーク内容について会話をする会にしてみる といった新しい試みを行いました。異なるグループのメンバー達が、同じ時間を過ごしながら意見を交わすことで、より相互理解と繋がりを強くすることができたと思います。 www.lifull.blog まとめ 帰任して2年経ち、スペインでの経験と学びからエンジニアマネージャーとして何を考えどう動いたのかを書き綴ってみました。 私の場合は海外の会社に転職したようなものだったので、言葉の違いに始まり、文化のギャップやマインドの違いで苦労はしました。しかし、それを乗り越えることで新しい学びを得られ、日本での取り組みに繋がったと感じています。 LIFULLのエンジニアには海外での経験も積んでみてほしいと思います。今の状況下、現地に行くことは難しくなっている一方、オンラインでのコミュニケーションは格段に取りやすくなっています。海外のカンファレンスなどオンラインで開催されているものは多数あるので、アンテナを広げて様々な価値観や取り組みを学び、日々の仕事に活かしてもらえたらと思います。 最後に 学びからの取り組みを共有させていただきましたが、実際に「取り組み」をしてくれたのは、他でもないエンジニアのみんなです。大きな変化への適応や、大きな事を一人で成し遂げるのは至難の技です。メンバーひとりひとりの協力なくしては成し得ません。 これからも、エンジニアがOne Teamとして活躍できる場を創り、共に切磋琢磨して成長していける組織を創って行きたいと思います。

こんにちは！エンジニアの美馬です！Vite 使ってみました！ はじめに やったこと やっていないこと 開発の課題 周辺環境の課題 レガシー JS そのものの課題 ESModules がなく JS の依存が JS 内で完結しない 見慣れないプロトタイプチェーン Road to ESNext 導入したツール Vite JSDoc ESLint Prettier TestCafe Vite で嬉しかったこと 爆速ビルド 簡素な Config レガシーブラウザ対応 書き換えで苦労した点 Vite Backend Integration module/nomodule による問題 jQuery 成果 おわりに PR はじめに 新規 PJ では迷わずモダンな環境を選択します。しかし現実には既存のコードを流用・修正していかなくてはならないこともあると思います。 標準に追従しモダンな周辺ツールの恩恵を受けられるようにし、スムーズに開発を継続させるべく、フロントエンドの改善施策を行いました。 やったこと ES5→ESNext の書き換えを行った Vite の Backend Integration を使用した 周辺ツールを整えた Formatter - Prettier Linter - ESLint E2E Test - TestCafe Type Annotation - JSDoc やっていないこと TypeScript の導入 宣言的 UI の導入 デザインの刷新 開発の課題 対象のサービスは、マイクロサービスとしてメインのモノリスから切り出され、8 人のチームで開発していました。切り出したは良いものの、新規コンテンツページの作成等もりもりとサービスの開発は進むのに対し、開発環境のメンテナンスは特にされていない状況でした。 周辺環境の課題 開発ツールがそろっておらず、 効率の良い開発が行えるとは言いがたい状況でした。 ビルドツールがない トランスパイラはなく、生の ES5 が書かれていました。 バンドルツールは YUI Compressor が使用されており、bundle, minify はされていました。 JS の依存は HTML テンプレートにて管理されておりわかりにくい状態で、 ライブラリは npm で管理されておらず生ファイルが存在する状態。ライブラリのアップデートも難しい状態でした。 自動テストが十分でない 主要な機能を確認する E2E テストはあったのですが、JS エラーを網羅できるようなテストはなく、 ほかの部分ではほぼ手動でテストが行われていました。 不十分な静的解析 一応 Linter は JSLint が導入されていましたが、十分な静的解析は行えていない状況でした。（後述） ESModule での記述も静的に解析したかったこともあり、ESLint に乗り換える必要がありました。 （JSLint もこの施策中に大きめアップデートが来ていました。ESLint に乗り換えましたが。） レガシー JS そのものの課題 古くなった JS を書き続けるということは、JS の進化の恩恵を放棄し続けるということです。 ES2015 以前の JS では ↓ のような問題を抱えていました。 ESModules がなく JS の依存が JS 内で完結しない < script src = "jquery.js" ></ script > < script src = "common.js" ></ script > < script src = "app.js" ></ script > 依存は HTML テンプレートに直接書いて管理されます。 import, export の構文は使えず、どんどんグローバルは汚染されていき、 読み込み順序、読み忘れにより度々エラーが起き、JS を書いた後 HTML を開きエラーを確認する必要があります。 見慣れないプロトタイプチェーン someClass.prototype.say = function () { console.log( "hello" ); } ; 本サービスではこれを避けようとして独自のファクトリ関数のようなものによって擬似 Class が実装されていました。その結果、十分な静的解析ができない状態になっていました。 これらの影響により、ちょっと jQuery を推奨バージョンまでアップデートしようにも影響範囲は分かりづらく、独自に実装された内容が現在では不要であるはずの学習コストを生んでいることなど良い環境とは言えない状況でした。 Road to ESNext 効率の良い開発が行えていないと判断され、JS 改善 PJ が立ち上がり、ESNext への書き換えが始まりました。これは急に取り組み始められたものではありませんでした。 ES5 でそのまま運用されている背景からも分かるように、 これまでは事業としての開発に振り切られていた状態でした。 しかし昨年ごろから徐々に開発環境改善の動きがあり、改善の意識が高めてきた先の本施策でした。 次のような段階を踏んだ上で書き換えに至りました。 フロントエンドテスト環境改善の動きが出始める まずはテスト不足からアプローチされました。TestCafe での E2E テストが整えられ、主要な機能をテストできるようになりました。 TestCafe が CI で動き始める 毎朝とデプロイ時に E2E が動くようになりました。CodeBuild で動いています。 E2Eテストをクラウド移行したお話 - LIFULL Creators Blog TestCafe で全ページの JS Error を拾うようになる 全ページで初回ロード時の JS エラーを拾うようにしました。 リポジトリ内の使用されていないコードをひたすら grep して削除 ESNext 化する前に不要なコードは削除しておきました。 幸いリポジトリに配置されていた jQuery プラグインや自作ライブラリの多くは使われていないもしくは限定的な使われ方をしていたのでたくさん削除できました。 ビルドツール導入が検討される トランスパイラのみ導入すること、新環境を作成すること、等を検討する中で ノーバンドルツールである Snowpack, Vite のうち Internet Explorer 対応が容易かつ勢いが感じられた Vite に注目、採用することを決めました。 ESLint, Prettier を設定 既存の JS の ESNext 化の際、ツールで一括置換しようにもユニットテストはないので手動確認が必要になってしまいます。 また、Vite を採用するにあたって ESModules に書き換える必要があります。 全部書き換えることに決めたので、最大限にツールを活かして書き換えを行うべく周辺ツールを整えました。 ESNext 化 書き換え対象は 3 万行ほどありましたが、盤石な体制を整えて レビュー 1 人書き換え 2 人の計 3 人での手作業で JS を書き換えつつテストを作成するパワープレーを実行しました。 導入したツール Vite https://ja.vitejs.dev Rails や Laravel とも組み合わせることができます。 バックエンドとの統合 | Vite JSDoc もともと JSDoc を書く文化はあったのでそのまま採用しました。今回 TypeScript は導入していませんが型をざっくり守っています。tsc の checkJs によって型チェックを行うこともできます。 ESLint eslint-plugin-jsdoc JSDoc で不正な記述があった場合に検挙します。 eslint-plugin-import 存在しないパスやモジュールを指定した時に注意してくれたりします。 eslint-import-resolver-alias import エイリアスを設定しているので対応します。 eslint-plugin-prettier Prettier のエラーを ESLint のエラーとして表示します。 Prettier Why Prettier? · Prettier TestCafe E2E テストを行います。クロスブラウザに強く、セットアップが容易です。 Cross-Browser End-to-End Testing Framework | TestСafe Vite で嬉しかったこと 爆速ビルド 従来のビルドツールを導入すると分単位で待ち時間が生じてしまいます。 しかし esbuild のような高速ビルドツールやこの Vite などのノーバンドルツールによりその待ち時間は大幅に短縮可能になりました。 Vite では開発環境向けには Native ESM を活かし JS をビルドするので待ち時間がほぼありません。 3 秒で開発開始可能です。 簡素な Config postCSS, esbuild, Rollup と内包しているので Vite さえ面倒をみていればビルド環境が整えられます。 設定ファイルが簡素で、package.json もシンプルであることも良いところではないかと思います。 vite.config.js import legacy from "@vitejs/plugin-legacy" ; import glob from "glob" ; export default defineConfig( { plugins: [ legacyPlugin( { targets: [ "ie >= 11" ] , } ), ] , resolve: { alias: { pc: "/assets/js/pc" , sp: "/assets/js/sp" , common: "/assets/js/common" , } , } , build: { manifest: true , rollupOptions: { input: glob.sync( "**/js/**/entry.js" ), } , outDir: "out" , assetsDir: "js" , } , server: { port: 3000, hmr: { protocol: "ws" , host: "localhost" , } , } , } ); package.json " dependencies ": { " @vitejs/plugin-legacy ": " ^1.5.0 ", " vite ": " ^2.4.4 " } レガシーブラウザ対応 SPA ではなく MPA でしたが容易に導入することができ、 レガシーブラウザ対応もプラグインを設定して簡単に行えました。 github.com ライブリロードがあることも格段に開発体験を向上させてくれます。 （HMR まであるが JQuery を使用しているので今は活かされていない） 書き換えで苦労した点 Vite Backend Integration ガイド にあるように簡単にエントリーポイントのみ指定することで動作しますが、Native ESM による読み込みが行われるため RTT が生じます。回避するには、Vite から出力された manifest.json から依存ファイルを辿り、preload directives やタグを SSR しておく必要があります。 manifest.json { " assets/main.js ": { " file ": " main.5a48225c.js ", " src ": " assets/main.js ", " isEntry ": true , " imports ": [ " _moduleA.9fb6069d.js " ] } , " _moduleA.9fb6069d.js ": { " file ": " assets/moduleA.9fb6069d.js ", " imports ": [ " _moduleB.ead1d8b3.js " ] } , " _moduleB.ead1d8b3.js ": { " file ": " assets/moduleB.ead1d8b3.js " } } HTML（SSR） < script type = "module" src = "assets/moduleB.ead1d8b3.js" ></ script > < script type = "module" src = "assets/moduleA.9fb6069d.js" ></ script > < script type = "module" src = "assets/main.js" ></ script > module/nomodule による問題 type=module では常に use strict モードとなるので注意が必要です。 また、トップレベルの this は global ではなく undefined を返すようになります。 ECMAScript® 2022 Language Specification 既存のライブラリで最上位にて this を参照していたものを window に変える必要がありました。 jQuery 全書き換えのついでに 1 系から 3 系へのアップデートを行いました。 VSCode で型を参照しつつ非推奨の構文を取り除くことができ便利でした。 VSCode にて unbind が非推奨であると指摘されている 成果 7.1 万行あったJSから不要なJSを削除して 2.9 万行、ESNextに書き換えて最終的には 1.2 万行にまで減りました。 静的解析が強力になったのでレビューコストが削減されました。 パッケージ管理ができるようになったので外部ライブラリを導入しやすく、メンテナンス可能になりました。 おわりに 捨てるでも新しい何かをつくるでもなく、標準に寄せ、負債を縮小するという選択をとりました。 進化し続ける技術に追従しつつ、ユーザーにもエンジニアにもうれしい開発をしていけたらなと思います。 PR マンションを売る時も LIFULL HOME'S へ！ lifullhomes-satei.jp

みなさんこんにちは、SET(Software Engineer in Test)の Ruey です。 弊SETチームの活動として、自動テストの実施依頼を受けています。 最近は大規模な範囲にページ内の特定な要素を追加する施策の自動テストを対応しました。 テスト内容はURLへアクセスして特定のタグがあるかを確認することなので、データ駆動型テストで対応しました。 開発チームの実装後、こちらからデータ駆動型テストを実施し、結果を報告する形になります。 テスト結果報告後に開発チームはバグ修正を行い、すべてのテストケースがPassするまで「再テスト➡︎再修正」の繰り返しを行いました。 すべてのテストを実行すると実行時間がかかりフィードバックが遅れるため、前回失敗したテストケースのみを再実行したいです。 なので、そのような仕組みがあった方が対応しやすいと考えました。 今回の記事では、データ駆動型テストにおいて失敗したテストケースのみを再実行できる仕組みを紹介したいと思います。 目次 目次 データ駆動型テスト（Data-driven testing）とは？ データ駆動型テストの例 テストデータ sample-data.json サンプルコード data-driven.js どのような再実行の仕組みが必要か？ 失敗したテストケースのみを再実行できる仕組み 不連続のテスト再実行を実現する仕組みの例 テストデータ sample-data.json サンプルコード data-driven.js 最後に データ駆動型テスト（Data-driven testing）とは？ 仕組みを説明する前に、まずはデータ駆動型テストについて少し紹介します。 ISTQBの用語集の説明 では スクリプト記述技法のひとつ。テストスクリプトの実行に必要なテストデータおよび期待結果を含んだデータファイルを使う。 と定義しています。 今回の施策におけるテストでは、2000個程度のURLへアクセスして各ページ内に同じような検証を行います。 なので、テスト実行スクリプトを一つ用意して、後は大量のテストデータに記載しているURLと期待値を利用し、「URLへ遷移➡︎期待値検証」のループで対応します。まさしくデータ駆動型テストになっています。 データ駆動型テストのポイントとして、検証の部分を共通化することが大事です。テストケース数は大量になるので、全て同じ検証関数が使うことができれば実装が楽になります。 データ駆動型テストの例 ここはURLごとにページHTMLのtitleタグの内容を確認する例を紹介します。 テストデータ JSON式でURLとtitleタグの期待値が入っています。 sample-data.json [ { " url ": " https://devexpress.github.io/testcafe/example ", " expectedTitle ": " TestCafe Example Page " } , { " url ": " https://testcafe.io ", " expectedTitle ": " Cross-Browser End-to-End Testing Framework | TestСafe " } , { " url ": " https://testcafe.io/documentation/402632/reference ", " expectedTitle ": " Reference | Docs " } ] サンプルコード TestCafe というテストフレームワークで書いています。データ駆動型に対応していますので、簡単に実装ができます。 data-driven.js import { Selector } from 'testcafe' ; const dataSet = require( './sample-data.json' ); fixture `Data-Driven Tests` dataSet.forEach(data => { test(`Testing for '${data.url}' `, async t => { await t .navigateTo(data.url) .expect(Selector( 'title' ).textContent).eql(data.expectedTitle); } ); } ); シンプルなコードでsample-data.jsonにある3つのデータをループして確認することができます。 TestCafe公式サイトの各URLへアクセスし、ページタイトルにあるテキストとJSONデータにある期待値が一致しているかを検証します。 どのような再実行の仕組みが必要か？ 上記の例では3ケースしかないですが、今回の施策で実施したテストは2000ケースほどありました。 そして、一回目のテストでは200ケースほど失敗しました。 この結果を開発チームに報告し、開発チームが再修正を行った後、前回失敗した200ケースのみを再実行することになりました。 TestCafeだと、テストケース名を指定して実行する機能がありますが、200ケースを直接指定しないといけないのでかなり大変な作業になります。 このような場合に「 失敗したテストケースのみを再実行できる仕組み 」が必要です。 ※ 本記事では失敗したテストケースのみの再実行の説明なので特に書いていませんが、バグ修正後には全てのテストケースが通るかを確認すべきです。 失敗したテストケースのみを再実行できる仕組み テストフレームワークによっては、失敗したテストケースをあらかじめ設定した条件に沿ってその場で再実行する機能があります。 (Testcafeだと Quarantine mode ) ただし、今回の施策のように「開発チームが修正➡︎再テスト」を繰り返すようなパターンでは、この機能はそぐわないです。 このようなパターンのことを、ここでは 不連続のテスト再実行 と呼ぶことにします。 不連続のテスト再実行を実現するためには、前回の実行結果の記録が必要です。 再実行の際に記録を確認することで、前回失敗したケースのみ実行することが出来ます。 不連続のテスト再実行を実現する仕組みの例 今回はJSONのデータに前回のテスト結果を記録する部分を加えて、不連続のテスト再実行を実現する例を紹介します。 テストデータ JSONデータは状態記録用の「passed」を追加します。初期値はfalseを設定します。 sample-data.json [ { " url ": " https://devexpress.github.io/testcafe/example ", " expectedTitle ": " TestCafe Example Page ", " passed ": false } , { " url ": " https://testcafe.io ", " expectedTitle ": " Cross-Browser End-to-End Testing Framework | TestСafe ", " passed ": false } , { " url ": " https://testcafe.io/documentation/402632/reference ", " expectedTitle ": " Reference | Docs ", " passed ": false } ] サンプルコード サンプルコードは実行の前にテストケースの実行状態を確認して、if文で実行もしくは実行しないを判断します。 また最後は実行成功時に状態をJSONファイルに状態を更新します。 data-driven.js import { Selector } from 'testcafe' ; const dataSet = require( './sample-data.json' ); const fs = require( 'fs' ); fixture `Data-Driven Tests` .after( async t => { fs.writeFileSync( './sample-data.json' , JSON.stringify(dataSet, null , 2)); } ); dataSet.forEach(data => { if (!data.passed) { test(`Testing for '${data.url}' `, async t => { await t .navigateTo(data.url) .expect(Selector( 'title' ).textContent).eql(data.expectedTitle); data.passed= true ; } ); } これでテストフレームワークに不連続のテスト再実行の機能がなくでも、 テストデータに前回の実行結果を追加することにより、失敗したケースだけを再実行できる仕組みを簡単に実現できます。 最後に この再実行できる仕組みを利用することで、修正後のデータ駆動型テストを簡単に行うことができました。 再実行したいテストケースの直接指定の大量な作業から解放できました。 ケース数が非常に多いデータ駆動型テストでの不連続のテスト再実行が必要な時に、この仕組みはとても役に立ちます。 もしみなさんも同じようなデータ駆動型テストを実施する機会があれば、この仕組みが参考になれば幸いです。 今回のサンプルで紹介したTestCafeには不連続のテスト再実行の仕組みがないですが、他のテストフレームワークにはあるかもしれません。 そのテストフレームワークを直接利用してもいいと思います。 最後は宣伝ですが、弊社製の Buckyにも不連続のテスト再実行 の機能がありますので、ぜひご検討ください！ 以上、ありがとうございました！

導入 こんにちは、QAエンジニアの星野です。 突然ですが、改善活動はお好きでしょうか。 自分の所属するQAグループ内でSaPIDという改善手法の実施を行いました。 ここでは、SaPIDの紹介と導入〜初回の壁、失敗と工夫についてをお伝えいたします。     SaPIDとは SaPIDという名前は、 S ystems  a nalysis /  S ystems  a pproach based  P rocess  I mprovement metho D  から命名されています。 公式な説明を以下に引用します。   SaPIDは、当事者自らが システム思考 を活用して対象のメカニズムをシステムとして構造的に捉え、最も効果的で現実的な箇所、あるいは新しい価値創出に有効な施策・対策をうち、成果をあげていくための手法です。 特定の個人が実践することも可能ですが、チームや関係者、組織のメンバーが参画し、 デザイン思考 を併用して一緒に成長する、そして新しい価値を共創する方法を併せ持つのがSaPIDの特徴です。 引用 :  https://www.softwarequasol.com/sapid/       基本的には公式の提示している説明をお読みいただけば、どんなコンセプトでどんな特徴があるのか把握できるかと思います。   とはいえ参照する方が全員ではないと思いますので、 私の思うSaPID がどういうものかを箇条書きにします。 SaPIDとは、 当事者自らが主体的となり、 各々の感じている課題や懸念、不安や不満を挙げながら、 それらの背景や真の課題を明らかにして、 課題と課題の因果関係（原因と結果）を可視化し、 改善したい課題と、改善するための活動の検討、改善できているかの評価方法を、 納得感をもって検討・決定することができる手法 であるというのが私の理解です。   後述しますが、改善にあたって問題解決を急ぎすぎて何を解決すべきか吟味せずに対策を考えてしまうことも多いと思います。 SaPIDは合理的かつ改善に取り組むチーム全員が納得感をもって進められるようになっており、そこが魅力だと思っています。     コンセプトは上記の通りです。 具体的な中身としては、各々が挙げた課題や事実の関係性をこちらの 図 のように明らかにしてきます。 課題や事実の関係性が可視化できたら、具体的な改善のターゲットを特定し関係性をたどって根本から問題を解決していく手法です。     導入の壁と乗り越え方 SaPID経験者がいない 名前こそ知っているものの、チーム内にSaPIDの経験者はおらず具体的に何をするのかもわかっていない状況でした。 そこでとりあえず雰囲気だけでも体験しようと思い、 SaPIDの勉強会 を探して参加してきました。 （connpassで検索すると最近でもSaPIDに関する勉強会は開催されています。）     ちょうど勉強会の中身がゆるく軽量化されたSaPIDのワークだったため、 チーム内で定期開催されている勉強会で体験してきたワークをさらに軽量化し、短時間でSaPIDの雰囲気と自分が魅力を感じた要素に絞ってチームに広めました。     学習コスト どんな手法にも言えますが、SaPIDを知るために学習コストがかかります。 SaPIDを学ぶためにはまずは書籍で全体像の把握をおすすめします。 細かな内容や実践しないとわからないようなTipsも多いため、あまり木を見ずに森を見るように読み進めることを推奨します。     さらにSaPIDを実際に体験をするために、勉強会を探すか年１回程度開催されている公式のSaPID Bootcampへの参加するとなおよいでしょう（参加者は書籍を割引で購入できます）。 参考 :  SaPID Bootcamp SaPIDは今もアップデートされているため書籍の情報はSaPID Bootcampや勉強会の内容よりも少し古くなっていますが、考え方やコンセプトは変わりません。     基本的には書籍を読んで全体像を理解し、SaPIDを実践するときは書籍を開きながら細かい進め方やTipsを参照すると良いと思います。 後々必要になったら参照しようと付箋を貼りながら読み進めたところ、このような状態になりました。 こう見ると、さほど多くないと思います。 書籍自体も難解な箇所はないため、サクッと読み進められるはずです。     また、疑問点や感じた細かいことはtwitterでつぶやけば有識者や公式から助言をもらえることも多いです。   失敗と工夫 時間がかかってしまう チームの学習 SaPIDの導入にあたりファシリテートを務める人が書籍や勉強会で学習コストを払っているかと思います。 しかし、チームで行う場合、全員がSaPIDのことをある程度知らなければなりません。 全員に書籍を読んでもらい勉強会やSaPID Bootcampに申し込んでもらうわけにもいきません。     ファシリテートを務める人がキックオフを行ったり、各STEPのはじめに説明を行うなど手厚くサポートをしたほうが良いでしょう。 SaPIDでは参加者のことを尊重することが大事であると 明言 されています。 仮にやり方に誤りがあっても大きな問題ではありませんので、正しさよりも参加者の改善へのやる気や積極性を損なわないように進めてください。 SaPIDは一度で終わりではありませんので、困ったことがあればその次の実施時に改善するだけのことです。   実施の長期間化 どんなことにも言えますが、初めての実施には時間がかかります。 ひとつずつ手順を確認したり、課題や意見を挙げるにも「何を考えるか」を考える時間がか かって しまうでしょう。 他にもSaPIDの STEP2にあたる情報の精査や、STEP3の構造化 を行う際の合意形成や構造図の整理など、コツを掴めば早くなるのですが要領を得るまではどうしても時間がかかります。     書籍の中で挙げる課題の数の目安について経験上20個程度と言及されているのですが、いざ実施すると本当にそのくらいの数がちょうどよいです。 はじめのSTEPで課題が多く上がると後のSTEPすべてに影響が出てくるため、優先順位づけをして挙げる数を絞ってもらうなどの工夫をすると良いでしょう。 書籍の中にはこういったTipsが随所に書かれているため、もし特定のSTEPで困った場合は改めてその章を読み直してみるとヒントが得られるかもしれません。     参考：挙げた課題が多くなりすぎて複雑化してしまった問題構造図     ファシリテーター兼当事者 自分を含め、導入を推奨する立場の人は、ファシリテーター兼当事者になってしまう問題があります。 進行上は大きな問題ではなく、むしろ他の参加者は見様見真似で進められるためスムーズになるのですが、 ファシリテーターがファシリテートではなく、SaPID全体の流れをファシリテーターの考える方向に誘導してしまいがちになります。     初回であればSaPIDに慣れるためにそのような進め方でも悪くはないかと思いますが、 慣れてきたらあくまで参加者の意見を引き出したり、課題の深堀りや隠れた別の課題を洗い出すことに専念するよう意識する必要があります。 私自身、これがうまく出来ている自信はないですが、参加者を巻き込んだ一人舞台にならないように常に意識しています。   問題解決慣れ エンジニアであるがゆえの問題として、普段から問題解決に慣れていることが挙げられます。 日々、様々な問題を解決しているからこそ、課題を挙げるSTEPでも解決策を考えてしまいがちです。 問題を洗い出すフェーズではあくまで問題を洗い出すにとどめ、問題を精査する際も深堀りは行いますが解決策まで考えてしまわないように留意しなければなりません。 我々はつい「こうすればよいのではないか」「こんな手法がある」「〇〇があれば解決する」と考えてしまいがちです。 ファシリテートを行う人が意識するのはもちろん、参加者にも都度伝えておいたほうがよいです。   おわりに 今回はSaPIDについてご紹介しました。 日々の業務に課題や不満、不安を感じることがあれば、SaPIDの導入を考えてみてはいかがでしょうか。 チーム全員で大々的に始めることが難しければ、賛同してくれる人だけで小さく回して少しずつ周囲を巻き込んでいくとよいでしょう。  

こんにちは。Ltech運営チームの河西です。今回は、2021年7月13日(火)に開催した「Ltech#18 AIで住まい探しをスムーズに！【おとり物件予測＆3D間取り】」についてレポートします。 lifull.connpass.com Ltechとは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。特定の技術に偏らず、様々な技術の話を展開していく予定です。 AIで住まい探しをスムーズに Ltech#18のテーマは、住まい探しをより便利にするためのAIを使った取り組みです。LIFULLでは2018年よりAI戦略室を立ち上げ、「創造と革進で喜びを届ける」をビジョンに掲げ、様々な取り組みを行ってきました。今回はその中でも 物件間取り図の3D化 おとり広告予測モデルの開発 といった内容の取り組みを語ってもらいました！ それではさっそく発表レポートに行きたいと思います。 3D間取りを支える技術 最初は3D間取りを支える技術の発表です。 3D間取りを支える技術 from LIFULL Co., Ltd. www.slideshare.net 3D間取り図とは、LIFULL HOME'Sにおける2次元の間取り図をディープラーニング技術の活用により、画像認識・ポリゴン化して3Dモデルとして可視化し、より実際の物件に近い形で見ることができるサービスです。 これにより、従来1件あたり数万円の作成コストがかかっていた3Dモデルを安価・大量に生成ができるようになるようになりました。 ※3D間取りはこちらから実際に体験できます！ https://www.homes.co.jp/3dmadori 次にそんな3D間取り図サービスを支えている技術を見ていきます。 3D間取りを支える技術は非常に広範囲に渡っています。特に、LIFULLでの全社アプリケーション実行基盤である「KEEL」を活用することにより、AIに特化したエンジニアでもシステム構築の負荷が軽減され、サービスの早期リリースが実現できたとのことです！ ※KEELは過去CreatorsBlogでも紹介しています。 www.lifull.blog 次に間取り図画像の認識や、工夫しているポイントについてです。 間取り画像の認識については、3つの層に分け出力を行い、3Dモデル化しているそうです。3Dモデルとして可視化する際にも工夫している点として、 3Dモデル内の移動を簡単にするために、ポリゴン化したデータに移動点を作成して、移動データを付与 2次元間取り図内に浴室やトイレといったアイコンがない場合でも、独自のルールで設置し、可視化 などといった点についても話してもらいました。 最後に今後の展望については360度カメラを使ったフォトグラメトリの活用・家具配置シュミレートなども実現していきたいと語ってもらいました。 3D間取り図の開発には2~3年を要し、データの収集に苦労したり、機械学習モデルを何度も変更したりと、このような素晴らしいサービス誕生の裏には絶え間ない努力があるのだと感じました！ LIFULL HOME'Sのおとり広告予測モデルの開発 続いておとり広告予測モデルの開発の発表です。 LIFULL HOME'Sのおとり広告予測モデルの開発 from LIFULL Co., Ltd. www.slideshare.net おとり広告とは、LIFULL HOME'S上で「成約済み物件の広告の消し忘れ」や「呼び込みのための架空物件の広告」など実際には契約ができない物件広告が存在している状態です。おとり広告があることにより、ユーザーは安心して住まい探しができないといった問題があります。LIFULL HOME'Sでは、 専属の情報審査チームによる能動調査 不動産管理会社とデータ連携 掲載110番 といった形でおとり広告をなくす取り組みを行っていますが、今回は「専属の情報審査チームによる能動調査」にAIを取り込み、募集終了物件の特徴を学習させて、募集終了確率を予測するAIを開発しました。 次に実際の能動調査の流れやAI学習から調査対象予測までの流れを見ていきます。 従来の専属の情報審査チームによる能動調査では審査チームが一定のルールに基づいて、調査対象物件リストを調査しています。そのため ルールでは選定できない物件がある ルールの複雑化への対応が難解 などの問題がありました。 AIを用いた機械学習フローの導入では、一定ルールに基づいた物件リストデータを用いますが、今度はAI学習用データに偏りが生じ、結果的に募集終了確率の精度が悪化してしまう問題が発生しました。そこで、精度を向上させるために、一定ルールではなく、無作為にデータを抽出することで、偏りをなくし、学習モデルの精度を向上させる取り組みを行ったそうです。 また、このようなモデル開発を効率的に行うための工夫として、BigQueryを用いたデータ加工、AutoML Tablesでの学習自動化、一連の流れをAirflowでスケジューリングし、機械学習フローを全自動化する効率化も合わせて行ったとのことでした！ 最後に、おとり物件をゼロにすることが最終的な目標と語ってもらい、ユーザーがより安心して住まい探しができる未来の実現に向けて、素晴らしい取り組みだと感じました！ まとめ 今回はAIを用いて住まい探しをよりスムーズにするための取り組みをお二方に発表してもらいました。今回発表されたもの以外にもAI戦略室では様々な施策を計画中とのことで、今後どのようなサービスが出てくるのか非常に楽しみです！ 最後に Ltechでは、LIFULLエンジニアが中心となって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。今後も Ltech を積極的に開催していきますので、ぜひ気になった方は、connpass で LIFULL のメンバー登録をよろしくお願いします！ lifull.connpass.com

こんにちは！ KEEL チームの花塚です。 最近一番驚いたことは、OPA Gatekeeperの「OPA」を「オーパ」と発音するらしいということです。 さて今回は、OPA GatekeeperやConftestなどを用いてKubernetesのセキュリティ面を強化した話です。 以前からチームメンバー全員がセキュリティに気を配っているものの、今まで対策していることが妥当なのか、考慮漏れはないだろうかということを定期的に確認する機会がありませんでした。 闇雲に対策せず一度自分たちの対策を見直し、継続的にセキュリティを向上していける仕組み作りの過程をお伝えできればと思います。 目次 目次 解決したかった課題 OPA Gatekeeperとは Pod Security Policyの廃止 Kubernetesへの脅威 本番環境に導入するまで GatekeeperとConftestで使用するRegoを同期させる ConstraintとConstraintTemplateをクラスタへ適用する GatekeeperとConftestのテスト CIの形骸化を防ぐ おわりに 解決したかった課題 改めてセキュリティ対策を進める上で解決したい課題がありました。 それは「マニフェストの監査が自動化できていない」ことです。 KEELはマルチテナント構成をとっており、各サービスのマニフェストを一つのクラスタにデプロイします。 人力で各サービスのマニフェストのチェックすることは、不適切な設定・悪意のある設定の見落としなどが発生する可能性がありましたし、そのようなマニフェストをデプロイできない仕組みが必要でした。 結論としてOPA GatekeeperとConftestを採用しており、この後に詳しく紹介します。 OPA Gatekeeperとは 解決したい課題でも触れたように、結論としてはOPA Gatekeeperを採用しました。ここでは簡単にOPA Gatekeeperについて紹介します。 OPA Gatekeeper(以降、Gatekeeper)は、KubernetesのAdmission Controllerとして動作し、アンチパターンなマニフェストのデプロイの禁止などを可能にするカスタムコントローラーです。 github.com 以下の例では、 Constraint と ConstraintTemplate のCustom Resourceをデプロイすることで hostPID: true であるPodのデプロイを禁止することができます。 package deny_host_pid violation[msg] { input.review.object.spec.hostPID msg := sprintf( " Sharing the host pid is not allowed: %v " , [input.review.object.metadata.name]) } 上記の例でも分かる通り、Gatekeeperは、内部でポリシーエンジンである Open Policy Agent を使用しているためポリシーの記述にRegoを使用します。 強い権限を用いているマニフェストのデプロイを禁止するなど、セキュリティ面でも活用できますが、Istioの VirtualService や Gateway の衝突を防ぐなど、さまざまなユースケースを実現することができます。 余談ですが、Regoを使うことで汎用的にポリシーを記述することができる一方、「学習コストが高そう」 、「少し苦手」という方がいるかもしれません。 最近ではRegoの学習への課題を解決するために、ポリシーをyamlで記述できるKubernetes NativeなKyvernoが開発されています。 github.com Pod Security Policyの廃止 Kubernetesクラスタのセキュリティ面を強化していく意思決定をした際、まず最初に解決策として候補に上がったのが Pod Security Policy です。 PodSecurityPolicy を使うことで、Privileged containerのデプロイなど、セキュリティ的に好ましくない行動を制限することができます。 しかし PodSecurityPolicy は、Kubernetes v1.21から非推奨となり、v1.25からは廃止となることが発表されました。 github.com 先ほど紹介したようにGatekeeperは、さまざまなポリシーを記述することができます。 PodSecurityPolicy でできることは、多くのことがGatekeeperでも実現可能です。 実際にGatekeeperのlibraryでは、 PodSecurityPolicy をRegoで記述した サンプルコード が置かれています。 KEELでは、以前からGatekeeperを使っていることや廃止されることを考慮して、 PodSecurityPolicy の代わりとなるものをRegoで記述する意思決定を行いました。 また、Gatekeeperと似たような用途として使える Conftest というツールがあります。 Gatekeeperは実際にクラスタ内でリソースが違反していないかを動的にチェックしますが、一方Conftestは、Kubernetesのマニフェスト(マニフェスト以外にも対応しています)が違反していないかを静的にチェックします。 ConftestをCIに組み込むことで、デプロイ前にマニフェストがポリシーに違反してないかを確かめることが可能です。 ConftestもGatekeeperと同様にポリシーをRegoで記述するため、Gatekeeperとセットで採用しています。 ちなみに PodSecurityPolicy は廃止されるようですが、今後は PodSecurity admission が PodSecurityPolicy の代替となるようです。 Kubernetesへの脅威 Kubernetesに限らずセキュリティ対策を行う場合は、まずは「脅威を知る」ということが重要になります。 最初はKubernetesのセキュリティの全体感を、以下のような記事を読んで把握することをおすすめします。 クラウドネイティブセキュリティの概要 | Kubernetes Matrix - Enterprise | MITRE ATT&CK® Threat matrix for Kubernetes NIST SP 800-190 今回Kubernetesのセキュリティ対策を考える上で参考にしたのが、Kubernetesを対象とした以下の脅威モデリングのレポートです。 github.com このレポートは2020年1月に作成されているので少しだけ古いですが、一般的なKuberentesクラスタを対象とした主なAttack Vectorを把握することが可能です。 またAttack Treeもレポートに含まれており、ある攻撃を達成するための大まかな道筋を把握することもできます。 例えば以下の「Malicious Codeの実行」に関するAttack Treeでは、Privileged containerを利用したステップなどが必要であるということが分かります。 引用: https://github.com/cncf/financial-user-group/blob/master/projects/k8s-threat-model/AttackTrees/MaliciousCodeExecution.md このように攻撃の目的を達成する道筋を把握することで、「Privileged containerのデプロイを禁止する」など具体的な対策を考案することができます。 AWSやGCPなどのクラウド上でKubernetesを運用している場合は、「使用している権限(IAM Userなど)でどこまで悪用できるのか」を考慮するなど、自分たちの環境と照らし合わせて対策を考えることが大切です。 このように簡単に脅威を洗い出すだけでも、対策への妥当性を説明できることやコストに見合った対策を優先して取り組めると思います。 本番環境に導入するまで さて、ここからはセキュリティ対策を本番環境へ導入するまでの過程について書いていきたいと思います。 GatekeeperとConftestで使用するRegoを同期させる ConftestとGatekeeperで同じ内容のポリシーを記述する場合でも、以下の理由からRegoを併用することができません。 少しだけ文法に差異がある Gatekeeperでは ConstraintTemplate に直接Regoが埋め込まれる GatekeeperとConftestのRegoが別々で管理されるということは、どちらか一方を変更した場合、もう一方のRegoも変更しなければなりません。それは不便ですよね。 そこでKEELチームでは、GatekeeperとConftestのRegoを併用するためにkonstraintを導入しました。 github.com ここでは詳しく説明しませんが、konstraintの library を使用することで、GatekeeperとConftestのRegoの差異を吸収してくれます。 以下がkonstraint用に書き換えたポリシーです。 core や pod ライブラリをimportしています。 package deny_host_pid import data.lib.core import data.lib.pods policyID := " P1000 " violation[msg] { pod_has_hostpid msg := core.format_with_id(sprintf( " %s/%s: Sharing the host pid is not allowed " , [core.kind, core.name]), policyID) } pod_has_hostpid { pods.pod.spec.hostPID } ポリシーを記述した後に、以下のコマンドを実行すれば Constraint と ConstraintTemplate が生成されます。 $ konstraint create <policy_dir>. 現在はkonstraintとGithub Actionsを併用することでRegoのファイルを更新しただけで、自動で Constraint , ConstraintTemplate のファイルを生成・更新するようにしています。 ConstraintとConstraintTemplateをクラスタへ適用する Constraint と ConstraintTemplate を何も考えずにクラスタに適用してしまうと、意図していないリソースまでも影響を受ける可能性があります。 enforcementAction: dryrun を使用し、一定期間様子を見ながら適用することをおすすめします。 また、Gatekeeperではデフォルトでメトリクスを公開しているため、違反している Constraint 数も知ることが可能です。どの Constraint が違反しているかは、今のところメトリクスからは判別できないようです。 github.com Gatekeeper v3.4.0からは、 enforcementAction に warn が追加されたそうなので、本番環境での Constraint の使い分けがいろいろとできそうです。 GatekeeperとConftestのテスト 本番に適用することを考えると、記述したRegoのテストについても考慮しなければなりません。 セキュリティに関する機能のテストはとても重要です。いつの間にか攻撃し放題になっていたら嫌ですよね。 まずは記述したRegoのテストについてですが、先ほど説明したようにkonstraintを使用することで、RegoをConftestとGatekeeperで同期させています。 そのため片方のRegoが正しく動くということを証明できれば、もう一方のRegoも同様に正しく動くということが言えそうです。 Conftestの場合、cliで verify コマンドを使用すると、xxx_test.regoというファイルのテストケースを実行してくれます。 $ cat policy/privileged-container/src_test.rego package privileged_container test_privileged_true { input := { "securityContext" : { "privileged" : true }} container_is_privileged(input) } test_privileged_false { input := { "securityContext" : { "privileged" : false }} not container_is_privileged(input) } $ conftest verify 2 tests, 2 passed, 0 warnings, 0 failures またKEELでは、e2eテストを定期的に実施しています。 www.lifull.blog 以下のようにGatekeeperのテストケースを書いておけば、意図しないデプロイが防がれているかを定期的に確認することができます。 Describe( "Gatekeeper" , func () { Context( "when try to deploy deployments" , func () { f := framework.NewFramework(basename, framework.Options{ClientQPS: - 1 }, nil ) f.SkipNamespaceCreation = false BeforeEach( func () { gatekeeperTester.cs = f.ClientSet gatekeeperTester.namespace = f.Namespace.Name }) It( "should be successful to deploy a normal deployment" , func () { gatekeeperTester.createNormalDeployment() }) It( "should be failed to deploy a violated deployment" , func () { gatekeeperTester.createViolatedDeployment() }) }) }) CIの形骸化を防ぐ CIにおけるセキュリティ等のベストプラクティス(今回だとConftestのポリシー)を提供する場合に考慮すべきことは、「CIの形骸化」です。 Linterなどを導入してみたはいいが、結局無視している状態になることは少なくないと思います。 KEELではCIを形骸化させないために、CIのテストに失敗したら 必ず 対応する方針にしています。 これは言い方を変えると、「必ず対応すべきポリシーやテスト のみ を提供する」ということになります。 「できれば対策をしたほうがいい」ようなものは提供せず、あくまでガードレールのような開発する上で必ず対策しておきたいものを提供しています。 また、各種Linterの出力をrunbookに変換できる runbook-translator というソフトウェアも開発しています。 各Linterの出力を、reviewdogの errorformat を用いてParseして変換することにより、開発者に何をしてほしいのかを具体的に指示します。 github actions comment errrorformatを使うことで、Linterの特定のエラーコードは無視するなども可能です。 おわりに いかがでしたでしょうか。Kubernetesにおけるセキュリティ対策を、考案から本番環境に導入するまでの流れを紹介しました。 今回の取り組みは、脅威を洗い出して対策を考案したこともあり、間違いなくクラスタのセキュリティを向上させたと思います。 また対策に必要な工程の一部を自動化させたことで、今後も継続してセキュリティ対策に取り組めると思います。 まだまだセキュリティ関連でもやることがありますので、これからも取り組みを発信していきます。 それではまた次回のブログで！

こんにちは。テクノロジー本部の稲垣です。 LIFULLでは、提供するサービスによって、様々なDBが稼働しています。 異なるDBエンジン間でのデータ移行が必要となるプロジェクトが立ち上がることとなり、AWSが提供しているAWS Database Migration Service（AWS DMS）による検証を行う機会がありました。 www.lifull.blog AWS Database Migration Service（AWS DMS）がリリースされて間もないころに、一度検証目的で使ったことがありましたが、今回使ってみて、色々と分かったことがあったので、紹介します。 AWS Database Migration Service（AWS DMS）とは エンドポイント レプリケーションインスタンス（Replication Instance） データベース移行タスク（Replication task） DMSを使用した２つのデータ移行パターン 移行用の環境を別途作り、動作確認した上で移行 サービス運用しながらデータ移行 継続的なレプリケーション（CDC）を使用する際の注意点 ソースDB側の更新量に合わせた、レプリケーションインスタンスのサイジング データベース移行タスクの設定について テーブル作成モードと再開・再起動 CDCのTransactional Apply ModeとBatch Apply Mode DMSの検証 DMSのログ 実際に使用する前に確認しておくこと おわりに AWS Database Migration Service（AWS DMS）とは docs.aws.amazon.com AWS Database Migration Service (AWS DMS)は、リレーショナル データベース、データ ウェアハウス、 NoSQL データベース、その他の種類のデータストアなど、さまざまなデータベースを格納できます。AWS DMS を使用して、オンプレミスのインスタンス間 (AWS クラウドセットアップを使用)、またはクラウドセットアップとオンプレミスセットアップの組み合わせの間で、AWS クラウドにデータを移行できます。 https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/Welcome.html より一部抜粋 Oracle,MySQL,PostgreSQL,MariaDB,Microsoft SQL Server,Db2,Amazon DynamoDB,Amazon S3など、様々なデータベースに対応しています。 また、RDS-RDS間でも利用することができます。 AWS Database Migration Service（以下 DMS）は、「レプリケーションインスタンス」を作成して、ソースおよびターゲットの「エンドポイント」を指定します。 そして、「データベース移行タスク」を作成して、移行処理を実行させるといった流れです。 AWS DMSレプリケーションプロセス https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_GettingStarted.html より抜粋 上記の説明で出てきた、以下の３つについて説明します。 エンドポイント データベース移行タスク レプリケーションインスタンス エンドポイント データベースの接続情報の定義 ソースDB（Source Database）とターゲットDB（Target Database）それぞれに存在する レプリケーションインスタンス（Replication Instance） ソースDB、ターゲットDBとの接続を確立し、ソースDBで発生した変更内容をキャッシュする データベース移行タスクが実行されるインスタンス データベース移行タスク（Replication task） ソースDBとターゲットDBの間でデータ移行を実際に行う場所 移行タスクのタイプが「フルロードのみ」、「フルロード＋継続的なレプリケーション（CDC）」、「継続的なレプリケーション（CDC）のみ」によって、タスクの動作が異なります。 フルロードのみ：ソースDBから既存のデータをフルロードし、レプリケーションインスタンスにキャッシュし、ターゲットDBに適用 フルロード＋継続的なレプリケーション（CDC）：フルロードが終わった後に、ソースDBで変更があった内容を定期的に読み込み、レプリケーションインスタンスにキャッシュし、変更データをターゲットDBに反映させる 継続的なレプリケーション（CDC）のみ：フルロードは行わずに、ソースDBで変更があった内容を定期的に読み込み、レプリケーションインスタンスにキャッシュし、変更データをターゲットDBに反映させる 今回は、 フルロードのみ および 、フルロード＋継続的なレプリケーション（CDC） での検証を行いました。 DMSを使用した２つのデータ移行パターン 実際にDMSを使用して、データ移行を行う場合、以下の２つのデータ移行パターンを想定しました。 移行用の環境を別途作り、動作確認した上で移行 サービス運用しながらデータ移行 移行用の環境を別途作り、動作確認した上で移行 【データ移行の流れ】 既存の本番環境と並行して、新しいDBに読み書きするアプリケーションを開発 データ移行用のターゲットDBを作成 データ移行タスクを設定 データ移行タスクをフルロード実行（新しいDBにソースDBのデータが反映される） 新しいDBを参照して、動作確認 アプリケーションを本番環境にリリースする際は、一時的にサービスを止める データ移行タスクを停止し、フルロード実行 新しいアプリケーションをリリース（以降は新しいDBに対して読み書き） 【メリット】 事前に動作確認を行っているため、本番環境での不具合を事前に発見できる テストをして問題があった場合も、環境を再構築すれば切り戻しできる 【デメリット】 環境構築に時間がかかる 同じ機能のソースプログラムを複数管理しなければならない サービス運用しながらデータ移行 【データ移行の流れ】 データ移行用のターゲットDBを作成 データ移行タスクを設定 ソースDBの変更内容をターゲットDBへ定期的に反映 アプリケーションのDB参照先を段階的にソースDBからターゲットDBに変更 移行テーブル対象が増える際は、データ移行タスクを一時的に止めて、テーブルマッピングに追加→データ移行タスクを再開 【メリット】 リリースを止めずにデータ移行ができる 最小限の構成でデータ移行ができる 【デメリット】 データ移行後に問題が発生した場合の切り戻しが困難 本番環境に影響が出てしまった場合、事業へのマイナスインパクトがある 安全性を重視するのであれば「移行用の環境を別途作り、動作確認した上で移行」、多少安全性を犠牲にしても、工数を優先するのであれば「サービス運用しながらデータ移行」といった選択になります。 今回は、移行ケースとして、「サービス運用しながらデータ移行」を想定し、Data Migration Serviceの設定を行いました。 DMSの設定については、web上で紹介しているページがありますが、実際にやってみると、分かりにくい箇所がいくつかあったため、紹介します。 継続的なレプリケーション（CDC）を使用する際の注意点 ソースDB側の更新量に合わせた、レプリケーションインスタンスのサイジング 今回の移行ケースでは、ソースDBに更新が発生する状態で、ターゲットDBにデータ移行を行います。 よって、フルロード＋継続的なレプリケーション（CDC）を採用するため、以下の流れでデータを反映していきます。 ソースDBで変更が発生 ↓ レプリケーションインスタンスで変更内容をキャッシュ ↓ ターゲットDBに反映するためのSQLを生成 ↓ ターゲットDBに対して生成したSQLを実行し、変更を反映 ソースDBでのトランザクション処理順に、ターゲットDBに反映するための内容をレプリケーションインスタンス内でまとめて、ターゲットDBへ反映する処理を繰り返しています。 つまり、ソースDB側の更新量が多くなると、その分レプリケーションインスタンス内での処理にかかる負荷が増えていき、レプリケーション遅延を引き起こしやすくなります。 データベース移行タスクの設定について データベース移行タスクについて、少し前で触れました。 データベース移行タスクを設定する際は、主に以下の２つです。 タスク設定 テーブルマッピング タスク設定、テーブルマッピングともに、AWSコンソール上で直接設定する方法と、json形式で設定する方法があります。 テーブルマッピングについては、テーブル数が多いケースでは、json形式で設定したほうが楽です。 タスク設定については、検証時に設定した内容について触れます。 テーブル作成モードと再開・再起動 タスクを設定して、テーブルマッピングで設定したテーブルに対して、どういったモードで再開するかを設定できます。 テーブルマッピングの変更などで、定期的にタスクを停止および再開する際に使用します。 テーブル作成モードには、以下の３つがあります。 何もしない：タスクを停止したときの状態のまま ターゲット上のテーブルを削除：ターゲットDBのテーブル自体を削除 TRUNCATE：ターゲットDBのテーブルは残したままで、テーブルのデータのみ削除 そして、タスクを再開すると、新規にテーブルマッピングが追加されたテーブルについて、 テーブル作成モードが適用されます。 一時的にテーブルマッピングから外したテーブルを、再度追加した際に、テーブル作成モードを「何もしない」以外にしてしまうと、ターゲットDB側の該当テーブルのデータが消えてしまうので、注意が必要です。 CDCのTransactional Apply ModeとBatch Apply Mode DMSタスクはデフォルトでは、 Transactional Apply Mode です。 ソースDBでトランザクションがコミットされた順にターゲットDBへ適用されます。 一方で、ターゲットDBへの書き込み量を減らしたり、まとめて書くことで効率的に動作させることで、高パフォーマンスが期待できる Batch Apply Mode が存在します。 タスク設定のBatchApplyEnabledをTrueに設定することで、有効化できます。 Batch Apply Modeの場合、以下のようにまとめて変更を行うため、ソースDBでトランザクションがコミットされた順で、必ずしも反映されない可能性があります。 一定期間にソースDBに行われた変更をレプリケーションインスタンス上にキャッシュ ↓ 同一テーブルに対する複数のクエリはDMS側でまとめられる ↓ 最終的な変更をまとめてターゲットへ書き込む 今回の要件では、「サービス運用しながらデータ移行」することが前提であり、ソースDB内のテーブル間で依存関係があるテーブルが複数存在していたため、Batch Apply Modeの適用は見送りました。 DMSの検証 タスク設定に「検証の有効化」というチェックボックスがあります。 「検証の有効化」チェックボックス チェックボックスの下の説明には、以下のように書かれています。 全データのロードを実行した後すぐにAWS DMSでソースとターゲットのデータを比較する場合は、この設定を選択します。 検証することで、データが正確に移行されたことを確認できますが、完了するまでに通常より時間がかかります。 ソースDBとターゲットDBで、同じDBエンジンでデータベースの文字コードが異なる場合、DBエンジンが異なる場合など、ソースDB側に特殊文字などが入っていることが原因で、ターゲットDBに移行できないデータが存在するケースがあります。 その場合、ソースDBとターゲットDBで差分が生じてしまうのですが、DMSの検証を有効化することで、AWSコンソール上で差分が発生しているテーブルと原因となっているデータなどを検出してくれます。 データ移行で漏れが発生してしまうと、大きな問題になる可能性もあるので、データを確実に移行したいケースでは有効化するのがオススメです。 テーブルマッピングに設定したテーブル全てが、DMSの検証対象です。 しかし、以下の点に該当する場合は、有効な検証結果が得られない、大幅なレプリケーション遅延が発生するなど、サービスに影響が出てしまう可能性があります。 ソースDB側で大量の更新が定期的に発生するテーブルが存在する ソースDB側に膨大なレコード数、およびカラム長が長いなど、データ量が多いテーブルが存在する DMSの検証処理自体は、レプリケーションインスタンスで行われますが、ソースDBの変更をターゲットDBに反映するレプリケーション処理も、同じくレプリケーションインスタンスで行われています。 よって、DMSの検証処理、レプリケーション処理どちらかの負荷が大きくなると、もう片方の処理にも影響を与えてしまう可能性があります。 例えば、「サービス運用しながらデータ移行」するケースで、ターゲットDB側も既にアプリケーションで利用されている場合は、DMSの検証を有効化することで、レプリケーション処理自体が遅延してしまうというリスクを抱えてしまうことになるので、設定にあたっては検討が必要です。 DMSのログ DMSのログとしては、以下があります。 DMSタスクログ ClouwdWatch Logsに出力される DMSタスク例外情報 ターゲットDB内にテーブルawsdms_apply_exceptionsが作成され、エラーが発生したテーブルやエラー情報が格納される DMSの検証情報に関するログ ターゲットDB内にテーブルawsdms_validation_failures_v1が作成され、エラーが発生したテーブルやエラー情報が格納される awsdms_apply_exceptionsについては、カラムSTATEMENTに、ターゲット側でエラーが発生したときに実行されたステートメントが記録されます。 awsdms_validation_failures_v1については、カラムDETAILSに、DMS検証時に指定されたキーと一致しないすべてのソース/ターゲット列値のJSON形式の文字列（エラーとなったデータ）が記録されます。 実際に使用する前に確認しておくこと 色々と説明しましたが、DMSを本番稼働しているサービスに使用する場合、以下の点について、確認しておいたほうがよさそうです。 データ移行パターン（サービス運用しながら・移行用の環境を別途作る・開発を一定期間止める） サービス運用しながらデータ移行する場合は、データ移行するソースDBで更新頻度が高いものがないか 移行するテーブル間で依存関係があるものがあるか（依存関係がない場合は、Batch Apply Modeモードの適用も検討） DMSタスクの数（複数稼働させる場合は、対応するレプリケーションインスタンスも用意するか） DMSの検証有効化有無（DMSの検証を無効化する場合は、ソースDBとターゲットDBの差分チェック方法の検討） おわりに 実際にData Migration Service（DMS）を使ってみて、分かりにくかった点について紹介しました。 オンプレミスで動いているDBをAWSへの移行を検討している、もしくはAWS内で別のDBエンジンへの移行などで、Data Migration Service（DMS）の利用を検討している方にとって、少しでもこの記事がお役に立てたら幸いです。

こんにちは。Ltech運営チームの井坪です。 今回は、2021年6月8日(火)に開催した『Ltech#17 実録！LIFULLアジャイル導入までの挫折と取り組み』についてレポートします。 lifull.connpass.com Ltechとは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。特定の技術に偏らず、様々な技術の話を展開していく予定です。 LIFULLアジャイル導入までの挫折と取り組み Ltech#17のテーマは『アジャイル』です。日本でも多くの企業でアジャイル開発が導入されてきていますが、導入したけどうまく使われていないといったことも耳にされることが多いかと思います。特に大企業では既存の業務の進め方が存在し、アジャイルな開発がやりにくい場合も多いようです。LIFULLでの導入事例を踏まえて、導入時の課題や推進していく条件、体制作り・運営の苦労や工夫について語っていただきました。 大企業でアジャイル開発を推進できる条件とその心構え 大企業でアジャイル開発を推進できる条件とその心構え from LIFULL Co., Ltd. www.slideshare.net 最初の発表は『LIFULLで経験したアジャイル開発の導入における課題』とその経験から学んだ『アジャイル推進していくための条件』について発表していただきました。 LIFULLでは2013年頃、開発スピード向上のためにスクラムが導入されるようになりましたが、開発体制や当時のリリースフローの影響もあり運営が難しく下火になっていました。 その後、2018年頃から中途入社メンバー中心に各部署や各プロジェクトでスクラムが採用されるようになり普及し始め、今ではアジャイル勉強会の開催やスクラムサークルの活動が行われるようになりました。 アジャイル導入・運営から学んだ「推進してくための条件」は以下のようです。　※発表者個人の見解になります。 * 型に囚われない * 考えるきっかけを作る * 土壌を作る 開発チームにはスクラムの経験者と未経験者がいる場合もあり、最初から完全なスクラムの型を目指す必要があるのか。 最初から完全な型通りに進めようとすると難しく上手くいかないこともあったりします。 どこに課題があるか気付いてもらうところから始め、チーム内で解決策を話し合い考えてもらい、世の中で起きている変化や課題に対してどう対応していくのかを話し合うことでチーム全員が納得して進められるようになっていきます。 スクラムを利用したアジャイルオフショア開発のとりくみ スクラムを利用したアジャイルオフショア開発のとりくみ from LIFULL Co., Ltd. www.slideshare.net 次は、LIFULLにはベトナムのホーチミンに開発子会社である『LIFULL Tech Vietnam(LFTV)』があり、LFTVとの開発においてスクラムを利用したオフショア開発のために取り組みについて発表していただきました。 リモートワーク全体の問題としてチーム間のコミュニケーションが不足するうえ、開発チームは日本とベトナムに分かれているので、デイリースクラムで雑談する機会を設けてコミュニケーションを図ったり、 ベトナムチーム側の問題を検知しづらいため雑談を兼ねた定期的な相談できる場を設けているそうです。 最後に 今回はLIFULLでアジャイル開発を導入・推進されている お2人に発表していただきました。LIFULLの事例や個人の意見ではありますが、今後アジャイル開発を導入しようとしている方々やアジャイル開発で困っている方々のご参考になれば幸いです。 Ltechでは、LIFULLエンジニアが中心となって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。 今後もLtechを積極的に開催していきますので、 ぜひ気になった方は、connpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

プロダクトエンジニアリング部の関川です。 最近リモートワークを行う上で欠かせないツールがリアルタイムコミュニケーションツール。 ZoomやDiscordなどの製品はそれぞれの方法でリアルタイムコミュニケーションを可能にしてきましたが 民主化された技術の一つとして、WebRTCという技術があります。 この記事はWebRTCに調べる機会があったので、基本的なWebRTCについてとその仕組みについて備忘録のような形でまとめました。 インフラ初心者でもわかりやすいように心がけて書きました。 触りやこんな技術なんだということをお伝えできれば幸いです。 WebRTCってなに？ WebRTCのRTCは Real Time Communicationの略で、文字通りwebにおけるリアルタイムコミュニケーションを実現する技術です。 ブラウザ間での映像、音声などのデータを相互にやり取りのできるように作られており、2012年頃にGoogleによってオープンソース化されました。 専用のアプリケーションを必要とせず、ウェアラブルデバイスとの通信に用いられたりと幅広い利用がされています。 強みとしては、レイテンシーの少なさと多くのブラウザが標準対応を行っていることで、特にChromeやSafariに新たに機能追加など行うことなく利用できる点は 導入へのハードを大きく下げ、誰でも簡単にリアルタイムコミュニケーションができることへの貢献になりました。 さて、このWebRTCを支える基礎技術についての説明をします。 WebRTCを支えるネットワーク技術(基礎) P2P通信とは？ P2P通信はPeer to Peerの略です。Peerとは英語で対等、同等の意味を持つ単語で文字通り、対等同士の通信ということになります。 よく比較されるのが、サーバークライアント型の通信です。サーバーに問い合わせて、情報もらう形式などサーバーから送られる情報とクライアントから送られる情報とでは かなりの差があるのに対して、 P2P型は対等な立場で情報を共有するという特徴 を持っています。 大きな差としてはサーバークライアント型と比べて負荷分散がされている点と回線が非常に軽いです。 ネットワークの型 テレビ会議システムはリアルタイム通信を行う上で負荷分散と回線の軽さが非常に重要なため 、この技術が用いられていると推測できます。 ただし、勘違いしていけないのは「WebRTCは一様にP2P通信を行っているわけではない」という点です。それに関しては後述するTURNについてのお話で触れます。 UDP UDPとはユーザ データグラム プロトコルの略で、これは名前での理解はなかなか難しいですね笑 ちなみにプロトコルとは各々が統一性のない好き勝手な情報を伝えないように取り決めた約束事のことです。 では何の約束事かというと、UDPはデータを送るための形式の定義です。 UDPの話をするときに必ず出てくるといっても過言ではないのがTCP（トランスミッション コントロール プロトコル）です。 この2つはよく比較されますが、その違いを端的に言うと、データをどれだけ確実に送りたいかです。 情報の欠落などの不具合を避けるためTCPはコネクションを作成し、送られてきたデータの順番に間違いや欠落がないかを確認して、正しく送られてきたかを常に確認します。 一方UDPはコネクションの手順などを省き、受ける側がデータを受け取ったかを確認する作業も省略します。 これだけ聞くとTCPの方が優れているように思えますが、リアルタイム性を求める場合はUDPの方が早いことは確かです。 通常のコミュニケーションでも一言一言に対して、「今の聞こえた？」「聞こえたよ」と確認することはないため、WebRTCとの相性はよいのです。 WebRTCは音声や映像はただ伝えるだけという特徴を生かしてUDPに対して独自の再送制御を作って、リアルタイムコミュニケーションを実現しています。 WebRTCの基本構成 どのようにWebRTCがつながるのか続いて説明します。 ここではP2P通信を前提として話を進めていきます。 WebRTCの構成はこのような構成になります。 構成要素 P2P通信するといっても 「P2P通信ってことはサーバーレスなんでしょ？なんでサーバーが必要なの？」と上の図を見て感じた方もいるのではないでしょうか？ 確かに P2P通信はサーバーを必要としませんが、それは相手について知っていたらの話 です。 いざ ブラウザ同士でP2P通信するぞとなっても、相手はネットのどこかにいる名前も住所もしゃべる言語も知らない相手 です。 特定することは難しいでしょう。 そのため必要なのがシグナリングサーバーです。 シグナリングサーバー シグナリングサーバーとは 通信するために必要な情報を相手に伝えるためのサーバー です。 各ブラウザはシグナリングサーバーを経由してプロトコルの交換や通信経路の探索など行うための情報を共有します。 その時に用いられるのがSDP (Session Description Protocol)です。 SDPとは、通信を行う際、お互いが どのような映像・音声のコーデックを使えるかなど通信における取り決めをやりとりするためのプロトコル で 様々な情報を含んでいますがまず重要なのが以下の二つです。 セッションを構成するメディア そのメディアを受信するために必要な情報(アドレス、ポート、形式など) これらの情報をシグナリングサーバー経由で互いに送りあうことで、P2P通信のための準備を整えていきます。 P2P通信確立の流れとしては ① SDPをブラウザAが作成して、それをシグナリングサーバーに送信し、ブラウザBに送る。これをoffer SDPといいます。 ② もう片方のブラウザが受け取り、その中で自分も使えそうななどを探し、通信できるものを返す。これをanswer SDPといいます。 SDPのやり取り これで双方がどうのように通信するのかは確立できます。 ただし、これだけではまだP2P通信は確立できないのです。 通信の壁、NAT 確できない理由をNATの説明とともに行います。 NATとはネットワークアドレス変換のことを意味し、一般家庭などではブロードバンドルーターやWiFiルーターがその役割を果たしています。 1つのグローバルIPアドレスを、複数のPCやデバイスで共有することができるようにする仕組みです。 また複数のPC/デバイスが同時に通信できるように、ポートマッピングによるポート変換も行っています。 このNATを超える作業がP2P通信を行う上で非常に重要になります。 ブラウザは基本知りうる情報はNAT内部のこと つまり ローカルネットワークのIPアドレス 自分のUDPポート ですがローカルネットワークのＩＰアドレスを相手に伝えたところで通信できるはずがありません。 たとえば、マンションの部屋番号がわかっていても、住所がわからないのでは相手に物を送ることはできません。 そのため、ネットワークの外から見た情報（グローバルIP、NATによって割り当てられたUDPポート）を得る必要があるのです。 STUNサーバー グローバルIPアドレスがわからなければ誰かに教わる必要があります。そのために必要なのがSTUNサーバーです。 STUNとはSession Traversal Utilities for NATsの略です。 これは通称"NAT越え"を行う際に用いられる手段で、ネットワークの外から見た自分の情報を教えてくれるサーバーです。 よく鏡のような役割と例えられます。（自分を写してくれる的な意味で） STUN このようにして得られた情報を元にICE Candidateを作成して互いにやり取りします。 先ほどのP2P通信確立の流れの続きとして ③ STUNサーバーから得られた情報をシグナリングサーバー経由に送り、相手の SDP で受信したリストから候補となる IP/ポートのペアを取得し、そこに STUN リクエストを送信する。 ④ 相手のブラウザから応答が返ってきた場合、発信元のブラウザはチェックが成功したと見なして、その IP/ポートのペアを有効な接続候補として認定する。 この接続候補をICE Candidateといいます。 ICEとはInteractive Connectivity Establishmentの略 で、 ブラウザを取り巻く環境は人それぞれ違うため、互いにP2Pの通信のできそうなIPやポートをかき集めて、相手と共有し、接続確認を行うためのプロトコルです。 基本的にはこのICE Candidateで通信可能経路を見つけることができれば晴れてP2P通信が可能な状態になります。 ただし、この際UDPホールパンチングを行うため、それが可能な環境でなくてはP2P通信を確立できません。 ここまでのP2P通信前提のWebRTCは、STUNによりNATを超えることができなかった場合には、基本的に通信は困難なものになります。 TURNサーバー STUNでも超えられないNATを超えるために必要なのがTURNサーバーです。TURNはTraversal Using Relay around NATの略称で パブリックIPアドレス上に TURN サーバーを置き、 UDP 通信を行うブラウザ同士は直接的には TURN サーバーにデータを送信し、 TURN サーバーは受け取ったデータをそのままもう一方へとリレーする、という仕組みです。 P2P通信ができないと判断した場合に補助的に用いる場合もありますが TURNでデータをやり取りする場合は基本的にはP2P通信ではなくなります 。 TURNサーバー まとめ 上記の内容は基本的にはWebRTCの初めの一歩なものです。皆様の役に立てば幸いです。 個人的には将来的にはVRデバイスなども用いた開発ができると面白いことができるだろうなと感じました。 この技術を勉強することは通信やインフラの知識をつけるという観点でもおすすめの技術なので、試しに触ってみてください。 またそこから安定性などを求めたりすると数多くのプロトコルやハードウェアや回線などの戦いができる初心者でも楽しめて、なおかつやりこみ要素の高い技術です。 LIFULLでは一緒に働く仲間を募集しています。よろしければこちらも合わせてご覧ください。 hrmos.co hrmos.co

こんにちは。Ltech運営チームの山下です。今回は、2021年5月13日(木)に開催した『Ltech#16 LIFULL HOME'S におけるエンジニア×マーケティングテクノロジー』についてレポートします。 lifull.connpass.com Ltechとは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。特定の技術に偏らず、様々な技術の話を展開していく予定です。 エンジニア×マーケティングテクノロジー 今回の Ltech のテーマは「 LIFULL HOME'Sにおけるエンジニア×マーケティング 」です！ LIFULLにはマーケティングスキルとエンジニアスキルの両方を兼ね備えた「 マーケティングテクノロジーエンジニア 」と呼ばれるハイブリットなエンジニア職があります。 あまり馴染みの無い職種ですが、今回は なぜマーケティングテクノロジーエンジニアが必要なのか 実際にどのような業務を行なったのか と言った内容で語っていただきました。 それでは発表レポートに行きます！ エンジニア × マーケティングテクノロジーが必要な理由 エンジニア × マーケティングテクノロジー が必要な理由 from LIFULL Co., Ltd. www.slideshare.net 最初は、「エンジニア × マーケティングテクノロジー」のスキルを掛け合わせた、「マーケティングテクノロジーエンジニア」についての紹介と、「マーケティングテクノロジーエンジニア」が必要な理由です。 プロダクトを運用する上では効果測定を含めた分析が必要不可欠ですが、マーケター・アナリスト〜エンジニア間のコミュニケーションコストが割高になったり、要件調整・設計段階でエンジニア観点が欠落しているため、システムの品質低下につながりがちですね。 分析用のタグが乱立することで、仕様が煩雑化し、調査するにはソースコードを読むと言った経験はWebエンジニアであれば多数の方が経験されていると思います。 エンジニアにマーケティングスキルを持たせることで、要件・設計段階から参画することにより、 サービスのPDCA高速化 、 システムのQCD向上 が期待できます。 マーケティングテクノロジーエンジニアは「マーケター」「データアナリスト」「Webアプリケーションエンジニア」のハイブリット型のエンジニアで、「各担当者のブリッジを行うのではなく、 各領域の習熟度を高めるプロフェッショナルである 」というのはとても印象に残りました！ 広範囲のスキルセットを必要とするため、ハードルは高いですが、今後需要が加速することが想定されますね。 LIFULLではLINEを中心としたオムニチャネル戦略をとっています。次のセッションで実際にどのようなことをやったのか触れていきます！ 実践マーケティングテクノロジーエンジニア 実践 マーケティングテクノロジーエンジニア from LIFULL Co., Ltd. www.slideshare.net 続きまして、LINEによる物件情報の通知配信時間を改善したお話についてです。 施策当初、LINEの通知配信時間を物件詳細画面の閲覧される時間帯を参考に設計していたところ、「 物件詳細画面を閲覧する時間とLINEを確認する時間は同じなのか？ 」「 より効率の良い時間があるのではないか？ 」と言った仮説を元に動き出した案件になります。 当初のシステム構成上、外部システムを経由してWebhookしていたため、限られた情報しか取得できなかったそうです。 そこで、LIFULL独自のアプリケーションである「EOS（Elastic Omnichannel Service）」へ移行することで、外部サービスを経由せずWebhookすることが可能になり、全てのLINE利用者の行動をデータ化し集計することに成功しました。 結果、データサンプル数が増え、より細かいユーザーの行動データを集計することに成功し、様々な分析を行えるようになりました。 現行のデータ数に満足せず、より正確なユーザーの行動を集計するためシステム構成を変更することは、マーケティングテクノロジーエンジニアがいるからこそできるアクションだと思いました！ まとめ マーケティングテクノロジーエンジニア（CRMエンジニア / データエンジニア）は世の中にまだ浸透していないですが、これから需要が高くなっていき、企業 / プロダクトに必要不可欠な存在になっていくことが想定されます。 今回は「エンジニア×マーケティングテクノロジー」についてのセッションでしたが、今後「エンジニア×何かしらのスキル」をかけ合わせたハイブリットなエンジニアが増えていくだろうと思いました。 最後に Ltechでは、LIFULLエンジニアが中心となって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。今後も Ltech を積極的に開催していきますので、ぜひ気になった方は、connpass で LIFULL のメンバー登録をよろしくお願いします！ lifull.connpass.com

こんにちは。LIFULLのプロダクトエンジニアリング部の野澤です。エンジニアリングマネージャーをやっています。 LIFULLでは組織構造として部の下に「ユニット」があり、その下に「グループ」がぶら下がっています。 今期からは私はユニット長を拝命し、間接マネジメントを行うようになりました。 マネジメント業務の中でも1on1は部下のモチベーション維持やキャリア形成、戦略理解を促進させるために重要な手法です。 グループ長時代も1on1はやっておりましたが、間接マネジメントをやるにあたり、メンバーからは相談がしにくくなってしまったようで、「特に話したいことはありません」となってしまうことが増えていきました。 そこで改めて1on1を有意義にするためにはどうしたらいいか考えてみました。この記事ではそのための取り組みを紹介できればと思います。 LIFULLでの1on1 1on1は今やいろんな業界や会社で取り入れられていると思います。 LIFULLでは「3つのしごと」について1on1で対話をすることが推奨されています。 「3つのしごと」とは「仕事」、「志事」、「私事」です。 仕事 「仕事」はもっとも分かりやすい1on1のテーマでもあります。 普段行っている仕事で困っていることや感じたことなどをざっくばらんに意見交換します。 なかには技術的にうまく行かなかったことの相談に乗ることもあります。 また、仕事を通して得られた学びや気づき、成長したことなどについても話してもらうことが多いです。 他にも指示した戦略や戦術、目標に対しての質問に答えたり、どうやったらもっとチームがスムーズにコミュニケーションできるようになるかなどといったことについても話します。 業務をスムーズに進められるようにすることや、メンバーの成長を促進するのもマネジメントの役割なので 1on1のなかで課題発見や課題解決をしたり、成長の確認や次の成長のためのアドバイスを行うようにしています。 志事 次に「志事」です。志事は主にキャリアやスキルアップについての話題です。 LIFULLでは「内発的動機づけ」を非常に重要視します。 なぜなら、自分自身がやりたいと思って取り組むのとそうでないのとでは、パフォーマンスに雲泥の差が出るからです。 また、LIFULLでは 「利他主義」 を社是として掲げ、「常に革進することで、より多くの人々が心からの『安心』と『喜び』を得られる社会の仕組みを創るを経営理念としています。 なので当人が「心からやりたい」と思い、熱中できるような仕事でなければ、社会をあっと言わせるような革進を生み出すことは難しいですし、「指示されたことだけをやっている」ような仕事では、ついつい目の前の作業だけに意識がいってしまい、「人々の心からの『安心』や『喜び』」からかけ離れてしまいます。 なので、時々目線を上げるためにも「本当にやりたいことができていますか」、「理念に対しての仕事ができていますか」という問いかけを行います。 こういった話のなかで、「挑戦したいと思っていることがある」、「違う仕事をやってみたいと思うようになった」のような会話が生まれます。その後、具体的な部署異動や職種変更を検討していきます。 LIFULLでは「キャリア選択制度」があり、半年に一回、自身のキャリアを見直し、配属を希望する部署を申請することができます。必ずしも部署異動が実現される訳ではないですが、日々の1on1を通じてその人のやりがいや将来目指しているものを把握し、より会社の戦略・戦術にフィットするような部署を検討します。 また、そうしたキャリアを実現する上でどういうスキルが必要か、どうやって伸ばしていくことができるかといったことも話し合います。オススメの本やイベントを紹介したり、他部署のメンバーを紹介することもあります。 私事 いわゆる雑談でプライベートな話です。 一緒に働くメンバーと気持ちよく仕事をする上で欠かせないのが、「その人となりを知ること」です。週末どんなことをしたかとか、プライベートで悩んでいること、面白い発見、その他なんでも話します。思いついたことをカジュアルに安心して話せる機会です。 こうした私事についての話を通して、相互理解を深め、信頼関係を構築します。特に新しいメンバーのオンボーディングの際や新しく部署を新設した際はとても大事な会話になると思います。 コロナ禍になり、普段取れるコミュニケーションも限定的になってしまったこともあり、週に30分はこうした1on1をすることにしています。 何に困ったのか 冒頭で「間接マネジメントをやるにあたり、メンバーからの相談もしにくくなってしまったようで」と書いた件です。 1on1では最初に「話したいこと、相談したいこと、困っていることはありますか」と質問することにしています。1on1は基本的にメンバーのための時間で、メンバーが話したいことを優先したいからです。 ですが、ユニット長になってからは「特にありません」となることが多く、一方的に私が質問するような会になってしまったのです。 直接現場のメンバーと話すとなると、彼らにとって私は現場で一緒に働いているわけではないし、彼らはグループ長とも1on1をやっているので、ユニット長にどこまで話していいか、何を話していいか分からなくなってしまったようです。 どう解決したのか ということで、私は以下の2つを実施しました。 1on1の目的を文書化する 1on1の使い方を文書化する 1on1の目的を文書化する ユニット長としてメンバーの仕事、志事、私事の状況を理解することには意味があり目的があります。目的を明確にすることで、「話してもいい」という共通理解を作ることにしました。 例えば 「仕事」…ユニット長として、みんなが仕事で最大のパフォーマンスを発揮できるように、困っていることを確認し、解決したい。 「志事」…ユニット長として、みんなが満足いくような成長をすることで会社の理念の実現に近づけるように、みんなが心からやりたいと思っている仕事ができているかを確認し、個人のキャリアに合った仕事の可能性を検討できるようにしたい。 「私事」…ユニット長として、一緒に働くメンバーとして、お互いに好きなこと、嫌いなこと、嬉しかったこと、困っていることを理解することで、信頼関係を深めたい。 のような感じです。 こうすることでメンバーからは何のために、何を話すべきなのかが明確になります。これを社内ブログで投稿し、誰でも見れるようにしてみました。 1on1の使い方を文書化する 上記だけでも足りるかな、と思ったのですが1on1の活用事例も合わせて掲載してみました。 相談相手 / 壁打ち相手 仕事で〇〇しようと思っているんですがどう思いますか？ 仕事で〇〇に困っているんですがどう思いますか？ ◯◯さんに困っています 会社や部の方針 このあいだ総会で言っていた戦略について疑問を持ったので教えてください 追加されたり変更された会社のルールや制度について、それらの目的や意図を教えてください キャリアについて この間とある本を読んで（とある人と話して、またはとあるイベントに参加して）、自分はもっと◯◯みたいな仕事がしたいと気づいたのですが、どうやったらそういった仕事の機会をもらうことができるでしょうか？ どうやったらその仕事ができるようなスキルを身につけることができるでしょうか？ 上司へのFB この間、野澤さんは◯◯みたいな発言をしていましたが、言い方が適切ではなかったと思います もっと他の部署の組織長みたいに具体的なビジョンを示して欲しいです もっと公平な評価をして欲しいです 今の目標設定に納得がいっていません もっとメンバーの仕事を見て欲しいです 仕事が多すぎます。もっと優先順位をつけて選択と集中をして欲しいです 上司へのプライベート（？）な質問 野澤さんは休日は何やってるんですか？ 好きな食べものはなんですか？ 野澤さんのキャリアビジョンについて教えてください 野澤さんが20代のときのことを教えてください ◯◯のニュース見ました？野澤さんはどう思いますか？ みたいな感じです。 この「上司にとっての1on1の目的」と「活用事例」はいわば、1on1のコンテキストを豊かにするものだと思っています。1on1に対する期待を上司とメンバーとの間ですり合わせる作業です。ルール化すると重たいですが、コンテキストをリッチにしておけば、個々人が自由に考えて話すべきことを考えやすくなります。（この辺は 『NO RULES(ノー・ルールズ) 世界一「自由」な会社、NETFLIX』 を参考にしてみました） どうなったのか 実際に話題のバリエーションが広がりました。 上記のブログを投稿した後の1on1では「ユニット長の貴重な時間を私の雑談に費やすのはもったいない」と思っている方がいたことも分かりましたし、「細かな業務や技術的な相談で煩わせたくない」と考えていたメンバーがいたことも分かりました。 特に「1on1の使い方」がメンバーには刺さったらしく、「こういう質問もしていいんだ」という感じたそうです。雑談もバリエーションが広がり、「野澤さんが20代のときのインターネット黎明期ちょっと後のときってウェブの可能性をどう思ってたんですか？」みたいな話も出るようになりました。 1on1は基本的にメンバーのための時間です。メンバーがうまく1on1を活用してもらえるよう意識付けを行っています。こんな感じで日々、エンジニアリングマネージャーとしてのマネジメントを試行錯誤しています。 LIFULLの1on1に関しては、 弊社CTOの記事 も合わせてご覧ください。 LIFULLでは一緒に働く仲間を募集しています。よろしければこちらも合わせてご覧ください。 hrmos.co hrmos.co

こんにちは。Ltech運営チームの市来です。 今回は、2021年3月31日(水)に開催した『Ltech#15 未来の体験をつくるLIFULL Labの取り組み ~ LIFULLのR&D部門とは ~』についてレポートします。 lifull.connpass.com Ltechとは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。特定の技術に偏らず、様々な技術の話を展開しています。 未来の体験をつくるLIFULL Labの取り組み ~ LIFULLのR&D部門とは ~ Ltech#15のテーマは、LIFULLのR&D部門である『LIFULL Lab』の取り組みについてです！ LIFULL Labでは、社会における既成概念、人々の固定概念を壊し、「あらゆるLIFEを、FULLに。」する研究・企画・開発を行い、世界を変えるような未来の体験をつくる取り組みを行っています。 今回はLIFULLのR&D部門である LIFULL Labの方々にこれまでの事例やいま取り組んでいる内容について語っていただきます！ それでは各発表のレポートです。 「ありえるかもしれない未来」をR&DするLIFULL Lab 「ありえるかもしれない未来」をR&Dする LIFULL Lab from LIFULL Co., Ltd. www.slideshare.net 最初の発表は、「Well-beingな暮らし」の実現を目指し、社会課題解決に向けたResearch&Designを行うLIFULL Labの活動方針や研究領域や取り組みなどについてご紹介です。 LIFULL Labでは、外部パートナーとオープンイノベーションで「体験できる」状態まで実装するということで R&Dの「D」意味としては「Development」はなく「 Design 」であるというのが印象的でした。 また、現在進行中のプロジェクトとして紹介された下記プロジェクトはどれもワクワクするものばかりでした。 現在絶賛R&D中のWell-being Cityについても近々公開できるかも！？ということで、とても楽しみです！ VR空間上で「したい暮らし」を見つける体験のプロトタイプ『 空飛ぶホームズくん 』 ユーザのTwitterの投稿を解析し、自分に足りていない感情に出会える場所を推薦するサービス『 LIFE WILL 』 絶賛R&D中の「Well-beingになれる街」のあり方とその指標を探索するプロジェクト 食による社会課題解決と持続可能な社会を目指すプロジェクト『 Earth Cuisine 』 上記の「空飛ぶホームズくん」と「LIFE WILL」については、この後のセッションで深堀していきます！ Well-beingを測る「LIFE WILL」開発の舞台裏 Well-beingを測る「LIFE WILL」開発の舞台裏 from LIFULL Co., Ltd. www.slideshare.net 続いて、ユーザのTwitterの投稿を解析し、自分に足りていない感情に出会える場所を推薦するサービス『LIFE WILL』についてのお話です。 Twitterの直近200件の投稿から感情分析し、ポジティブな感情だけではなくネガティブな感情にも触れることでよりWell-beingになるという考え方（感情の多様性＝Emodiversity）で、 分析した結果、よりWell-beingになるための場所や街、物件情報を全国1800の市町村からレコメンドしてくれるサービスとなってます。 「ラッセンの円環モデル」を参考にLIFULL独自の感情モデルを作ったり、分析結果がネガティブな印象になりすぎないように感情のオノマトペ化やキャラクター化を行ったり、どのように作り上げていったのかを知ることができとても面白い内容でした。 今後の課題としては、現在ユーザの感情分析はTwitterのみで、街の感情分析はアメブロ・はてなブログのみなので、その他のテキストデータも分析に使えないか探索していくとのことでした。 分析するテキストデータが増えることにより、さらにユーザや街の感情が精緻化されそうなので楽しみです。 ちなみに私のTwitterアカウントで試したところ、一番強い感情は「ツンツン」で一番弱い感情は「モヤモヤ」と結果が出てきて、自分では把握していない感情を知ることができました！ みなさんも是非おためしください。 lab.lifull.com ニオイセンサで探索する街の新たな指標 ニオイセンサで思索する街の新たな指標 from LIFULL Co., Ltd. www.slideshare.net 続いて、街のニオイも居住先を決める際の新たな指標になるのではないかという仮説を思索しているお話です。 街には特有のニオイがあり、プルースト効果によって懐かしいと感じるのではないかという仮説をもとに、ニオイセンサを用いて街のニオイを検証している内容となります。 ニオイセンサのメーカーに、街のニオイのサンプルとして街の空気を入れた袋を段ボールに入れてメーカーに送った話は面白かったです（笑） センサメーカーからは、「街によってニオイの主成分が変わることが分かり、街のニオイの判別できる可能性がある」という回答をもらったとのことで、細谷さんにて実際に計測し可視化するためのアプリを開発したり、自転車にセンサをつけて街中を走ったりなど、技術力・実行力共に高くカッコいいと思いながら聞き入ってました。 課題としては、現状ニオイの基準点を整備できていなかったり、気象条件によって左右されないようにしたり、サンプルがまだ足りないなど、まだまだ仮設の段階とのことでした。 ニオイの感じ方は人それぞれ違うと思いますが、数値化されることで科学的に同じニオイかどうかわかるのはとても興味深い内容でした。 このニオイのR&Dが進んでいくと、街のニオイが住まい探しを行う上で新たな検索軸になりそうですね！ 「空飛ぶホームズくん」を実現するVR技術 「空飛ぶホームズくん」を実現するVR技術 from LIFULL Co., Ltd. www.slideshare.net 最後に、VR空間上で新たな住まい探しを体験する「空飛ぶホームズくん」についてのお話です。 「空飛ぶホームズくん」はVR空間上に再現された街を飛び回りながら物件探しを行うことができます。 VRに初めて触れるユーザでもVR酔いしないような操作や移動速度などを試行錯誤したり、操作で迷わないようにかなりシンプルな操作となるように設計したりなど、ユーザに寄り添ったものになっているなぁと感じました。 VR上に再現しているミラーワールドにはゼンリン3DマップやGoogleMapが使用されていますが、つい先日公開された「PLATEAU」を用いることができるかについても調査しているとのことでした。 VRで物件探しができるようになることで、遠く離れた場所の物件でも手軽に見れるようになるので、もっと広めていきたいですね！ アフタートーク 各セッションが終わった後、登壇者全員でざっくばらんにアフタートークをしました！ LIFULL Labで扱うテーマはどのように決めているのかについてや街のニオイの収集を手伝いたいなど、参加していただいた方々とゆる～く雑談を行いました。 PLATEAUなどのオープンデータも続々と出ているとのことで、VR界隈が広く普及して身近なものになっていければなと感じました。 最後に Ltech では、LIFULLエンジニアが中心となって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。 今後もLtechを積極的に開催していきますので、 ぜひ気になった方は、connpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

テクノロジー本部の鈴木( @szk3 )です。ソリューションアーキテクト・クラウドアーキテクトとして業務にあたっており、最近はWebRTC周りに興味関心があります。 自分が所属するチームでは「アーキテクト相談」 という 技術相談の取り組み を行っています。 今回は、その技術相談で取り入れている 「ナレッジマネメント」および、知識経営の提唱者である野中郁次郎先生が提唱した「SECIモデル」 について紹介します。 背景 相談手法 ナレッジマネジメントとは？ SECIモデルとは？ アーキテクト相談の対応範囲 プロセスをスムーズに回せるような環境・運用整備 表面化・連結化における、形式化（ナレッジ化） 運用への向き合い方 回答に時間がかかりませんか？ 他の技術相談窓口と競合しませんか？ ナレッジの効果測定はどうやっていますか？ 情報鮮度への対応はどうしてますか？ まとめ 背景 LIFULLでは、多種多様なプロダクト開発を行っておりますが、それらの設計や開発工程においてグループ内だけでは判断しづらい内容がでてくることがあります。 そういった悩みは、個人・組織において以下のような問題を引き起こしかねません。 個人レベル 悩みの解決の糸口が見つからず、開発工程を圧迫する ルールや規約があることを知らず、手戻りにつながった そもそも、誰に聞いていいかわからない 組織レベル 別のグループも同じ悩みを抱えているが、その悩みが共有できてない 相談内容と回答の中から、汎用的なものはストックしておきたい そういった課題に対し、汎用的な技術相談窓口として機能しつつ、それらのやりとりを一過性のものにしない相談の仕組みが「アーキテクト相談」です。 「アーキテクト相談」の目的は "システム・アーキテクチャの初期設計・手戻り工数削減" です。 この目的を達成するために "解決策を一緒に整理し、使えるナレッジとして再利用できるようにする" という一連の流れをサポートしています。 相談手法 「ナレッジマネメント」を説明する前に、相談手法について整理します。 他の方法(例えば対面での口頭、電話）もありますが、ここではテレワークを前提とした現時点で実際に使っている相談手法を列挙しています。 手法 メリット デメリット チャット (Slack / Chatwork ) ・個別相談でも気兼ねなく聞ける ・ほぼリアルタイムで相談にのってくれる ・ やりとりの流れを追うのに時間がかかるケースがある ・大人数の部屋だと相談しにくい人が、少なからずいる オンライン会議 (Zoom / Meet ) ・話したほうが早いケースがある ・熱量が伝わりやすい ・相談内容を他の人にシェアしづらい（議事録残らない可能性） ・時間的な制約がある チケット駆動 (JIRA) ・議論が混ざりにくい ・シェアしやすい ・テンプレ化しやすい ・情報をリンクさせやすい ・チケットを書くのが大変（文章の整合性、伝える情報の粒度) ・解決までに速度がワンテンポ送れる ドキュメントを読む (公式Web, Confluence、Github(README)、Google Drive等の資料) ・自己解決できる ・シェアしやすい ・目的の情報を探すのが、困難な場合がある ・情報鮮度が信用出来ないケースがある ※ドキュメントを読むは、正確には"相談"ではありませんが、解決したい課題があるという意味では同じレイヤーに存在する手法だと考えます。 お察しの通り、 どれか一つで解決するのはなく全ての手法を使っています し、運用ルールしだいでデメリットを解消するようなことも可能です。 また、相談者のコンテキストに合わせて、複数組み合わせることもあります。 どれが良いというのはなくて、 相談相手が「選択できる」状態を作っておき、特性にあわせた手法を選べるのが重要 と考えています。 また、上記には含めていませんが、Google グループ の「会話」はスレッド的に使えます。オープンにディスカッションできて検索もできるので、お手軽に情報管理するのにおすすめです。 ナレッジマネジメントとは？ 「アーキテクト相談」では、相談と回答から再利用可能な情報を抽出しドキュメンテーションしています。 その一連の流れを、 ナレッジマネジメントのフレームワーク「SECIモデル」を用いて運用しています。 「ナレッジマネジメント」とは、 企業が保持している情報・知識と、個人が持っているノウハウや経験などの知的資産を共有して、創造的な仕事につなげることを目指す経営管理手法 *1 です。 ナレッジマネジメント - Wikipedia この管理手法を、技術相談の過程で生み出される情報資産の管理に適用しています。 「ナレッジマネジメント」に関しては、北陸先端科学技術大学院大学　知識科学研究科　梅本研究室の資料が大変参考になります。 www.jaist.ac.jp SECIモデルとは？ 「SECIモデル」とは、ナレッジマネジメントのフレームワークであり 個人の暗黙知を組織的な形式知に変換し、その形式知を個人が体験することで暗黙知に変えていくプロセス になります。 そのプロセスにおける、知識変換の流れを４つのステージで表現しています。 それぞれのステージを簡単に説明すると、 共同化 では、個別の暗黙知を共有し組織の暗黙知として扱えるようにします。 表出化 では、組織の暗黙知を明示的な言語や図を通じて形式化します。 連結化 では、形式化された情報を組合わせて新しい形式を生み出したり体系化します。 内面化 では、整理された情報を使って個人が行動・体験して新しい暗黙知にしていきます。 このプロセスを継続的に回し続けることで、 組織的に使える情報資産を作り、個人と組織に貢献していくことが可能になります。 アーキテクト相談の対応範囲 「SECIモデル」はやや難しそうにも見えますが、チームとして具体的にやっていることがイメージできると、意外とシンプルであることがわかります。 宛先のない技術相談の窓口として機能し、課題の顕在化を推進する（ 共同化 ） 課題を整理し、ソリューションを一緒に考え、ナレッジ化する（ 表出化 ） ナレッジを体系化する（ 連結化 ） 新しいナレッジの認知を促し、個人が利用できる状態を創出する（ 内面化 の環境整備） ここから分かる通り、「アーキテクト相談」の責務は単純に相談内容に回答するだけに留まりません。 「SECIモデル」の共同化から内面化までの全てのプロセスに関与します。 では、具体的に何をしているか説明します。 プロセスをスムーズに回せるような環境・運用整備 「SECIモデル」の実践において、相談者や回答者側のルールを整備や、相談窓口の多様化（チャット / オンライン会議 / チケット駆動）など、日々改善サイクルを回しています。 たとえば、 ナレッジの一覧をどのようにすれば見つけやすくなるのか？ ナレッジのフォーマットはわかりづらくないか？ ナレッジ担当の負荷は分散されているか？ 相談者は質問しづらくないか？ 効果測定をどのように行うか？ など、考慮ポイントは多岐に渡ります。 そのため、週次の定例MTGにて相談内容と運用改善についてディスカッションし、TRYし続けています。 表面化・連結化における、形式化（ナレッジ化） 技術相談への回答後、そのやりとりからナレッジを抽出しますが、ひとつの相談から複数のナレッジが得られることもあります。 それらのナレッジ候補について、チーム内でナレッジ化の必要是非についてレビューを行います。無駄に全てをストックすることはしませんし、再利用しにくい知識はここでフィルタされます。 ナレッジ化が合意された知識はドキュメンテーションされますが、その成果物であるナレッジもチームによるレビューが行われます。これによりナレッジの質を高めています。 また、ナレッジを検索しやすいように整えたり、そのナレッジ同士の関連を更新していく作業も対応範囲のひとつです。 運用への向き合い方 技術相談および「ナレッジマネジメント」の運用過程において、課題や懸念点も生まれてきます。 ここでは、運用における課題や懸念点について、チームがどのように考え、向き合っているかを紹介します。 回答に時間がかかりませんか？ 技術相談（特にチケット駆動）でのやりとりは、全てにおいて決して早いレスポンスが返せているとは思っていません。 提供された資料の読み込みと、回答期待値のすり合わせに時間がかかるケースなどは一定数存在します。 ただし、これらは回答精度をあげるために必要な時間であったりもするので、 ある程度は許容しています。 許容はしつつも、それらを可能な限り短くしようとする改善活動は行い続けています。 たとえば、あまりにも回答に時間がかかりそうなチケットは、チケットを分割することで回答者側のアサインを増やす工夫をしています。 仕組みに縛られすぎず、 目的を見据えたうえで柔軟に対応しています。 他の技術相談窓口と競合しませんか？ LIFULLではスペシャリティのあるチームが多数ありますので、そういったチームでは相談窓口を開いています。 しかし、それらと 競合するとは考えていません。 相談者の質問ドメインが明確であれば、それぞれのスペシャリストなチームが対応するのが、最も適切で自然だと考えているからです。 たとえば、社内のアプリケーション実行基盤チームはSlackで問いかければ数分で答えが返ってきます。その体験は代替できないものであり、専門的な相談に対しては直接聞いてもらったほうが明らかに全員の幸福度は高いと考えています。 逆に、ドメインを定義しにくい相談や、クラウド活用、アプリケーションの設計に関する相談については、「アーキテクト相談」が窓口になるケースが多いです。 ナレッジの効果測定はどうやっていますか？ これはまだ試行錯誤中ですが、その中でもいくつか取り組んできた例を紹介します。 まず前提として、アーキテクト相談では ナレッジをConfluenceに保存しています。 Confluenceとはチーム開発におけるドキュメントのコラボレーションツールです。 非常に多機能で、JIRA（課題管理ツール）と連携するとドキュメントを統合的に管理することができます。 www.atlassian.com 効果測定として、当初はナレッジへの「いいね」の数などが指標の候補になりました。 しかし、もっとわかりやすく直感的なフィードバックをいただけるように、以下のようなアンケートページをConfluence上に作成しました。 ConfluenceではHTML(+css+javascript)を記述することができるので、HTMLマクロでアンケートを作成しています。 ボタンを押すと、そのページのコメントに評価内容を投稿する仕組みになっており、各ナレッジからこのマクロを含むページをインクルードすることで、アンケートを一元管理しつつ、より詳細なフィードバックが得られる仕組みを実現しています。 また、直近では、Google Analyticsを使い、効果測定のための指標を作れないか検証を始めたりもします。 ここらへんは、まだまだ発展途上です。 情報鮮度への対応はどうしてますか？ Confluenceのラベル機能を利用して、見直す可能性があるナレッジを可視化しています。 具体的には、ナレッジに「要ナレッジメンテ」のラベルを付与し、コンテンツレポートテーブルマクロで一覧化しています。 これらを定期的に見直す仕掛けをつくることで、鮮度を保っていきたいと考えています。 まとめ 以上、 「アーキテクト相談」という技術相談を通じたナレッジマネジメントの実践 について紹介しました。 技術相談については、100社あれば100社のスタイルがあると思います。 それぞれのベストプラクティスを探す旅に正解や終わりはありません。 「アーキテクト相談」への 相談件数は前期比で2.8倍になり相談していただけるUUも増加傾向にあります が、まだまだやれることがたくさんあると感じており、今後も改善しつづけ発信していきたいと思います。 我々は、「SECIモデル」を用い "知識の管理"、"知識の経営" を実践していくことで 「経営をリードするエンジニア」を体現していきたい と考えています。 新しい季節は人の流れが変化し、技術的な相談事が増える時期でもあります。 そういった機会をチャンスと捉え、「SECIモデル」で社内で使える知識に変えていきたいですね。 弊社の取り組みが、これから技術相談のフローを整備しようとしている方の参考になれば幸いです。 *1 : Wikiより抜粋

品質改善推進ユニット 品質統括グループの岡です。 社内の開発が円滑に効率よく進められるような仕組みづくりや、システムやプロセスの品質向上のための活動をしています。 昨年より始めた取り組みを紹介いたします。 きっかけ LIFULLでは、常に新しいことに挑戦し、スピード感を持って日々開発を進めていける土壌があります。 一方で、組織も大きくなり運営するサービスも増加してきたこともあり、開発チーム、各プロジェクト、システムの状況を把握することが難しくなってきました。 そんな状況の中で、情報をもっと早くキャッチアップできていたら予防できたはずの障害が発生し、課題が明らかになりました。 「システムや開発プロセスの品質が見えていなくて、打つべき対策を打てていない可能性が…」 「そういえば、運営するシステムに関する情報が品質改善の組織としてきちんと把握できていない…」 品質改善推進Uが行ってきたこれまでの開発PJ支援は、主には開発担当者からの相談を受けてからでしたので、どうしても後手になってしまったり、問題が起こるまで手を打てずにいました。 目指すのは開発チームのパートナー そこで、必要な対策が事前に打てるように能動的にこちらから働きかけていくことはできないか、ということになりました。 やりたいことは、「○○ができてません」といった品質に関する指摘をしていく…ということではありません。 私たちは、開発チームに寄り添って、コミュニケーションすることを大切にしていきたいと考えています。 共に品質に関する状態を確認し、今後の計画を見つめ直すことで、後回しになりがちなシステムの技術的負債の解消に関わる改善施策などが中長期的計画にしっかり組み込まれるようになる、そんな改善サイクルを構築していくことを目指すことにしました。 はじめに、理解するところから まずはLIFULLで運営するプロダクトについて、アセスメント（情報収集、調査、分析、評価）を行う必要がありました。 プロダクトオーナーの協力を得て集まった定性的情報、各種ツールを利用して取得した定量的データなど様々な情報をコンバートしてデータベース化し、TableauというBIツールを利用して情報集約と可視化を行いました。 それらのデータを元に、品質に関して専門に動ける品質改善推進の組織が、開発チームの協力を得ながら追加の情報収集と調査を共に行い、理解を深めながら今後の計画を検討することにしました。 アプローチしたいプロダクトは… とはいえ、プロダクトの数は９０近くあったため、収集済みのプロダクト情報から１回目のアセスメントによりアプローチを開始するプロダクトを絞り込み、初回の対象プロジェクトとして、以下の３つの項目に注目して約４分の１のプロダクトを抽出しました。 事業規模（売上や会員数など） 個人情報の保持件数 セキュリティに関する対策状況（定期的な診断状況、監視運用体制など） 現在、初回の対象プロダクトとなった開発チームに対し、アプローチを開始し、詳細のヒヤリングや追加調査などに着手し始めたところです。 ひと段落したら、例えば運用状況（開発形態や外部サービス連携有無など）やシステム経過年数など、別の観点でのアセスメントにより抽出したプロダクトへのアプローチを検討する予定です。 開始してみて いくつかの開発チームと取り組みを開始したところですが、どの担当者も快くざっくばらんに応じてくれ、非常に協力的で助かっています。 意図を理解しようとしてくれているのを感じますし、開発者としての問題意識の高さを感じます。 この活動を通して、 「複数の課題があり何を優先して対応すべきか迷っている」 「対策していたが、今回再確認したら別の要因でうまくいっていなかったところが見つかった」 「体制変更により業務フローも変更のため、早急な移行計画が必要」 など、課題の整理や気づきを得られたり、さらに深掘りした調査の実施に繋がったり、協力体制を築くきっかけになったりしています。 より効率の良い品質向上への改善提案、計画、支援につなげていく流れを作りたいと考えています。 まとめ 今回の取り組みは私たちにとっては新しい試みであり、完成形はまだ見えていません。 生み出されたサービスの品質維持・向上と、さらにスケールさせていくための後押しとなるような、意義ある活動にしていけるようこれからも試行錯誤していければと思います。 お読みいただきありがとうございました。

はじまして、プロダクトエンジニアリング部の関川です。 最近はテレワークの影響で、めっきり外に出ることが少なくなり、会議もzoomなどを用いたものがほとんどです。 巷ではVR空間で会議するなどを一部の企業が取り入れているようでwithコロナの新しい風を感じます。 そんなオンラインVRが導入されるのはまだ先の話の方が多そうですが、まず自作で体験してみるのはどうしょうか？ そのための技術の選定や簡単なPUNを用いたプロジェクトの作成方法をまとめたので試してみてください。 また今回は導入ですが、次回の記事でoculusを用いたオンラインVRを作成していきます。 オンラインVRを作成する場合に上がるBaaS技術 VRを作成するといえばいろいろな開発環境想像される方は多いですが、 今回のターゲット開発環境は Unity です。 開発環境 Unity2019.4.15f1 VRオンラインサービスを作るとなると ・サーバーはどう用意する？ ・費用は？ などを考える必要があり、一気にハードルが上がるイメージですが そんなときに利用したいのがネットワークエンジンライブラリ。 ライブラリの導入は爆速でネットワーク問題を解決してくれます。 Unityに対応したネットワークエンジンは複数あり、その概要と個人的見解などを紹介します。 結論から書くとタイトルにある通り、PUN2はいいです。 PUN(Photon) Photon Unity Networking Photonは世界No.1の独立系リアルタイムネットワークエンジンです。そのUnity用パッケージをPUNと呼びます。 フレームワークとしてPUNとPUN2があり、今からやるならPUN2を推奨します。 photonはマルチプレイヤーでのゲームを可能にし、あらゆるプラットフォームのゲームに対応しています。（PC、スマホ、家庭ゲームなど） また機能として、ユーザー数に応じた自動スケーリング、ランダムマッチなどを可能にするマッチメイキングAPIなど開発を支援するものが盛りだくさん。 個人的にはアセンブリが整理されていてテスト書きやすそうという部分が大きいです。 MUN Monobit Unity Networking マルチプレイを簡単に実装できるUnity専用の無料アセットです。 日本の開発ということもあり、法人へのサポート体制がかなりしっかりしていそうです。利用料もPUN2と変わらず、過去に 違い と言われてたUDP通信非対応はMUN2では対応されたため、いよいよPUN2との差がほんとにすくない印象なのですが 個人単位でのドキュメントとかがあまり見られないので、学習面を考えると日本語、英語合わせて文献豊富なPUN推しです。 UNet Unity５.x系の最大の産物。 Unity公式のネットワークエンジン。 この項目で伝えたいことは UNet は非推奨となり、今後 Unity から削除される予定です。新しいシステムが開発中です。 ただこれはよく使われていたBaaSなので、 PUNもMUNもこれをベースに作られています 。 故にUNetの記事は調べると今でもかなり出てきますし、たまにPUNと偽って出てくる時があるので注意です。 チュートリアルとかも手厚いのでネットワークエンジンの基礎を学びたい方はここをあえてやるのもいいのかもしれないです。 Mirror UNetからの移行をするユーザーのためのOSSのネットワークフレームワークです。 これ単体ではPUNなどと違い、インターネット経由の通信はできず、LAN内環境で動かすことができます（逆にPUNはPhoton server経由がマスト)。 そのため、 インターネット環境を必要としないのは魅力的ですが、サーバーも別容易となるとオンラインVRを爆速で作るには学習コストが高いですね。 個人的には文献もさほど多いとは言えないのとUNetから入らないと「Mirrorワカラナイ」になりそうなのでここでもPUN推し。 結論:PUN2を使う PUN2とMUNはほんとに近い物で、選ぶときは少し迷いましたが、やはり困ったときの文献の量は非常に大きいので、今回はPUN2を用います。 そのためPUN2についてもう少し掘り下げて行きます。 PUN2とは 仕組み PUN2は極力開発者の負担を減らすため、構造すら 公式チュートリアル で「気にする必要がない」と明言しているくらい開発者は意識せずとも作成できます。 そのため、ここで理解しておかないといけないのはPhotonのマスターサーバーとロビーとルームの概念です。 マスターサーバーはPhotonに対するすべての通信を管理している立場であり、複数のゲームサーバーが存在しています。 その先にゲーム単位など個々のロビーが存在しています。 さらにそのロビーの先にプレイヤー同士が集うルームがあるイメージです。 Photonはこの概念が重要なの覚えておくとよいです。 利用料 PUN2自体は無料ですが、Photon Cloud自体は料金表が存在します。 利用料は従量課金性で、指標としてCCU(Concurrent Users:同時接続ユーザー数)と転送量が出てきます。 利用プランとして 20CCUまでは無料枠として使うことができるので、開発などの段階やお試しが可能です。 詳しい料金に関してとPUN plusに関しては今回のスコープから外しますので、 こちら を参考にしてください。 PUN2でオンラインの空間を作る VR開発を行う上だとどのデバイスに対応しようとかはあるのですが 今回はまずオンラインゲームを作る大まかな部分を手順を解説していきます。 まずは登録・ルームサーバーを立てる ここら辺は大体のPUN2に関しての 他の記事 で書かれているので割愛しますが大まかな流れだけ共有します。 ボイスチャットを用いるので二つのアプリケーションidを作成してください。 1. Photonの公式サイトに入り、右上の会員登録を済ます。 2. マイダッシュボードへ行き、新しいアプリケーションを作成しアプリケーションIDをコピーする。 3. Photon Voiceのアプリケーションを作成して、アプリケーションIDをコピーする。 プロジェクト作成する unityを立ち上げプロジェクトは３Dで作成します。 プロジェクトにasset storeからPUN2とPhoto Voice 2をインストールして、 各IDを入力してください。 サーバーとの接続はこれ一行 PhotonControllerという名の空オブジェクトを作成おいて、 scriptsファイルにC#コードを追加 Photonのネームスペースを追加して一行。 PhotonNetwork.ConnectUsingSettings(); これをシーン開始の"start"の中に仕込めば完了。 ルーム作成とジョインのコールバック定義 次にマスターサーバーへ接続完了した後のコールコールバックを定義します。 動きとしては、 1.マスターサーバーに入って、ルームがあれば入る 2.なければ作成してルームに入る という流れ。 コールバックが爆速に早くなったのがPUN2のPUNとの違いだそうです。 public class MatchMaker : MonoBehaviourPunCallbacks { // アバター public GameObject PhotonObject; void start (){ PhotonNetwork.ConnectUsingSettings(); } // マスターサーバーに接続したとき public override void OnConnectedToMaster() { // ルームがないならルームを作り,あとならそのままルームに入る PhotonNetwork.JoinOrCreateRoom( "room" , new RoomOptions(),TypedLobby.Default); } // ルームに入ったとき 　　 public override void OnJoinedRoom() { // アバター(オブジェクト)を作成する PhotonNetwork.Instantiate(PhotonObject, Vector3.zero, Quaternion.identity, 0 ); } } photonサーバー設定を行う photon server setttingsを探し以下のように設定を行います。App IDを設定していればJPサーバーに設定を変更するだけでよいです。 Photon VoiceのAppIDも忘れずに入力しましょう。 状態共有するには？（オンラインゲーム化） アバターとして扱うゲームオブジェクトは prefab化 しておきます。 また共有したい情報によりますが、アバターなど人型の場合,add componetから "Photon view"と "Photon TransormView"と"PhotoAnimatorView"を追加します。 さらに"Audio Source"と"Photon Voice Speaker"をボイスチャット用に着けます。 実行する オブジェクトにスクリプトを結び付けなどを行い、 アプリケーションをビルドして最低二つのアプリでログインし、同一空間にアバターが二つあり、声が届いていれば成功です。 まとめ 爆速でのオンラインツールを開発可能にするのがPUN2の強みです。 ぜひ一度やってみてはいかがでしょうか？ 今回はオンラインVRを作成する前段階としてオンラインゲームを作成しましたが 次回はoculusのデバイスを用いて、オンラインVR作成する手順を解説したいと思います。

KEELチーム の相原です。 最近開発している コマンド1発でKubernetes上にProduction Readyな環境を手に入れる コードジェネレータの話です。 Kubernetesの利用を広める上での課題 Kubernetes Manifestの難しさ 既存の解決策 設定量の増大 コードジェネレータで解決する 捨てやすさ 抽象度 変更への追従しやすさ Open Application ModelとKubeVela keelctl を開発してきてみて Kubernetesの利用を広める上での課題 KEELチームが開発しているアプリケーション実行基盤は巨大なMulti Tenancy Kubernetesクラスタをベースとしていて、各アプリケーション開発者はKubernetes Manifestといくつかの設定を記述するだけでProduction Readyな環境ですぐにアプリケーションを稼働させることができます。 これは車輪の再発明の防止や開発速度・運用品質の向上などの大きなメリットをもたらし、LIFULL HOME'Sの大部分と新規開発のアプリケーションの多くがこの上で稼働するようになりました。 こうして我々のプロジェクトは一定の成果を得ることに成功しましたが、社内で利用を広めていくにあたっていくつかの問題点が出てきました。 Kubernetes Manifestの難しさ 一つ目はKubernetes Manifestの難しさです。 topologySpreadConstraints や podAntiAffinity を利用したPodの適切な分散 PodのTerminating時にEndpoint ControllerによってPodのIPがロードバランシング対象から外れるのを待つための preStop フック(あるいはそれ相当のアプリケーションによるSIGTERMハンドリング) 安全なPod Evictionのための PodDisruptionBudget の設定 Recommended Labels の付与 適切なSecurityContextの設定 Kubernetes Manifestを書くにあたっては、このような広く知られているベストプラクティスがいくつかあり、アプリケーション開発者にこうした設定を要求するには無理があります。 LIFULLではIstioを利用している ため更に設定量は増えますし、Service Topologyのようなバージョンアップによって増えた新しい機能も取り入れて欲しいといった思いもあります。 既存の解決策 一般にこういった課題を解決するためにはHelmや、現在ではKustomizeなどが用いられてきました。 これらのソフトウェアを利用することでベストプラクティスをテンプレート的に用意して、利用者は必要最低限のパッチを当てるだけでよいというようなものです。 ただしHelmはChartの作成者によって自由度が大きく変わるため、特定のミドルウェアであればともかく大勢が満足するようなウェブアプリケーションのテンプレートをHelm Chartとして提供することは難しいです。 Kustomizeは割とこの問題の解決だけを考えれば理想的な選択肢で、 Remote Build を用いればベストプラクティス部分をうまく共通化できるでしょう。 モノレポにしていればRemote Buildも必要ありません。 実際に我々もKustomizeは出た当初くらいから長く使ってきています。 LIFULLではモノレポではなく権限分離の考えからアプリケーションごとにリポジトリを分けているため、当時はまだなかったRemote Buildが必要となりKustomizeのWrapperを自前で書くなどしてこの問題に対処してきました。 しかし、次第にKubernetes Manifest以外の生成にも目を向ける必要が出てきて、より包括的なアプローチが求められるようになりました。 設定量の増大 我々はアプリケーション開発者の関心事を減らすため、KubernetesやIstioをはじめとしてその他開発者支援のための多くのKubernetes Operatorを提供しています。 他にもGrafanaやPrometheus(+ Thanos + Trickster), Fluentd, Spinnakerを提供することによって監視基盤やデプロイパイプラインなども運用して開発者に提供しています。 それぞれにOperatorがあったりなかったりなかったら作ったりしていますが、それでも全てをKubernetes Manifestで設定することは叶いません。 これではManifest TemplatingソフトウェアでKubernetes Manifestを生成してからも数ステップの設定作業が必要となってしまいます。 更にビルドパイプラインや各種Lintをはじめとした多数のGitHub Actions、依存AWSリソースを作成するためのCloudFormationテンプレートも提供しているため、いずれにせよ設定量の増加が課題となってきていました。 (Kustomizeと同様にCI周りもモノレポだと楽になりそうですが、モノレポをちゃんとやろうとすると先述の権限分離に加えてVCS周りを頑張らなきゃいけなくなったりするのでリポジトリ戦略を変えるという判断にはなりませんでした) コードジェネレータで解決する こうした課題を解決するため我々はコードジェネレータ keelctl を開発しました。 こちらで用意したKubernetesのCustom Resource Definitionをインタフェースとして、開発者がそこに必要な項目を入力すると先に述べたようなアプリケーションの開発サイクルに必要なものが すべて 自動で生成されます。 生成されるものは以下のように多岐に及んでいます。(かろうじて秩序は保たれています) Kubernetes Manifest ConftestやDocker Imageへの動的解析など各種Lintを実行するGitHub Actions git-flowを実現するためのGitHub Actions ビルドパイプライン他各種AWSリソースを作成するCloudFormation Template ビルドされたDocker ImageやKubernetes ManifestをデプロイするためのSpinnakerのパイプライン PrometheusおよびAlertmanagerでのProduction Readyなアラート設定と通知先設定 GrafanaのProduction ReadyなDashboard 上記に関する説明やダッシュボードへのリンクなどのドキュメント まさに コマンド1発でKubernetes上にProduction Readyな環境を手に入れる コードジェネレータです。 ビルドパイプラインもついているので正真正銘コマンド1発叩いた瞬間からGitHubにpushするといい感じにデプロイされるようになります。 (小さいアプリケーションの参考実装が入ったGitHubのTemplate Repositoryも一緒に提供していて、そこにはDockerfileも入れているため開発初期からこれらを手に入れることができます) ドキュメントの自動生成は結構気に入っています。 そのアプリケーションのリポジトリ内にドキュメントを生成することでよくありがちなオレオレドキュメント乱立の防止をしたり、諸々の設定とライフサイクルを共にしていることでドキュメントが古い状態で放置されるあるいは中央管理されているドキュメントから古い情報が消されて置いて行かれるといったことが防がれています。 辛いことや面倒なことをアプリケーション開発者のために肩代わりするようなソフトウェアであるためやってることは結構泥臭くて、Custom Resource Definitionに入力された設定値をもとに筋肉であらゆるファイルを動的に生成するといったようなことをしています。 Custom Resource Definitionを使っていますが、以下のような点を考慮しながらCustom Controllerとしてではなくコードジェネレータとして作りました。 捨てやすさ 先に述べた問題をCustom Resource Definitionで抽象化して解決するということはKubernetesの上にPaaSを構築することと等しいです。 PaaSの採用を決めるにあたって最も懸念となることが、捨てやすさです。 PaaSはその性質上、利用者から見たインタフェースの抽象度が高く内部の処理もブラックボックス化されているため、別のPaaSへの移行やPaaSをやめる際に多くのコストがかかってしまいます。 Custom Controllerはいい仕組みですが、今回のような乱暴なユースケースではいざ我に返ってこのアプローチをやめようとした時に捨てづらく、やめる際にもコストを支払うことになってしまいます。 一方、コードジェネレータであれば成果物として生成されたファイルをそのまま使い続けられるように設計することが可能です。 そこでCustom Controllerを作るときの要領でCustom Resource Definition周辺のエコシステムを活用しながらも、Kustomizeでそのまま使えるKubernetes Manifestを生成したりするなどして捨てやすさを念頭に置いて開発されています。 Custom Resource Definition周辺のエコシステムは非常に強力で、Validation, Versioningやドキュメントの自動生成、エディタの補完などの恩恵を受けることができるためCuston Controllerでなくともインタフェースとして利用する価値がありました。 抽象度 PaaSをデザインするにあたっては、抽象度をどのようにコントロールするかも考えなければなりません。 先に捨てやすさを意識しているのでロックインはされませんが、抽象度はユーザ体験と拡張性に影響します。 実際に我々はここで一度失敗をしています。 keelctl 以前に開発していたKustomizeのWrapperのように振る舞うManifest Templatingソフトウェアでは、極力アプリケーション開発者がKubernetesのことを知らなくてもいいようにKubernetesの概念を完全に隠蔽する強い抽象化をしていました。 しかし、次第にアプリケーション開発者の要求が複雑化してManifest Templatingソフトウェアが追い付かなくなったり、Kubernetesに詳しいアプリケーション開発者が細かくコントロールしたいと結局実装を読むみたいなことが起きるようになってしまいます。 その失敗を経て、 keelctl で利用するCustom Resource DefinitionではKubernetes Manifestの部分で抽象化を行わないようにしました。 こんな感じです。 apiVersion : keel.lifull.com/v1alpha1 kind : KEELConfiguration metadata : name : &name keelctl-sample spec : ... applications : - base : metadata : name : *name spec : feature : redis : enabled : true replicas : 5 deployment : spec : strategy : type : RollingUpdate rollingUpdate : maxSurge : 25% maxUnavailable : 1 template : metadata : annotations : sidecar.istio.io/inject : "true" spec : containers : - name : &main-container server env : - name : TZ value : Asia/Tokyo ... overlays : - name : *test override : metadata : namespace : *test-namespace spec : deployment : spec : template : metadata : annotations : sidecar.istio.io/proxyCPULimit : 100m sidecar.istio.io/proxyMemoryLimit : 256Mi sidecar.istio.io/proxyCPU : 100m sidecar.istio.io/proxyMemory : 256Mi spec : containers : - name : *main-container image : *test-repository このようにDeploymentといったKubernetes Objectをそのまま露出させています。 これには、エディタの補完でupstreamのものをそのまま利用できたり、Kubernetes Manifestを生成する時の実装が楽、Kubernetesに詳しい人がそのまま弄れる、拡張性が高いみたいなメリットがあります。 実際にDeploymentと同列にIstioのVirtual ServiceやDestination Ruleなども設定できるようになっており、実装コストとyamlの秩序が許す範囲であればいくらでも拡張することができます。 (それぞれの apiVersion はCustom Resource Definitionで管理していて、それぞれに非互換の変更が発生した際はCustom Resource Definitionの apiVersion を変えて対応しています) その上でアプリケーション開発者の関心事を減らすべく、 topologySpreadConstraints や Pod Disruption Budget , Recommended Labels のような露出すべきでない情報を生成時の実装に閉じ込めていて、裏でいい感じにそれらをデフォルト値として生成してくれるようにしてKubernetes特有のベストプラクティスを知る必要がない状態にしました。 こうしてベストプラクティスを知る必要がない状態になってしまえばKubernetesに詳しくない人のための抽象化は不要で、必要な項目があらかじめ埋まっているテンプレートを用意したうえで各項目に丁寧なコメントを付与するだけで十分やっていけています。 難しいのはKubernetes ManifestではなくKubernetes特有のベストプラクティスなのでそれさえ裏に隠してしまえばこの程度で十分でした。 Kubernetes Manifestの公式ドキュメントはよくできているため、無用な抽象化はドキュメントの焼き直しにしかなりません。 Kubernetes Objectで表現できないような機能については雑に feature というキーを用意していて、ここでキャッシュ用のRedis/memcachedクラスタやLighthouseを実行してPrometheus用のMetricsを出すPrometheus Exporterとかを利用できるようになっています。 またKustomizeに倣って base と overlays というキーを用意していて、ここで共通部分の定義と環境ごとの出し分けを実装しました。 ここでも Strategic Merge Patch というupstreamの機能をそのまま利用することで実装をサボっています。 抽象度をうまくコントロールすることで、upstreamの成果を利用しながら利用者の知識レベルに依存しない使いやすいインタフェースを実現することに成功しました。 変更への追従しやすさ 同じことをCustom Controllerで実現すると更新の配布のしやすさはCustom Controller側に軍配が上がります。 Custom Controller側を弄るだけで利用者に等しく更新を配布することができるためです。 逆に更新の配布を考えなければGitHubのTemplate Repositoryで配るだけでも十分かもしれません。 そこで、コードジェネレータでも似たような更新の配布しやすさを実現すべくセルフアップデートの機能を実装しました。 セルフアップデートの機能があれば、コマンドを叩くだけでバイナリを最新の状態に保つことができます。 また、生成される成果物のテンプレートはgolang 1.16から入った embed を利用して全てバイナリに含めています。 (バイナリはそれなりに大きくなりますが2021年に問題があるレベルではありません) こうすることでテンプレートもバージョン管理されるため、利用者は以下のようなコマンドを定期的に実行することで手元の設定ファイルを最新に保つことが可能となりました。 $ keelctl self-update $ keelctl gen keel_configuration.yaml . こうして更新の配布を簡単にすることで、各設定を最新に保つだけでなくセキュリティ面での統制を効かせることにも成功しています。 更に .keelctl_version のようなファイルも生成することで、それぞれのリポジトリが利用している keelctl のバージョンを外からトラッキングできるようにもして統制を強化しました。 全社基盤をやっていて陥りやすいものとして、作った機能が使われない、責任分界点が曖昧になり更新作業などが行われない、といったものがあると思います。 keelctl ではCustom Resource Definitionを責任分界点としつつ、更新を半ば強制的に配布する仕組みを整えたことでそうした問題への対処に成功しました。 また、 .keelctlignore というファイルに .gitignore と同じ書式でパターンを記述すると任意のファイルをオプトアウトする機能を実装しています。 これを利用することで例えば今はKubernetes Manifestの生成はせずに、ConftestやDocker Imageへの動的解析など各種Lintを行うGitHub Actionsだけを生成したいといった要求を叶えることができます。 これにより既存のリポジトリに段階的に導入することが可能となり、利用先は今ではLIFULLの大部分にまで広がりました。 自分の書いたコードをすぐに全社に配布できることからチーム外からのContributionも多く来るようになり、 keelctl は日々目まぐるしく進化しています。 Open Application ModelとKubeVela 実は似たような試みとしてMicrosoftが主導する Open Application Model というプロジェクトとその実装である KubeVela があります。 oam.dev kubevela.io Open Application Modelはクラウドネイティブなアプリケーションを定義するための仕様で、KubeVelaはそれをKubernetes上で実行するための実装です。 apiVersion : core.oam.dev/v1beta1 kind : Application metadata : name : first-vela-app spec : components : - name : express-server type : webservice properties : image : crccheck/hello-world port : 8000 traits : - type : ingress properties : domain : testsvc.example.com http : "/" : 8000 このようなKubernetes Manifestを適用するとKubeVelaがCustom Controllerとして いい感じ にKubernetesに展開してくれます。 KubeVelaは Traits という概念で機能をコントロールすることができ、デフォルトで KEDA や Flagger などが組み込まれています。 例えば上記の type: ingress のようなものがそうで、このような設定を記述するとFlaggerによるCanary Deploymentなどを手に入れることができるといった感じです。 つまり、KubeVelaはOpen Application ModelをインタフェースとしてKubernetes上にPaaSを構築できる、 コマンド1発でKubernetes上にProduction Readyな環境を手に入れる ソフトウェアです。 Traitsは このようにPlatform Builderによって拡張可能 で、 keelctl の feature のようにキャッシュ用のRedis/memcachedクラスタを展開するためのTraitsを提供するみたいなことが可能となります。 type: webservice に相当するWorkload Typeも同様に拡張可能であるため、抽象度が高いことによって痒い所に手が届かないみたいな問題は少なくともWorkload Typeを拡張すれば解決できるでしょう。 keelctl の構想当初にOpen Application Modelは無かったのでLIFULLではこのようなアプローチになりましたが、Kubernetes上でPaaSっぽいことをやりたいのであればKubeVelaは有力な選択肢であると思います。 (今や keelctl はKubernetes Manifest以外にも手を出していたり、LIFULLが構築してきたKubernetesエコシステムを手放すという判断には中々なれないので直近での移行は検討していませんが...) 強いて言えば、KubeVelaがCustom Controllerであることの捨てづらさは理解して慎重に判断した方が良いということくらいでしょうか。 アプリケーション開発者の辛いことや面倒なことを肩代わりするために我々のようなPlatform Builderの努力を要するという点は keelctl でもKubeVelaでも同じでそれはPaaS提供者の宿命です。 keelctl を開発してきてみて ということで コマンド1発でKubernetes上にProduction Readyな環境を手に入れる コードジェネレータを開発した話でした。 やっていることは泥臭いですがもたらした恩恵は非常に大きかったです。 今まで楽観的に見積もっても2週間くらいかかっていたアプリケーションのローンチまでに必要な実行環境周りの作業、デプロイフローの構築やサーバの設定に監視周りの整備といったことが コマンド1発 で終わるようになりました。 他にも多くのアプリケーション開発者を支援する機能がチーム外からのContributionも受けながら提供されています。 そして、日々の改善はセルフアップデート機能によって多くいる keelctl 利用者に配布されて各種設定は最新に保たれ、こちらから利用状況がトラッキングできることで統制面でも役立っています。 コードジェネレータによってあらゆるものを自動生成するというアプローチは一見乱暴ですが、投資した時間に対して大きな成果が出ているし、捨てやすく作っているからと楽観視しています。 Kubernetesはその拡張性からこういったPaaSのような取り組みをしやすく、アプリケーション開発者の生産性向上やアプリケーション品質の向上に大きな影響力を発揮することができました。 そこからもう少し踏み込んでこういったコードジェネレータを開発することで更に影響範囲を広げることができ、我々 KEELチーム は単なるKubernetesチームではなくなり、より広く生産性や品質に責任を持つチームへと変化しつつあります。 広く生産性や品質に影響力を発揮したいKubernetesな各位はコードジェネレータの開発を検討してみてはいかがでしょうか。