はじめに 左から 村本 阪上 家坂 メディカル事業部のKTです。 先月の26日に BIT VALLEY -INSIDE- が弊社セミナースペースにて開催されました。 初回ですが、50人近い方にご参加頂きました。 ありがとうございました。 コミュニティの運営として、弊社CTOの森實が参加していることもあり、初回のイベントでは弊社社員が3人登壇させていただくことになりました。 BIT VALLEY -INSIDE- とは BIT VALLEY -INSIDE- とは、渋谷界隈にオフィス（やお店）を構える企業が発起人となり、若者の登壇の場や共創の場、ネットワーキングなどを目的とした場の提供をするコミュニティです。 詳細はこちらを御覧ください🙋 melev.leverages.jp blog.samuraikatamaris.red (森實のブログより引用） 今回のイベントは、2部制になっており、第1部は持ち時間25分の発表でした。 第2部は、LT大会で各々思いの丈を5分でお話しいただきました。 今回はそんなイベントの第1部をメインにレポートしたいと思います。 第1部 カスタマーサクセスから考えるサービス成長 （レバレジーズ株式会社 マーケティング部 家坂光弥） 弊社マーケティング部の家坂からは、サービスの成長におけるカスタマーサクセスの重要性についてのお話でした。 カスタマーサクセスから考えるサービス成長 from Miya Iesaka www.slideshare.net カスタマーサクセスとは、「顧客の継続率、LTVを最大限に引き上げる活動である」と、カスタマーサクセスの定義について述べた後に サブスクリプションモデルのAdobeの成功事例を例に上げ、 利用者層が広がる 高額買い切りから少額課金モデルに切り替えるため リリースがスピーディになる 頻繁にリリースが可能であるため 収益の安定 前月の売り上げから売り上げが想定しやすいため 離脱（チャーン）を防ぐ ユーザの利用状況を細かく監視して適切なアプローチができるため という4つの成功要因を挙げ、サブスクリプションモデルにおいては特にカスタマーサクセスが必要であるということに言及されていました。 また、質疑応答では 「ユーザーの成功状態の定義は？」という質問を会場から頂きました。 それに対して、家坂からは 「ユーザーの状態によって違うので、最初にカスタマージャーニーで定義をする」 という回答をしました。 ここから、カスタマーサクセスとはユーザー一人1人によって成功の定義が異なるため、実践がかなり難しい一方でしっかりとユーザーと向かい合うことで継続率にダイレクトに反映されるので特にサブスクリプションモデルのビジネスに必要なアプローチであることがよくわかりました。 機械学習と統計データが切り開くミライ （レバレジーズ株式会社 マーケティング部 阪上晃幸） 弊社マーケティング部の阪上からは、蓄積されたデータをHR領域のサービスにどう活用しているのか、あるいは、どう活かしていくことが可能なのかというお話でした。 HRビジネスにおけるデータサイエンスの適用 @ BIT VALLEY -INSIDE- Vol.1 from Teruyuki Sakaue www.slideshare.net データの使い方として、 予測 登録時のデータやアクセスログを元に、転職熱が高いかどうかを判断 広告配信の意思決定に利用 意思決定支援 SNS広告がサービスのブランディングに効果的であるか計測 問題発見 蓄積されたデータを分析に活用 (音声ログデータが溜まっているので何か活用できないかという問題ありきの利用方法) の3つの使い方をしているようです。 EC系や旅行系のような短期間に何度も利用されるようなサービスとは違い、成果が出るまでの期間が長い（ログインや利用頻度が少ないため）という苦悩もありつつも、インパクトの大きな「予測」、「意思決定支援」、「発見」に上手く利用していくことで、それぞれの関係者にとって役に立つものを提供していくことができるようです。 また個人的に2つ目の「意思決定支援」の背景として同期の成果を証明してあげたいという、同期思いなデータの役立て方をしているのが印象的でした。 ベンチャー企業のインフラを運用して学んだ99のこと （レバレジーズ株式会社 メディカル事業部 村本雄太） 弊社エンジニアの村本は、ベンチャー企業のインフラを運用した際に学んだことを紹介してくれました。 speakerdeck.com 今回のお題目は、 自動化のすゝめ ユースフルなサーバー構成を作る方法 サービスを継続的に動作させるためには の3本立でした。 全体的に、人がやらなくても良いことをシステマチック(コード化や自動化) に行うことで簡単なミスを減らしたり、属人化を防ぐことができるようにするということでした。 サービス運用者にとっては当たり前ですが、サービスを一秒でも止めないために、できるだけミスがないようにしておくことはもちろん、起こった原因をすぐに特定し、対応できる環境であることも重要だなと考えさせられました。 第2部 第2部のLTは、5分という限られた時間を使って思いの丈をぶつける時間です。 Alexaアプリを開発した話や、本番環境をぶっ壊した話。 それから、React開発から学んだ責務の話や、また元バーテンダーの方がIT業界に転身して感じたことなど、みなさんそれぞれが魅力的な発表をしてくださいました。 全ての内容を紹介しきれなく残念ですが ryurockさん 373.3さん Ryo0815さん nagatatomoさん wataruscriptさん tyoshikawaさん ご参加ありがとうございました。 次回以降のLTも募集しておりますので、我こそはという方がいらっしゃればよろしくお願いいたします。 おわりに いかがでしたでしょうか？ エンジニアリング、マーケティングも営業も混ざって行うイベントに参加するのは初めてだったのでとても新鮮でしたが、職種を超えたコミュニケーションが生まれる場としてとてもよいコミュニティが生まれたなと参加して感じました。 今後も月に1回ペースでイベントを開催していく予定ですので、興味があればぜひご参加ください。 また、Facebookにコミュニティページもございますので、ぜひチェックしてみてください。 https://www.facebook.com/bitvalleyinside/ www.facebook.com ありがとうございました。

はじめに 本記事では、配属から1ヶ月間(5月末〜6月末)で社内ツール改善を通して学んだことを書きます。 主に内容としては次のとおりです。 SlackとDocbaseの通知設定を行うための連携部分の実装 開発の流れを学びながらの実装 成果物に対するフィードバック 今後の課題 自己紹介 はじめまして。18新卒の北陸出身の人です。 生魚苦手なので、北陸の方から東京へ出て来ました。 学生時代はGo書いたりScala書いたりしてました。社会人になってからはJS書いてます。 使用ツールの説明 Slack Slackの特徴として、外部ツールとの連携や、公開されているAPIの豊富さからエンジニアに人気のツールとなっています。最近では、日本語対応もしており、エンジニア以外のユーザも導入コスト下がったのではないか、と思います。 Docbase Docbase とは、 KRAY Inc. が運営しているドキュメント共有サービスです。 Kibela や、 Qiita:team などと比較してコストが安く、使いやすいことが特徴となっています。 実際に取り組んだこと 前提として、既に一部SlackとDocbaseの連携が行われていました。 なぜ連携したのか Docbaseの導入や、Slackとの連携の背景などに関しては、 こちらの村本さんの記事にて、詳しく書かれています。 tech.leverages.jp 改善したこと 僕が初めての業務で担当したのは、Docbaseで設定されている通知状況をSlackから変更できるように改善することでした。 ↓↓完成品↓↓ /docbase notify on で、通知をonにすることができ、 /docbase notify off で通知をoffにできるコマンドです。 on の後ろに個別に設定したい項目がある場合は指定することができます。たとえば、 /docbase notify on comment とすることで、投稿にコメントが付いたときの通知をonに変更可能です。 なお、今回の開発にあたって利用したものは次のとおりです。 node.js: v6.10.3 npm 3.10.10 slack API docbase API API Gateway AWS Lambda 構成(簡易) 取り組んだ背景 弊社では、Webhookを用いてDocbaseで記事が投稿・更新などされたら、Slackの対応しているチャネルに通知が飛ぶ設定を行っています。導入以前は、通知の設定の追加・変更を行うたびに、Docbase上で通知設定可能な権限を持っている人にお願いをする必要がありました。通知設定の追加・変更のたびに、管理者にお願いして変更してもらうのも無駄なので、誰でも変更できるようにしようというのが背景です。 経験したこと 改善を通して 使用してもらった人からリアクション、フィードバックを貰えた 「便利になった」、という感想から、「現在の通知設定の状態がみたい」、といったような改善点のご指摘等までいただけた プロダクトとは違うツールの開発の流れを実際に実行した 新卒でこのような社内のツールの改善を行うことで開発の流れを学びながら取り組めて非常に良かった スプリントごとにタスクを割り振って、Zenhubを用いて割り振られたタスクを実装していくというフローを少しずつ順を追っていくことができた その他 手厚いコードレビューを受けた(今までコードレビューを頂く機会があまり無かった) 同期も別記事で述べていることですが、コードレビューが非常に手厚く、ロジックのみならず、フォーマットの部分まで含めてレビューしてくださります。レビューを受けて学んだことに関しては同期とほとんど同じです。 例えば、コーディング規約に則っていないコードとして、 こういうもの( else の後ろにスペースを入れる必要あり)です。チェックしたつもりでしたが、漏れがありました…。(この数日後Linterの導入を決意する) 他にも、ロジックに関しては、このように冗長だったコードが、 const current_notify_setting = notifySettingInfo.receive_notification_settings const types = { 'publish' : current_notify_setting [ 0 ] .value, 'update' : current_notify_setting [ 1 ] .value, 'share' : current_notify_setting [ 2 ] .value, 'comment' : current_notify_setting [ 3 ] .value, 'star' : current_notify_setting [ 4 ] .value, 'goodjob' : current_notify_setting [ 5 ] .value, 'join' : current_notify_setting [ 6 ] .value } const body = { id: id, notificatable_type: 'Group' , notificatable_id: group_id, receive_notification_settings: { receive_publish_post_notification: types [ 'publish' ] , receive_update_post_notification: types [ 'update' ] , receive_sharing_post_notification: types [ 'share' ] , receive_comment_notification: types [ 'comment' ] , receive_star_notification: types [ 'star' ] , receive_goodjob_notification: types [ 'goodjob' ] , receive_join_user_notification: types [ 'join' ] } , group_id: group_id, type: 'slack' , webhook_url: notifySettingInfo.webhook_url } レビューを経て、次のようにスマートになりました。 let notifySettings = notifySettingInfo.receive_notification_settings.reduce((settings, setting) => { settings [ setting.name ] = setting.value return settings } , {} ) const body = { id: id, notificatable_type: 'Group' , notificatable_id: group_id, receive_notification_settings: notifySettings, group_id: group_id, type: 'slack' , webhook_url: notifySettingInfo.webhook_url } デプロイ後の修正に関するフィードバックの内容 フィードバックの内容としては、 - コマンドを忘れてしまう - 現在設定されている通知設定を確認するコマンドがほしい - Privateチャネルの方で実行してみたところ動かなかった です。公開してから早くも様々なフィードバックを頂きました！ 使っていただけている証拠なので感謝です。 今後の課題 docbase notify help を作るか、 docbase help を作るかどうか docbase notify status の実装を行い、現在の通知設定を確認できるようにするかどうか Privateチャネルの方はSlackの運用方針と逆なので対応しない予定ですが、あまりにも要望が多い場合は対応する予定です おわりに 社内で使用しているツールの改善を通して、「改善に終わりはなく、どこかの誰かが、改善点を見つけて報告してくれる」という構造を体験することができ、エンジニアとはなんたるや、の初歩的なところを学ぶことができました。 実際に社外の人に使われているサービスではないため、考えることは少なかったのですが、その少ない中でもたくさんのフィードバックをいただけました。次の業務ではご指摘いただいた点を再度指摘されないようにしていきます。 以上、配属1ヶ月で学んだことでした。

はじめに レバレジーズ株式会社インハウスエンジニアの村本です。 本稿では、DocBaseというドキュメントツールを浸透させるために試行錯誤した際のお話を綴っております。 これから組織にドキュメントツールを導入したいと思っている方や、使われていないツールを使ってもらいたいと思っている方が、ツールを浸透させる際の一つの参考になれば幸いです。 ドキュメントツールを浸透させようと思った背景 当時弊社ではドキュメントをまとめていたツールが乱立していました。各チームでベストだと思うツールを選択していた結果なのかと思いますが、チーム間のナレッジ共有や異動の際には不便極まりないものでした。 当時の状態を伝えるために、簡単に当時使われていたツールを列挙してみます。 Confluence esa Google Docs Google Sites Google Spreadsheet ファイル共有サーバ Github Wiki Evernote Excel この状況で、以下のようなことが起こっていました。 チームで一子相伝のドキュメントが引き継がれ続ける 引き継がれたドキュメントは引き継がれる度に悪化していく 古い情報が残ったまま更新されない もはや参考にならない 誰にも引き継がれない野良ドキュメントが出てくる どこに何のドキュメントがあるかわからない どのツールに何のドキュメントが書かれているのかがわからない ドキュメントのリンクを知っている人しかたどり着けない どこにドキュメントを書けばよいかわからない ドキュメントが色んなツールに散らばる 負のループ ナレッジが共有されない 同じ轍を踏み始める 個人のメモに一旦書いて共有しない 実は、社員の殆どは情報共有に課題を感じており、上記のことにも気がついていたのですが、誰も手がつけられない状態でした。 このような状態を解決するために、乱立するドキュメントツールを統一し、どこに何のドキュメントがあるのか、どこにドキュメントを書けばよいかを明確にしたいと思ったのが事の発端です。 何をしたのか 結論から書くと、 DocBase というツールを導入しました。 DocBaseを選んだ理由としては、「Markdownでかける」「非エンジニアにも使える」「安い」ことでした。 DocBaseを浸透させるためにやったこと DocBaseを導入するところまでは簡単だったのですが、DocBaseをどう社員全員に浸透させるかが課題でした。 そこで、エンジニアの私がやったことをご紹介したいと思います。 Slackと連携 弊社ではコミュニケーションツールとしてSlackを使っているのですが、このSlackとDocBaseを連携させるためのSlack Appを作成しました。 このSlack Appの機能は以下の2つです。 - 自分をDocBaseへ招待出来る機能 - SlackのChannelと1対1のDocBaseのGroupを自動で同期させる機能 それぞれについて、少し詳しく説明します。 自分をDocBaseへ招待出来る機能 まず最初に、Slackの Slash Commands を使って、自分をDocBaseに招待出来る機能を作成しました。 上のようにSlack上で /docbase invite me と投稿すると、自動でDocBaseのAPIを叩いて、招待メールをSlackに登録しているメールアドレスに送るという仕組みになっています。 これによって、ツールを使うために誰かに依頼をする手間が省けるため、参加障壁を下げることができました。 実際に運用してみた所感としては、参加障壁を下げることはツールを浸透させる上で、最初の重要な課題になると思います。 私は、DocBaseを導入する前に、esaというドキュメントツールを浸透させようとして失敗しました。 esaはとても使いやすいUIでオープン文化にとてもフィットしたとても良いドキュメントサービスでした。 しかし、使う人は極一部だけでした。その人達は、僕の周りの人達です。 誰かに何かをお願いすることは、人が行動を起こす際に、想像以上の障壁になると思っています(ツールを使いたいとは思っていない人は特に)。 その障壁を取っ払い、自分で能動的に参加出来るようにすることで、ツールを加速度的に浸透させることに繋がるのではないかと思います。 SlackのChannelと1対1のDocBaseのGroupを自動で同期させる機能 DocBaseにはGroupという概念が存在しています。 Groupにメンバーを招待し、Groupに参加しているメンバーだけGroup内のドキュメントを閲覧出来るようになっています。 このGroup機能をうまく活用すれば、どこにドキュメントがあるか探しやすく出来ると考えました。 弊社では、SlackのChannelはルールに従って作られています。例えば、組織やチーム、プロジェクトごとにChannelが作られています。 また、Channelは一部を除いて全てPublicで構成されているため、Slackに参加しているユーザは自分の興味があるチャネルに自由に入ることができます。 そこで、SlackのChannelと1対1のDocBaseのGroupを作成し、SlackのChannelにJoinしているメンバーをDocBaseのGroupにJoinさせるという機能を作成しました。 これにより、ドキュメントが書かれていそうなChannelのGroupからドキュメントを探すことが可能になりました。 また、自分に関係のあるドキュメントのアクティビティはDocBaseのダッシュボードで確認出来るので、ドキュメントの更新も追うことが出来るようになりました。 既存ドキュメントツールからの移行するスクリプトの作成 当時、マーケティング職だけ Confluence というAtrassian製の製品を使っておりました。 なかには有用なドキュメントもあったのですが、私がヒアリングした時点では新しくドキュメントを書くことには使われておらず、一部の人がドキュメントを参照しながら仕事をしているという感じでした。 そこで、Confluenceの記事をDocBaseへ移行するスクリプトを作成しました。 Confluenceのドキュメントはexportすることは出来るのですが、すべてHTMLの形式でダウンロードされてしまいます。 DocBaseはMarkdownで投稿するような仕組みでしたので、HTMLをMarkdownに変換し、DocBaseの投稿APIを使って投稿するというスクリプトをRubyで組みました。 ConfluenceのドキュメントをDocBaseへ移行することで、今まで仕事で使っていた記事を参照していた人をDocBaseユーザにすることができました。 また、Confluenceの記事を移行したことにより、Confluenceの契約を解除することができたので、ドキュメントツールを一つ統合することができました。 結果どうなったか これらの取り組みにより、日常的にDocBaseが使われるようになりました。 2018年8月現在では、約170名のメンバーがDocBaseを使用しており、毎日平均で30記事くらいが更新されています。 もはや、DocBaseがないと業務に支障が出るレベルまで浸透しています。 (オペミスで一部のDocBaseユーザをチームから退会させてしまった時は大変でした。) 最近では、ある部署が使っていたesaのドキュメントをDocBaseに移行する動きも出ています。 また、勉強会のレポートや、ポエム的な知見の共有記事も投稿されるようになってきました。 まとめ DocBaseを浸透させることができたのは、以下のことがポイントではないかと思います。 - 参加障壁を下げること - 日常的に使うツールと紐付けること - 既存のツールを統合すること 今回は、上記のポイントに対して、エンジニアとしてSlack Appを作るというアプローチを取りました。 エンジニアは課題に対して、「解決方法を知っている」 + 「解決方法を実行できる」スキルを持った職種だと思います。 今回のような課題を、社内にいるエンジニア全員がハック出来るようになると、とても面白い組織になるんじゃないかと思います。 We Are Hiring レバレジーズ株式会社では一緒に働いてくれるエンジニアを募集しております。 社内の課題を色々ハックしたい！という方は是非以下からご応募お待ちしております！ https://recruit.jobcan.jp/leverages/list?category_id=5142 recruit.jobcan.jp

写真(左)泉澤 (右)久松 はじめに メディカル事業部のMKです。 8月23日(木)に レバテック株式会社 が運営している ヒカラボ にて 【学生限定！】『就活時に自分が聞きたかった』ITベンチャーのエキスパートエンジニアが語る就活攻略法 が開催されました。 本イベントは、学生が就職した後に起こってしまうキャリアのミスマッチや、想像していた働き方と違うなどのギャップを少しでも減らすことができたらという想いから開催に至りました。 総勢20名以上の学部2年から大学院の学生にお越しいただきました。 今回は当日の様子を紹介させていただきます。 レバテックとは 弊社の関連会社であるレバテック株式会社が関東中心に、4000社以上と提携する業界最大規模のエンジニア&クリエイター支援事業です。 転職から日々の スキルアップ まで、「働く」や「学ぶ」を支援しています。 ヒカラボとは レバテックがエンジニア、クリエイターの方のために無料で開催する勉強会の総称です。 技術向上を目的とした勉強会をメインに開催しており、幅広く、様々な技術について学ぶことができます。 また技術以外のテーマでもキャリ アチェ ンジや フリーランス 活動をテーマにした勉強会も開催しておりますので、ご興味をお持ちの方は是非ご参加ください。 講演者プロフィール 久松 剛 (ひさまつ つよし) レバテック株式会社 新卒事業特別顧問。 レバテック株式会社 メディアシステム部 部長。 個人での受託開発・IT革命・国プロを経験。 時給1200円のアルバイト プログラマ を経てIT ベンチャー へ。 BtoB・BtoC インフラ全般の責任者、新卒 中途採用 、上場、情報システム部部長を経験後、 2018年5月にレバレ ジー ズ中途入社。 エンジニア組織の強化、採用、技術顧問、 M&A システム評価担当を手がける。 泉澤 匡寛 (せんざわ まさひろ) 学生向けキャリア支援サービス事業責任者。 キャリアアドバイザーとしてITエンジニアの転職支援からリクルーティングアドバイザーとして企業の採用支援を担当。 デジタルハリウッド やLIG、起業家向けエンジニア養成スクールなどでのキャリア セミ ナーを行う。 講演内容 IT業界について 就活の心構え エンジニアへの道 IT業界について まず、学生に対して泉澤よりIT業界が今なぜトレンドなのかを話しました。 現代の中心はIT業界 様々な業界の成長はIT業界の発展が牽引している。 企業に創業、成長、成熟から衰退までライフサイクルがあるように、業界にも同じようなライフサイクルがある。 今話題のIoT(Internet of Things)を利用して成長しているように見える業界でも、IoTの技術はIT企業が作り出しているためIT業界が牽引していると言える。 自分の市場価値を高める必要性 技術が発展している現代だからこそ、AI(Artificial Intelligence)によって代替されない自分の「価値」を高める必要性がある。 近年のAIの発展により、私たちがしている仕事の多くはAIによって代替される可能性が高い。 例えば、工場での管理及び作業を全て機械だけで運用しようとしている企業もある。 一方で、それらの技術を生み出し作り出しているエンジニアは市場価値が高く、技術の可能性が広がると需要がさらに高くなると言われている。 就活の心構え 次に、技術顧問から人事まで幅広く経験している久松が「IT業界での就活で心がけることや注意するべきこと」について話をしました。 大手を意識しすぎない 現在「売り手市場」だからと言って大手企業などを受けても、この先その企業がどうなるかは誰にもわからない。 企業規模や現時点での 知名度 、親の認知度に流されるのではなく、企業を幅広く見て判断するべきである。 選考は恋愛における告白だと捉える 面接を恋愛の告白だと考えると、相手が言われて違和感を感じる回答がわかってくる。 面接官「どういう キャリアパス を歩もうとしていますか？」 就活生「まずは技術力を磨いて、3年後には独立したいです」 上記は下と同義。 面接官「私とどういう時間を過ごしていきたいと考えていますか？」 就活生「3年付き合って自信が持てたら本命にアプローチしたいです」 このように、告白に置き換えることでどう答えていくのが建設的な面接のやり取りに繋がるのか見えるようになっていく。 エンジニアへの道 最後に、エンジニアを目指したい学生に対して久松が「エンジニアになるためにやっておくべきこと」について話をしました。 1日8時間、平日5日間プログラムを書いてどう思うか？ まず、自分自身がエンジニアとしての生活を受け入れられるかを知る必要がある。 そのために、学生のうちから「1日8時間、平日5日間プログラムを書いてどう思うか？」を体感しておくのが望ましい。 先にイメージもしくは知っておくことで、自分が想像していた理想と現実のギャップを小さくすることができる。 サンプルコードからの脱却 エンジニアとして生きていくためには、考えて書く論理的思考力を磨いておく必要がある。 学生の傾向として、サンプルコードを書いてプログラミングをした気になっているケースが多い。 サンプルコードをベースに、プラスαで何か機能などを追加していくことで実際に考えて書くことの練習にもなるため、今のうちにしておくべき。 その他にも、「 スクリプト言語 と コンパイラ 言語どちらも触っておくべき」「 ハッカソン で達成感に浸るだけではなく、論理的思考を意識してプログラムを作り込む」「アルバイトや インターン で実際のIT業界を知る」などを伝えました。 まとめ 今だけではなく、未来も。 周りに流されず、自分の軸で。 技術の発展が目まぐるしく起こる今の時代だからこそ、学生のうちから考えることの大切さを知れるイベントでした。 これからも定期的に弊社ではイベントを開催予定ですので、是非ご参加していただければと思います。

はじめに 自己紹介 はじめまして。 レバレジーズに18年4月に入社したMKです。 大学まで文系で、プログラミングをはじめたのは2016年なので実質ほぼ未経験みたいな状態で入社しました。 現在は社内向けツール開発がメイン業務で、今後は作成したツールに関しても本ブログで触れていきたいです。 何について書くの？ 今回は、良質なコードを知るためにおすすめと言われる「リーダブルコード」（表紙が楽譜で最初はエンジニアの本とは思いませんでした）の紹介を、自分の経験と照らし合わせて書いていきます。 冒頭でもお話しましたが、自分がほぼ未経験から入社して開発に携わっているので、入社してからの数ヶ月（配属されて実質2ヶ月）でこれは他の新卒やほぼ未経験の人におすすめ、と思ったことを中心に書いていけたらなと思います。 どうしてこのテーマなの？ このテーマにした理由は、いわゆる「良いコード」を知っていると自分が楽になりますよねってことを伝えたいからです。 知ってるだけで意識することができるので、どんどんコードが読みやすくなっていくのが自分でもわかります。 実際自分でも自分のコードが読みづらすぎて苦労しました。 入社後の学び 「リーダブルコード」の紹介 リーダブルコードを知らない人もいると思うので、まずは本の説明から。 簡単に言えば、 何を意識すれば読みやすいコードが書けるか を丁寧に教えてくれている本です。 もう少し具体的にいうと、変数名や関数名の付け方やコメントの付け方などを書いてくれています。 弊社のテックブログ内にも、上記の命名規則を新卒がどのように指摘してもらってどう改善したかが書かれている記事もあります。 興味がある方は是非下記のKFくんの記事も合わせてご覧ください。 tech.leverages.jp 個人的に意識することが多かった章 個人的に意識する機会が多かったのは、ズバリ、第7章です。と言っても章番号だけで分かる人はすごいですよね。 第7章は「制御フローを読みやすくする」について書かれたもので、関数から早く返そうやネストを浅くしようなどの内容も記されています。 最初に任された業務で書いたコードは、ネストだらけでした。 とりあえず動くものを作ろうという思いから早く形にしようという一心で作ったら、if文の中にif文が入りまくるif文祭りになってしまっていました。 このままでは流石にまずいと感じ、リーダブルコードを業務後すぐ買いに行き、そこから毎朝1章ずつコードを書く前に読むようにしました。 そもそも何でif文を減らしてネストを浅くすることがコードを読みやすくすることに繋がるのか。 文字で説明するより実際の例を見た方が早いと思うので、 sample.php で例を見ていただきたいと思います。 // sample.php <?php if ( $ request [ 'status' ] === 'success' ) { if ( $ user [ 'is_admin' ]) { if ( $ request [ 'action' ] === 'add' ) { } elseif ( $ request [ 'action' ] === 'delete' ) { } } else { // code for no permission user } } else { // code for failure } ?> 上のような sample.php だとコードを読んでいる人は、 今どこのif文に入っているか 閉じ括弧はどこのものなのか などの要素を読んでいる時に常に意識していないといけません。 今回はこれらの読み手（書いている自分も含む）にかかるストレスを軽減してあげられる方法を紹介していきます。 紹介する方法としては、実際にどのようなコードを自分が最初書いていて、それをどう修正したかを先ほど見ていただいた sample.php と sample_after.php で表したいと思います。（実際のコードではないですが、割と書き方は似てます。） さきほどの sample.php ですが、if文の中にif文が入っていて普通に読みにくいですよね。 この中に何行ものコードが含まれるので、実際のコード内だと読みづらさはかなり上がります。 次が sample_after.php です。 // sample_after.php <?php if ( $ request [ 'status' ] !== 'success' ) { // code for failure return ; } if ( !$ user [ 'is_admin' ]) { // code for no permission users return ; } if ( $ request [ 'action' ] === 'add' ) { } elseif ( $ request [ 'action' ] === 'delete' ) { } ?> 元々の sample.php より読みやすくなったのではないでしょうか。 ここで意識したことは、 早く返すこと 改行を入れること の二つです。 「早く返すこと」はリーダブルコードに書いてあるテクニックで、「改行を入れること」はレビューの際に言われたことです。 if文などで、肯定して条件を作っているときは逆に否定して試してみるとネストを浅くできたりして読みやすさが上がりますね。 まだまだ改善の余地はあるのはもちろんですが、一つ目のコードよりは「読みやすさ」を意識して書くことができるようになっている気がしませんか？ まとめ 長々と書いてきましたが、結局言いたかったことは一つです。 とりあえず、良いコードを知ろう です。 まずは何が一般的に良いコードと言われているのかを知るところから。知っていれば実際に書けるかは別として、意識することができます。 何度も意識して何度も修正することでコードが読みやすくなるので、開発にかかる時間も減ってくるのではないでしょうか？ その良いコードとはどういうものかをわかりやすく書いてくれている例の一つが「リーダブルコード」です。 特に新卒や開発経験があまりない人たちにはとても良い教科書になると思うので、少しでも興味を持たれたら是非一読を。

こんにちは。新卒1年目エンジニアのKFです！ 学生時代は、SwiftやRubyを書いたり、機械学習を触ったりしていました。現在は主にPHPを書いています。 今回は、配属されてから1ヶ月ちょっとの間でたくさんのコードレビューを頂いたので、その中でも主に命名規則について共有したいと思います。 背景 そもそもなぜこのテーマなのか 私は学生のころにコードを書いていましたが、コードレビューしたこともされたこともありませんでした。 そのため、「自分が分かればいいや！」という感じで書いていて、命名規則などがバラバラになっていました。今見返してみると何書いているかわかりません。笑 こんな全く命名規則などを気にしてなかった私がどのような点に気をつけるようになったか、実際にどのようなコードレビューを貰ってどう改善したかを共有できればと思います。 今どんなことやっているの？ 現在は社内の営業の方たちが使用する「レバ☆スタ」と呼ばれるWebシステムの開発を行っており、CakePHPを利用して開発しています。以下のように登録されている求職者の方達の情報を管理しています。 命名規則について コードレビューをいただく中で、「自分が書いたコードを他の人が見ても理解できること」 「未来の自分が見ても理解できること」という2点を意識してコードを書くようになりました。 ここでは私が業務中にコードレビューしてもらって、どのような指摘を受けたか、そしてどのように修正したかを紹介できればなと思います。 ただ、命名規則はチームによって違ったりするのであくまで参考程度でお願いします。 また、コーディング規約などは PSR-1 や PSR-2 も参考にしてみてください。 1. 名前は分かりやすく長くならないように メソッド名をつける時に分かりやすさを意識しすぎて以下のように長くなってしまいました。 修正前 private function getDaysFromOfferDateToInterviewDate($employee_id){ //・・・・ 中略 ・・・・ } コードレビューの際に「なんかメソッド名違うしそもそも長いかな」とコメントをいただきました。 面談日から内定日までにかかった日付を返すメソッドだったのですが、今見返すと自分でも長いなと思ってしまう..... なので以下のような改善をしました。 修正後 private function getDaysFromInterviewDate($employee_id){ //・・・・ 中略 ・・・・ } 修正前のメソッド名だと長すぎてどういうメソッドなのか理解するのに時間がかかりますが、修正後のメソッド名だと名前が短くても意味が理解できるようになってるかと思います。 2. 変数名が何を指しているのか明確にする ユーザの情報をDBから取ってきて、それを格納する変数名をこのようにしていました。 修正前 $userName = $this- > MsEmployee- > find('first', array( //・・・・ 中略 ・・・・ ) ); return $userName; ここで指摘されたこととして「ユーザ名以外も取得しているので userName という変数名はおかしい」というものです。 実はユーザ名だけを取得しているつもりで命名したのですが、実際は他の情報まで取得していました。変数名を正しくつけなければ間違って使ってしまう恐れがあります。 これを踏まえて以下のように修正を行いました。 修正後 $employee_user = $this- > MsEmployee- > find('first', array( //・・・・ 中略 ・・・・ ) ); return $employee_user; 修正前の変数名の場合、格納されているものと変数名が違うので、実際に変数を利用しようとした時に意図しないことが起こる可能性があります。 修正後の場合、正しい変数名になっているので意図しないことが起こりにくくなります。 なので変数名は正しく分かりやすいものを付けましょう！ 3. メソッド名は正確に あるかないかをチェックするメソッドを書いていた時に、先頭に check をつけて命名していました。 修正前 public function checkEmployeeOffers(){ //・・・・ 中略 ・・・・ return true; } ここでは「 check は便利な言葉だけど何をチェックしたいのかが分からないから is や has を使いましょう。」とレビューを頂きました。 "存在する" ことをチェックしたいのか "存在しない" ことをチェックしたいのかが人によって捉え方が違うので check という単語は便利だけど使わないように、ということでした。 よって check を使わずに is を使うこととしました。 修正後 public function isOffers(){ //・・・・ 中略 ・・・・ return true; } これによって誰がこのメソッドを見ても "存在する" ことをチェックしたいんだなと明確になります。 その後に「存在するか」というものには先頭に is をつけるようになったのですが、ある時に以下のようにメソッド名を命名しました。 修正前 public function isEditable(){ //・・・・ 中略 ・・・・ return json_encode($business_trip_contents); } ここでは「 return true/false であれば is でいいけど何かを返しているからメソッド名は適切ではない」と指摘を受けました。 私の中では「存在するか」をチェックしているので is をつけていたのですが、その場合は true/false を返さなければいけないのにjsonを返していました。 この場合は is ではなく get をつけるべきなので以下のように修正をしました。 修正後 public function getBusinessTripContents(){ //・・・・ 中略 ・・・・ return json_encode($business_trip_contents); } これによって true/false 以外のものが返り値として設定されていることを理解することができます。 まとめ 配属されて1ヶ月ほどですが、命名規則以外のことでも丁寧にコードレビューをして頂いているので学生の頃にはなかった経験を日々しています。 その中でも自分の書いたコードを他の人が見てもすぐに理解できるように書くことは難しいなと実感しながらコードを書いています。 特に命名規則などをあまり気にせずに書いてる人は少しずつでいいので意識するべきだと思います。 そういう人たちはとりあえず「リーダブルコード」の本を読むことがおすすめです！ 私もまだまだなので早くコーディング技術を上げていきたいと思います！ 参考 PSR-1: Basic Coding Standard PSR-2: Coding Style Guide

はじめに メディカル事業部のKTです。 先月の18日に Twilio Developer Meetup 2018 Summer が弊社 セミ ナースペースで開催されました。 開催直前まで2回増席するほど、これまで開催されたTwilioユーザーミートアップに比べても多くの参加者の方にお越しいただいたようです。 今回はそんなミートアップの様子をご紹介させていただきたいと思います。 Twilio Developer Meetupとは KDDI ウェブコミュニケーションズ様主催で行われた、 Twilio利用ユーザー様同士のコミュニティ活性を目的としたユーザーミートアップです。 今回は、Twilio社から デベロッパ ー エバンジェリスト である Marcos Placona 様を迎え、 コアユーザー様が経験した開発秘話をLT形式で発表するイベントとして開催されました。 Marcos様は、GoogleDeveloperExpertであり、.NETの地域organiserを務めるなど、かなり技術に精通した人物です。 エバンジェリスト が来日されることはあまり例がないので、Twilio系のイベントの中でもかなり注目されていたようです！ 各発表について ここからは、当日発表された内容をご紹介させていただきます。 Twilioで困ることの解決方法 harinoma.info 弊社西口は、Twilioを利用したサービス開発時に困った際に、どういったチャネルを利用して解決していたのかということを 経験談 も踏まえて紹介いただきました。 また、今回のようなユーザーグループを盛り上げるメリットとして、日本語で顔を合わせて相談がしやすいということと、市場が拡大するにあたって アーリーアダプタ である自分たちの市場価値があがるという2点についても言及しています。 いいかんじのシステムアラートをTwilioで 株式会社Speeeの西様は、某TV番組の放映時に自社のサーバーが落ちた経験を通じて、Twilioを使ったシステムアラート環境を構築した事例についてご紹介いただきました。 speakerdeck.com これにより 電話通知によってアラートに気づきやすくなる コミュニケーションを取りながら復旧することによって2次災害を減らす システムの構築コストもほぼゼロ といったメリットが生まれたそうです。 ~エンジニアじゃなくてもできる~ Twilioの活用事例のご紹介 レインメーカー 株式会社の長谷川様は、非エンジニアでもTwilioは他のサービスと連携が簡単なので、 活用してみようという発表でした。 例えば、「イベントの繰り上げ当選のメール通知に気づかずに参加できなかった。」という経験を元に、 特定のメールが届いた際に 電話がかかってくる。 というような仕組みを作成し、実際に自分で利用しているようです。 speakerdeck.com Architecture of wellcast ~ Live Streaming System ~ www.bokukoko.info 合同会社 セルフリー本間様は自社のリアルタイム配信可能なシステムの開発にTwilioを利用した際の知見をご紹介いただきました。 デ バイス やブラウザへの対応が複雑なWebRTCがTwilio側で提供されているので、それを利用してシンプルに開発することができることがTwilioを使うメリットだと仰っていました。 ただ、Twilioのユーザーとしてまだまだ課題も見えてきていて、料金や一部機能の改善要望についても言及しておりました。 TwilioでAlexaスキルを作った話 http://forexrobotics.jp/pdf/Twilio_Alexa.pdf Forex Robotics株式会社高橋様には、TwilioとAlexaを組み合わせたサービスの事例をご紹介いただきました。 ご高齢の方が自宅で一人で倒れてしまった時に、Alexaを通じて「助けて」と伝えると、登録された連絡先に対してTwilioを通じて電話がかかるような仕組みです。 こうしたように、日常生活にもTwilioが利用できるという事例をご紹介いただきました。 終わりに 全体として、LT以外にもパネルディスカッションと懇談会にて、ざっくばらんに エバンジェリスト や、コアユーザー様の方々に質問する時間も設けられていて、 インタラクティブ にユーザー様同士がコミュニケーションを取れるイベントでした。 参加された方々も普段は聞けないコアユーザー様の話を聞くことができ、大変満足そうでした。 また、 エバンジェリスト のMarcos様によると、日本国外含めてもかなりの規模のミートアップだったと仰っていました。 ただ、最近日本でも勉強会が頻繁に開催されるなど、ユーザー数も増えつつありますが、 認知度がまだまだ低い 困った際にまだ英語で情報を探さないといけない、 エンジニアの数も多くはない といったことが、課題として上げられておりました。 そういった課題を解決するためにも、今回のようなコミュニティを活性化させることによって、 「ユーザー自身で解決していこうという」 気持ちが伝わってくる。そんなイベントでした。

はじめに こんにちは！ 新卒1年目エンジニアのKMです。 大学では、企業や 地方自治 体と連携して、アプリを企画・開発していました。 今は、 キャリアチケット という新卒向け就職支援の新規サービスを開発しています。 新卒1年目が新規サービスを開発する上で学んだことを紹介できればと思います。 背景 レバレ ジー ズといえば、 オールインハウス です！ 弊社は、エンジニア・デザイナー・マーケーターが密に連携してサービスを作り上げるのが特徴です。 何かデザインで困ったことがあれば、すぐ近くにいるデザイナーさんと話し合いながら業務を進めています。 弊社だと職種に関係なく、共同で作業を進めるために Google スプレッドシート を使用することが多くあります。 例えば、エンジニアではなくてもプログラムを書いて、外部からデータを取得して スプレッドシート 上に記録したい場合が多々あります。 ですが、職種によっては Windows を利用している社員もいるため、 Python などの環境構築をするのは何かと手間になります。 簡単なプログラミングをやってみる そこで、エンジニアではない人向けに GAS で簡単なプログラミングをやってみました！ GASとは GAS（ Google App Scripts）とは、 Gmail や Google スプレッドシート などの Google のサービスを スクリプト で操作することができるプラットフォームです。 ちなみにGASは、 JavaScript がベースになっています。 クラウド 上で動作するので、環境構築が不要ですし、簡単に共有することができます！ 住所から緯度経度を取得 今回は、 Geocoding API を使って住所から緯度経度を取得してみたいと思います。 例えば、以下のようなデータがあるとして、取得してきた緯度経度を入力したいと思います。 1. スクリプト の作成 ツールバー の ツール を押し、 スクリプトエディタ を押します。 これで、作成は完了です！ 2. コーディング function index() { // 緯度経度情報があれば、シートに書き込む var sheet = SpreadsheetApp.getActiveSheet(), values = sheet.getDataRange().getValues(); for ( var i = 1; i < values.length; i++) { var address = values [ i ][ 1 ] , location = getLatLng(address); // 緯度経度情報があれば、シートに書き込む if ( location ) { sheet.getRange(i+1, 3, 1, location .length).setValues( [ location ] ); } } } function getLatLng(address) { // Web APIでデータを取得 var url = 'https://www.geocoding.jp/api/?q=' + encodeURI(address), res = UrlFetchApp.fetch(url), xml = XmlService.parse(res.getContentText()), root = xml.getRootElement(), location = root.getChildren( 'coordinate' ) [ 0 ] ; if ( typeof location == 'undefined' ) { return false ; } return [ location .getChildText( 'lat' ), location .getChildText( 'lng' ) ] ; } 簡単な解説 encodeURI() 住所が日本語ですので、住所部分を エンコード （符号化）しています。 UrlFetchApp.fetch() HTTP通信を行っています。 XmlService.parse() XML 形式のレスポンスをパース（ 構文解析 ）しています。 SpreadsheetApp.getActiveSheet() 今開いているシートを取得しています。 sheet.getDataRange().getValues() シートのデータを取得しています。 sheet.getRange().setValues() 書き込みたいセルの範囲を取得して、データを書き込んでいます。 3. スクリプト の実行 スクリプト エディタで実行することも可能なのですが、今回はボタンを作成して、ボタンを押すと スクリプト が実行するようにしたいと思います。 手順としては、以下のとおりです。 ツールバー の 挿入 を押し、 図形描画... を押します。 図形 を押して、図形やテキストを作成します。 作成した図形の右上の記号を押して、 スクリプトを割り当て... を押します。 割り当てる スクリプト として index を入力します。 動作確認 ボタンを押すと、緯度経度が入力されているのが確認できます！ まとめ 今回作成した スクリプト は、実際の業務でも活用されており、業務の効率化を図ることができました。 新卒1年目が提案した案が採用されて、業務で活用されているのも弊社の特徴かと思います。 また、今回はGASで Google スプレッドシート を操作する方法を紹介しましたが、 Google Drive や Gmail を操作したり、他のサービスと連携することができます。 GASは非常に手軽で便利なので、ぜひエンジニアではない人のプログラミングのきっかけになれればと思います。

はじめに わたしはだれ？ こんにちは！この4月から新卒で入社したTMです。 学部の専攻はデザインで、フリーペーパーやアニメーションを作っていました。 今はエンジニアとして参画していて、社会からの洗礼を受けているところです。楽しい。 この記事の概要 社内改善のために、Slackで匿名投稿できる機能を作りました。 AWS のLambdaや、Slack API を主に利用しており、試験運用中です。 そもそもの発端 Slackのオープン運用 社内の風通しを良くするために、publicチャンネルで発言しようというSlack文化を広めています。 こうすることで、社内の 情報のキャッチアップ がしやすくなったり、 一体感を生む ことができたりしています。 使いやすいようにカスタマイズ中 運用していく中で、もっとこうしたほうがいい、こんな機能が必要なのではないかと試行錯誤しています。1人につき1つpublicチャンネルがあったり、 DocBase というサービスと連携したり、どんどん使いやすくしているところです。 意見を気軽に言いづらい？ そんな中で、Slack内外問わず、 社内に対する改善意見や不満を直接では言いづらい人がいる という噂を聞きました。ほんとかなあ？と思いつつ、確かに会社の規模を考えればそういう人がいてもおかしくは無さそうです。 原因は何か そもそも、意見や不満を発信することによって、 何か不利益を被ってしまうのが怖い のではないかなと考えました。そんな怖い会社ではないはずなのですが。多分。 解決するためには 発言した内容が、発言した個人と結びついてしまうことが1つネックになっているのでは？ 匿名投稿できるようにしよう Slack上の特定のチャンネルで匿名で意見を投稿できるようにしてみたら、今まで拾えなかった貴重な意見や不満を拾えるのではないかと思いました。実際やってみないとわからないよね、ということで実験的に作り、運用しています。 実際にやったこと 使った技術 AWS Lambda 今回はトリガー自体が単純であることと、イベント発生数が少ない（おそらく）ので、使いました。社内の別のプロジェクトでもちらほら使われているようです。 Slack API （スラッシュコマンドと Bot ） Slackって誰がタイピングしているのかわかりますよね。全員が機能をoffにすれば別ですが、それはだるい。いい方法はないかなと調べた（試した）ところ、なんと スラッシュコマンド中はタイピング出ない んですね。嬉しい。 留意点 スラッシュコマンドは 3秒以内にレスポンスを返さないといけない という制約があるので、Lambda_1からLambda_2を呼びつつ、一旦レスポンスを返しています。 const AWS = require('aws-sdk'); exports.handler = (event, content, callback) => { const functionName = process.env.PROCESSER_FUNCTION; let lambda = new AWS.Lambda(); let params = { FunctionName: functionName, InvocationType: 'Event', LogType: 'Tail', Payload: JSON.stringify(event) }; // ここでLambda_2を呼び出す lambda.invoke(params, (err, data) => { if (err) console.error(err); }); // 一旦レスポンスを返す callback(null, event); }; できたもの 以下のように入力すると・・・ /anonymous hogehoge Anonymous という bot として投稿されます！　 制作期間は企画を含めて2週間でした。 アイコンは、温かみと生き物感があるものにしようということで、今の猫になりました。名前は「あのにゃー（非公式）」です。 工夫したところ うっかり実名投稿してしまうのを防止するために、自分のDMからもチャンネル指定で投稿できます。 /anonymous #meyasubako hogehoge 現在は#meyasubako（目安箱）みたいな意見投稿用チャンネルのみに投稿できるようLambda側でfilterをかけています。 つまづいたところ Lambdaでの実装をローカルで試すのが難しいです。 sam-cli というのでローカルテストはできます。ただ、今回はLambdaからLambdaを呼び出すところがすんなりいきませんでした。どうしても解決できず、 AWS にテスト用環境を作ってやりました。 運用をはじめて 実際にこんな投稿がありました こんな軽めの投稿や・・・　※社内のミ ニコン ビニの話 時差出勤に対するちょっとガチな要望・・・ そしてオープンSlackへの改善意見・・・ 今のところのGood 溜め込んだり、プライベートで話していたりしただけではただの不満や愚痴で終わっていたコンテンツが、たとえ匿名でもオープンな場で発信されることによって、いろんな人が考える機会を得ることになっていると思います。 今のところのBad 軽いのから重いのまでありますが、何か改善意見や不満が発信されたときに、実際に解決のために動く機構が存在していないことが問題かもしれないなと思います。 今後について 機能試験も含めて小規模な人数で運用していましたが、現在は徐々に規模を拡大しています。人伝てに広げていくのが、チャンネルを気持ちよく運用するのにちょうどいいかなと思います。ある程度運用したら、本当に意味があるのか検証します。 おわりに 配属最初のタスクが、これでした。社内の課題に対して向き合いつつ、 AWS の利用やSlackのカスタマイズなど今まで経験のないことを同時にしたので、すごく脳汁を分泌しました。が、これがレバの新卒なんだなあという感じです。 運用の結果がでたら、そのときにまたブログでご報告します。ではでは。

1. はじめに メディカル事業部インフラ担当新卒2年目エンジニアの村本と申します。 本記事では、私が新卒1年目でインフラ経験0のところから、メディカル事業部のインフラを任せられるようになるまでに、ぶち当たった壁とその対処法を綴っております。 これからエンジニアになる学生の方や、これからインフラ業務に携わる方、これからインフラ担当者を育てるという方が、学び・学ばせる一つの参考になれば幸いです。 2. インフラ担当となった背景 私は配属後、メディカル事業部の社内向けの営業管理ツールとオウンド媒体の大規模リニューアルプロジェクトに携わっておりました。 配属されて3ヶ月間は営業管理ツールの開発をしており、ひたすら PHP を使ってWebページ作成していました。 そんな中ひょんなことからCircleCIを使ったテストとデプロイの自動化タスクが振って来ました(自席に帰ってくるとCircleCIと書かれたメモ紙が、まるで 赤紙 のように置かれておりました...(メモ紙は真っ白))。 CircleCIに関しては元々、入社前に インターン をしていた会社で使用しておりましたので、その経験を活かして自動化タスクをやることになりました。 その際、隣に座られていた先輩エンジニアが、1人でリニューアルのインフラ基盤の構築を担当していたのですが、「リニューアルインフラの基盤構築」 + 「開発/テスト用の環境の提供」 + 「その他依頼対応」を一手に担っていたため、圧倒的に人手が足りていませんでした。 そういう状況を隣で見ていたこと、少し開発業務から離れたこと、また私自身がインフラに興味があったことから、リニューアルインフラ基盤構築業務に携わることとなりました。 3. ぶち当たった壁と対処法 インフラに興味があったとはいえ、入社前にはHeroku上に Rails アプリケーションを乗せるくらいの経験しかしたことがなく、Webアプリケーションがリク エス トを処理する仕組みやネットワークの仕組みなどは、全く理解していない状態でした。 更に、リニューアル後のインフラ環境は AWS を使った クラウド 上に構築することが決定されており、 AWS を使った クラウド の基礎知識も必要でした。 このセクションでは、私が実際に知識不足でぶち当たった壁や事故について、いくつかご紹介していきます。 Nginxの概念・構成がわからない インフラに携わるようになった時の最初のタスクが、Ansibleを使ってNginxの設定を自動化する事でした。 (メディカル事業部のリニューアルインフラは全て、Infrastructure as Codeになっています) Ansible自体は Yaml で書かれた設定ファイルであったことと、READMEがきちんと書かれていたので、ある程度はすぐに使えるようになりました。 しかし、Nginxの設定に関しては、各設定項目が意味がわからず、また ディレクト リ構成もベストがわからない状態でした。 対処法 各設定項目の意味や概要を知るためにとにかく ググる 各ディレクティブの役割を知る httpディレクティブ serverディレクティブ locationディレクティブ 各設定項目の詳細については Nginxのドキュメント を読む ディレクト リ構成については laravel/homestead などを参考に構築する site-avaiable、site-enabled構成になっていた 元は Apache がそのような構成だったらしいなど 有効化無効化がシンボリックリングで簡単に行える 開発環境の破壊事件 インフラ担当になってから1〜2ヶ月くらいたった頃でした。 サーバを触るのにも少し慣れてきて、調子に乗っていたのかもしれません。 新規事業である 介護施設 紹介事業のLP作成のタスクが振ってきまして、私はそのLPを2週間で作成することになりました(リニューアル中に)。 その際にデザイナーさん用の開発&確認環境を用意することになりました。 用意されたサーバは、データセンターで仮想化されて起動しているオンプレミスのサーバでした。 そのサーバに 介護施設 紹介事業のLPを表示するために必要な設定を施していきました。 一通り設定を終え、画面が確認できる環境を作った3日後くらいに、 Hologram というライブラリを使えるようにして欲しいという依頼が飛んできました。 メディカル事業部では、スタイルガイドの生成に、 Hologram というライブラリを使用しており、 介護施設 紹介のLPでも使えるようにして欲しいとのことでした。 Hologram は Ruby 製のライブラリだったので、サーバに Ruby をインストールする必要がありました。 私はいつも通り何も考えず、新しい Ruby をインストールするためにコマンドを実行しました。 そう $ sudo yum -y update を...。 コマンドの実行が終わると、 なぜか全てのコマンドが実行できなくなっていました。 !!!?! この状態に焦り、一人でひたすら調べ、 LD_LIBRARY_PATH のパスが通ってないから通してみたり色々やってみましたが、結局解決出来ず、ベテランエンジニアに助けを求めに行こうとしたら、 ssh 接続が切れて、2度と ssh 接続が出来なくなってしまいました。 原因は yum update をしたことで カーネル がアップデートされ カーネルパニック を起こしてしまったことでした。 結局データセンターに問い合わせて再起動することで対応して頂いたのですが、その対応に3日ほどかかってしまいデザイナーさんの開発をストップさせてしまいました。 この事故から暫くトラウマで、 yum update と sudo コマンドが打てなくなりました...。 対処法 サーバに変更を加えるコマンドはめちゃくちゃ慎重に打つ 暫くは上長に見てもらう or 上長に打ってもらう そもそも カーネル が上がらない用に設定する yum -y update --exclude=kernel* どうしようもなくなる前に即ベテランエンジニアに相談 どうしようもなくなってからでは遅い AWS ふんわりとしかわかっていなかった問題 実は AWS の操作に関しては、先輩エンジニアに手取り足取り丁寧に指導して頂いたおかげで、特に困ることはありませんでした。 しかし、そのために AWS の基礎概念である VPC やSubnetやRouteTableまわりの知識はふんわりとしか理解しておらず、 AWS のコンソールを見ても、何故この設定がされているのかわからない状態でした。 このままではいつまで立っても、インフラ担当として一人立ちが出来ず、先輩エンジニアの負担は減りません。 対処法 AWS のドキュメントを読む AWS のドキュメントは初見の人は翻訳されていなかったり、翻訳がされていても変な文章になっていることもあり、読みづらいかもしれませんが、慣れてくると概念的なことも、細かい仕組みの部分もベストプ ラク ティスも全て乗っているので、一読することをおすすめします。 個人アカウントで色んなサービスを使ってみる 私は個人開発でクローラや API を作成していたので、それらを AWS 上に構築することで、実際に AWS に触れながら学ぶことが出来ました Expressで作ったAPIをaws-serverless-expressでサーバレス化した話 - Qiita EC2で直接動かしていたクローラをECSに移行した話 - Qiita サーバレスやコンテナのような個人的興味があるものを使ってみる 興味があるものを触ると学びが早いのでおすすめです 試験を受けてみる AWS では、技術的スキルと専門知識を証明し、キャリアアップにつなげるための試験が用意されています https://aws.amazon.com/jp/certification/ AWS の認定資格取得のために一通りの基礎的なサービスについて学ぶ必要があるので、 AWS でサービス運用するための知識は自ずと付きます 資格取得のための勉強方法については以下をご参照頂ければと思います 新卒2年目になったのでAWSソリューションアーキテクトを受けてみた - Qiita 4. まとめ この一年で色々な壁にぶち当たり、その度に色々な方法で対処してきました。 壁を乗り越える度に少しずつ成長を実感できた、とても学びの深い1年だったように感じます。 おかげで、今ではメディカル事業部のインフラを1人で運用して、リニューアルのリリースから現在まで問題なくサービスを運用することが出来ております。 しかし、まだまだ改善できる部分は沢山ありますので、今後も壁にぶち当たりながら改善していこうと思います。 5. We Are Hiring レバレ ジー ズ株式会社では一緒に働いてくれるエンジニアを募集しております。 AWS を使ったモダンなインフラ基盤を作りたい！色々改善したい！という方は是非以下からご応募お願いいたします！ エントリー

はじめに メディカル事業部のKTです。 今回は入社2年目の私がレバレ ジー ズのエンジニアとして、 この1年間どのような経験をしたのかということをご紹介できたらと思います。 開発歴が浅い私のようなエンジニアが壁にぶつかった時、少しでも参考になるものがあれば嬉しいです。 目次 背景 事業フェーズについて 入社当時の自分について プロジェクトに参画して学び得たもの エンジニアがやるべきこと プロジェクト理解の大切さ まとめ 背景 事業フェーズについて 私たちのチームについては、こちらを参照ください。 tech.leverages.jp 配属された当時、メディカルチームは社内システムとオウンド側の大規模なリプレイス中でした。 私がプロジェクトに参画したのは、約2年のプロジェクトの残り半年くらいのフェーズで、 仕様書を見ながら（たまに仕様から考えて）ひたすらページの作成を行うのが主な業務内容でした。 チームの編成としては、エンジニア、デザイナーとマーケをあわせてが30数名といったようなチーム編成です。 入社当時の自分について 入社時の私のプログラミング歴は１年ほどでした。 一通り言語に関する本を読み（たのしい Ruby ）、 チュートリアル を元にシステムの理解はできており、記事などを見ながらとりあえず動くものが作れるといった程度の技術力を持っていました。 インターン で（主にフロント側）チーム開発も行っていたのと、研究ではとりあえず動くものを1から作成し AWS を利用してデプロイも行っていたので、アプリケーション開発に関しては一通り学んでいました。 プロジェクトに参画して学び得たもの 私がプロジェクトを通して学んだ、非常に大事なポイントを2つ紹介したいと思います。 エンジニアがやるべきこと 1つ目は、「エンジニアがやるべきこと」とは 問題解決 であるということです。 ただ、当時の私はそんなことも考えずに、とにかくコードを書くことに必死でした。 作業ゲームのように修正やリファクタを行い、 プロジェクトにとってその改修が何になるかを全く考えない無責任な実装をしてしまっていました。 （もちろんリファクタ自体は大切な作業だと思います。） 気づいたときには、 「きれいにコードを書くこと」 が目的になっていました。 それでいて結果が出ていないのにも関わらず、コードを書く量は多いので仕事をした感だけが蓄積されていくのが怖いところです😰。。。 そんなときに先輩から、「エンジニアがやるべきことはコードを書くことではなく、 課題を解決する ことだ。」と指摘されたのを覚えています。 それからは、 （実装する前に）この実装は本当に必要なのか。代替えはないか 目的に対しての解決策になっているか 本当に「今」やらないといけないことなのか などを意識するようになり、結果として無駄なコードが減り、実装の優先度を考えた作業ができるようになりました。 また、やらないことを決めたおかげで自由に使える時間も増えました。 ぜひ、 その行動が問題解決に繋がっているか ということを意識してみてください。 やらなくてもいいような仕事が削られて、やるべきことに時間が回せるようになると思います。 プロジェクト理解の大切さ 2つ目は、 プロジェクト理解 の大切さです。 チュートリアル や、個人開発しかやったことのないエンジニアにとって最初の難関は、 社内の複雑なプロジェクトの関係性を理解することにあるかなと私は思います。（体験談） 今までのアセットをどう活かして実装するか 自分の書いたコードが極端に目立っていないか など個人開発とは違い、より長期的な運用を見越した、汎用的な実装が求められます。 私は、プロジェクトに馴染むコーディングが苦手でした。どうしても自分の書いたコードだけ目立ってしまってそれを何度か指摘されたことがあります。（一概に個性を出すことがすべて悪いこととは言い切れませんが、規約やロジックの組方があまりにも違っていていると、他のメンバーの理解にコストが掛かってしまいます。そのため、チーム開発においてあまり個性を出しすぎることは非推奨のようです。） そのため技術の勉強に加えて、プロジェクトの ソースコード を読み込んで コーディング規約は何をベースにしているのか ロジックはどこに書いたらいいのか 変数のスコープは適切なのか 細かいところだと、クラスやメソッドにはどういったネーミングが推奨されているのか などを理解する事に時間設けるよう調整しました。 それらを理解することで、 実装時に思考時間が減り、作業量・作業スピードが向上した 設計から行う実装も既存のリソースを参考にし、検討できるようになった 携わったことのないライブラリの改修もある程度理解できるようになった など、メリットは数知れずです。 もちろん既存の実装をそのまま鵜呑みにする必要はありませんが、 思うように仕事が進まない🤦。。。 と思ったらまずは自社のプロジェクトの ソースコード を読み、 それを参考にコードを書いてみるといいかもしれません。 おわりに 今回は、1年目に携わったプロジェクトの経験から、2年目の私の振り返りをまとめさせていただきました。 大きく2つ「エンジニアが本当にやるべきこと」と「プロジェクト理解の大切さ」を得られたことについてご紹介しました。 最初の1年でこれからエンジニアとして生きていく上で必要な心構えを理解できたいい機会だったと思います。 次回からは、今年度入社の新卒のメンバーのアウトプットや取り組みにについてもご紹介できたらと思います。 最後までお読みいただき、ありがとうございました。 以上、KTがお送りいたしました🙇。

はじめまして。この度、レバレジーズもテックブログをはじめることになりました🙋。 記念すべき1エントリー目を担当させていただく事になりました。KTです。 初回ということで、簡単にレバレジーズについてと、私の所属チームの紹介をさせてください。 レバレジーズについて オフィスイメージ レバレジーズは、主に人材領域で事業を拡大してきました。 エンジニア・看護師・介護福祉士・フリーターの方々への転職支援サービスや、 エンジニアの為のQ&Aサービスである、teratailなどを運営しております。 年間で10数個、様々な新規事業を創り、海外にも展開をしていく。そんな会社です。 ※1 基本的にオールインハウスでプロジェクトを制作しており、制作、営業とマーケに精通した人材が社内にいる ことで、コミュニケーションコストと社内での知の蓄積と共有ができるということが弊社の強みだと思います。 このブログでは、プロジェクトに関する知識を技術者以外の立場の職種からもご紹介していきたいと思います。 所属チームについて 所属チームについても、簡単に紹介させてください。 私のチームは医療・介護領域を担当しています。 内訳としてはエンジニアとデザイナー合わせて約20名ほどで4つのサービスの企画開発を行っております。 （2018/07/12 現在） その他にも、それぞれのサービスにマーケターがついて施策の検討や分析を行っております。 今年はエンジニアの新卒もチームに4人配属が決まり、だいぶ大所帯になりました。 社内で使われている言語はPHPがメインですが、技術選定に関しては各チームに任せられています。 そのため、フレームワークや、アーキテクチャなどはチームごとに選定しております。 私たちのチームでは、バックエンドにPHPフレームワークであるLaravelを利用し、フロントにVue.jsを採用しております。 アプリケーションの開発以外にも、分析基盤を活かした機械学習なども行っております。 ざっくりとですが、以上が会社の概要と私の所属するメディカルチームの紹介になります。 ブログでは、各チームごとにレバレジーズの開発やプロダクトについて発信していきたいと思います。 今後とも、よろしくお願いいたします💁! ※1 syukatsu-pro.com