はじめに レバレジーズ株式会社 エンジニアの高橋です！ 本日から、社内で毎週金曜日に行なっている勉強会、通称「てっくらんち」を皆さんにお伝えします！！ 「てっくらんち」ってどんな勉強会？ お昼にやっているゆる〜い勉強会です。 毎週金曜日に開催しており、社内エンジニアの発表をお昼ごはんを食べながら聞くスタイルの勉強会です。 発表者は毎回一人で、発表時間は15分〜30分程度、質疑応答も含めると30~45分ほどの内容になっています。 ジャンルは様々で、エンジニアの生存戦略的な内容から、Dockerの踏み込んだ話まで、技術に関する内容であれば何でもOKな形をとっています。 発表者も様々で、あらゆる部署のエンジニアや、フリーランスでJoinされている方、支店や外勤のエンジニアなど、社内の多くのエンジニアが参加しています。 本日のてっくらんち 発表日：2020/06/19 発表者：住村 翼 題目：クリーンアーキテクチャ入門 てっくらんち ~ クリーンアーキテクチャ入門 ~ 感想 今回は、住村さんから弊社でシステム化をしているお米予約システム＆お米を炊く例にして、クリーンアーキテクチャの概要から、実際に実装をするときどうするかをお話していただきました。 特にDIに関して、メリット、デメリットを踏まえて教えていただいたので、実装するときに今後の実装に活かしていこうと思います。 We Are Hiring レバレジーズ では「てっくらんち」のような社内での勉強会や「レバテックラボ」という外部の講師を招いたパブリックな勉強会も開催しております。 また、横浜に開発拠点ができるなど、新たな働き方も創出しています。 弊社に少しでも興味を持っていただいた方はご連絡いただけると幸いです。 https://recruit.jobcan.jp/leverages/list?category_id=5142 recruit.jobcan.jp

こんにちは、msatoです。 AWS re:Invent2019のワークショップ「ENT206 Optimize AWS costs and utilization with AWS management tools」のレポートになります。 概要 この実践セッションでは、AWSのツールとサービスを使用して、ビジネス全体のコスト最適化を推進する方法を学びます。 AWS IAMポリシー、AWS予算、AWSコストエクスプローラーなど、コスト管理のコアツールを検討します。これらのツールを習得した後、Amazon Athenaを使用した高度な課金分析と、Amazon QuickSightを使用した視覚化について詳しく説明します。 原文 In this hands-on session, you learn how to use AWS tools and services to drive cost optimization throughout your business. We look at the core tools of cost management, such as AWS IAM policies, AWS Budgets, and AWS Cost Explorer. After mastering these tools, we go deeper into advanced billing analysis with Amazon Athena and visualizations using Amazon QuickSight. スピーカー Nathan Besh Cost Lead, Well-Architected , Amazon Web Services Arthur Basbaum AWS Cloud Economics , Amazon Web Services レポート Governance AWS BudgetsとIAM Policiesでコストの統制を行います。 AWS Budgets 使用量と支出を通知することができる(予算を超えたらアラートを飛ばす) 予算の使用状況をレポートにして、配信することが可能 IAMポリシー ユーザが起動できるインスタンスのタイプを指定することができる(t3.larage以下を起動できるようにするなどができる) Visualization and Analysis Cost ExplorerやGlue、Athena、QuickSightを使ってコストを可視化します。 Cost Explorer 無料で使えるコスト分析ツール コストと使用状況を分析し傾向やコスト要因を把握することができる Glue マネージド型 ETL (抽出、変換、ロード) サービス Athena Amazon S3 内のデータをSQLを使用して分析できるサービス GlueとAthenaを活用したコスト可視化 コストのレポートをS3に保存する(請求ダッシュボードから可能) Glueを使ってデータを分析しやすい形に整えます Athenaで分析する クエリの例) Top10 アカウントIDごとのコスト select "line_item_usage_account_id", round(sum("line_item_unblended_cost"),2) as cost from "workshopcur"."workshop_c_u_r" where month(bill_billing_period_start_date) = 12 and year(bill_billing_period_start_date) = 2018 group by "line_item_usage_account_id" order by cost desc limit 10; Top10 EC2 Costs select "line_item_product_code", "line_item_line_item_description", round(sum("line_item_unblended_cost"),2) as cost from "workshopcur"."workshop_c_u_r" where "line_item_product_code" like '%AmazonEC2%' and month(bill_billing_period_start_date) = 12 and year(bill_billing_period_start_date) = 2018 group by "line_item_product_code", "line_item_line_item_description" order by cost desc limit 10; Right Sizing インスタンスのサイズを適切にして、コストをカットします。 インスタンスのサイズを一つ落とすと、料金は半分になる Cloudwatch インスタンスで使用しているリソースの状況を確認する Cost Explorer EC2 Optimaization cloudwatchで取得しているメトリクスからインスタンスサイズをレコメンドする cloudwatch agentからのメトリクスもレコメンドに使える Pricing Models Savings Planを使って、コストの割引を受けます Savings Plans 1年間または3年間、一定の利用料をコミットするだけで、その利用料に対して割引がてきようされる Cost Explorer > Savings Plansから見積もりを確認することができる RI report Cost Explorer > Savings PlansからRIのレコメンドを確認できる Well-Architected Tool AWSのベストプラクティスにそったアーキテクチャにすることで、コストを最適化します。 Well-Architected Tool サービス > Well-Architected Toolから使用できる 運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化の5つの柱からなる質問に答えることで、現状とベストプラクティスを比較できる まとめ 弊社でもリザーブドインスタンスを購入するなど、コストカットの取り組みは行ってきました。 このセッションを聞いてまだまだできることはありそうだと感じました。 コストについて知って、お得にAWSを使いましょう。

こんにちは、msatoです。 AWS re:Invent2019のワークショップ「DOP202-R2 - [REPEAT 2] Implementing GitFLow with AWS tools」レポートになります。 概要 短命の機能ブランチを利用することは、多くのチームにとって最適な開発方法です。このワークショップでは、AWSツールを使用してマージとリリースのタスクを自動化する方法を学びます。 AWS CodePipeline、AWS CodeCommit、AWS CodeBuild、AWS CodeDeployを使用してGitFlowを実装する方法の高レベルフレームワークについて説明します。また、事前に構築された例を見て、個々のユースケースにフレームワークをどのように採用できるかを調べる機会もあります。 原文 Utilizing short-lived feature branches is the development method of choice for many teams. In this workshop, you learn how to use AWS tools to automate merge-and-release tasks. We cover high-level frameworks for how to implement GitFlow using AWS CodePipeline, AWS CodeCommit, AWS CodeBuild, and AWS CodeDeploy. You also get an opportunity to walk through a prebuilt example and examine how the framework can be adopted for individual use cases. スピーカー Ashish Gore　Sr. Technical Account Manager , Amazon Web Services Amit Jha　Sr. Solutions Architect , Amazon Web Services GitFlowとは git-flowは、正確にいうと Vincent Driessen 氏が提唱する「A successful Git branching model」というブランチモデルをサポートするツール（コマンド）の名称です。 一般的には、モデルとツールのどちらの名称としても使われています。git-flowでは、役割が決められた5種類（場合によっては6種類）のブランチを切り替えながら開発を進めていきます。 ブランチの作成やマージに決まりを設けることで、複数人での開発時にもブランチをわかりやすい状態に保つことができ、不用意なマージによる問題を避けることが可能です。 [参考 Git-flow ～Gitのブランチモデルを知る～] ( https://tracpath.com/bootcamp/learning_git_git_flow.html ) 資料 AWS TOOLS GITFLOW WORKSHOP レポート Codeシリーズを始めとしたAWSサービスを使って、Gitflowを実現するワークショップです。 使用するAWSサービスの概要 今回のワークショップで、使用するAWSサービスの概要です。 CodeCommit: Gitリポジトリをホストするサービス CodePipeline: 継続的デリバリーサービス CodeBuild: ビルドサービス(ソースコードのコンパイル、テスト) CodeDeploy: デプロイを自動化するサービス Lambda: サーバレスでコードを実行できるサービス Cloudformation: AWSリソースのプロビジョニングサービス Elasticbeanstalk: ユーザがインフラを管理しなくても、アプリケーションをホスティングできるサービス ブランチが作成された際の流れ ブランチが作成された際に、自動で環境が立ち上がりコードがデプロイされます。 流れは以下です。削除時も同様です。 ユーザがCodeCommitリポジトリにブランチを作成する Codecommitトリガーで、ブランチが作成されたのを検知してLambdaを呼び出す LambdaではCloudformationを実行する Cloudformationでは、CodePipelineとElasticBeanstalkが作成される。 まとめ ブランチを作るだけで、環境が立ち上がりデプロイされるのはとても楽ですね。 個人的には、CodeCommitのトリガーが便利だと思いました。 AWSのサービスなので、Lambdaとの連携が簡単です。 (githubでもwebhook使えばできます) Gitのブランチモデルに合わせて、最適なデプロイの流れを作っていきたいです。

こんにちは、msatoです。 12月1日よりはじまったAWS re:Invent 2019に、当社からは私を含むエンジニア2人が参加しました。 re:Inventでの学習効果を最大限に高めるために、快適に過ごすためのTipsを紹介します。 移動編 reinventは複数の会場があり、会場によってはバスで数十分かかります。 地図上はさほど離れていない用に見えますが、端から端までで 約4km あります。 (MGM GrandからEncoreまで、徒歩で約50分) 会場内もとにかく広いです。 移動で消耗しないためのTipsを紹介します。 歩きやすい靴は必須 re:Inventでは、とにかく歩くことになります。 日によっては、歩数が 20000歩 を超えたこともありました。 (日本人の１日あたり平均歩数は、約8000歩) 靴ずれや移動で疲れないために、歩きやすい靴必須です。 帰国日が一番多かったですが、reInvent期間中は平均15,000歩くらいになっています。 セッションはできるだけ同じ会場にまとめる できるだけ移動を少なくできるように、予定を組むことをおすすめします。 会場間の移動で、30分以上かかることもあるので時間を無駄にしてしまいます。 有意義に過ごすために、日によって会場をまとめる・overfloowルームを活用するなどしたほうがいいです。 こまめな給水を心がけよう 周りが砂漠のため乾燥しています。 疲労をためないために、こまめな水分補給をおすすめします。 給水スペースは会場の至るところにあるので、活用しましょう。 宿泊編 ホテルは「ザ・ベネチアン/パラッツオ」おすすめ 「ザ・ベネチアン/パラッツオ」 がおすすめです。 理由は、メイン会場だからです。 メイン会場では、Keynoteや前夜祭(MidnightMadness)が行われます。 単純に行く回数が多いと思われるので、宿泊先にしてしまえば移動時間を短縮できます。 (私自身も、期間中毎日1回は「ザ・ベネチアン/パラッツオ」行きました) 水の確保が大切 ホテルの部屋にも水のペットボトルがありますが、高いです。 また自販機もないため、水の確保が面倒です。 近くのドラックストアでまとめて買うのがおすすめです。 「WealthMart」「CVS」などで買うことができます。 1ガロン(約4リットル)の容器で買うとコスパがいいです。 初日に1人 1~2本買っておけば手間が少ないです。 同じことを考える人は多いみたいで、初日は売り切れてました。 できるだけ早めの時間に買いに行くことをおすすめします。 写真撮り忘れましたが、こんな感じです。 ポータブル加湿器を持っていこう ラスベガスはとにかく乾燥してます。 私は１日目、就寝時に口の中が乾きすぎて起きました。 日中のパフォーマンスを低下させたいために、睡眠の質は確保したいところです。 タオルを濡らして加湿するのもいいのですが、最近は持ち運びに便利な小型の加湿器があります。 値段もリーズナブル(1000~2000円)なので、日本で買っておくことをおすすめします。 セッション編 予約できなかったセッションでも、当日並べば受けれる事が多い セッションは事前に予約することができます。 しかし、人気のセッションを予約するのはなかなか難しいです。 「どうしても受けたいけど、予約を取れなかった」場合は、 当日並んでみましょう。 当日席が用意されているため、並んでみると受けれることが多いです。 開始の30分~1時間前に行けば高確率で受けれます。 人気のセッションは、1時間半前くらいに並ぶのをおすすめします。 ハードウェア系のワークショップ受けてみよう ハードウェア系(Deepracer、Deepcomposer、Alexa、IoT系)のワークショップおすすめです。 おすすめの理由は、2点あります。 普段触る機会がない人が多いと思うので、刺激になる ワークショップでハードウェアを貰えることがある 今回は、DeepcomposerやDeepracerがもらえたそうです。 (聞いた話では、昨年はAlexaとかももらえたとか。) 知識も増えて、帰国後も学習できるハードウェアが手に入り一石二鳥ですね。 AWS Deepcomposer セッションカタログはこまめに確認しよう reInventの期間中もセッションやワークショップは追加されます。 追加されたセッションは一瞬で埋まってしまうこともあります。 こまめに確認して、受けたいセッションを逃さないようにしましょう。 「 new launch 」とかでセッションカタログを検索すると見つけやすいです。 最後に 実際にreInventに行ってみて、知っていたら便利そうなことをまとめました。 快適に過ごして、reInventの学習効果を最大限にしましょう。

こんにちは、msatoです。 AWS re:Invent2019のワークショップ「ARC313 Architecting Global Storage with AWS Lambda and storage Gateway」のレポートになります。 概要 企業は、AWSテクノロジーのベストプラクティスを使用して、オンプレミスとクラウドの両方で世界中の生産施設に資産を同期する方法を探しています。このセッションでは、AWS Lambda、Amazon API Gateway、Amazon Simple Storage Service（Amazon S3）、AWS Storage Gateway、AWS Directory Service、およびAWS Fargateを使用して、世界中の従業員のコラボレーションを可能にするサーバーレスグローバルストレージプラットフォームを構築する方法を学びます。 Companies are searching for ways to synchronize their assets to their production facilities around the world, both on-premises and in the cloud, using best practices with AWS technologies. In this session learn how you can use AWS Lambda, Amazon API Gateway, Amazon Simple Storage Service (Amazon S3), AWS Storage Gateway, AWS Directory Service, and AWS Fargate to build a serverless global storage platform to enable employee collaboration around the world. スピーカー Paul Roberts Rob Hilton Principal Solutions Architect , Amazon Web Services レポート 構成図 動画ファイルを格納できるグローバルストレージの構築です。 具体的にはアテナに動画編集者がいて、トロントから確認したいというケースでした。 (アテナは読み書きが可能で、トロントでは読み込み) AWSのマネージドサービスを使用して、サーバレスで作ります。 使用するサービス S3 動画ファイルを置きます masterとstudio(読み込み専用)というバケットを作ります(masterがアテナで、studioがトロント) StorageGateway クライアントからSMBでS3をマウントさせるためです AWS Fargete 　- フロント部分に使います AWS API Gateway リクエストを受けて、lambdaを起動します AWS Lambda masterにアップロードされた際に、studioのバケットにコピーします まとめ オンプレで作ったらかなり手間がかかりますが、AWSのサービスを使うことで簡単に作れました。 また、サーバレスのためコストや運用の手間もほとんどありません。 StorageGateway使ったことがなかったので、ワークショップで実際手を動かしながら作れたのはいい経験になりました。 グローバルストレージを構築する機会はなかなか無いと思いますが、このアーキテクチャは色々応用が効く気がします。

こんにちは、msatoです。 reInventで学んだことのアウトプットのために、JAWS-UG 初心者支部でLTしてきました。 JAWS-UG 初心者支部とは 以下 引用 です。 AWSをこれから活用したい人や一緒に勉強する仲間が欲しい人を主なターゲットとしています。 AWSへの理解を深めていただくお手伝いをすることはもちろんのこと、みなさまがより楽しく学び、よりステップアップしていくためには不可欠となる、初心者支部の卒業→JAWSの他支部へと巣立つためのお手伝いをします。 イベント概要 12/6-12/6にラスベガスで開催されたre:InventのreCap(振り返り)と、LT大会が行われました。 JAWS-UG 初心者支部#21 reInventReCap＆LT大会 登壇してきました「IAM Access Analyzer使ってみた」 reInvent期間中に発表されたサービス「IAM Access Analyzer」について話してきました。 資料は公開していますので、ご興味のある方は是非ご覧になってください。 伝えたかったことは以下です。 ポリシーの設定ミスによる意図しないアクセスを防ぐとことができるサービス 無料で簡単に有効化できる 「AWSアカウント作成時のやることリスト」に入れたほうがいいと思うほど、有用なサービス 最後に 「アウトプットしないことは知的な便秘」LTで度々出てきて印象的でした。 いい言葉ですね。アウトプットしなきゃという気持ちになります。 JAWS-UGではアウトプットの機会を提供してくれています。 特に初心者支部はLT初心者でも、発表しやすい雰囲気があります。 今回のようなLT大会もたまにやっているので、初めてのLTにおすすめです。

Leverages Advent Calendar 2019 - Qiita 最終日を担当します。ITインフラの研究職からSREを経て、現職ではいつの間にかVPoEのようなことをやっています 久松 です。キャリアを拗らせて唸っているうちにこういうキャリアになった、と説明しています。 今回はHRE（Human Resource Engineering）と題しましてエンジニア組織のカタチとマネージメントについてお話させていただきます。昨今のエンジニア組織マネージメントの難しさに悩む方々は多いかと思います。組織図や開発関係者一覧、タスク量計算をしていて「何だこれは」と思っている方々も多いのではないでしょうか。私自身、VPoE的な業務に取り組むにつれ、ふとインフラエンジニアだったあの頃と似通った着想に至りました。組織図をCDPっぽく描くというのが今回の主テーマです。何故EMやVPoEといったソフトなスキルを持ったポジションが求められるのか、エンジニア組織運営の難しさを理解する一助になれば幸いです。 従来型の会社組織 データセンター（会社）の中で全てが収まっています。室温から空調まできちんと整えられています。オンプレミス環境のオペレーションに関わったことのある方は思い当たると思いますが、物理サーバのホスト名に拘ったりして可愛がりますね。落ちると悲しいし、涙します。 増設（採用）は好ましいことですが、ラック（会社の物理空間）に限界もあります。計画はしっかりとデータセンター管理会社（バックオフィス）と連携しておく必要があります。 サーバやプロセスの監視も必要です。異常発生時はその現場に駆けつけましょう。ハードウェア（フィジカル）・ソフトウェア（メンタル）・ネットワーク（人間関係）など様々な課題が有りえますので、それらを吸い上げる仕組みや関係性づくり（1on1等）が必要です。 従来型組織 遠隔開発拠点 都内でのエンジニア採用が難しいと感じた場合、遠隔地で採用をかけるケースも多く見られます。海外でオフショアだったり、国内でニアショア、もしくは地方支店の一角を開発拠点にするケースもあります。その場合、意識すべきは意思疎通です。遠隔地に居る分、伝送遅延はありますので何往復も意思疎通するとその分ロスが発生します。何の機能を本社に残し、何を機能を外に出すのかが重要になります。社内組織として設ける場合は「外注感」「下請け感」が出ないようにしなければならず、機能ごと任せてしまうというのは一つの解法だと考えています。 遠隔開発拠点 SES 正社員でまかなえない業務が発生した場合、SESが登場します。フリーランスだったり所属会社の正社員だったりします。契約単位は時間のケースが多いですね。さながらパブリッククラウド的な形。同じドメイン（社内）で稼働をお願いするためにDirect Connect利用のケースもあるでしょう。ALB（タスク分配）やCloudWatch（勤怠管理）も必要です。 SES 請負、コンサル 機能を部分的に他社に依頼するケースもあります。アプリケーション開発を受託開発に出すケースもあれば、チューニングといったスポット依頼のケース、AI開発や分析のような専門性の高いケースもあります。 AWSで言うところのManaged Service利用のようなセットアップと運用を丸々委託するパターンもあれば、Facebook APIやTwitter APIなどをインターネット経由利用するように基盤に乗っかるパターンもあります。 重要なこととして障害・仕様変更・サービス終了などにより依頼先が（一時的にでも恒久的にでも）応答しなくなった場合、極力本番環境に影響しない形での実装と運用が必要です。私も前職ではFacebookベースのサービスのインフラを担当していましたが、先方都合の部分はいかんともし難いものでした。「他人の褌で相撲を取っている」という感覚を忘れてしまうと大事になりがちです。 請負、コンサルとの契約 社内副業 俄に流行の兆しですね。新卒採用イベントにて他社さんの会社説明などを聞いていると「実は取り組んでいます」という会社さんがちらほら居られます。これはつまり外注という選択を取る前に社内の余剰リソースでタスクを消化させようという動きです。余剰リソースを有効活用という意味合いでは仮想化のようなものですね。 加えて 弊社調査でも言及 させて頂きましたが、若手エンジニアには限られた時間でできるだけ複数の経験を積みたい（複業）というタイムパフォーマンス志向が見られます。 余剰リソースの有効利用や、複業に応える解答としては肯定できる社内複業制度ですが、労務や制度的な難易度が高いです。実務的な観点で問題となるのは「タスクの切り分けとマネージメント」が挙げられます。 社内副業制度 クラウドソーシング タスクを細切れにして外部に依頼します。特にインフラを構築せずともリクエストを投げるとリザルトが返ってくる様はさながらLambdaです。ただしプロセスの信頼性は低く、タイムアウトする可能性もありますのでプロセス管理が重要となります。 クラウドソーシング （エンジニア）組織のミライノカタチ 経営層の視点で「働き方改革は誰のためにあるのか？」と問われると「メンバー層」を対象にしたものではないかと答えています。特に能動的な行動を好むメンバー層への働き方改革の影響は大きく、所謂自社メディアと呼ばれる企業、それも他社との比較がしやすいITベンチャー密集区ではその直撃を免れていないように思います。 あるスタートアップ事業さんでは正社員は数名のみが在籍し、タスク分解を徹底し、残りは全てフリーランスで事業展開をされています。出勤日は固定ではなく、カレンダーに稼働時間を登録して貰った上で消化していくというスタイルを取られていたりもします。稼働可能な時間（スキマ時間）に稼働するスタイルはスポットインスタンスと言えます。 経営目線で考えると会社とは何か（少なくとも社員数は重要ではなくなる）、正社員には何を期待し何を残すのかを考えなければならない時代に来ています。オンプレミスとパブリッククラウドのハイブリッド構成だとデータベースをオンプレミスに残すケースが多いですが、会社組織であれば事業イメージをカタチにする企画職や、開発管理をするPM業務が該当するかと思われます。こうした人達をどこから連れてくるのか、育てるかというのも課題となってきます。事業コンセプトだけが会社に残るケースもあるのではないでしょうか。 一方、メンバー視点で考えると働き方改革を前に「ええじゃないか」と踊るのではなく、前回記事の 指名される理由 が必要になってきます。自分の自己責任が叫ばれる時代の中、どの立ち位置で、時間・成果のいずれの報酬体系で、どう渡り歩いていくのかを意識しなければなりません。また、弊社レバテック事業においてもこうした流動性の高い不確実な時代の流れを捉えつつ、日本一の相談相手として歩まなければならないと考えています。 タスク細分化による組織のミライノカタチ 最後に 働き方の多様化が進み、自社のみでの開発組織の完結が難しくなってきた現在、人的マネージメントは困難を極めています。だからこそEMやVPoEといったソフト面の職種が登場したのだと考えています。 こうしたデザインパターンに載せて考察していくとHRとSREで共通点が見つかったり、マネージメント上の課題が発見できたりするというのが今回提唱したHREです。インフラエンジニアの基本であるトポロジ図やCDPに倣って、自社の組織図を書いてみるのも一興ではないでしょうか。 今回は書くと棘のあることはあえて伏せているのでいつの日かあるかも知れない書籍化に取っておきます（DRとかオートスケーリングとかマルチクラウドとかクラウド移行とかリプレイスとか）。 qiita.com

はじめに はじめまして！ Leverages（レバレジーズ）Advent Calendar 2019 18日目担当の吉澤です。 普段は、看護師向けの転職サイトや社内システムの開発・運用などをしています。 今回は、LINEでの顧客対応に用いられるチャットシステムの構築についてと実際運用してみてどうなの？みたいなところを書いていこうと思います。 何作ってるの？ ↓ざっくりこんな感じのやつを作っています。 開発に至った背景については以下の記事に書かれています。 markezine.jp LINEのMessaging APIとFirestoreを用いて、社内のSFA/CRMシステムから顧客とLINEのやり取りができるような機能です。 以下、内製のSFA/CRMシステムを社内システムと略します。 構成 全体的な構成としては以下の様になっています。 サーバーサイド まず、ユーザーがメッセージを送るとLINEサーバーからWebhookを受け取ります。受信時のメッセージの取りこぼしがあると、そもそものコミュニケーションツールとしての役割を満たせなくなってしまうため、ここは特に気を使わなければならない部分でした。 そのため、Webhookを受け取ったらペイロードをそのまますぐにキューに追加し、仮に後続の処理に問題があったとしても、ログから復旧できるような構成にしています。 サーバーサイドは慣れ親しんでいたという理由もありlaravelを利用しています。 キュードライバはAmazon SQSを使おうかとも思いましたが、当時SQSがFIFOに対応していなかったこともあり1回のみのメッセージを保証したかったのでRedisを利用しています。 後は順にキューから取り出し、Firestoreへの保存など受信時の処理を行っています。 クライアントサイド 次にメッセージを表示するクライアント画面ですが、ここはVue.jsとfirebaseのsdkを用いて、該当ユーザーのメッセージのcollectionをリッスンし、変更があればステートに追加していくといった割と一般的な処理になっています。 自力でWebSocket使って...みたいなことをしなくていいのでfirebaseほんと楽で便利ですね！ ただ当時、「Firebaseの読み取り超過で○百万円飛んでった 😇」みたいな記事が上がっていたのと、実際にリリース後どのくらいの読み取りが発生するかが予想しづらい状況であったため、ドキュメントの読み取り数には警戒していました。 そのため対策としてメッセージを20件ずつローディングするようにしたり、オフラインキャッシュを利用するなどして読み取り数を削減していました。今思うとFirestoreの無料枠も大きいのでそこまで警戒する必要もなかったかもと思っています。 通知機能 メッセージ受信時の通知に関しては、FirebaseCloudMessagingとServiceWorkerを使ってプッシュ通知をしています。 普段、通知許可を求められると不快に感じてしまうタイプではあるんですが、こういう利用用途が限られていてユーザーに使ってもらうことが前提の場合はサクッと実装できて便利だなと思いました。 社内システムにおいては、サポートブラウザが限定できる点や実装効率の面でもPWA周りの技術のメリットを享受しやすいのではないかと思いました。 ーーー 全体的には、このような構成で何とか一年近く運用できています。 加えてメッセージのやり取り以外の面でも、LINEログインを用いたオウンドサイトからの登録や定期的なメッセージ配信など集客面での機能追加なども行っています。 最近、LINE側でも頻繁に機能追加されているので、いろいろできそうで面白いですね😉 運用してみて このプロジェクトにおいては、技術面以外でも多くの学びがありました。 まず、これまで顧客とのLINEでの連絡は通常のLINEを利用していました。 これを内製のシステムに乗り換えるとなると提供されていない機能があったり、実装工数などの兼ね合いでどうしても今まで出来ていたことが出来なくなる機能が存在します。 狩野モデル *1 でいうところの当たり前品質が「本家のLINEで出来ていたこと」に該当していたように思います。 当然、利用者からすれば不便に感じる部分があったかと思います。 また、移行において仮にLINEで出来ていたことを実現できていたとしても、それだけではただ代替性が高いだけで、移行コストの方が高く感じてしまうのではないかと思います。(自分に置き換えてもそうなので、ｗ) そのような状況の中で、社内システムの開発・運用において以下のような点が重要だと感じました。 背景・目的への理解 何か新しいものを導入する際にはその背景や目的を明確にすることはもちろん、それが現場の人たちの中でも共有され、腑に落ちているかが重要だと思います。 よく職種間のやり取りにおいて、専門的な用語でなく相手が理解しやすい言葉でのコミュニケーションを心がけようと言われますが、たとえ言っている内容を理解できたとしても、それがどのくらい重要であるかという温度感は担当する役割によって違っていたりします。 全員が納得するのは中々難しいかもしれないですが、そういった認識のギャップを埋めていく動きも必要であると感じました。 ただ納得してもらうために、不用意に決定を曲げてしまうと本来の目的から逸れていってしまうこともあるので、その塩梅は中々難しいように感じます。 実際にはチームメンバーが現場への説明、疑問や不安の払拭、改善要望に対する対応目処の伝達など、とても献身的に働きかけてくれたこともあり、理解が得られていったように思います。 エンドユーザーの視点を持つ ここでいうエンドユーザーはサービスにおける最終的な顧客のことを指します。 社内システムの開発において、システム自体の利便性を高めるということはとても重要ですが、それが最終的にどうユーザーに還元されるのかという視点を持つことも必要だと思います。 例えば システムのレスポンス速度を改善することによって、現場の業務効率が上がり、ユーザーへの対応速度が上がる データを入力しやすくすることによって、今まで個人の中に埋もれていたような情報が蓄積されるようになり、ユーザーがより詳細な情報を得られるようになる などのようなことです。 普段、開発をしていると目の前のタスクの消化だけに目が行ってしまったり、自分は何のサービスを作っているのかが分からなくなってしまう時があるので、立ち返るという意味でも重要であるように感じます。 また、担当の職域が違うとその担当内での視点に寄ってしまいがちですが、同じ視点で議論することによって共通認識が取れやすくなるように思います。 同じサービスを提供する者同士として、目的は共通であるという前提の理解と、お互いがユーザーの視点に立ち、何ができるかを一緒に考えていくという姿勢が重要だと感じました！ We Are Hiring ! レバレジーズでは一緒に働く仲間を募集しています！ 創業14年目を迎え、より一層テクノロジーでの課題解決が求められるフェーズになってきたように思います。 技術での事業貢献、ユーザーファーストでのサービス作りなどなど、ご興味ある方、是非ご連絡お待ちしております！！ https://recruit.jobcan.jp/leverages/show/b01/7682 recruit.jobcan.jp *1 : 顧客満足度に影響を与える製品やサービスの品質要素を分類し、それぞれの特徴を記述したモデル | wikipedia:狩野モデル

はじめに レバレジーズメディカルケア株式会社CTOの内田です！ 横浜に開発拠点を作ってみたらイイ感じだったので書いてみました、興味ある方どうぞ！ 本題 福岡など地方にサテライトオフィスなど聞く事も増えました。 IT会社（だけではないですが割愛）は東京に集中していて、これは諸説ある所だと思っています。 なので本社は渋谷スクランブルスクエアですが今回、 横浜にも開発拠点を作ってみました 。 社長と拠点作成の話をしたあと「身体バキバキに鍛えたいッス！」と雑談してたら、 ここの本格的な筋トレ器具 も何機か横浜に送ってくれる事に、オフィスは ここ の3F、キレイだし横浜駅も徒歩圏で、鍛えれるし、素敵です。 ↓いきなりですがかわいい横浜拠点のメンバーたちｗ それでは、実際に 横浜を選んだ自身とメンバーたちによる比較を感じたままに紹介します。 比較 (体感比) 通勤 渋谷本社への電車はギュウギュウなのに対し、横浜支店は逆方向だから空いています。横浜近郊に住んでいる人以外にもメリットがあるようで、朝の集中力はチームとしても大事にしているので嬉しいです。 家 賃貸相場情報をHOME'sで見てみました。(2019/12時点) 渋谷駅 不動産・住宅情報サイトLIFULL HOME'S - 渋谷駅の家賃相場 1K 12.13万円 1LDK 28.08万円 2LDK 51.59万円 横浜駅 不動産・住宅情報サイトLIFULL HOME'S - 横浜駅の家賃相場 1K 8.61万円 1LDK 14.11万円 2LDK 21.69万円 駅付近の相場だと思いますが参考にはなりそうです、思ったよりもすごい差でした。（横浜駅から一本離れれば更に安いですがそこは一旦割愛） 入外出 (出勤やランチ) 渋谷 どこを歩いても人が沢山でお店も混みがち、エレベーターもなかなか来ない。色々と待ったり混雑が多めです。 横浜 意外にも平日は混まなくて、エレベーターもすぐ来る。色々と待たなかったり混雑が少なめです。 まとめ 総合した効果として皆がいうのを要約すると以下、 集中力が上がった 通勤コストの削減と、スモール化による周りの目の減少と考えています。 会社への好感度が上がった 働き方の多様化に応えて貰えたことや、この総合点の高い環境に感謝しているのかも。 これがQoLの重要性なのだと感じる日々です。 オマケ スカイスパのコワーキングスペースでの1on1 スカイスパに仕事上がりに徒歩数分で行けるのも最強ポイントですｗ ちなみに、 プロサウナー達の厳正な審査による"今行くべき全国のサウナ11選" で6位の施設がスカイスパです。 ぜひお試しあれ！

メディアシステム部 部長の 久松 です。 今回のテーマに関わってくるので自己紹介させて頂きますと 2000年からIT革命真っ只中のIT業界にインフラの研究開発から入り、20年が経とうとしています。 20代　大学教員を目指す インターネット動画配信、P2Pをテーマに研究員として活動 博士進学翌年にリーマンショック、その後 事業仕分け・震災 30歳　学術からビジネスへの転身 博士取得と共にポスドクのポジションが無期延期になり、就活も難航し、就職課に「進路未定」で提出 高学歴ワーキングプアとしてアルバイトプログラマに（額面で月給15万円） ベンチャー企業に就職後、やがてインフラ責任者をやりながら気がつけばリクルーターに 現職への転職 エンジニアの取りまとめの役割ですが、ほぼVPoE エンジニア紹介事業のレバテックでは技術顧問としてエージェントの専門性向上を担当 エンジニアキャリアに悩んだり採用したりするうちに新卒・中途採用、オンボーディング、新卒・博士キャリアをテーマにしたセミナーをするようになる 今回は私が現在、レバレジーズ社員やエージェント教育の過程でお話しているエンジニアの生存戦略とその機会提供についてご紹介させて頂きます。 エンジニアを勤め上げるにあたっての脅威 生き残りやすいエンジニアの特徴 ベースとなる基礎知識 専門性 2つを時流に合わせて変化 コミュニケーション力 リーダーシップ、マネージメント、プレゼンテーション、教育、採用より2つ以上 プレゼンテーション 教育 採用 まとめ エンジニアを勤め上げるにあたっての脅威 人生100年時代と言われている中、年金の支給タイミングの後ろ倒しを加味すると80歳程度までは 何かしらのキャリアチェンジ・ジョブチェンジを繰り返しながら行きていく必要があります。 特にITエンジニアとしては 技術トレンドの移り変わり AIによる自動化 Sketch2CodeだったりAmazon CodeGuru Reviewerだったり足音は聞こえますね 「巨人の肩の上」に乗ったできる若手 構築がスムーズな開発環境、溢れる教材、溢れるソースコード、 QA環境 ・・・ 海外からの高度人材 フリーランスやクラウドソーシングの一般化による有期のスポット人材の増加 を考えなければなりません。 生き残りやすいエンジニアの特徴 私自身が事業仕分けられたということで需要の底を経験したということもありますが、20年の間に ITバブル クラウドバブル SNSバブル ソーシャルゲームバブル AIバブル と各種のバブルと共に数多くのエンジニアの栄枯盛衰を見ることができ、生き残りやすいエンジニアの特徴が見えてきました（図）。 これを意識し、メディアシステム部のエンジニアには様々な機会に挑戦してもらっています。 エンジニア生存戦略 ベースとなる基礎知識 計算機の基礎、インターネットの基礎が挙げられます。特にインターネットの低レイヤについての知識はJavaScriptのフレームワークのようなハイレイヤーの技術に比べると革新速度はゆっくりですし、パケット交換方式は当面続きそうなので臆することなく身につけておくことをおすすめします。 専門性 2つを時流に合わせて変化 ヒトとは基本的に怠惰なものなので「可能であれば身につけた一つの技術で生涯食べていきたい」と思いがちです。 ただIT業界とは無情なもので5年程度でパラダイムシフトが発生し、身につけた技術は骨董品になります。 加えていかにも流行りそうな顔をして近づくバズワードというのもあります。 どちらか一方の専門分野が廃れても良いように2つの専門性、加えて時流に合わせて変化させることが必要です。 コミュニケーション力 他業種とのコミュニケーション力です。よくあるできるエンジニアの凋落パターンとして、 「いつも何をやっているのかよく分からないし、何を話しているか分からないし気難しそうなので話しかけにくいけど流行りの技術を身に着けているらしいので今は仲良くしておくと得だ」 と、周囲に思われているうちは需要があるものの、流行の終焉と共に周りから人が居なくなるというものです。 いざというときに周りに助けを求めるためにもコミュニケーションは取りましょう。転職してもフリーランスになっても繋がりは役に立ちます。 リーダーシップ、マネージメント、プレゼンテーション、教育、採用より2つ以上 いくつか補足をしておきます。 プレゼンテーション プレゼンテーションはブログの投稿でも構いません。その人が何をしているかを自分以外に積極的に知ってもらう術を持っているかということです。 短期的には予算の出どころに対する説得や説明に繋がります。中期的には「指名をもらう」ことに繋がりますし、怠ると控え目に表現して「忘れられてしまう」ということになるケースも多くあります。 　 教育 教育は自分の持っている技術や知識を後進に伝えられるかどうかです。特に知識の更新の早いIT業界では、知り得た事柄をまとめて周りに拡散していくという能力が強く求められるようになっています。 採用 採用はチームビルディングに繋がります。人材不足という中でどれだけ自分の属している組織に勧誘し、人を引き込むことができるかというスキルは年々高まっています。 まとめ 1990年前後の金融バブルを解説する専門家の間でも目にしますが「バブルの中に居る人はバブルだと思わない」と仰っしゃります。先に述べたIT界隈のバブルの中の人も、永遠の需要と反映を信じている人が多く居ましたが、今のエンジニア売り手市場もバブルですし弾けてから改めて認知されるでしょう。 良いのか悪いのか分かりませんが80歳まで労働しなければならないと仮定した場合、ジョブチェンジやキャリアチェンジを想定して生きなければなりません。 　 一つのヒントとして「これは自分の仕事じゃないな」という仕事が目の前に現れたとき、それを受け入れるか拒否するかというのが分かれ目になるのではないかなと考えています。 Engineering Manager vol.2 Advent Calendar 2019 qiita.com

ogp はじめに メリークリスマス！(早い) レバレジーズ株式会社エンジニアの村本です！ 12月も半ばに差し掛かり、ようやく冬らしい天気になってきました。皆様はどうお過ごしでしょうか。 我が家では電気カーペットを購入したのですが、あれは人をダメにしますね。最高です。 ということで、 Leverages Advent Calendar 2019 11日目の記事です。 今回は、有志のエンジニアで開催している勉強会「てっくらんち」についてご紹介したいと思います。 TL;DR ランチの時間に勉強会を始めました ゆる〜い雰囲気作りを目指しています 発表希望者が増加中...! Youtube Liveで配信する(かも)...!? 「てっくらんち」ってどんな勉強会？ お昼にやっているゆる〜い勉強会です。 毎週金曜日に開催しており、社内エンジニアの発表をお昼ごはんを食べながら聞くスタイルの勉強会です。 発表者は毎回一人で、発表時間は15分〜30分程度、質疑応答も含めると30~45分ほどの内容になっています。 ジャンルは様々で、エンジニアの生存戦略的な内容から、Dockerの踏み込んだ話まで、技術に関する内容であれば何でもOKな形をとっています。 発表者も様々で、あらゆる部署のエンジニアや、フリーランスでJoinされている方、支店や外勤のエンジニアなど、社内の多くのエンジニアが参加しています。 この勉強会の目的としては「お昼の時間を使い、自分が知ってる技術を自慢して、社内の技術力を底上げをしよう！」というものを掲げています。 元々社内の勉強会には、エンジニアミートアップという社内のエンジニア全員が集う会があり、そこに発表枠が設けられていたのですが、 発表ハードルが高く、開催頻度が低いこと から、発表者が少なく、社内でのアウトプットがあまり活発ではない印象でした。 そこで、 お昼の時間にローカルな場で勉強会を開催すること で、 発表ハードルを下げ、アウトプットの場を増やそう というのが「てっくらんち」の成り立ちです。 運営は有志のエンジニア数名で行われており、2019年7月頃から始めて累計16回開催されました。 ちなみに「てっくらんち」はひらがなで固定しているのですが、名前の由来も以下のように かなりゆる〜く ベンチャーらしい素早い意思決定がされています。 chat 「てっくらんち」のる〜る 「てっくらんち」では堅苦しくならない程度で、会の目的や存在意義がズレないように3つだけルールを定めています。 1. 発表者は次々回の発表者を指名できる権利を持つ 勉強会を重ねるにあたって発表者が固定化されることを防ぐために、発表者には次々回の発表者を指名できる権利を持たせています。 俗に言う「いつものメンバー」だけでやっている勉強会では参加しづらく、そういう勉強会はメンバーの意思が弱くなった時点で衰退していきます。このルールを定めることで、発表者の新陳代謝を促し、参加しやすく続きやすい勉強会になることを意図しています。 またこのルールでは、知り合いのエンジニアから指名されることになるため、普段アウトプットの少ないエンジニアも発表しやすくなるのではないかという狙いもあります。 実際に、自分から発表したいです！と手を挙げるより、知り合いから「お前のこの話聞きたいから話してよ〜」って言われる方が気持ちが楽ですよね。 とはいえ、いきなり「次はお前だ m9(^Д^)」とか言われて揉めても困るので、予め「指名するかも」ということを指名予定者に伝えることを推奨しています。 実際にこのルールを運用してみて、新卒エンジニアや、普段前に出て話すことの少ない人が発表者になっていたりするので、想像以上にうまく機能しているように思います。 あと、嬉しい誤算としては、当初は隔週開催予定だったのですが、発表者希望者が増えたことにより、毎週開催に切り替わりました 😆 2. 堅苦しくしない (お昼だもんw) これは会の雰囲気を定めつつ、発表のハードル下げるために設けているルールです。 折角お昼ごはんを食べながら発表を聞くので、殺伐とした空気にするのではなく、一エンジニアとして、技術を楽しめるような会にしたかったという思いがあります。 発表者としても殺伐とした空気より、和やかな雰囲気の方が話しやすいですよね。 とはいえ、外部の発表の練習として真剣なフィードバックが欲しいという方もいますので、発表者のリクエストがある場合には答えるように柔軟な対応をしています。 ただ、正直これはまだ完璧には機能できていないと思います。 やはり発表を聞くとなると発表者以外喋らないので、少々堅苦しい空気になってしまいます。 この空気を打破するために、発表スライドにコメントを流してみるなどアイディアでの解決を考えています。 最終的には発表中に良い野次が飛ぶくらいゆる〜い雰囲気になれば良いなと思っています。 3. チャレンジングな姿勢を忘れない 折角アウトプットのハードルが低い勉強会なので、失敗や間違えを恐れずに、大胆な意見が出やすいようにこのルールを設けています。 正確な情報をアウトプットするのはとても良い事ですが、自分の意見や思いを伝えることも同じく重要だと考えています。自分の意見をアウトプットする際には、反論やマサカリなどが飛ぶ 恐れ がありますが、 ローカルな場でご飯を食べながらアウトプットするようなゆる〜い場所 では、失敗をしても大した痛手にならないし、むしろ大胆に自分の意見を披露することで今までなかった視点からフィードバックを貰える可能性も出てきます。 また、フィードバックに関しては質疑応答の時に貰えなくても、同じ職場で働いている社員同士なので、雑談のタイミングや社内のチャットツールの中で貰えたりします。なので、発表に対する意見はかなり貰いやすい環境であるということは実感しています。 質疑応答やフィードバックで技術的な議論が活発にされるのが理想です。 実際の様子 event1 event2 event3 まとめ アドベントカレンダーの11日目ということで弊社の勉強会をご紹介いたしました。 ランチタイム に ローカルな場 で行うことで、 アウトプットのハードルを下げ つつ 発表者を増やす仕組み を作っています。 また、実際に4ヶ月程運用してみて、以下のような傾向が見受けられました。 アウトプットする人が増えた！ 社内エンジニアの技術スタックを知る良い機会になった！ 全然知らない技術に触れる機会が増えた！ 個人的な感想としては、一人のインプットには限界があるので、自分が深堀りができていない技術や体験できていない技術を、身近な社内のエンジニアを通して学ぶことができるのは最高だと思っています。 (人間の集合知ってすごい...！) 今後について 「てっくらんち」は既に次々回まで発表枠が埋まっており、引き続き開催する予定です。 また、徐々にアウトプットの範囲を広げていくことも検討しています。 その第一歩として、Youtube Liveでの配信を検討しています。 元々、支店や外勤のエンジニア用にMeetを使ってストリーミング配信を行っていましたが、アーカイブが残らず、参加できなかった場合の救済策がありませんでした。そのような流れから、Youtube Liveで見逃し配信を可能にし、シェアしやすいようにしようとしています。 また、Youtube Liveに移行することで、外部公開が可能になるので、内容によっては公開するなどして、徐々にアウトプットの範囲を広げていく計画です。 ということで、今後も「てっくらんち」を通して技術力の底上げに寄与しつつ、もっと盛り上がるように努力し続けていこうと思います。 We Are Hiring レバレジーズでは「てっくらんち」のような社内での勉強会や「ヒカラボ」という外部の講師を招いたパブリックな勉強会も開催しております。 また、最近では横浜に開発拠点ができるなど、新たな働き方も創出しています。 弊社に少しでも興味を持っていただいた方はご連絡いただけると幸いです。 https://recruit.jobcan.jp/leverages/ we_are_hiring

はじめに はじめまして。19新卒SREチームの id:t-kusakabe です。 入社して3ヶ月。僭越ながらtech blogを書かせていただくことになりました。頑張っていきます！ 目次 ビアバッシュと題してLT大会を開催した お前たちの1ヶ月の成長を見せてみろ！！ 実際にやってみて ビアバッシュと題してLT大会を開催した 新卒の皆さんはいかがお過ごしでしょうか。 入社して3ヶ月。配属先も決まりタスクをバリバリとこなし始めたのではないでしょうか。 弊社でもエンジニア職は5月末頃に各事業部へと配属され、それぞれ活躍するようになりました。 実際にタスクをこなしていくのは楽しいのですが、他の事業部に配属された同期との関わりが薄くなってしまい、少し寂しくもありました。 そんな時、エンジニアならどうするか。 そうですよね、LT *1 ですよね！！！ みんな、大好きLTです！！！ そんなことで去る6月25日、弊社で19卒エンジニア限定でビアバッシュと題してLT大会を実施しました！ ※残念なことに、開催した場所が来客者の方も居られるところであったためビアはお預けでした。残念。。。 お前たちの1ヶ月の成長を見せてみろ！！ 配属されてから1ヶ月の振り返りをテーマに、 お前たちの1ヶ月の成長を見せてみろ！！ というタイトルでLTを行いました。 各事業部で新卒たちはどのようなことをしていたのか。 配属される前と配属された後でどのように変わったのかを見せつけるテーマにしました。 実際、配属先の事業部でこういうことやったぞ！こういうチームにアサインされたぞ！こういう能力が身についたぞ！ という話がたくさん出てきました。 とはいえ普通にLTをやっても面白くないですよね。 というわけで色々コンテンツも用意してみました。 用意したコンテンツ 目標とゴールまでの道のりを可視化 コメント活性化ツール「マサカリカード」 リーダー陣からのありがたいお言葉 目標とゴールまでの道のりを可視化 新卒それぞれがなりたい姿を宣言し、その姿を目指して山を登っていく、というのをイメージしてこんなものを作りました。 毎月、 目標にどれだけ近づけているのか しっかり頂上を目指して走れているのか を可視化出来るようにしました。 この山を見つつ、 今月はどれくらい登ることができたのか 頂上に向かって登れているのか 同期はどの辺りを登っているのか 今のペースで本当に頂上にたどり着けるのか がわかるのと、楽しみながら自分の状態を把握出来るのでとても効果がありました。 自分の現在地をどこにするかが悩みどころですが、僕の場合は新卒なのと経験をたくさん積みたいということで一番長い道のスタート地点を現在地にしました。 ここから一気に駆け上がっていく予定です！ 今後はこの山を見ることで新卒たちの成長が伺えますね。 全員で頂上を目指せるように頑張っていきたいです。 ちなみにこれらは全て弊社のデザイナーに作っていただきました！！！ 新卒たちが目標に向かって走っている感じを表現したい、と伝えるとこのような素敵なものを用意してくださりました。 新卒だけでなく、たくさんの社員に好評でした！！！ コメント活性化ツール「マサカリカード」 LTと言ったらマサカリですよね！ しかし、意外と誰もマサカリを投げなかったり攻撃的なこともあるので、優しくマサカリを投げれるコンテンツも用意しました。 発表終了後に新卒全員でカードを引き、書かれている内容に沿って質問をします。 カードに書かれている内容によっては、笑いが起こるものであったり、クリティカルな質問になったりなど意外と面白い試みでした。 質問者:「〇〇さんの成長が自分ごとのように嬉しかったです！！！」 全員: 「(笑)」 質問者: 「ところで、来月の取り組みで気になったのですが、具体的にはどういうことをどれくらいされるのですか？」 のようなやりとりが行われ、笑いを生みつつマサカリを投げるということできました。 カードを引く人はランダムで決められるので全員が発表者のLTを集中して聞くようになったのも良かったです。 リーダー陣からのありがたいお言葉 新卒だけでLTをしてもただの発表会になりそうだったので、リーダー陣の先輩方に質問役をお願いいたしました。 1ヶ月で何をして、何ができるようになったのか。エンジニアとして何を意識すべきなのか。 などなど、1ヶ月の振り返りをさらに深掘りする機会をいただき、かつアドバイスもいただきました。 なんとしても翌月からの行動に取り入れていきたいです。 実際にやってみて みんなでわいわいするのはやっぱり楽しいですね。 同期が活躍していることを知って自分も負けていられないなと感じます。 また、先輩方からも「面白かった」「良い会だった」と言っていただけたので良かったです。 思いつきベースでの企画ではありましたが、やってみなよと後押ししてくれる先輩に感謝をしつつ、今後もこのような活動をどんどんやっていきたいと思います！！！ *1 : ライトニングトーク

はじめまして。 目指せ、カイゼンマスター! まえしょうです。 レバレジーズのマーケティング部CRMチームに所属しており、日々「最適なタイミングで最適なコンテンツを最適なチャネルで届ける」ため奮闘しています。 今日は、そんな私の重要なチャネルの1つであるメールの話です。 このブログの読者さんは嫌いかもしれませんね・・・。実は、そんなメールが生まれ変わろうとしています! サービス・プロダクトのグロース手段としてメールを見直してもらえるよう、3月25日にGoogleから正式リリースされたAMP for Emailを取り上げます。 [ 目次 ] そもそも、AMPとは? AMP for Email誕生の背景 ふむふむ、なにができるの? さっそく、試してみた まだ、できていないこと これからのメールの未来について そもそも、AMPとは? モバイル端末におけるウェブページの高速表示を実現して、ユーザー体験向上させようぜってやつ。 Googleが中心となって開発した新しいHTML規格のことです。 AMP for Email誕生の背景 ここ10年で世の中のコンテンツは静的なものから動的で対話的なものにがらっと変化しました。 ぱっと上げるだけでも、LINE、Slack、Amazon、ニュースアプリ、マンガアプリ・・・。 そんな中、古の連絡ツールであるメールはどのような進化を経たのでしょう。 ・・・し、進化してねぇ!!!! メールで通知がきたり、おすすめが飛んでくるのに、メールからどっかに遷移させられる!!!! そりゃ、まぁ、嫌われますよね。 しかし、AMP for Emailによって、メールは動的かつ対話的なツールに生まれ変わろうとしているのです! ふむふむ、なにができるの? 例えば、メール上で次のようなことが可能になります。 アンケートに回答 おすすめ商品の内容を確認して購入 配送状況が常に現在のものにアップデートされる 既に、開発に着手している企業もあるようで、メールというよりはウェブサイトのようなユーザー体験が期待できます。 出典: TechCrunch - Google makes emails more dynamic with AMP for Email さっそく、試してみた エンジニアでも、デザイナーでもないので上記サンプルに比べるとしょぼいですが、1時間くらいあればこんなのが作れます。 大まかな構造や画像は、 amp.dev のチュートリアルから拝借しています。 (セレクターなど、開発途中で時間切れになってしまいました。やろうと思えば、永遠にできる。) サンプル (所要時間: 1時間) HTMLにCSS直書きしたりして頑張った経験まである筆者は完成時、感動で涙しました。 メール屋さんな方は共感できるかと思います。 なお、メール作成者向けで、もう少し詳細な内容も書く予定です。少々お待ち下さい。 GitHubにコードを公開 していますので、待ちきれない方はそちらを御覧ください。 まだ、できていないこと 本格的な実装や検証を今後やっていく必要があります。 Gmailでのサンプルメール受け取り (Gsuite側の設定問題?) 既存のHTMLメールと共存させるコーディング 各種配信ツールでのテスト 動的なコンテンツの埋め込み より対話的なコンテンツの作成 これからのメールの未来について 賛否両論あり、まだまだこれからな技術ですが、大きな可能性を秘めている、と思っています。 きっとユーザーに「お、便利やん!」と言ってもらえるはず!! そして、メールの進化に伴い、メール作成者に必要とされるスキルセットも大きく変化していきそうです。 静的で自由度の低いオワコンから、動的で対話的な今風のコンテンツになっていくにあたり、ぱっと思いつくだけでも、メール内での情報設計、フロントエンドデザイン、ウェブ系のエンジニアリング・・・。 そんなわけで、CRMチームは技術に興味のある方、腕に覚えのある方を募集しております。 We are hiring! それでは、また次回、どこかでお会いしましょう。

はじめに こんにちは、18卒のおでんとよばれているものです。 7月から 看護のお仕事 の実装をやっていく中、ABテストの検証結果待ち状態で新しい実装が着手できないという問題が発生しました。 これに対して、BayesianABテスト方法を提案してみところ、検証が終わるまでに2週間〜3週間かかっていたものが、わずか1週間で終えることができるようになりました。 今回は、その使い方について紹介したいと思います。 ABテストとは Webサイトで画像や文章などをAパターンとBパターンの2パターンを用意して、 どちらの方がよりユーザーに行動を促した を検証するものです。 Webマーケティングの施策検証方法の１つとして実施されています。 インターネット広告では、 CV数（コンバージョン数） や CVR（コンバージョンレート） を高くすることが求められており、ABテストを実施して広告を出し分けるようにしています。 活用方法 A社のおでんの広告を使った時とB社のおでんの広告を使った時に、どちらのCV率（コンバージョン率）が高くなるかの施策をして、次のような結果が得られたとします。 ABテスト例 クリック数 CV数 CVR ページA 30000 425 1.42% ページB 28000 340 1.21% ABテストを実施して計測したCV数やCVRが、A社とB社の違いで本当に効果があるかどうかを検証する必要があります。 この検証をする際に、 カイ二乗検定 がよく使われています。 しかしカイ二乗検定には欠点がありサンプルサイズが小さい場合、効果があるかの判定が出にくいです。 ABテストサンプルサイズが小さい例 クリック数 CV数 CVR ページA 2255 32 1.42% ページB 1985 24 1.21% 冒頭での、ABテストの結果待ち状態になっている課題の原因が、サンプルがたまるまでの時間が長いことでした。 このサンプルサイズの問題を解決したのが、BayesianABテストです！ ABテスト実戦 では実際に上の２つのデータを使って、カイ２乗検定とBayesianABテストを用いた検証を用いた検証をして比較してみたいと思います。 使う言語は、解析でよく使われているRを使います。 カイ２乗検定を用いた検証 カイ２乗検定とは カイ２乗検定について例を元に説明したいと思います。 Webページでテストをした結果、以下の結果が得られたとします。 ボタン押した ボタンを押さなかった 赤いボタン 70 180 青いボタン 30 120 この時に、赤いボタンと青いボタンと関係があるかないかを検証できるのがカイ２乗検定です。 詳しい説明に関しては以下の参考サイトをみてください。 独立性の検定―最もポピュラーなカイ二乗検定 | ブログ | 統計WEB サンプルサイズが大きい場合の検証 まずは、サンプルサイズが大きい例を使い検証をしてみます。 実行プログラム > AB <- matrix(c(30000-425, 425, 28000-340, 340), ncol=2, byrow=T) #データを入力 > chisq.test(AB) #検証結果出力 検証結果 Pearson's Chi-squared test with Yates' continuity correction data: AB X-squared = 4.4033, df = 1, p-value = 0.03587 この結果で重要なのはこいつです → p-value p-value は、有意確率と呼ばれています。カイ２乗検定では、有意確率が 0.05以下の場合、要因の違いによってCV数に効果を与えていると判断されています。 今回の結果では、 p-value が 0.0359（有意確率が 0.05以下） でした。 この結果から、A社の広告を使った方がCV数が良くなると判定をすることができます。 サンプルサイズが小さい場合の検証 次にサンプルサイズが小さい例を使い検証をしてみます。 実行プログラム > AB <- matrix(c(2255-32, 32, 1985-24, 24), ncol=2, byrow=T) #データを入力 > chisq.test(AB) #検証結果出力 検証結果 Pearson's Chi-squared test with Yates' continuity correction data: AB X-squared = 0.21426, df = 1, p-value = 0.6434 今回の結果では、 p-value が 0.6434 でした。 この結果からは、別の広告を使ってもCV数に効果がないと判定されます。 このようにカイ２乗検定では、同じCVRであってもサンプルサイズが小さい場合、効果があるかの判定が出にくいと言われています。 BayesianABテストを用いた検証 BayesianABテストとは BayesianABテストは、ベイズ推定の手法を取り入れた検証方法です。 事前確率と実際に得られたデータを元に、A社のおでんの広告がB社のおでんの広告に比べて何％の確率で良いかを検証をすることができます。 ベイズ推定については、参考書籍がとても分かりやすいのでぜひ合わせて読んでみてください。 参考書籍 完全独習 ベイズ統計学入門 著者 小島 寛之 2015/11/20 事前準備 BayesianABテスト用のパッケージを以下のコマンドでパッケージをインストールをします。 > install.packages("bayesAB") ミラーサイトをどこにするかというメッセージが表示されたら、japanを選択をしてください。 インストールが完了したら準備は終わりです。 サンプルサイズが大きい場合の検証 先ほどと同じように、サンプルサイズが大きい例を使い検証をしてみます。 実行プログラム > library(bayesAB) #パッケージ読み込み > set.seed(10) #乱数固定 > A<-rbinom(30000,1,425/30000) #Aページのクリック数、CV数を入力 > B<-rbinom(28000,1,340/28000) #Bページのクリック数、CV数を入力 #ベルヌーイ分布の事前分布をベータ分布として初期パラメータを一様分布を仮定してa=1,b=1とし、シミュレーションを行う > AB <- bayesTest(A,B,priors = c('alpha' = 1, 'beta' = 1),distribution = 'bernoulli') > summary(AB) #検証結果出力 > plot(AB) # グラフ出力 検証結果 Quantiles of posteriors for A and B: $Probability $Probability$A 0% 25% 50% 75% 100% 0.01175708 0.01402836 0.01448583 0.01495520 0.01764696 $Probability$B 0% 25% 50% 75% 100% 0.009160405 0.011274530 0.011707422 0.012143179 0.014543185 -------------------------------------------- P(A > B) by (0)%: $Probability [1] 0.99852 -------------------------------------------- Credible Interval on (A - B) / B for interval length(s) (0.9) : $Probability 5% 95% 0.09790378 0.39482144 -------------------------------------------- Posterior Expected Loss for choosing B over A: $Probability [1] 3.125861e-05 グラフ結果1 グラフ結果2 結果1 先ほど出力した結果の中で、最初に確認して欲しいのが P(A > B) by (0)%: の部分です。 この数字は、AのページがBのページよりもいい結果が得られる確率を表しています。 P(A > B) by (0)%: $Probability [1] 0.99852 今回の結果では、 $Probability が 0.99852 でした。 グラフ結果1のCVRと発生頻度を注目すると、AとBの間に差が開いていることがわかります。 また、グラフ結果2はCVRの相対効果値を示したヒストグラムです。このグラフからは、ページAがページBよりもいい結果が得られる確率がどれぐらいあるかを確認をすることができます。 これらのことから、 AページのCVRが99.9%の確率でBページよりもいい結果が得られる という判定ができます。 結果2 次に確認して欲しいのが Credible Interval on (A - B) / B ~ の部分です。 この数字は、信用区間（credible Interval）に対してどれぐらいの効果が見込まれるかを表しています。 Credible Interval on (A - B) / B for interval length(s) (0.9) : $Probability 5% 95% 0.09790378 0.39482144 この数字がちょっとイメージがしにくいので図を作ってみました。 解釈図 ここの数字では、CVRの効果が出る確率を示しています。 まず、 5% 0.0979... は、AページをBページと比較した際に、Aページが109.7%以下の効果を出す確率が5%であることを示しています。 また、 95% 0.394... は、AページをBページと比較した際に、Aページが139.5%以上の効果を出す確率が5%であることを示しています。 以上の結果から、AページをBページと比較した際に、 Aページが90%の確率で109.7%〜139.5%の効果を出す と判定をすることができます。 サンプルサイズが小さい場合の検証 次にサンプルサイズが小さい例を使い検証をしてみます。 実行プログラム > library(bayesAB) #パッケージ読み込み > set.seed(10) #乱数固定 > A<-rbinom(2255,1,32/2255) #Aページのクリック数、CV数を入力 > B<-rbinom(1985,1,24/1985) #Bページのクリック数、CV数を入力 > AB <- bayesTest(A,B,priors = c('alpha' = 1, 'beta' = 1),distribution = 'bernoulli') #計算 > summary(AB) #検証結果出力 > plot(AB) # グラフ出力 検証結果 Quantiles of posteriors for A and B: $Probability $Probability$A 0% 25% 50% 75% 100% 0.007731823 0.015774076 0.017579264 0.019503243 0.032946183 $Probability$B 0% 25% 50% 75% 100% 0.004870983 0.011291718 0.012934394 0.014705932 0.027729893 -------------------------------------------- P(A > B) by (0)%: $Probability [1] 0.8921 -------------------------------------------- Credible Interval on (A - B) / B for interval length(s) (0.9) : $Probability 5% 95% -0.09560675 1.06632725 -------------------------------------------- Posterior Expected Loss for choosing B over A: $Probability [1] 0.01438976 グラフ結果3 グラフ結果4 結果1 P(A > B) by (0)%: $Probability [1] 0.8921 今回の結果では、 $Probability が 0.8921 でした。 グラフ結果3のCVRと発生頻度を注目すると、サンプルサイズが大きい時と比べて、AとBの間に差が開いていないことがわかります。 また、グラフ結果4のCVRの相対効果値に注目すると、ページAがページBよりもいい結果が得られる確率が89.2%であることが判断できます。 これらのことから、 AページのCVRが89.2%の確率でBページよりもいい結果が得られる という判定ができます。 結果2 Credible Interval on (A - B) / B for interval length(s) (0.9) : $Probability 5% 95% -0.09560675 1.06632725 解釈図 ここの数値では、AページをBページと比較した際に、5%の確率でAページが 90.5%以下で悪化させる ことを示しています。 また、AページをBページと比較した際に、5%の確率でAページが206.6%以上の効果が出ることを示しています。 これらの結果と結果1の数値を考慮すると、AページをBページと比較した際に、Aページの方が 89.2%の確率でCVRの効果が期待できる と判定することができます。 このように、BayesianABテストの検証では、サンプルサイズが小さい場合でも いい結果が得られる確率 と 信用区間に対する効果 の2つの結果から検証をすることができます。 そのため、サンプルサイズが小さい時の検証には、カイ２乗検定よりもBayesianABテストがむいていると思います。 おわりに 感想 BayesianABテストを調査＆実践してみて、大学時代に勉強したことが結構でてきたので、学生時代にちゃんと取り組んでよかったなぁと思いました。いろんな場面で統計学は使えると感じたので、これからも統計については追っていきたいと思います。 次挑戦すること 今回は１つ１つコマンドを入力してBayesianABテストを行っていましたが、次はGASなどを使ってスプレッドシートから自動で検証をしていきたいと考えています。 最後までお読みいただき、ありがとうございました。

はじめに こんにちは！ 18卒の いっちー と呼ばれている者です。もう入社してから1年が経ちました。そんな1年のほとんどの期間で実装を行ってきたSlackbotについての記事をここで投稿しておこうと思います。 今回は僕がSlackbotを実装する上で苦労した所を書きます。 僕のこの記事を読んで一人でも同じ失敗をしない人が増えればいいなぁと思います。 TL;DR 学んだこと 長いので簡単にまとめると、大変だからこれは心がけよう！と学んだことは次の3つです。 なるべくチャンネル間のやり取りを行う場合は、データベースを使ったほうがいいということ ダイアログの要素のサイズに注意すること ライブラリのチェックはこまめに行うようにリポジトリの通知をつけること 実際の申請画面のスクショはこちら。 申請画面 対象読者 これからSlackbotでチャンネル間のメッセージをダイアログで実現しようとしている人 ライブラリのチェックをしてないとどんなことがあるのか気になる人 社内ツール(Slack) 弊社では、コミュニケーションツールとしてSlackを使っております。 最近よく聞く「オープンな文化」を目指し、みんなパブリックなチャンネルで意見を述べ、質問もしています。僕個人では、必要な情報が過去の投稿から見つかることがあり、コミュニケーションコストが削減されているのを感じています。 また、弊社ではチャンネルの乱立を防ぐべく、チャンネル作成者の制限を行っています。以前は、チャンネルを作成する際は、担当者にメンションをつけて作成依頼をしておりました。 しかし、メンションをつけると、相手に通知が飛ぶだけではなく、送り手も送っていいのかなぁ、迷惑じゃないのかなぁ、といった不安を感じてしまう側面もあり、なかなかチャンネル作成を依頼できない、、、といった状況が頻発しました。 そこでBotになら気兼ねなく送れるのでは？という発想の元、Slackbotプロジェクトが発足しました。 Slackbot SlackbotとはSlack上で動くBotのことです。 社内では、「チャンネルを作成して」という依頼をSlackbotに送ることで、その依頼を権限持ちの「誰か」が実行してくれるように、申請承認チャンネルに投稿してくれます。 実装について Techblogという位置づけ上、技術的な話もしておきます。 使用環境 言語: Golang 1.11.2 パッケージ管理: dep slack用のパッケージ nlopes/slack サーバ: AWS EC2 機能一覧 現在搭載されている機能としては大きく分けて次のとおりです。 ユーザ招待機能 チャンネル作成機能 チャンネルリネーム機能 チャンネルアーカイブ機能 実装で苦労した所 別チャンネルに対してのThreadでの返信機能実装が大変だった 作ってきたSlackbotは基本的にはThreadとチャンネル間でのやり取りを行います。つまり、Slackbotを通して申請用と承認用の2つのチャネルに投稿されます。 Slackの仕様として、Threadで返信するためには、Threadで返信したい対象メッセージのタイムスタンプ情報が必要です。つまり、申請用のチャンネルで申請を出したあと、申請メッセージのタイムスタンプを承認用のチャンネルで保持しないといけないのです。普通なら、ここでKVSのようなもので保持するんですが、初期段階では用意してませんでした。 KVSなどが無い状態でどうしたのか、というと次の画像が語っているのですが、申請メッセージの中にタイムスタンプ情報を入れてます。そうすることで、ダイアログで承認を実行すると、今の実装では、タイムスタンプ情報をリクエストの中に乗せて、送信してくれます。 あとは、ダイアログ送信時の処理部分で、タイムスタンプ情報を扱うことで、実現しました。 承認画面 // 本来のコードとは違います // GetTimestamps ... get timestamp from message func GetTimestamps(message slack.AttachmentActionCallback) ( string ) { fieldLength := len (message.OriginalMessage.Msg.Attachments[ 0 ].Fields) applyTimestamp := message.OriginalMessage.Msg.Attachments[ 0 ].Fields[fieldLength- 1 ].Value return applyTimestamp } 別チャンネルの投稿と紐付いているタイムスタンプを返り値として渡すという関数を作りました。 タイムスタンプは、一番最後の要素にするので、 fieldLength を使って最後の要素の Value を取得しています。 最後に、申請結果をThreadで返す機能を作ったということもあり、この大変さに気づくまで遅くなりました。 というのもCallbackなどを設定しているので、てっきり前のダイアログ送信イベントでトリガとなったメッセージのタイムスタンプ情報を持っていると思っていたからです。(持っているはずがなかった…) Dialogを使用した別チャンネルへの投稿が大変だった このテーマだと、 message APIをSubmission時に叩けばいいんじゃないか？と思われるかもしれません。まさしくその通りで僕もそのまま実装しました。 でも、なんのエラーもなく、投稿されないという状況に陥りました。 原因は確実にこれ！と言えるわけではありませんが、いろいろ試してみたところ、Submission時に渡せる要素の長さに制限がありそうでした。 timestamp情報を先程持たせているという話をしましたが、そのtimestamp情報は申請元と承認側のtimestampを一度に送信しているため、文字列の長さが比較的長くなります。 画像にあるように、 1552527866.001200 が2つある状態でそれに追加で originalTimestamp というようなstructのフィールド名もつけているため1要素で渡す情報が長くなりました。 最初は定義したstructに問題があったのか、とか受け取り側のプログラムに問題があったのかなど考えました。 最終的に、渡すデータを短めの適当な値で試したところ、思った通りに動作したため長さに原因があることがわかりました。 なので、もともと originalTimestamp: 1552527866.001200, timestamp: 1552527866.100000 としていたところを、 originalTs: 1552527866.001200, ts: 1552527866.100000 に変更することでギリギリしのげました。 長さについては特に言及されていなかったので、試行錯誤が大変でした。 原因っぽいところに気づいて、無事動く状態に持っていけたのは非常に良かったですが、この原因調査が全実装のなかで一番大変でした。 ライブラリ自体に大きな変更があったときの対処が辛かった 例えば次のコードは、メッセージをThreadに対して送信するための関数です。 // 変更前のコード // ReplyMessageToThread ... Threadで返信するための関数 // message: 返信する投稿内容, ts: Threadの対象の投稿のTimestamp, p: 投稿メッセージのパラメータ func (s *SlackListener) ReplyMessageToThread(channelID string , message string , ts string , p slack.PostMessageParameters) error { p.ThreadTimestamp = ts if _, _, err := s.Client.PostMessage(channelID, message, p); err != nil { return fmt.Errorf( "faild to post message: %s" , err) } return nil } // 変更後のコード // message: 返信する投稿内容, ts: Threadの対象の投稿のTimestamp, p: 投稿メッセージのパラメータ func (s *SlackListener) ReplyMessageToThread(channelID string , message string , ts string , p slack.PostMessageParameters, a slack.Attachment) error { p.ThreadTimestamp = ts if _, _, err := s.Client.PostMessage(channelID, slack.MsgOptionText(message, false ), slack.MsgOptionPostMessageParameters(p), slack.MsgOptionAttachments(a)); err != nil { return fmt.Errorf( "faild to post message: %s" , err) } return nil } PostMessageParameters に、AttachmentsというPropertyが入っていたことで、スッキリとかけていましたが、ライブラリの変更により、 PostMessageParameters のstructから、Attachmentが分離されました。その変更により、すごい長くなりました…。 このように、 PostMessageParametesrs の Attachments を使っていた部分はほとんどが使えなくなりました。変更履歴を確認した所その変更が取り込まれたのが気づいた月の約3ヶ月ほど前でした… ライブラリの変更を追わずに、実装をし続けることで、こんなに大変なことになるんだ…ということの勉強になりました。 それからは、Slackにライブラリの変更通知を飛ばすように設定しました。 現状の辛い運用 Threadで返信するために、タイムスタンプ情報が必要だ、と述べたんですがそのタイムスタンプ情報は申請メッセージの中にあります。 ただ、それは運用している人にとっては全く意味のないものなので、表に出すようなものではないです。本来必要なものは、申請メッセージとの紐付け、つまり申請メッセージへのパーマリンクです。 若干申請者とのやり取りをThreadで行うことがあるのですが、それを手助けする機能が今無いのです。 これは非常に辛いと思うので、改善していこうと考えています。 改善への道 まず、KVSを導入しメッセージ間の紐付けをそこで行います。 KeyとValueとしては、それぞれ 申請元メッセージのタイムスタンプ と、 承認メッセージのタイムスタンプ とします。 そうすることで、承認メッセージのタイムスタンプ情報を元に、元のタイムスタンプ情報を得ることができます。 また、元メッセージのタイムスタンプ情報がKVSの中に保持されているので、承認メッセージにタイムスタンプ情報が不要になるため、代わりにパーマリンクを貼ることができます。 パーマリンクを取得するAPIとしては、 chat.getPermalink - slack を使用します。 おわりに 学んだこと OSSのライブラリを使うときは、アップデートを気にしておかないと、動かなくなる 通知を飛ばすことでちゃんとアップデート情報を追う SlackのAPIについての知識 ダイアログを送信したときのリクエストの長さに上限があり、正常なステータス返しても処理が実行されないこと 今後の改善 KVSのような仕組みを導入 タイムスタンプ情報ではなくパーマリンクを乗せる 以上の2つをこれから取り組んでいこうと考えています。 感想 全社で職種関係なく使うコミュニケーションツール内で、実現したいことをサポートをするBotを作って、色んな人に使ってもらえる経験をできてよかったなーと思います。社内で使用していることもあり、すぐにフィードバックを貰え、改善できる環境っていうのはエンジニアにとって非常に楽しい環境でもあります。 また、この開発を通して、Slack APIについては社内でも詳しい方になった気がして、なんか嬉しいです！ 今後も社内で使っているSlackbotがより良いものになるようにしていきたいと思います。 ありがとうございました！

はじめに こんばんは。もうすぐ新卒1年目が終わりそうで焦ってるM.Kです。 先日、予約したら1年待ちと噂のカンバン運用で有名な「 株式会社ヴァル研究所 」（以下、ヴァル研究所）のオフィス見学ツアーにマーケ・エンジニアの計7名で参加しましたので、その様子について書きたいと思います。 ヴァル研究所とは？ ヴァル研究所とは、路線検索のパイオニアとも言われている「 駅すぱあと 」を始めとする様々な有名サービスを提供している1976年に設立された会社です。 今回のツアーの案内もしていただいた、 カイゼン・ジャーニー の著者である新井剛さんが所属しており、新井さんの知識と経験も加味されて、会社全体で多くの業務カイゼンが進んでいます。 ヴァル研究所エントランス オフィス見学ツアーとは？ 今回参加したオフィス見学ツアーは、ヴァル研究所が実際に業務カイゼンのために導入している「見える化・カンバン・カイゼン」の活用事例を紹介してもらえるツアーです。 ツアーの内容は、開発部やマーケティング部、総務部など、様々なチームのメンバーが、各々で導入しているカンバンやカイゼンの方法について実際に使用しているカンバンの前で説明してもらえる贅沢なものになっています。 予約したら1年待ちのこのツアーですが、弊社森實がもともと新井さんと面識があり、入社前から予約をしていたため、今回は参加することができました。 オフィス見学ツアーの様子 ロビー ツアー前に集合したロビーですが、すごくおしゃれで、様々な賞も飾られていました。 中でも、弊社社員一同が最も盛り上がったのは、電光掲示板に弊社への歓迎のメッセージを表示してもらえたことです。 なかなか電光掲示板での歓迎はされないので、とても新鮮で嬉しいおもてなしでした。 エントランスの歓迎電光掲示板 ツアー開始 実際のカンバンを見せて頂く前に、ヴァル研究所の歴史についても学ばせてもらいました。 私達の後ろにあるのが歴代の紙の時刻表なのですが、今でも一部はここから手作業でデータを入力したり、実際に徒歩にかかる時間を計りに現地へ行ったりしているそうです。 弊社社員での集合写真 業務カイゼン用カンバン紹介 本当に多くのカンバンを拝見させて頂けたので、その中でいくつかピックアップして3つ紹介していきます。 チーム内タスクの見える化 最初に、お邪魔させていただいた総務部で、週・日単位でのタスク管理のカンバンを見ました。 カンバンとしては、 今週の予定 今週のタスク 待ちタスク（他の人に渡しているタスクを置いておく） 本日のタスク 完了したタスク に分類されています。 そして、チーム内でのフローとしては、次の日にやるタスクは毎週金曜日に決める。毎朝の朝会でその日に取り組むタスクを決めて、タスクを「今週のタスク」から「本日のタスク」に移動する。最後に、終わったらタスクを「完了」に移動するとのことです。 タスクの見える化の役割もありますが、タスクを消化していくことで達成感も味わうこともできるのでモチベーションが上がる方法だなと感じました。 タスクの見える化用カンバン 非効率の見える化 監査部では、VSM（バリュー・ストリーム・マッピング）と呼ばれている業務のプロセスを見える化して無駄を改善していくためのカンバンが印象的でした。 自分たちの業務のプロセスを全て書き出し、より効率化できる部分はないかをチームで洗い出しているそうです。 具体的には、エクセルの作業をモブプログラミングでの改善などをして、以前は42時間かかっていた作業を17時間ほどまで短縮できたとのことでした。 非効率の見える化用カンバン 残業の見える化 マーケティング部で見たのは、各社員がどれだけの残業をしたかを「う○ち」の絵で見える化したカンバンです。 フレックス制度を利用し、定時前に帰れたらお金の絵を書いて溜まった「う○ち」は相殺できるとのことです。 残業が多いことを見える化することによって、忙しい理由の分析をより正確にやることができ、結果的に残業時間の削減につながっているといいます。 残業の見える化用カンバン 社員サポート用のカンバン紹介 ここからは、業務上のタスクの管理ではなく、目では見えない心やスキルに焦点を当てたカンバン運用について2つご紹介します。 スキルの見える化 1つ目のカンバンは、誰が何のスキルが得意で何を身に付けたいと思っているのかを見える化させたカンバンです。 スキルを見える化することで、「〇〇については〇〇さんに聞こう」「〇〇君は〇〇をもっとやりたいから次は任せよう」などの行動をサポートすることができるようになったとのことです。 スキルの見える化用カンバン 気持ちの見える化 出社したときと退社するときに、社員が今の心理状態を色で分けて貼るためのカンバンです。 心の状態を見える化することで、管理者は「この人最近落ち込んでる」「この人出社と退社で心の状態が落ち込んでる。仕事で何かあったのかな？」などを考えることができ、いち早くサポートをしてあげることができるとのことです。 気持ちの見える化用カンバン 他にも「モヤモヤの見える化」や「チーム目標の見える化」、「価値観の見える化」など多くの「見える化」の施策が実践されていました。 チームごとで使用してるカンバンも異なり、日々カイゼンをしていることがとてもよく伝わってきました。 おまけ カンバンとは違いますが、とても面白いかつ便利な見える化がされていました。 それが、「エラーの見える化」です。 毎分リクエストをサーバーに送り、もしもエラーが返ってきたらダ◯スベイダーが音を立てるのだそうです。 コンソールを毎回見に行かなくてもエラーがわかる仕組み作りとそれをみんなが見えるようにする施策はとてもいいですね。 エラーの見える化用 まとめ ヴァル研究所はまさに「見える化」を全社的に取り組んでいる企業であることがとてもよくわかるツアーでした。 「カンバン」と言っても種類が豊富で、チームによって全く違いました。 どのチームも各々にあった方法を模索し、実践し続けていることが、説明していただいた内容からも、社内に置いてあるカンバンからもよくわかりました。 チームで施策全体や各メンバーの業務、心理、スキルについて共通認識を持つのはとても大変なことです。 そこを、ヴァル研究所のようにカンバンを使って「見える化」を進めていくと、問題発見から話し合い、そして解決までのスピードが加速する気がしますね。 弊社もまだまだカイゼンしていく課題が多い会社ではありますので、少しずつ、ヴァル研究所の皆さまを見習ってカイゼンをしていきたいと思います。

こんにちは！メディアシステム部の森實です。 さて、今回は実行委員の坂さんから声をかけていただいた縁で、3/27〜28に日本大学理工学部 駿河台校舎１号館で行われたソフトウェアテストシンポジウム 2019 東京（以下、JaSST'19 Tokyo）にて「プロばこ 4 JaSST」というワークショップをプロジェクトマネージャ保護者会として実施してきたのでレポートします。   はじめに  ソフトウェアテストシンポジウムってなに？ プロジェクトマネージャ保護者会ってなに？ プロばこってなに？ プロばこ 4 JaSSTってなに？ ワークショップ テスト技術者としての思い テスト技術者が感じていること おわりに  テスト技術者としてできることからはじめる 次回予告   はじめに  ソフトウェアテストシンポジウムってなに？ ソフトウェアテストシンポジウム（以下、JaSST）とは、『ソフトウェア業界全体のテスト技術力の向上と普及を目指して、NPO法人ソフトウェアテスト技術振興協会（ASTER）』が全国各地で開催するイベントで、2003年から行われています。 JaSSTにはソフトウェアテスト技術に関心の高い多くの参加者が集まり、交流を深めることのでき、2003年から行われています。   JaSSTソフトウェアテストシンポジウム   プロジェクトマネージャ保護者会ってなに？ プロジェクトマネージャ保護者会は、2016年当時、野村総合研究所だった僕とエクサだった稲山さん（現在はUZABASE）ではじめたユニットです。現在では正メンバー5人となり、プロジェクトマネージャを支援する活動をすることを目的に、パネルディスカッションやワークショップを不定期に行っています。   https://www.facebook.com/pmhogosyakai/   プロばこってなに？ プロばこは、プロジェクトマネージャ保護者会で作っているプロセステーラリングを学ぶためのワークショップコンテンツです。 各会社にはいわゆる開発標準プロセスがあると思いますが、単にそれにのっかってもプロジェクトはうまくいきません。制約事項、プロジェクトの特性に応じてそれらのプロセスをテーラリングして使うために、チームの作業プロセスのデザインと合意形成のフローをワークショップ形式で体得することを目的としています。 プロばこV0c from Fumitaka Inayama   プロばこ 4 JaSSTってなに？ プロばこは通常プロセステーラリングを行いますが、今回JaSSTの参加者がテストに精通した技術者が集うということで、対象をテストに関する部分に絞っています。 テスト技術者やテスト環境の「あるべき姿（なりたい姿）」を吐き出し、どうしてそうなりたいのか、そのためには何をしたら良いのか、を初めて会った人同士のチームで考え、共有するコンテンツです。   speakerdeck.com       ワークショップ テスト技術者としての思い 今回は、90分という枠の中で、テスト技術者としての積もり積もった思いをできるだけ出してもらい、その本質を見直して、正しいアプローチをチームで議論することが目的です。 参加者が主体的にならないとこのワークはできないのですが、本当にみなさん集中して、とても楽しそうに、思いの丈をぶちまけてくれたと思います。 特にテストというのは、リードタイム短縮と障害削減のバランスが非常に難しい部分です。テストエンジニアとしても理想と現実のギャップにおける葛藤を感じるとともに、前向きに考えていることが普段からあるのでしょう。 同じテスト技術者同士の議論、とてもいい顔してますよね！！   テスト技術者が感じていること  僕が見ていて感じたことの一番は、多くの場合、テスト技術者というロールがプロジェクトの中では大きな意味付けをされていないという現実です。 プロジェクトマネージャにとって、プロジェクト計画書、全体テスト計画書、全体リリース計画書というのは、プロジェクトの初期にほぼ同時に作らなければいけない大切な3つの計画書です。 しかし、書き出された付箋を見るからに、そもそもテスト計画がなかったり、テスト期間をバッファと見做されていたり、テスト云々の前にプロジェクトが正しくスタートを切れていないことに起因する、プロジェクト管理上のあるべき姿（ありたい姿）がとても多く挙げられていました。 昨今、アジャイル界隈でもQA部門を開発チームに入れるという話がよく聞かれるようになりましたが、言葉は違えど、現場の意見としてそういう関わり方をしたほうがいいということを感じていることもよくわかりました。   おわりに  テスト技術者としてできることからはじめる みなさんがすごくステキだったのは、明日から変えるために、現実的な世界に何を持ち帰るかを真剣にディスカッションしていた姿です。 それは、テスト仕様書のフォーマット改善を提案してみるとか、開発チームにお菓子を差し入れしてみるなどの本当に小さな一歩でしたが、きっとその一歩の積み重ねが大きな成果につながっていくのだろうなと感じました。 次回予告 ぁ、（プロジェクトマネージャ保護者会としての活動は）未定でした・・・ので、オファーお待ちしておりますw 若者の登壇の場も募集しておりますので、いつでもお声がけください。

はじめに お久しぶりに更新です。 KT です。 これから2~3回に分けて、Leveragesのエンジニア組織についてご紹介できればと思います。 第1回目は、月に1回行われるエンジニアミートアップについてです。 目次 エンジニアミートアップって何？ 具体的にどんなことしているの？ おわりに エンジニアミートアップって何？ ミートアップの様子 エンジニアミートアップとは、各事業部のエンジニアが集まり、現状報告や全体周知をする会です。 月に1度、約1時間ほどの短い会ではありますが、様々なコンテンツを持ち回りで運営しております。 全エンジニアが参加し、事業部間での知の共有を目的としております。 具体的にどんなことしているの？ 過去に行ったコンテンツは、こんなものがあります。 今月入社のメンバー紹介 イベントの周知 月に1度、 BIT VALLEY -INSIDE というイベントを開催しているので、そちらの詳細について 発表練習の場 持ち寄り勉強会 各事業部の困りごと、やってること共有 この中から、いくつかを詳しく紹介させていただいます。 発表練習の場 まずは、登壇前の練習の場としてこのミートアップの活用です。 外部の登壇機会がある人が、この場を使って発表練習をする時に使われます。 単に登壇者の発表練習としての機会以外にも、知の共有といったメリットもあり頻繁に実施されているコンテンツの1つです。 例えば最近では、JAWS Days 2019に登壇したメンバーが、登壇前に練習の場としてこのミートアップを使っていたり、 tech.leverages.jp 過去にはTwilioのMeetupに登壇したメンバーのレビューが行われたりもしました。 tech.leverages.jp 持ち寄り勉強会 持ち寄り勉強会も開催されたりもします。 個人単位や、事業部単位で得意な分野を他のエンジニアに共有する場として使われています。 例えば、フロントエンドのベストプラクティスについて持ち込みで、勉強会を開いてくれたり、 qiita.com 事業での取り組みを他事業部に展開するにあたって、前段階で勉強会を予定してくれたりと、個人や、組織単位で知の共有を行う取り組みもなされています。 各事業部からの共有 最近からですが、 「各事業部の困りごとや、力を入れているところ」 の共有を追加し、各部署が何をしていて、何に困っているのかを全員が把握できるような機会を作り出すことができました。 そもそもなぜそんな機会が必要かというと、自分以外の部署がやっていることを把握できなくなってきたからです。 メンバーも増え部署内で完結することが多くなってきたこと 結果、部署内でのやりとりは多くなったが、他部署とのやりとりは減った 働くオフィスの階や、場所自体が異なるためリアルなコミュニケーションが減った Slack上の表面的な情報だけでは他部署の事例を知ることは難しい この結果、他の部署が前にやっていたことを再度実装するようないわゆる 「車輪の再発明」 が起こる状況にありました。 そこでこのミートアップで、各部署の現状を共有することによってこうした負をなくしていこうというのが目的です。 まだ、初めて間もない取り組みなので具体的な成果は見えませんが、参加しているメンバーの満足度は高かったようです。 おわりに まだまだ取り組みとしては、始まったばかりで内容に関してもこれから精査されていくことになると思いますが、参加している側の所感として、他事業部の取り組みを知る機会は大切だと感じました。 例えば、よく言われている車輪の再開発のように他部署で利用されている技術をうまく利用したり。 サービスによっては同じようなフェーズを経験することになるので、そうしたときの「転ばぬ先の杖」的な状態を会社全体で保っていけることで、開発スピードを加速させ事業に貢献できる開発組織を作り上げる事ができると思います。 それ以外にも、外部で登壇する人が増えてきて「自分もやりたい！」と競争心を燃やしてくれる機会であったりと、個々人の成長にもうまく働いているように思います。 参加者自体の満足度を担保するためにも、定期的なコンテンツの見直しも行われています。 最後までお読みいただき、ありがとうございました。 次回は、エンジニアの作業環境などについての記事をお届けできればと思います。

JAWS Days 2019 こんにちはー！SREチームの村本です。 今回、JAWS Days 2019というイベントで、「実践！CloudFormation Best Practice ~CloudFormationで始める組織改革~」というタイトルの、ランチセッションをしてきました！ 小さめのイベントやLTくらいであれば、経験はありましたが、JAWS Daysのような大きなイベントでの登壇は初めてで、かなり面白い体験ができたので、それについてまとめていこうと思います。 資料については、既に公開してますので、ご興味のある方は是非ご覧になってください 😊 JAWS Daysについて まず、JAWS Daysを知らない人のために、JAWS Daysの説明をしておきます。 JAWS Daysは、日本AWSユーザグループであるJAWS-UGの中でも最大のイベントです。 https://jawsdays2019.jaws-ug.jp/about/ ユーザグループ主催のイベントなので、お硬い感じはほとんどなく、個人的には、お祭りといった感覚で楽しませてもらいました。 今回で7回目の開催となるJAWS Days 2019では、なんと来場者数1950名というかなりビックなイベントですね。 https://jawsdays2019.jaws-ug.jp/archives/2597/ ↓は懇親会の最後に撮られた集合写真です( 出典 ) 集合写真 登壇が決まるまで 突如、弊社CTOの方からJAWS Daysでランチセッションしない？っていうお誘いが来たので、2つ返事でOKしました。 ↓はそのやり取りです。 2つ返事をした後に、100人席で15分くらい話すよーっていうのを聞いて、ガクブルしながら覚悟を決めました...。 プレゼン作り JAWS Daysという大きなイベントで話すので、何を話そうと思ったのですが、1ヶ月前くらいからちょこちょこ進めていたCloudFormationのリファクタリングで詰まっている人が多そうだなーと思ったので、今回のネタに決定しました。 本番の3週間前くらいから話す内容が決まっていたし、一度別のイベントで話した内容なので、余裕をぶっこいていたら、気づいたら本番の3日前 😅 そこからは、寝る間も惜しんで資料を作り、エンジニア部長や先輩後輩に発表練習に付き合ってもらい、なんとか人前に出せるプレゼンが出来上がりました。 3日間連続で発表練習に付き合っていただいた方、FBをくださった方本当にありがとうございました。 (結局、安定してセッション時間内に収まるようになったのが当日のAM4:00でした。最初の写真の顔が死んでるのはきっとそのせいです...w) JAWS Days 当日 11時くらいに会場について、プレゼン資料をSpeakerDeckにアップロードして、Twitterでつぶやく準備までして、準備万端な状態で待機していました。 僕はGトラックでのセッションだったのですが、1つ前の オミカレの曽根さんのセッション が大人気で、立ち見が多すぎて通路が塞がるほどになっていました。 これを見て、こんな場で話すのか、やべーなと思いつつ、流石にこんなに人来ないから大丈夫か！と謎の深夜テンションでなんとかやり過ごしました。 ランチセッションだったので、皆さんお弁当片手に気軽な感じで聞くようなセッションでした。 それに対して、僕は眠気と緊張がせめぎ合ってよくわからない状態になりながら、セッション開始を迎えました...w ↓スライドは笑っているけど顔が死んでいる様子 今回はCloudFormationの設計に関わるお話をメインでさせて頂きました。 セッションの内容として、僕が伝えたかったのは以下の3つです。 CloudFormation Stackを適切に分割しよう CloudFormation Stackをアプリチームと分散管理しよう CloudFormation Stackの依存関係は閉じよう まぁ、要はCloudFormationを使うならベストプラクティスに則って使いましょう(そうしないと痛い目みるゾ)っていうことです。 セッション自体は、立ち見が出るくらい盛況で、とても驚きました。 お越しいただいた方、ありがとうございました！ 登壇後に、企業ブースを回っていると「CloudFormationの話をしていた人ですよね？」って感じで、セッションで触れなかった内容などご質問いただきました。 結構頑張ってセッションしたので、フィードバックを貰えたのは、とても貴重で有り難く、純粋に嬉しかったです。 総括 結論、JAWS Days 2019は最高でした！ このような大きいイベントでのメジャーデビューは、本当に沢山の学びがあって、とても良い体験になりました。 実は、去年のJAWS Days 2018に一般枠で参加させてもらっていまして、その時に「いつかJAWS Daysで登壇したいなー」とか思っていたら、想像以上に早く実現することができました。 感無量です。ランチサポーターになってくれた弊社に感謝。 このようなチャンスを頂けたのもそうですが、チャンスが目の前にある時には、ちゃんと掴むことが大事ということも実感しました。 来年はSREチームの他のメンバーには、チャンスを掴んで、是非登壇して欲しいなーと思っています。 また、僕自身もなんとか参加できるように、今からネタ作りに励みたいと思います！

はじめに お久しぶりです！TMです。 以前書いた、「 配属0日目の新卒がSlackに匿名で投稿できる機能をつけた話。 」という記事の続編です！ Slackに匿名投稿機能をつけて、その後どうなったかを書いていきます。 キーワードは、「良いチームであるために」です。 前回の投稿のおさらい 社内で意見や不満を言いたくても言いづらい人がいる、という噂があるが本当だろうか？ 発言の内容と発言者が結びついてしまうことが原因の1つなのかもしれないぞ...。 Slackに匿名で投稿できるappを作って検証してみよう！！ そして、実際に運用を始めたところまでが、前回の投稿でした。 運用してみて 細かいアップデートを何度か繰り返したものの、最終的にサービスは停止することになってしまいました。 アイコンを猫にしていたので、なんだか自分のペットが突然事故に遭って帰らぬ猫になってしまったような気持ちです。...合掌🙏 ちなみにどんな投稿があったか Slackの連携appの利用に対して・・・ 福利厚生に対して・・・（この投稿がきっかけで直していただき、今は音もせず快適です！） 社内の仕事環境に対して・・・（すぐに対応していただきました！） なぜ運用を停止したか 突然ですが、良いチームとは？ Googleの こちら のページで、「効果的なチームとは何か」について述べられています。 その中で、今回注目したいのは、 心理的安全性 です。 心理的安全性について、Googleは以下のように述べています。 「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。 （中略） 心理的安全性の高いチームのメンバーは、Google からの離職率が低く、他のチームメンバーが発案した多様なアイデアをうまく利用することができ、収益性が高く、「効果的に働く」とマネージャーから評価される機会が 2 倍多い、という特徴がありました。 つまり、心理的安全性とは チームメンバー同士が相手を信じられるかどうか ということです レバレジーズでも、チームで事業を進めていくにあたり、お互いが信頼できる状態にあるかはとても重要視しています。 匿名投稿をしてみてのメリデメ 良かった点 発信すらされなかったかもしれない発言を、発信するところまで押し上げることができた。 オープンSlackを利用したことによって、社内で起こっていることを共有する場にできた。 悪かった点 匿名であることで、会話から対等性が失われてしまった。（建設的な意見交換ができていなかった） それ直接言えば良いのでは...？という内容が匿名で投稿されることで、無駄に大ごとになってしまった。 なんてことない内容でも、匿名で投稿されることによって、何か不穏なニュアンスを感じ取ってしまう副作用がついてしまった。 心理的安全性を踏まえて 本件を振り返り、匿名投稿を心理的安全性の観点でまとめると、 匿名による対話によって友好的な関係性は構築されない 投稿を見ている人への不安感を助長してしまう という問題があります。よって、良いチームであるために、利益よりも不利益が大きいと判断したため、匿名投稿機能を廃止することにしました。 これからどうするか これから取り組んでいかなければならないことは2つあります。 実名でも気軽に意見を発信できる仕組みづくり 匿名投稿のサービスを止めただけでは、ただ前の状態に戻っただけです。匿名で投稿されていた内容を見ると、言いたくても言えないことがある人は実際におり、まだ潜在的にも存在していると考えています。そのため、匿名投稿に代わる発信方法を考えていかなければなりません。 組織の心理的安全性そのものをあげる 匿名投稿の発端は、「意見や不満を発信することによって、何か不利益を被ってしまうのが怖いのではないか」ということでした。この状態は、すでに心理的安全性が担保しきれていないことを表しています。意見を発信できる仕組みを整えると同時に、間違いなくアプローチしていかなければいけないポイントです。 なかなか難しいですが、少しずつ改善していきたいです。 まとめ 自分が入社して初めて作ったプロダクトが、3ヶ月でクローズしてしまって複雑な気持ちはありますが、今回の件を無駄にせずに成果を出すことで、弔いにしたいなと思います。 また、弊社のケースでは、匿名投稿はデメリットが大きいと判断しましたが、組織にいる人の性質や組織の規模、フェーズなどの変数次第ではメリットが大きくなりそうです。もし、同じような取り組みをしていて、順調に運用できているという団体があればぜひ事例を伺いたいです。