はじめに こんにちは。 ラク スエンジニアのstrongWhiteです。今回は8月に 京都アジャイル勉強会 に行ってきましたのでレポートしようと思います。 アジャイル とは、要求仕様の決定や変更に対して、柔軟に対応するためのソフトウェア開発手法のことです。昨今有名になりつつある アジャイル ですが私としても興味がありましたので今回勉強会に参加してみました。 ※この記事では アジャイル に関する詳細な説明は省きます。 アジャイル ・ スクラム を初めて聞く方は馴染みのない用語が出てきますがご了承ください。 京都 アジャイル 勉強会とは アジャイル ・ スクラム を実践しようとしている（もしくは実践中の）人を対象とした勉強会で、自身（あるいは自社）が抱えている アジャイル ・ スクラム に関する疑問、不安などをざっくばらんに議論し、お互いに理解を深め合う会です。ちなみに私が行ってきたのは以下の勉強会です。 connpass.com 私の所属するチームでは アジャイル ・ スクラム を取り入れた開発をしているので、今回は アジャイル ・ スクラム を実践する中で私が抱えている疑問や不安を勉強会に参加されている皆さんにぶつけてみることにしました。 学んだこと ディスカッション形式の勉強会は初めてだったので新鮮でした。また、 アジャイル ・ スクラム に対する理解も少しながら進んだ気がしました。私としては日々 スクラム ・ アジャイル を実践する中で プロダクトバックログからスプリントバックログを出すまでに時間がかかり次のスプリントが始められない という課題を抱えていたのですが、今回の勉強会でとある方から「見切り発進的に次のスプリントを始めるのはよくないので、時間がかかってもいいから全てのスプリント バックログ を出してから次のスプリントをスタートすべき」という助言をいただき、少し勇気をもらえました。 終わりに 今回のようなディスカッション形式の勉強会は講義形式のお堅い感じは全くないので私としてもリラックスして受講できました。機会があればまた アジャイル ・ スクラム 系の勉強会に参加したいと思います。チームとしても私としてもまだまだ アジャイル ・ スクラム を始めたばかりなので、また疑問が出てきたらこういう勉強会の場で解消していこうと思います。 参考 アジャイル開発 京アジャ

こんにちは、MasaKuです。 ビッグデータ という言葉をよく目にしますが、その背後にある技術についてはあまり理解していませんでした。 そこで、 ビッグデータ を支える技術のひとつであるNoSQLについて興味が生まれたので、今回の記事では、NoSQLについて勉強した結果についてまとめようと思います。 （本記事の執筆には以下の書籍を参考にさせていただきました） NOSQLの基礎知識 ビッグデータを活かすデータベース技術 はじめに NoSQLとは RDBとの違い NoSQLに期待すること NoSQLのデータモデル キーバリュー型 カラム指向型 ドキュメント指向型 グラフ型 おわりに 参考文献 はじめに 現在、 Twitter は、１日あたり１０テラバイトを超えるデータを扱っているそうです。 10テラバイトというと、書籍一冊のデータ量（５０万文字）とすると書籍１０００万冊分に相当します。 モバイルデ バイス からも簡単にアクセスして写真や動画コンテンツを発信できる Webサービス が普及してきたことが ビッグデータ の発生の起因のひとつになったと言えるでしょう。 ビッグデータ の対応には3Vという以下のような特徴があります。 Volume（膨大な量） Velocity（速さ） Variery（多種多様） 今後、更にリッチな情報を扱う Webサービス が普及してくると、 ビッグデータ を処理する技術がますます重要になることから、NoSQLの技術発展が期待されます。 NoSQLとは PostgreSQL や MySQL などの RDB では対処しづらいような ビッグデータ に対応すべく生み出された技術で、 SQL を使用しないということが特徴です。 「Not Only SQL 」の略であり、「 SQL だけでなく、新しいデータベースの技術も利用する必要があるというムーブメントのことである」と多くの方に認識されています。 しかし、「NoSQLとはズバリこういうこと！」という定義についてはまだ明確化していないようです。 NoSQLとして代表的なものには、 Google の BigTable 、アマゾンの Amazon DynamoDB などがあります。 RDB との違い NoSQLと RDB との違いについて以下にまとめました。 機能は豊富ではない データの整合性が緩い 結果整合性でよいという考え NoSQLでは、 RDB で当たり前に利用できるJOIN（結合）が通常はサポートされていません。 また、同時実行制御（ 排他制御 ）を成立させる トランザクション の機能が緩められており、データの整合性よりも、大量のデータを素早く処理することを優先しているという特徴があります。 NoSQLと RDB の特性の違いを説明する上で重要な「 CAP定理 」という定理があります。 分散型データベースシステムにおける三大要件として以下が存在します。 Consistency（整合性）…常に同一のデータを参照する Availability（可用性）… 常に読み出しと書き込みができる Partition Tolerance（分断耐性）…ネットワークが分断されても間違った結果を引き起こさない 分散型データベースシステムでは、上記の3つのうち最大２つしか満たすことができない、というのがCAP定理です。 CAP定理 RDB にはACIDという特性が存在し、 トランザクション が信頼性をもって実行されるための必要条件を定義されています。 一方、BASEというものも存在し「アプリケーションは常時稼働し、常に整合性を保つ必要はないが結果的に整合性がとれる状態に至るという特性を備えているべき」という考え方があります。 CAP定理の提唱者であるEricBrewer氏は以下のように説明してます。 システムに整合性（C)と分断耐性（P）が求められる場合には、AICD特性を完備しなければならない。 だが、整合性（C）よりも可用性（A）と分断耐性（P）が求められるのであれば、そのシステムはBASEの特性を持つべきである。 RDB はCA（整合性と可用性）に分類され、ほとんどのNoSQLデータベースがCP（整合性と分断耐性）かAP（可用性と分断耐性）に分類されます。 RDB とNoSQLでは期待している性能が異なることから、NoSQLが RDB を完全に代替するものではないことがわかります。 NoSQLに期待すること NoSQL全般には以下のような要件を満たすことが期待されています。 一台のサーバには収容できないほど膨大なデータを扱う データを複数のサーバに分割して割り当てる 高価なハードウェア等ではなく、安価な汎用ハードウェアの上で稼働する データに紛失がなく、データは安全な状態に格納されている システム全体としては、いつでも使える状態にある 障害が発生しても短時間で復旧できる リアルタイムに近い応答性能を備えている また、データを高速に処理する上で、高度なデータベースチューニングの技術を必要としないことも特徴です。 データのサイズや形式が頻繁に変化するようなアプリケーションを RDB でデータを高速で処理し続けるためには、データベース設計に対する高い技術力を持ったエンジニアが常時対応しなければなりません。 これまでの RDB では十分な性能が得られなかったり、 RDB で実現しようとすると、構造が複雑になり、コストがかかりすぎるという問題を回避するための手段としてNoSQLが選択肢の一つとなりうることが期待されます。 NoSQLのデータモデル NoSQLには様々なデータモデルが存在します。 キーバリュー型 キーバリュー型 RDB のようなテーブルや関係性を定義せず、キーとバリューという組み合わせからなるシンプルなデータモデルです。 データが増えるにつれて表が縦の方向に伸びていくイメージです。 データモデルが単純であることからデータを容易に分割可能なことから、スケールアウトに最適なのが特徴です。 カラム指向型 カラム指向型 上記のキーバリュー型にカラムの概念を持たせたデータモデルです。 行に付与されたキーが複数のカラムを持つことができます。 カラム数は RDB のように固定ではなく、動的に追加していくことができます。 RDB を利用していると異質に思えるかもしれませんが、ほかの行には存在しないカラムを持つ行を作ることができます。 ドキュメント指向型 ドキュメント指向型 JSON や XML 形式で記述されたドキュメントの形でデータを管理することができます 各ドキュメントは階層構造を持たず、相互の関係を横並びに管理します。 RDB のように固定されたデータ設計が不要なことから「 スキーマ レスである」と言われます。 私はドキュメント指向型の説明を読んだ際、上記のカラム指向型との違いを明確に認識することができていませんでしたが、以下のようなものなのだと理解しました。 ドキュメント指向型の例 ブログの投稿履歴とメールの送信履歴をドキュメント指向型データベースに記録したとします。 これらは全く異なる性質のデータですが「投稿日と送信日が2018/9/18のデータ」と指定することで、関係するデータが取得できます。 このようなデータの性質が異なるものや、これまで取得していたデータの形式が唐突に変わってしまうような対象でも、ドキュメントの形式でデータベースに格納し、データを処理できるようにするのが オブジェクト指向 型のデータベースの特徴なのだと思いました。 グラフ型 グラフ型 データとデータ感のつながりを管理できるデータモデルです。 グラフ型のデータベースには以下の構成で表現されます。 ノード リレーションシップ プロパティ 例えば、 FaceBook の友達関係をグラフ型で表現すると以下のようになります。 Aさんというアカウントが存在します（ノード） AさんはBさんと関係があります（リレーションシップ） AさんとBさんは友達同士です（プロパティ） この基本構造を拡張していくと「Aさんの友達であるBさんの友達」や「Aさんと友達になってから3年以上経過したアカウント」といった検索も可能になります。 おわりに いかがでしたでしょうか。 筆者も、MongoDBというドキュメント指向型NoSQLを利用して簡単なWebアプリケーションを作ってみましたが、NoSQLについて調べて見ると様々なデータモデルが存在することがわかりました。 それぞれのデータモデルごとの強みが光るようなWebアプリケーションの特性についても今後調べていきたいと思いました。 参考文献 NOSQLの基礎知識ビッグデータを活かすデータベース技術 NoSQL - Wikipedia ブリュワーのCAP定理～データストレージの選定基準 - 浜村拓夫の世界 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

id:radiocat です。9/13に東京オフィスで開催したMeetupに登壇し「終わらない スクラム 」というタイトルで発表しました。今回のイベントを通じて、私たちが継続して スクラム に取り組んでいくうえでの様々な気づきを得ることができたので、それらを5つの学びとして記事にまとめてみました。ご参加頂いたみなさま、ありがとうございました。 rakus.connpass.com 発表の概要 発表の前半は私たちのチームが取り入れた アジャイル 開発のプ ラク ティスの説明で、今年3月の社内イベントで発表した内容がベースとなっています。それらの概要は以前のブログ記事にまとめていますのでご参照ください。 tech-blog.rakus.co.jp 発表の中盤からは開発を少しずつ アジャイル にし、やがて スクラム にチャレンジしていくために私たちが参考にした書籍やネット上の情報を紹介しました。そして後半部分では、現在のプロジェクトでも引き続き スクラム で開発を進めている中で新たに取り組んでいることを紹介しました。 speakerdeck.com 5つの学び 発表後の懇親会では参加者の方々からたくさんフィードバックを頂いて、それぞれの現場で実践している スクラム の取り組みなども教えていただき、とても有意義なイベントにすることができました。頂いたフィードバックも交えて、5つの学びをご紹介します。 1. 役割に徹することができる体制で スクラム を始める 私たちの スクラム チームではプロダクトオーナー（以下PO）をデザイン部門のメンバーが担っています。 その理由は大きく2つです。 開発チームは大阪、POのデザイン部門と ステークホルダー の事業部門は東京が拠点 BtoBのサービスであるため、デザイン部門はデザインの作り込みよりもUI/UXをしっかり検討することが求められる この話をした時に、「（上記の体制を書いた）スライドを見た時にそうだと思った」というフィードバックを頂きました。 スクラム チームの中で誰がPOや スクラム マスター（以下SM）を担当するかは スクラム に取り組むうえでの最初の難題の1つです。チームの中で誰がその役割を担えばその役割に徹することができるのかをしっかり問いかけて決める必要があります。 役割に徹することができない体制で スクラム を始めていたら恐らく失敗していました。世の中的に複数拠点やリモートワークを絡めたメンバー構成は当たり前となっていますし、それぞれの現場に合わせて最適な体制を考える必要があります。 ちなみに、今回の体制の場合は開発部門におけるリーダーという立場の私がSMを担うことがもう1つの課題になりました。 開発チームが機能するために組織としての役職が邪魔になることもあれば、うまく活用してチームを支援できることもあり、それらをうまく使い分けることも役割に徹するために必要なことです。 2. スプリントの期間は1週間がおすすめ 今回の発表で取り上げた開発プロジェクトでは2週間のスプリントで スクラム を始めましたが、現在はスプリントの期間を1週間にしています。 同様に1週間でスプリントを回している人から「1週間じゃないとスプリントを回すのは無理」というフィードバックをもらいました。大きな理由は以下の2点です。 スプリントの最初に2週間分のタスクを洗い出してプランニングするのが大変 2週間先の見込みを見極めるのが大変 私たちも慣れた今となっては1週間が最もやりやすく感じています。 チームの事情にもよりますが、スプリントの期間をどのくらいの長さにするかもまた スクラム に取り組む上での課題の1つです。私たちが最初にスプリントの期間を決めた当時は他のプロジェクトに稼働を使うメンバーもいたため2週間ぐらいがちょうど良いと判断しました。また、当時は1つのタスクの粒度を小さくする事に慣れておらず、1週間スプリントで大きな粒度のタスクの実行に想定外の時間がかかってしまうとあっという間にスプリントの終わりを迎えてしまう恐れも感じていました。しかし、今となっては1週間スプリントならうまくいかなくても改善して次に活かせば良いという感覚のほうが大きいです。 3. リファインメントと技術的スパイクの大切さと難しさ 次のスプリントに向けて バックログ を準備するリファインメントや技術的スパイクの活動は スクラム イベントとしては定義されていませんが、非常に重要でかつチームでルールを決めるのが難しい活動です。私達のチームではリファインメント会議をイベント化して強制的に時間を取るようにしています。 これについても同様にルールを決めて時間を取っているチームもあるというフィードバックを頂きました。やりかたはチームによっていろいろあるようでしたが、いずれにしてもプランニングまでに バックログ をきちんと準備できていなければ、スプリントはうまく回らないというのが共通の理解です。 ちなみに、現在私たちのチームでは1スプリントに2種類のリファインメント会議を実施しています。 開発チーム内リファインメント会議：技術的スパイクの状況確認や認識合わせが中心 スクラム チーム全体リファインメント会議： バックログ の整理と内容の認識合わせが中心 その理由は主に以下の3点です。 現在取り組んでいるプロジェクトの特性として技術面での不確定要素が多い 開発チームの人数が増えてきたため全体共有や認識合わせの場があったほうが進めやすい POと開発チームの拠点が別れているため時間を決めて実施したほうが進めやすい いずれも私たちのチームの事情によるものですが、これらを踏まえてリファインメントや技術的スパイクはそれぞれのチームでやりかたを考えて取り組む必要がある活動だと感じています。 4. チームの人数が増えるにつれて スクラム は難しくなる 私達のチームはメンバーが10人を超えたためスケールアウトを検討し始めています。 これに関連してチームのメンバーが9人いるという人からもフィードバックをもらいましたが、デイリー スクラム を時間どおりに終わらせるだけでも難しく、人数が増えると スクラム は難しくなると感じています。私たちのチームでも、スライドに書いてあるとおり スクラム ・オブ・ スクラム 、LeSS、 Nexus といった大規模 スクラム の事例を調査して検討をしていますが、事例自体があまり多くないのでまだ具体的な判断は下せていません。 ただ、スライドの下に書いてある「若手メンバーのミニ スクラム 」を試す期間で、一時的にメインのプロジェクトのメンバーを5人にしたところベロシティが上がってスプリントを以前よりうまく回せるようになったので、やはり5人ぐらいがちょうど良いという感覚も得ています。 5. チームの育成と成長は熱意を持って根気強く 上記の「若手メンバーのミニ スクラム 」や、以前このブログでも紹介した「 スクラム クイズ」に関しては良いフィードバックを頂きました。 チームのメンバーひとり一人がきちんと スクラム に向き合わなければ スクラム をうまく回すことが難しくなります。フィードバックの中でその点に課題を持っているチームの話もいくつか聞くことができましたが、チームの中で熱意をもって進められるメンバーがいないと スクラム を続けていくのは難しいと感じました。 我々もまだまだ試行錯誤しながら様々な取り組みを行っているところですが、そのためにも他のチームの事例や課題はとても参考になります。そういう意味で、今回のイベントではたくさんのフィードバックを頂き、私たち自身の新たな学びを得ることができました。 この学びをまたチームに持ち帰ってさらに スクラム を前進させていきたいです。 スクラム の習得はまだまだ終わりそうにありません。 今回のイベントをきっかけに当ブログに「終わらない スクラム 」というカテゴリを作りました。今後も スクラム の取り組みで得たことを随時発信していきたいと考えていますので、引き続きチェックして頂けますと幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは。開発エンジニアのd_ shr ( id:d_shr )です。 これまではNode.jsや PostgreSQL について書いていましたが 今回はIoTを支える 通信プロトコル MQTT についてまとめます。 tech-blog.rakus.co.jp tech-blog.rakus.co.jp はじめに 軽量で省電力 メッセージングとTopic メッセージング Topic MQTTの機能 QoS Retain Will まとめ はじめに MQTT は、Publish/Subscribe モデルのメッセージングにより、非同期に1対多の通信ができる プロトコル です。 シンプルかつ軽量に設計されているため、機械同士が通信を行いやり取りするM2M (Machine-to-Machine) や 家電や自動車など多種多様な「モノ」が通信を行いやり取りするIoT (Internet of Things) を実現するのに適した プロトコル と言われています。 軽量で省電力 HTTPと比較すると、軽量で省電力な プロトコル です。 MQTT のヘッダサイズは２バイト〜とHTTPに比べるとかなり軽量になっており その軽量さからバッテリーが限られているモバイル通信に適しています。 メッセージングとTopic メッセージング MQTT はPub/Subモデルでメッセージングを行います。 Pub/Subモデルではメッセージの送信者をPublisher、メッセージの受信者をSubscriber、メッセージの仲介をするのがBrokerです。 Publisher はメッセージをBrokerへ送るとき、送ったメッセージがどの Subscriber に届くのかなど気にする必要はありません。 Subscriberはメッセージがどの Publisher から送られて来たのか知ることなく欲しいメッセージをBrokerから受け取ります。 Topic MQTT では、Topicと呼ばれるキーを用いてメッセージングを行います。 トピックは「/」で区切られた階層構造になっています。 例：japan/osaka PublisherはTopicを指定してメッセージを送信し、Subscriberは受信したいトピックをfilterとして指定することで、欲しいメッセージだけを手に入れることができます。 MQTTの機能 QoS MQTT ではメッセージごとに到達保証に関する QoS (サービスの品質)を指定します。 QoS0 メッセージは最高 1 回 配信される メッセージが 送信先 に届くかは保証されない QoS1 メッセージは最低 1 回 配信される メッセージが 送信先 に届くことが保証されるが重複して届く可能性がある． QoS2 メッセージは正確に 1 回 配信される メッセージが過不足なく 1 回のみ到着することが保証される． Retain Topicごとに最後にPublishされたメッセージをMQTTサーバが保持しておく機能。 MQTT はPub/Subモデルなので、PublishしたときにSubscribeしていたクライアントにしかメッセージは送信されません。 具体的には、10分ごとに更新される情報を得るために新しくSubscribeしても，最長10分間はなにも情報が得られないことになります。 しかし、Retain機能を使うとその時点での最新の情報が得ることができます。 Will Publisherが切断されてサーバとの通信ができなくなったときに 指定されたTopicとメッセージをSubscriberに送信する機能。 予期せぬ切断などが発生したときに、SubscriberはPublisherが切断されていることを判断できます。 まとめ IoTを支える プロトコル MQTT について簡単にまとめてみました。 世の中にIoTが広がってきているので、それに関連した技術は追っていきたいと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

ラク スは「 IT技術 で中小企業を強くします！」をミッションに掲げ、 メール共有・管理システムのメールディーラーから始まり、経費精算システムの楽楽精算に至るまで、 延べ40,000社を超えるお客様に自社開発した クラウド サービスを提供してきました。 今回（9/13(木)）は、 ラク スで主力 クラウド サービスの開発を牽引するエンジニアによる トーク セッションと交流会を開催します。 クラウド サービス開発のエンジニアとして活躍している方はもちろん、 クラウド サービス開発にご興味をお持ちのエンジニアの方も気軽にご参加頂ければと思います。 自社開発ならではの技術・運用ノウハウや、新しい取り組みの成果や失敗談など ご参考にして頂ける情報を積極発信していきたいと考えております。 このイベントが新しい気づきや成長につながる機会を提供する場になるとともに、 ラク ス社員と参加者の皆さま、また参加者の皆さま同士で新たなつながりが生まれるきっかけになれば幸いです！ 開催概要 【日時】2018/9/13(木) 19:30～21:30(開場は19:00) 【会場】 ラク ス 東京本社 （〒151-0051 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス] ） 【定員】30名 【申込み】 connpass 【参加費】無料 【主催】 ラクス 今回の トーク テーマ 終わらない スクラム 　～楽楽精算のサービス拡大を支える スクラム 開発の取り組み 大塚正道（おおつかまさみち） ラク スでは、まだ多くの開発チームが ウォーターフォール 型の 開発プロセス を採用していますが、 一部のチームで スクラム による アジャイル 開発に取り組んでいます。 今回は楽楽精算チームでの取り組みを紹介します。 実際にやってみると様々な問題が発生しました。問題解決に向けたアクションや取り組みを通じて得た知見、今後の課題等を事例を交えてお話しします。 テッ クリード （自称）としてのやっていき！　～ iOS アプリ開発 チームを率いて 川並裕（かわなみゆう） 若手エースエンジニアが初めての iOS アプリ開発 でテッ クリード として奮闘したお話しです。 iOS アプリ開発 は、自身も初、メンバーも初、しかも短納期（3ヵ月．．．）。 この デスマーチ を予感させる不利な条件下で、テッ クリード としてどのようにチームをリーディングしたのか。 様々な事例を交えてご紹介します。 流行の開発手法ChatOpsとは　～楽楽明細チーム/ChatOpsでルーティン作業をまるごと自動化～ 三田英一（みたえいいち） Jenkinsの導入で自動化が進んだけど、「Jenkinsを毎回開くのは面倒」、「アカウントの作成も面倒」、「非エンジニアに使ってもらうにはちょっとハードルが高い」。 そこで導入したのがChatOps! Slack互換のチャットツール「Mattermost」でルーティン作業を丸ごと自動化しました。 利用した bot ツール、システム構成、Hubot スクリプト の実例など、ノウハウを余すことなくご紹介します。 タイムテーブル 19:00 開場・受付開始 19:30 イベントスタート 21:30 終了予定 トーク が終わり次第、交流会に移ります。 交流会では、フィンガーフード、ドリンクをご用意致します。 お気軽にご参加ください。 エントリー方法 [connpass] よりエントリーをお願いします。 ※当日はお名刺2枚ご持参ください ※提供可能な設備： Wi-Fi 、電源 会場 ラク ス　東京オフィス2F セミ ナールーム 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス]

はじめに こんにちは sts -250rrです。 前回の記事ではARをテーマに記事を投稿いたしました。 今回はテーマをガラリと変えまして「 機械学習 」について簡単にまとめてみようと思います。 昨今、 AWS の Amazon Machine Learningや Microsoft のAzure Machine Learning Studioなどで手軽に 機械学習 を利用できるようになって来たことに加え、 楽楽精算では、 iOS 向けに領収書のアップロードができるアプリをリリースしました。 楽楽精算 株式会社 ラク ス ビジネス 無料 このアプリでは 機械学習 系技術の1つである OCR （Optical character recognition）を用いて領収書データを読み取り、楽楽精算にアップロードしています。 世間的にも話題かつ、 ラク スでも 機械学習 に注目していることもあり、 良いタイミングなので 機械学習 について整理してみようということです。 今回は簡単に 機械学習 とは といった話から、 機械学習 を行うツールを使って 機械学習 を体験してみた内容をまとめていきます。 機械学習 とは？ はじめに、 Wikipedia では 機械学習 についてこう書かれています。 機械学習 （きかいがくしゅう、英: machine learning）とは、 人工知能 における研究課題の一つで、人間が自然に行っている学習能力と同様の機能をコンピュータで実現しようとする技術・手法のことである。 つまり、 人工知能 を実現する手段が 機械学習 という事です。 さらに Wikipedia を読み進めていくと概要にこう記載されています。 センサやデータベースなどから、ある程度の数のサンプルデータ集合を入力して解析を行い、そのデータから有用な規則、ルール、知識表現、判断基準などを抽出し、 アルゴリズム を発展させる。なお、データ集合を解析するので、 統計学 との関連が深い。 とあるように、実は 機械学習 は 統計学 と深い関連を持っています。 統計学 は、大量に得られたデータの性質や規則性、分類を見つけるような学問ですが、この 性質や規則を見つける事 が 機械学習 にとっての学習になるわけです。 機械学習 の種類 機械学習 について少し掘り下げていきます。 単純に 機械学習 といっても、大きく分けて「 教師あり学習 」と「 教師なし学習 」が存在します。 それぞれに学習方法やできることが異なりますので簡単にまとめていきます。 教師あり学習 学習に使用するデー タセット に対して、正解を与えておく学習方法です。 この学習では、大量のデー タセット から正解の情報を学習し、「ある特徴を持つものは、ある事柄に対して正解である」ことを判断できる学習方法です。 簡単な例だと、「赤い色という特徴を持つ果物」が「美味しい」と判断することができます。 しかし、正解として「美味しい」か「美味しくないか」のみを学習させているため、「赤い色という特徴を持つ果物」が「美しい」かは判断することはできません。 教師あり学習 を行う方法には次のようなものがあります。 線形回帰 ロジスティック回帰 ナイーブ ベイズ k近傍法 ニューラルネットワーク 教師なし学習 教師あり学習 とは反対に、学習に使用するデー タセット に対して、正解は与えません。 この学習は、大量のデータの類似度や規則性を学習し、データの分類を行います。 簡単な例だと、ある果物のデータを大量に集めてくると3つに分けられました。 機械自身には分けられたデータが何を示すものであるかはわかりませんが、次にデータが得られた時、3つのうちどこに該当するデータであるかを判断することができるようになります。 教師なし学習 を行う方法には次のようなものがあります。 主成分分析 k平均法 ディープラーニング 強化学習 *1 機械学習 を試してみる 言葉のみでは腑に落ちない部分もあるので実際どのように学習しているのかを試してみたくなりました。 そこでweka *2 というフリーの 機械学習 ツールを使っていきます。 (今回、wekaの使い方については特に説明いたしませんので悪しからず。。。) 今回は 教師あり学習 に「ロジスティック回帰」、 教師なし学習 に「k平均法」による クラスタリング を使っていきます。 これらの手法については下記の記事で詳細が紹介されていました。 qiita.com qiita.com お試し1： 教師あり学習 wekaのサンプルデータであるアヤメの品種分類データiris.arffを使っていきます。データの内容は以下の通りです。 クラス(正解):setosa, versicolor, virginica 特徴量(属性) - sepallength : がくの長さ - sepalwidth : がくの幅 - petallength : 花弁の長さ - petalwidth : 花弁の幅 上記のデータを持った150のデー タセット とロジスティック回帰を使って学習をさせてみました。 しかし、学習をさせるだけでは意味がありません。 学習の成果を見るために、10分割交差検定を用いて判別制度を見ていきます。 wekaならここまでやってくれるのでお手軽です。 検証結果の抜粋です。 === Stratified cross-validation === === Summary === Correctly Classified Instances 144 96 % Incorrectly Classified Instances 6 4 % Kappa statistic 0.94 Mean absolute error 0.0287 Root mean squared error 0.1424 Relative absolute error 6.456 % Root relative squared error 30.2139 % Total Number of Instances 150 === Detailed Accuracy By Class === TP Rate FP Rate Precision Recall F-Measure MCC ROC Area PRC Area Class 1.000 0.000 1.000 1.000 1.000 1.000 1.000 1.000 Iris-setosa 0.920 0.020 0.958 0.920 0.939 0.910 0.970 0.933 Iris-versicolor 0.960 0.040 0.923 0.960 0.941 0.911 0.975 0.933 Iris-virginica Weighted Avg. 0.960 0.020 0.960 0.960 0.960 0.940 0.982 0.955 学習による全体の判別制度96%、 それぞれの正解に正しく判別することができる確率が Iris-setosa : Iris-versicolor : Iris-virginica = 100％ : 95% : 92% という結果が得られました。 テストデータということもありなかなかの好成績ですね。 お試し2： 教師なし学習 教師あり学習 と同じようなデータで試してみます。 ただし、 教師なし学習 では正解データは必要ないため削除しておきます。 今回はk平均法による クラスタリング を行ってみました。 元データが3種に分類されていたので3 クラスタ に分類されるように設定しました。 テストデータとはいえ、綺麗に分類されるわけではなさそうですね。。。 ここで綺麗に分類するような学習ができれば、新たなデータを得た際にどこに分類するかを判別できるようになるわけですね。 かなりざっくりですが、数値や画面をみて少しだけイメージできました。 まとめ 今回は 機械学習 について簡単にまとめてみました。 しかしながら、この記事の内容は 機械学習 の表面をなぞった程度でしかありません。 今回のような内容をしっかり把握しておらずとも、はじめに述べたような Amazon Machine LearningやAzure Machine Learning Studioを利用することで簡単に 機械学習 は利用可能な世の中になりつつあります。 ただし、効率よく 機械学習 を取り入れるためにも、どんな方法が何に適しているのかは知っておくべきでしょう。 次回は今の 機械学習 の流行りをテーマに投稿してみようかと思いますのでお楽しみに。 *1 : 教師あり学習 、 教師なし学習 と同じレイヤーで分けられる場合もあります。 *2 : https://www.cs.waikato.ac.nz/ml/weka/

ラク スは「 IT技術 で中小企業を強くします！」をミッションに掲げ、 メール共有・管理システムのメールディーラーから始まり、経費精算システムの楽楽精算に至るまで、 延べ40,000社を超えるお客様に自社開発した クラウド サービスを提供してきました。 今回（9/13(木)）は、 ラク スで主力 クラウド サービスの開発を牽引するエンジニアによる トーク セッションと交流会を開催します。 クラウド サービス開発のエンジニアとして活躍している方はもちろん、 クラウド サービス開発にご興味をお持ちのエンジニアの方も気軽にご参加頂ければと思います。 自社開発ならではの技術・運用ノウハウや、新しい取り組みの成果や失敗談など ご参考にして頂ける情報を積極発信していきたいと考えております。 このイベントが新しい気づきや成長につながる機会を提供する場になるとともに、 ラク ス社員と参加者の皆さま、また参加者の皆さま同士で新たなつながりが生まれるきっかけになれば幸いです！ 開催概要 【日時】2018/9/13(木) 19:30～21:30(開場は19:00) 【会場】 ラク ス 東京本社 （〒151-0051 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス] ） 【定員】30名 【申込み】 connpass 【参加費】無料 【主催】 ラクス 今回の トーク テーマ 終わらない スクラム 　～楽楽精算のサービス拡大を支える スクラム 開発の取り組み 大塚正道（おおつかまさみち） ラク スでは、まだ多くの開発チームが ウォーターフォール 型の 開発プロセス を採用していますが、 一部のチームで スクラム による アジャイル 開発に取り組んでいます。 今回は楽楽精算チームでの取り組みを紹介します。 実際にやってみると様々な問題が発生しました。問題解決に向けたアクションや取り組みを通じて得た知見、今後の課題等を事例を交えてお話しします。 テッ クリード （自称）としてのやっていき！　～ iOS アプリ開発 チームを率いて 川並裕（かわなみゆう） 若手エースエンジニアが初めての iOS アプリ開発 でテッ クリード として奮闘したお話しです。 iOS アプリ開発 は、自身も初、メンバーも初、しかも短納期（3ヵ月．．．）。 この デスマーチ を予感させる不利な条件下で、テッ クリード としてどのようにチームをリーディングしたのか。 様々な事例を交えてご紹介します。 流行の開発手法ChatOpsとは　～楽楽明細チーム/ChatOpsでルーティン作業をまるごと自動化～ 三田英一（みたえいいち） Jenkinsの導入で自動化が進んだけど、「Jenkinsを毎回開くのは面倒」、「アカウントの作成も面倒」、「非エンジニアに使ってもらうにはちょっとハードルが高い」。 そこで導入したのがChatOps! Slack互換のチャットツール「Mattermost」でルーティン作業を丸ごと自動化しました。 利用した bot ツール、システム構成、Hubot スクリプト の実例など、ノウハウを余すことなくご紹介します。 タイムテーブル 19:00 開場・受付開始 19:30 イベントスタート 21:30 終了予定 トーク が終わり次第、交流会に移ります。 交流会では、フィンガーフード、ドリンクをご用意致します。 お気軽にご参加ください。 エントリー方法 [connpass] よりエントリーをお願いします。 ※当日はお名刺2枚ご持参ください ※提供可能な設備： Wi-Fi 、電源 会場 ラク ス　東京オフィス2F セミ ナールーム 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス]

はじめに こんにちは、 @rs_tukki です。新卒2年目です。 前回の記事は以下をご覧ください。 tech-blog.rakus.co.jp また、以前に書いた記事がじわじわアクセス数伸びてきているみたいです。ありがとうございます！ tech-blog.rakus.co.jp さて、本題に入りましょう。 社会人として2年目に入り、テストの結果を資料にまとめたり、バグ修正の対応方針を伝えたりと、自分のやったことを先輩や上司に報告、発表する必要性が増してきたように思います。 自分は今まであまり説明やら発表やらが好きではなかったのですが、今では得意というほどではないにしろ、徐々に苦手意識はなくなってきました。 今回は、エンジニアとして必須スキルである説明や発表の苦手意識を取り払うための1つの手段、 LT についてのお話です。 はじめに Lightning Talks(LT)とは？ 何故LTが有効なのか 「説明する」という行為の練習になる 色んな技術の知見が得られる 人と繋がる機会になる まとめ 参考 Lightning Talks(LT)とは？ ではまず、 LT とは何でしょうか？ 困ったときの Wikipedia 先生。 ライトニング トーク （英: Lightning Talks）とはカンファレンスやフォーラムなどで行われる短いプレゼンテーションのこと。様々な形式があるが、持ち時間が5分という制約が広く共有されている。 形としてのライトニング トーク は1997年の Python カンファレンスで初めて行われたとされている。[1]その時点では単に「ショート トーク 」と呼ばれていた。「ライトニング（Lightning：稲妻、電光石火）」という言葉が用いられるようになったのは、2000年6月に行われた YAPC 19100 Conferenceからとされている。[2]その後技術的なカンファレンスに於いて、この言葉が浸透するようになっていった。 LTというのは簡単に言えば短いプレゼンのことです。 プレゼンテーションというと、会社内では新しい企画の説明会、会社外では新商品の発表会…などなど、どちらにしても1時間以上は時間をかけてじっくりと話すイメージがあるかと思います。 ですが、LTは「稲妻 トーク 」という意味からも分かる通り、持ち時間はだいたい5分、長いものでも10分とごくわずかです。 LTの内容自体はある程度のテーマこそ指定されるものの、技術的な トーク に限定されないことも多く、皆さん限られた時間の中で自分の好きな話を自由に発表しています。(そして勉強会などでない限りは大体お酒がついてきます) connpass 等の募集サイトでも頻繁にLT会が開催されていたりします。 reedex.connpass.com connpass.com engineers.connpass.com 何故LTが有効なのか 最初に、LTとは 説明や発表の苦手意識を取り払うための1つの手段 と説明しました。 LT…というより発表自体に苦手意識のある人にはハードルが高いかと思いますが、それでも私としては、社内、社外問わず新卒のうちからぜひLTに登壇してみてほしいと思っています。 「説明する」という行為の練習になる LTの特徴は、何と言ってもその短さです。 「長い時間話すのに耐えられない」「目を合わせられない」という人でも、大体5～10分経ってしまえば強制的に終了ですから、割と失敗しても恥ずかしくないです。 社外のLTでヤジが飛ぶのが怖い…という人もいますが、大抵社外のLTは Twitter で実況されるので見ている人もヤジを飛ばしている余裕はないと思います(笑)。 togetter.com そんな環境の中で、自分が学んだことや気になっていることを短い時間で発表することで、資料の作成に慣れ、分かりやすい伝え方に慣れ、いずれは社内で人に説明することにも慣れていけるのではないかと思っています。 色んな技術の知見が得られる 新卒として会社に入社した皆さんは業務で使う技術を学んでいるかと思いますが、部署が異動になればまた別の技術が必要になるでしょうし、転職ともなれば今持っている技術では太刀打ちできないこともあるでしょう。 そんなときに、 新たな技術を(名前だけでも)知っている、というのは大きな武器になり得ます。 話をする側だけでなく、聴く側としても様々な人の様々な内容のLTを聴く中で、エンジニアとしての知識がどんどん身についていけると思います！ 人と繋がる機会になる こと社外のLTで言いますと、これも結構なメリットです。 先ほどLTの内容は Twitter で実況されると書きましたが、発表が終わり、懇親会になった後で気になった発表者にお話を聴いてみるのもいいと思います。そこから SNS 等で繋がることもありますし、話が盛り上がる中で別の勉強会に誘っていただけることもあります。 新卒の間はどうしても社外の人と繋がる機会が少ないかと思いますが、こういったLTの機会から輪を広げていってみてはどうでしょうか？ まとめ 今回の記事で言いたかったことは一つです。 「説明力」の向上のために、LTに積極的に登壇しましょう！ そして、 皆さんの面白い話をぜひ聞かせてください！ 以上です。ご視聴ありがとうございました。(LT風に) 参考 ライトニングトーク - Wikipedia IT業界でよく聞く「LT」ってなんなの？3つのメリットを知って、きみもLTしてみよう！ | トビラシステムズ株式会社

はじめに FM_Harmonyです、8月2回目の投稿になります。 ↓前回の記事はコチラです tech-blog.rakus.co.jp 今回はgitコマンドのfetchについて、学んだ内容をまとめてみました。 今回の記事を書こうと思ったきっかけは pullとfetchの違い について尋ねられた時、細かいところまで答えられなかったことです。 （大雑把に fetchはデータを持ってくるだけ、pullはmergeまで行う ということまでは答えられたのですが...） そこで、この機会にfetchについて学びなおしてみました。 Gitを学び始めたばかりの方や、復習したいと考えている方の参考になれば幸いです。 はじめに fetchの説明...の前にリモート追跡ブランチの説明 本題、fetchの説明 merge, pullの説明 おわりに 参考 fetchの説明...の前にリモート追跡ブランチの説明 fetchを説明するうえで リモート追跡ブランチ の説明は欠かせません。 では、リモート追跡ブランチとは何でしょうか？ リモート追跡ブランチ（Remote-tracking branch）とは、ローカル リポジトリ にあって リモー トリポジ トリの状態を保持する参照 です。 簡単に言うと、リモートにある同名のブランチと同一のコミットを指すブランチの事です。 このブランチの特徴として、リモート追跡ブランチのブランチ名は( リポジトリ 名)/(リモートのブランチ名)で固定される、ユーザが変更をコミットするなどしてブランチが指すコミットを直接操作することはできない、といったことが挙げられます。 そのため、ローカル リポジトリ からもリモート追跡ブランチを通じて、リモー トリポジ トリの変更を確認する、ローカルの作業ブランチにリモートの変更を取り込むといったことができるようになっています。 しかし、ローカル リポジトリ は24時間365日ネットワークに接続はしていません。 そのため、ローカル リポジトリ にあるリモート追跡ブランチは常にリモートのブランチと同じものを指すわけではありません。 誰かがリモートのブランチに変更をpushしてしまうと、リモート追跡ブランチとリモートにある同名のブランチが指すコミットが異なるということが発生します。 この状況を解消するために使うコマンドが fetch なのです！ 本題、fetchの説明 fetchコマンドを利用することで、リモー トリポジ トリの変更をローカル リポジトリ に取り込み、リモート追跡ブランチを同期することができます。 例えば、下記のコマンドを利用すると、リモー トリポジ トリ origin の master ブランチについて、変更をローカル リポジトリ に取り込み、リモート追跡ブランチ origin/master をリモートブランチ master と同期させます。 $ git fetch origin master この時点では、ローカルの作業ブランチに変更は反映されません。 そのため、例えばローカルのブランチ master に対してコミットを行っていた場合、リモート追跡ブランチとローカルのブランチとが分岐することになります。 merge, pullの説明 さて、こうして取り込んだリモートブランチの変更をローカルブランチに反映するにはどうすればよいでしょうか？ その方法の一つとして、 ローカルブランチにリモート追跡ブランチをmergeする という方法があります。 例えば、 origin/master とローカルブランチ master が分岐する場合、下記のコマンドを実行することで図のようなブランチ構造になります。 $ git checkout master $ git merge origin/master また、同じコマンドを実行した場合でも、 origin/master がローカルブランチの先のコミットを指しているだけで分岐していない場合、 master の指すコミットを変更するだけのいわゆる Fast-forward マージを行います。 別の方法として、 pull コマンドを利用するというものがあります。 これは、 fetch + merge と同じ動作を行います。 すなわち、 $ git checkout master $ git pull origin master というコマンドは、下記のコマンドと同義です 。 *1 $ git checkout master $ git fetch origin master $ git merge origin/master おわりに fetchについて簡単にまとめてみたのですが、いかがでしたでしょうか。 個人的にはリモート追跡ブランチの存在を知らなかったため、この機会に知ることができて良かったと思います。 今回の記事作成を通して、Gitについてまだまだ知識が足りないことが分かったので、また別の機会に他の操作(addやpush, etc...)について、機会を作って調べてみようと思います。 参考 Git - リモートブランチ Gitの公式によるリモート追跡ブランチとfetchの説明です エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com *1 : 厳密には同義ではなく、masterにmergeされるのはFETCH_HEADというfetchした際に作成されるブランチです。

id:radiocat です。既に記事で紹介されていますが、大阪オフィスの開発部内で毎月開催しているビアバッシュで『タスク管理のやりかたとツールの使いかた』というタイトルで発表をしました。 tech-blog.rakus.co.jp 今回はこの発表で紹介した スクラム 方式のタスクマネジメント手法を改めて記事にまとめます。 個人のタスクマネジメントとは？ そもそも個人のタスクマネジメントというのはいつ、何を、どう管理するのでしょうか？ 家族と生活している人は家族に頼まれた買い物を会社帰りに買って帰るために買い物というタスクを管理したいかもしれません。反対にプライベートは自由気ままに過ごしたいので細かい事まで管理したくない人もいるかもしれません。 ツールの選びかた 何をどこまで管理したいのかは人それぞれなので、ツールの選びかたもその人の生活スタイルや環境によって変わってきます。 世の中には様々なタスクマネジメントツールがあります。ネット上ではTrello、Todoist、asanaといったサービスを使った事例をよく目にします。私の所属するチームではTrelloを使っています。 trello.com ja.todoist.com asana.com 私の場合は家族と生活をしていて自分の時間は限られているのでスキマ時間は大切です。また、 スマホ は Android で、カレンダーやメールは Google のサービスを使うため、これらと連携した使い方もポイントになります。 また、性格的にプライベートをあまりキッチリ管理するのは息苦しく感じるため、スキマ時間を使うにしても手軽さやカジュアルさも重要です。 Google Keepの使い方 以上を踏まえて私が選んだツールが Google Keepです。 Google Keepはタスク管理ツールというよりはメモツールですが、それが逆にシンプルで個人でタスクを管理するならこのレベルで十分と感じています。 スケジュールとの連携など Google の他のサービスとも連携できます。 スマホ のホーム画面に表示される ウィジェット や、駅などの特定の場所に到着したら通知してくれるリマインド機能も便利です。 外出中であれば音声で登録したり、 スクリーンショット を撮って残りは自宅でという、その場の状況に応じた使い方も可能です。 スクラム 方式のタスクマネジメント実践方法 そして、 Google Keepを使い、 スクラム のやり方にヒントを得たタスク管理の手法が今回紹介する スクラム 方式のタスクマネジメントです。 スクラム 同様にシンプルで軽量なマネジメント手法です。 バックログ のように重要なものから1列に並べる Google Keepはメモツールとして登録したメモが縦一列に並ぶようになっています。そのため重要なものから順番に並べるだけで バックログ のように扱うことができます。 バックログ のように「完了した／していない」だけを管理 スクラム ではスプリントの期限までに完了していないタスクはたとえ途中まで完成していたとしても未完了として扱います。個人のタスクマネジメントも同様です。買い物をしたり、ブログに記事を書くというタスクが途中まで終わっていてもあまり意味がありません。そのため、完了したかどうかだけを観測するようにします。また、完了したタスクは「 アーカイブ 」することで一覧からは除外されますが、メニューから アーカイブ 一覧を表示することができるためいつでも完了したタスクを確認することができます。 タイムボックスを決めて繰り返す 私は毎週日曜日に1週間を振り返って、翌週のプランニングをしています。プランニングでは1週間でできそうな範囲の上位のタスクだけを重要な順に並び替えて、リマインドを設定したり、タスクの内容を整理します。 スクラム でもユーザーストーリーを具体化したり完了の定義を明確化したりして バックログ をReadyにしますが、個人のタスクも同じようにブログのアウトラインをメモしておいたり、 Google Keepのリスト機能を使ってやることの詳細をチェックリスト化してReadyにします。 スクラム 開発とは違うところ スクラム 開発とは違って個人のタスクマネジメントではやらないこともあります。 全体の見通しを立てない 何かを開発したりリリースするわけではないので、個人のタスク管理には終わりがありません。そのため全体の見積もりやバーンダウンチャートを作って見通しを立てるようなことはしません。 個々のタスクを見積もらない 全体の見通しを立てる必要がないので個々のタスクも見積もりません。ただし、個々のタスクがどれくらい時間がかかるかなどを細かく管理したい人は見積もりをしてもいいかもしれません。 これらはあくまで私の場合はやる必要がないと感じていることですが、必要に感じる場合はやりかたをアレンジしてみても良いかもしれません。その場合は Google Keepではできないこともあるので、上記で紹介したTrelloなどの本格的なタスク管理ツールを使うほうが良いかもしれません。 おわりに この手法はやりかたはシンプルですが、プロセスがきちんと回るようにするためには、日々の状況チェックや1週間単位の完了確認、ふりかえりをどこまでやるかなどを、自分でルールを決めてブラッシュアップする必要があります。理解は容易ですが、習得が困難な点も スクラム と同じです。 今回は私が愛用している Google Keepを使ってのやりかたを紹介しましたが、同様のやりかたは他のツールでもできるかもしれません。自分の使いやすいツールで実践してみると良いでしょう。ただ、 Google Keepは軽量で扱いやすいツールなので、今回紹介した手法に向いているツールだと思っています。私と同じように普段使うツールは Google のサービスが中心で手軽にタスクマネジメントしたいという人は Google Keepを使って スクラム 方式の個人のタスクマネジメントを実践してみてはいかがでしょうか。 当日発表したスライドは公開していますので良ければご覧ください。 speakerdeck.com 告知：Meetupで スクラム 開発について発表します 当ブログでも既に告知済みですが、9/13に開催される弊社主催のMeetupで楽楽精算の開発チームが実践している スクラム 開発の取り組みについて発表します。今回の発表は過去の 社内イベント の資料がベースですが、資料をアップデートして当時はリリース前で話せなかった内容や、プロジェクトのその後の状況についても話をする予定ですのでぜひご参加ください。 rakus.connpass.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

kuwa_38です。 ラク スでは月１回のペースで開発メンバーの交流会としてビアバッシュを開催しています。 ビアバッシュとはビールなどと軽食を片手にフランクに技術内容について発表したり語り合う交流会です。 （7月分のビアバッシュについては下記の記事をご覧ください） tech-blog.rakus.co.jp 大阪開発部のビアバッシュでは、決められたテーマに沿った発表を行う「テーマ枠発表」と自由なテーマで発表を行う「LT（Light Talk ）枠」が存在します。 今月のテーマは「 ツール特集 」です。各々が使用している便利なツールや業務効率化のために使っているツールについて発表して頂きました。 本記事ではテーマ枠、LT枠（自由発表）それぞれの発表についてご紹介します。 テーマ枠（ツール特集） ツール紹介 Node.jsとnpmの関連ツール My Powerful Scripts タスク管理のやりかたとツールの使いかた 個人的に使っている便利ツール 業務効率UP iOSアプリ LT枠（自由発表） インフラエンジニアの怖い話 トウダン・ジャーニー おわりに テーマ枠（ツール特集） テーマ枠で行われた6件の発表についてご紹介します。各発表の紹介を少し記載した後、発表内で述べられていたツールを列挙します。 ツール紹介 Snipping Tool や Tampermonkey の スクリプト など業務で使用している便利なツールや スクリプト を紹介して頂きました。業務でどのような時に使っているのかというお話もあったため、使う場面が想像し易すく、他のチームの方がどのような業務や進め方をしているのかといった点でも参考になる発表でした。また、 Snipping Toolが廃止される ことは知らなかったため驚きでした。 Snipping Tool phpStormのDiff Node.jsとnpmの関連ツール Windows でのNode.jsやnpmのバージョン管理ツールであるNodistやnpmのバージョン5.2.0で導入されたnpx、自作したパスワードを生成するツールについて紹介して頂きました。npmを使用する従来の方法と、npxを使う方法を前で実践して下さったため、npxを使うことでワンラインで簡潔に実行できることがわかる発表になっていました。 Nodist npm npx パスワードを⾃動⽣成するツール My Powerful Scripts Tampermonkeyで自作した便利な スクリプト についてランキング形式で発表して頂きました。GitLabでのレビューを簡単にするために優先度を付加するボタンを表示する スクリプト やMattermostで未読のみを表示する スクリプト などを紹介して頂きました。「Mattermostで未読のみを表示する スクリプト 」はチャットがスッキリして見易くなるので私も普段から使わせてもらっています。 Tab キー押下時に、タブ（Hard Tab）の代わりに、スペース x 4（Soft Tab）を入力するスクリプト GitLab の Merge Request の Code Review コメントに対応優先度を付加する スクリプト Mattermost で未読チャンネルだけを表示する スクリプト タスク管理のやりかたとツールの使いかた 色々なタスク管理ツールを紹介した後、現在使っているタスク管理ツール（ Google Keep）とその使い方、何が良いのかについて発表して頂きました。業務向きというよりはプライベートでのタスク管理にフォーカスしたお話でした。 Google Keepでは Googleカレンダー などの他の Google アプリと連携ができること、どこでも見れることが便利とのことです。また、メモのように手軽に書き込み週末に優先順位を変更し、次の1週間のタスクを決めているそうです。 Google Keep （発表者おすすめ） Trello （今の主流） Todoist asana Toodledo Google Tasks Microsoft To-Do 個人的に使っている便利ツール コピー履歴を保存してくれるツール（Clipy）や Markdown 記法を用いて綺麗に書くことのできるエディタ（Typora）、 Mac 上のアプリ・ファイルなどを検索できるツール（Spotlight検索）など業務の中で個人的に使っている便利なツールの紹介を行いました。業務で Markdown 記法を用いることが多いため、TyporaやMarpは愛用しています。 Clipy Typora Spotlight検索 Marp 業務効率UP iOS アプリ 業務効率化のために使用している iOS アプリについて紹介して頂きました。現在、発表者の方が行っている業務の関係上、Office LensやSkitchなどの画像加工アプリがメインでした。おまけとして、文字に濁点を付けていく、Dakutenといった面白いアプリの紹介もあったため、 堅苦しい ものでなく聞き手から笑いの起こる発表でした。私も情報共有のために スクリーンショット をとり、説明を付加することは良く行うためいつくか試してみようと思います。 Office Lens Skitch Key 楽楽精算 モザイク ぼかし&モザイク加工アプリ Dakuten LT枠（自由発表） LT枠で行われた2件の発表についてご紹介します。 インフラエンジニアの怖い話 夏といえば怖い話。この発表ではインフラエンジニアが実際に起こした、または、起こすと肝が冷えるミスについてご紹介頂きました。発表中は笑いが起こっていましたが、 rm -rf / やshutdownコマンドなど、誤って実行してしまうと笑いごとでは済まないミスについてご紹介頂きました。rmコマンドやshutdownコマンドを業務で使ったことはありませんが、機会があるときは本当に気を付けないといけないなと考えさせられる発表でした。 トウダン・ジャーニー php conference 2018 Kansai に登壇したことについて、登壇が決まるまで、業務として登壇するにあたり準備したこと、資料作成などについてご説明頂きました。公開リハーサルや当日の発表に至るまでの発表者間でのタスク管理や情報共有など、登壇までの過程や裏側について知ることができる発表となっていました。 （登壇された様子については下記の記事を御覧ください） tech-blog.rakus.co.jp おわりに 今月も様々なタイプの発表が聞くことができて、大変充実したビアバッシュになりました。 次回のテーマは「 他人のスライド発表会 」です。他の人が作ったスライド、面白かった記事やスライドを用いて発表して頂きます。今までにない発表形式なので、どのような発表がされるのか楽しみです。

ラク スは「 IT技術 で中小企業を強くします！」をミッションに掲げ、 メール共有・管理システムのメールディーラーから始まり、経費精算システムの楽楽精算に至るまで、 延べ40,000社を超えるお客様に自社開発した クラウド サービスを提供してきました。 今回（9/13(木)）は、 ラク スで主力 クラウド サービスの開発を牽引するエンジニアによる トーク セッションと交流会を開催します。 クラウド サービス開発のエンジニアとして活躍している方はもちろん、 クラウド サービス開発にご興味をお持ちのエンジニアの方も気軽にご参加頂ければと思います。 自社開発ならではの技術・運用ノウハウや、新しい取り組みの成果や失敗談など ご参考にして頂ける情報を積極発信していきたいと考えております。 このイベントが新しい気づきや成長につながる機会を提供する場になるとともに、 ラク ス社員と参加者の皆さま、また参加者の皆さま同士で新たなつながりが生まれるきっかけになれば幸いです！ 開催概要 【日時】2018/9/13(木) 19:30～21:30(開場は19:00) 【会場】 ラク ス 東京本社 （〒151-0051 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス] ） 【定員】30名 【申込み】 connpass 【参加費】無料 【主催】 ラクス 今回の トーク テーマ 終わらない スクラム 　～楽楽精算のサービス拡大を支える スクラム 開発の取り組み 大塚正道（おおつかまさみち） ラク スでは、まだ多くの開発チームが ウォーターフォール 型の 開発プロセス を採用していますが、 一部のチームで スクラム による アジャイル 開発に取り組んでいます。 今回は楽楽精算チームでの取り組みを紹介します。 実際にやってみると様々な問題が発生しました。問題解決に向けたアクションや取り組みを通じて得た知見、今後の課題等を事例を交えてお話しします。 テッ クリード （自称）としてのやっていき！　～ iOS アプリ開発 チームを率いて 川並裕（かわなみゆう） 若手エースエンジニアが初めての iOS アプリ開発 でテッ クリード として奮闘したお話しです。 iOS アプリ開発 は、自身も初、メンバーも初、しかも短納期（3ヵ月．．．）。 この デスマーチ を予感させる不利な条件下で、テッ クリード としてどのようにチームをリーディングしたのか。 様々な事例を交えてご紹介します。 流行の開発手法ChatOpsとは　～楽楽明細チーム/ChatOpsでルーティン作業をまるごと自動化～ 三田英一（みたえいいち） Jenkinsの導入で自動化が進んだけど、「Jenkinsを毎回開くのは面倒」、「アカウントの作成も面倒」、「非エンジニアに使ってもらうにはちょっとハードルが高い」。 そこで導入したのがChatOps! Slack互換のチャットツール「Mattermost」でルーティン作業を丸ごと自動化しました。 利用した bot ツール、システム構成、Hubot スクリプト の実例など、ノウハウを余すことなくご紹介します。 タイムテーブル 19:00 開場・受付開始 19:30 イベントスタート 21:30 終了予定 トーク が終わり次第、交流会に移ります。 交流会では、フィンガーフード、ドリンクをご用意致します。 お気軽にご参加ください。 エントリー方法 [connpass] よりエントリーをお願いします。 ※当日はお名刺2枚ご持参ください ※提供可能な設備： Wi-Fi 、電源 会場 ラク ス　東京オフィス2F セミ ナールーム 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス]

こんにちは。エンジニアのmickey-STRANGEです。 今まではめんどくさがりをテーマに、「簡単に○○する方法」を紹介してきました。 tech-blog.rakus.co.jp 今回の記事では、3年目になった私が、これまでのエンジニア生活の中でやっててよかったと感じる「 JavaScript で遊ぶ」ことについてお話したいと思います。 エンジニアになると周りから「勉強しといた方がいいよ」「いろんな技術触っといた方がいいよ」と声をかけられることが多いと思います。 しかし、何から手を付けていいか分からない、どんな技術を、どんな言語を触ってみればいいか分からない、と最初は思うかもしれません。 そういった新人エンジニアの方が勉強と気負い過ぎず、軽い気持ちで「 JavaScript で遊ぶ」ことから始めるメリットについてお話していきます。 実行環境の準備が要らない JavaScript の実行環境はブラウザです。勉強を始めるための環境構築というフェーズが必要ありません。 テスト用のHTMLファイルさえ用意してしまえばブラウザで開くだけで実行してくれます。 ただ、最初はHTMLの記述と JavaScript の記述を同時に考えるのが難しいと思います。そんな時は普段見るサイトのHTML構成をそのまま引っ張ってくることをお勧めします。 実際に公開されているHTML構成なので作り込みがされていて、簡単にしっかりとしたテスト用HTMLを用意することができます。 こうすることで、自分でベースのHTMLを用意しなくても JavaScript の練習が出来るようになります。 環境構築が必要ないのは、とっつきやすさという面でかなりの強さになりますね。 実際に使える業務知識が得られる JavaScript は業務でもよく使う言語です。Web系エンジニアなら当然、画面上の動きは JavaScript で記述することになります。 とはいえ、非同期処理があったり、画面上のユーザ操作との兼ね合いがあったりで、実行順が分かりにくくなる傾向があり、私の周りでも JavaScript に対して苦手意識を持つメンバがちらほらいます。 私も最初はそうでしたが、 JavaScript でちょくちょく遊んでいた結果、大規模な画面改修タスクを担当することになっても怯まなくなり、今では苦手意識は自分ではほぼないと感じています。 また、 JavaScript はもはやブラウザ上だけの言語だけではなく、 JavaScript ベースの言語でネイティブアプリの画面を構成できたり、サーバサイドの処理を記述したりすることもできます。 以前投稿されたGASも、 JavaScript ベースの言語だったりします。 tech-blog.rakus.co.jp JavaScript は他の言語と比べて、得た知識がどこかで業務に繋がる可能性の高い言語であるといえるでしょう。 小さな改善がすぐにできるようになる 普段見るサイトやブラウザアクセスするシステムの画面に対して、使いにくいなーめんどくさいなー、と思ったことはありませんか？ そんな時は chrome の 拡張機能 のTampermonkeyがおすすめです。 chrome.google.com Tampermonkeyは、指定したURLのページが開いたときに自動で JavaScript を実行してくれる 拡張機能 です。 これを利用することで、普段使うシステムの画面をちょっと使いやすくする、といったことが気軽に行えます。 また、作成した スクリプト は他のメンバのTampermonkeyの画面に貼り付けしてもらうだけで共有が出来るので、小さな改善をすぐチームに共有することが出来ます。 私も社内の基幹システムの膨大な数のメニューをいい感じに検索出来る スクリプト を作成して、チーム内に共有していたのですが、いつの間にか広まっていき、他のチームの方から感想をいただくこともありました。 用事がない限り他チームの方に話しかける機会はあまりないので、こういった面でもとてもよかったと思います。 さいごに 私が感じた「 JavaScript で遊ぶ」ことで得られたよかった点をまとめてみました。いかがでしたでしょうか。 とっつきやすく 、 業務に繋がりやすく 、 改善にもつながる 、というのはかなりのメリットだと思います。 また、 JavaScript は ajax を用いることで他システムの API を叩くことも可能ですので、1つの スクリプト 内で出来ることの幅がかなり広いです。 「勉強しよう」と思うと難しいかもしれませんが、このページのここをこうしたいな、を原動力に「 JavaScript で遊ぶ」感覚で手を付け始めると楽しさが分かっていただけるかと思います。 楽しいという感覚になってしまえば勝手に持続するので、遊び感覚で スキルアップ してみましょう！

はじめに エンジニアのFM_Harmonyです。 Rakus Developers Blogには、何度か記事を投稿させていただきました。 tech-blog.rakus.co.jp ↑前回の投稿記事はこちらです さて、今年も早いもので7月初旬に開発部へ新卒社員が配属されました。 また、同時期にオフショア先の ベトナム 子会社から出張者の受け入れを行いました。 そこで先日、新卒社員＆ ベトナム メンバーの歓迎会を開催いたしました！ 歓迎会の内容をまとめましたので、みなさまに ラク ス社内の雰囲気が伝われば幸いです。 交流の様子 まずは自己紹介から行いました、名前と顔を覚えていただくのは重要です。 今回は、普段のビアバッシュで用意しているものよりも、豪華な食事をご用意させていただきました！ 参加された方に伺ったところ、みなさんご満足いただけたようで何よりです。 普段はなかなか話す機会のない、先輩や管理職の方ともこうして話す機会を設けることができるのが、歓迎会のよいところです。 新卒の方も積極的に話しかけています。 ベトナム のメンバーの方はすっかり日本のメンバーとも打ち解けられようで、こうして記念撮影も行っておられました。 アイスブレイク：ペーパータワー 会の終わりごろには、アイスブレイク（Ice break）として ペーパータワー というゲームを行いました！ 簡単に説明しますと、A4用紙20枚を使って最も高いタワーを作ったチームが勝利するというゲームです。 では、ゲームの様子を写真とともにご覧ください。 ルール紹介 今回は以下のようなルールでゲームを実施いたしました。 1チーム4～5名で行う 2回ゲームを行い、それぞれで勝利チームを決定する 作戦を検討する時間は5分、実際にタワーを組み立てる時間も5分とする 利用して良いのは、A4用紙20枚および紙テープ1m分のみとする ↓ルールはこちらのサイトを参考にさせていただきました heart-quake.com ↓ルール紹介の様子、彼の厳正な審査により各チームの勝敗が決まります 作戦タイム ↓あるチームの作戦会議の様子、このプランニングにより作業がスムーズに行えるか決まります ↓別のチームの様子、紙を片手に作戦会議中です ↓ ベトナム メンバーの方々は1チームとして集まっていただきました 続いて実際の組み立ての様子といきたかったのですが、残念なことに撮影担当者もゲームに参加していたため、組み立て時の写真はありませんでした… そのため、結果発表の様子に移りたいと思います。 結果発表 ↓計測の様子、タワーが倒れないようみなさん必死です ↓中には予想外の組み立て方をされたチームも！ 肝心の結果はどうなったかというと、なんと 2回とも ベトナム メンバーチームの勝利 でした！！ ↓成果物と一緒に記念撮影、みなさんおめでとうございます！ おわりに というところで、今回はここまでとさせていただきます。 この記事を通して、みなさまに ラク スという会社の雰囲気を伝えることができたのであれば幸いです。 今回は私もイベント開催を担当したのですが、本当に楽しい歓迎会を開催することができて良かったです。 また、新人や ベトナム の方だけでなく、私たちも普段あまり話す機会のない方とお話しできたことも良かったと思いました。 最後になりますが、新卒の方にはこれからの活躍を、 ベトナム の方には日本で貴重な経験が得られるよう、心から祈っております。

こんにちは。開発エンジニアのamdaba_sk（ ペンネ ーム未定）です。 前回の冒頭で、ちょろっと以下のように書きました。 「OWASP ZAPについて調べてみた」という記事を書きました。 単体テスト 中にこっそり使ってみようかと思っていたのですが、手元の環境ではポート待ち受けでエラーが出てしまって放置しています……。 この件について、実はポート番号を選べばローカルプロキシとして使えそうだということがわかったのでそのことで続報を、と思ったのですが。 いいタイミングでまたもあの人が目立ってくれましたね！ 2018.kphpug.jp tech-blog.rakus.co.jp 先日開催された PHP カンファレンス関西 2018 に ラク スのエンジニアが登壇しました。我らが坂田くんがそのうちの一人として参加しています。 当日は私も見に行きました。開始前のえらく緊張してそわそわしている姿と、発表中の堂々と話す姿のギャップが激しかったのがすごく印象的でした。 というわけで、このブログへの次の投稿もこれをネタにするしかあるまいと思った次第です。例によって雑談に見せかけてまた坂田くんにインタビューしてみましたので、その時の話を今回は書こうと思います。 （※本人了承済み。ただし写真は気恥ずかしいのでやっぱりNGだそうです。ほんともう今さらな感じもしますが） なおイベントそのものと、弊社がこのイベントに公式に参加することになった経緯などについてはリンク先をご覧ください。 カフェスペースにて PHPカンファレンス 関西の開催された翌週、私はいい感じに話を聞けるタイミングを見計らっていました。坂田くんは何やら忙しそうで、なかなか昼食もいっしょに行けない様子。無理に時間を作ってもらうのも悪いのでどうしたものかと思っていたところ、ちょっとした休憩でも取るつもりなのかコップを持って執務室を出ていく坂田くんの姿が。私はチャンスとばかりに後を追いました。 ペンネ ーム未定 （以後 ペン未 ）「というわけでお話をしましょう」 坂田くん （以後 坂田 ）「何が『というわけ』なんだ……。ていうかそのメモ紙とペンは何？ またブログのネタにされるやつ？」 ペン未 「ちっ、君のような勘のいいガキは……」 坂田 「嫌いだというなら無理にお話しなくてもいいのだけど」 ペン未 「いやいや好きだから。もうめっちゃ好き。察しがよくて助かるわ～」 スピーカーディナーのこと ペン未 「前日にも業務後に何か行ってたよね？」 坂田 「スピーカーディナーっていうのに参加してた。当日はお互い発表があって話す時間が取れないからだと」 ペン未 「飲み会自体あんまり好きじゃないって言ってたのによく行く気になったね」 坂田 「せっかくの機会だからと思って。社外の人と交流する機会もあんまりないし」 ペン未 「どんな感じだった？」 坂田 「ネットの知り合いとのオフ会って感じだった。みんな私服だし、『もしかして、○○さんですか？』みたいな声のかけ方とかも。全員集まるまで適当にだべってる感じもまさしく」 ペン未 「へー。その場にいた人はみんなお互い初対面だった感じ？」 坂田 「いや、けっこう知り合いって感じの人も多かったかな。毎回登壇してるような人とか、現運営、元運営みたいな人達はお互いに知り合いで、むしろ私みたいな新参者の方が珍しかったような印象。それもあってちょっと話に加わりづらい感じがした」 坂田 「でも実行委員長の人は席も近かったしけっこう話せた。そういえば今回はスポンサーの応募も例年よりすごく多かったみたいで、しかも初めてスポンサーするってところも多かったらしい。それで問合せがいっぱい来て対応が大変だったとか」 ペン未 「そうなんだ。それはちょっと申し訳なかった感じがあるね……」 当日のこと ペン未 「発表直前はめっちゃそわそわしてたよね。坂田くんでも緊張するんだって思った」 坂田 「私だって緊張ぐらいします。ビアバッシュの発表のときだって緊張してるんですが」 ペン未 「全然そうは見えない」 坂田 「それ他の人にも言われたんだけど。なんでそう見られているのか……」 ペン未 「それは君がそういう振る舞いをしているからとしか言いようがないけど。でもあの時はことさら緊張してたってことでしょう？」 坂田 「まあね。発表が始まってからは多少落ち着くんだけど、発表前の5分間は結構つらかった」 ペン未 「発表前にパソ コントラ ブルもあったしね」 坂田 「そうそれ。私の持ってる唯一のノートパソコンが元XPで現 Linux 搭載の古いやつで、もともと使えるかどうかわからないねって話はしてたのだけど。 VGA のケーブルがあったから自分のパソコン繋げられると思っのに、いざ繋げてからパソコン起動させてみるとなぜかログインできなくなっているという。わけが分からなかったし時間も無かったから急遽パソコンを貸してもらった」 ペン未 「あせってパスワードミスってただけでは」 坂田 「間違ってはいなかったと思うのだけどなあ。後で VGA を外してから同じようにログイン試行してみたら普通に入れたし」 ペン未 「まあでも発表始まったら急にスイッチ入った感じだったよね。なんか練習よりも一段と分かりやすくなってたような気がするし。何か準備してた？」 坂田 「別に直前に特別なことはしてない。スライド見返すとかその程度で」 ペン未 「それで話せるとかすごいな。時間もほぼぴったりだったよね」 坂田 「時間は、実はちょっと遅いかもって思ってた。一回時計を見たのだけどいつ始まっていつ終わらないといけないのかわからくなって、もういいやって」 ペン未 「まじで。それめっちゃ不安じゃない？」 坂田 「今思うと不安なんだけど、発表中はなぜか時間のこと忘れてられたんだよね。不思議なことに」 坂田 「でも発表中に出ていっちゃた人がいたのは残念だったなあ」 ペン未 「あー、そういえばいたね。でもそれって仕方ないんじゃない？」 坂田 「そうかもしれないけど。でも今思い返してみると、確かに『Laravelの良かったところ』のセクションは確かに聞いててつまらないかもとも思うんだよね。Laravelの宣伝してるだけみたいな感じになってて。といってもどう変えればいいのかよくわからないのだけど」 ペン未 「まあそれは今後の課題ということで。また同じような発表をする機会があればその時考え直してみるといいですね」 坂田 「そうですね。そう頻繁に同じような発表をすることになっても困るけど」 そして仕事はつづく まだまだ話は引き出せそうでしたが、息抜きには十分なほどに話をしていました。 私たちは話をするうちに飲み干してしまったお茶を入れなおし、自席に戻りました。 これからは会社としても PHPカンファレンス のようなイベント、勉強会への参加を推進していくとのことなので、坂田くんに活躍してもらう機会が今後もたびたびあるのでしょう。 私は心の中でエールを送りつつ、先ほど聞いた話をブログにまとめるべくキーボードをたたくのでした。

@kawanamiyuu です。以前の 投稿 でお知らせしましたとおり、先日開催された PHP カンファレンス関西 2018 に ラク スのエンジニアが登壇しました。 また、 ラク スはシルバースポンサーとしてイベントに協賛いたしました。 イベント概要 日時 : 2018 年 7 月 14 日 (土) 会場 : グランフロント大阪 公式 HP : https://2018.kphpug.jp/ 2018.kphpug.jp 登壇 チャットディーラーの高速開発を支える Laravel（30分セッション） speakerdeck.com （本人コメント） PHP カンファレンスに限らず技術系のイベント初参加でした。最終的に私が登壇することになりましたが、会社としての参加が決まってからネタ出し、アウトライン作成、資料作成、発表練習等、最後までチームで準備を進めました。当日もちろん緊張はしましたが、不安を感じずに発表ができたのはチームのみんなのおかげです。 また発表以外の時間では聞く側としても楽しめましたし、勉強にもなりました。これからはもっと積極的にこういった社外のイベントや勉強会に参加してみようかなと思い始めています。 mixed 型なんてけしからんと社内チャットでつぶやいたら炎上した（ライトニング トーク ） 私、 @kawanamiyuu も実はライトニング トーク が採択されましたので話してきました。 speakerdeck.com （本人コメント） 今回がカンファレンスでの初 LT 体験でした。ネタはけっこう前から温めていて、社内のビアバッシュとかで話そうかと思っていましたが、今回弊社のエンジニアが 30 分セッションにも登壇するし、LT もやったれ！と思って応募したら採択されて、ドキドキしたけどとても楽しめました。 イベント 2 日前にオフィスで行った公開発表練習では 1 分半も時間が余ってしまい焦りましたが、自主練の結果、本番では時間ちょうどくらいで終われて安心しました。ほんとうはドラを鳴らされてみたかったです (^m^) 所感 今回、 ラク スにとって初めての技術イベントへの協賛および登壇でした *1 。いろいろ勝手が分からず、ちゃんとイベント当日まで漕ぎ着けることができるか不安でしたが、担当サービスを横断した登壇推進チームで協力して資料作成や発表練習を行い、当日、自分の会社のエンジニアが目の前で発表している姿を見てとても嬉しくなりました。 今後も継続して技術イベントに登壇していけるよう、また、コミュニティに貢献していけるよう、開発組織のレベルアップやエンジニアリング文化の 醸造 に取り組んでいきたいと思います。 *1 : これまでも弊社のエンジニアがプライベートで技術イベントで登壇することはありましたが、開発部の公式な取り組みとして登壇や協賛を行ったのは初めてでした。

Google API とは、 Google が提供するのサービスやプラットフォームを扱える API です。 これらの API を使いこなすことで、 Google のサービスを自身のアプリケーションへ組み込み、様々なことを実現できます。 ここでは、 Gmail を扱う API と、GoogleDriveを扱う API を PHP アプリケーションから利用する例に紹介します。 （内容は2018年7月現在の情報です。） この記事の内容 今回は、 Google API のガイドに記載されているQuickstartを用いて、 OAuth認証 を行い API を実行します。 *1 概要は以下の図のような感じです。 この記事では、「その1：プロジェクトの用意」で、 Google Cloud プラットフォームにプロジェクトを用意し、 「その2：認証情報の作成」にて、OAuthに必要な認証情報ファイルの作成、 「その3： API を叩く」でサンプルプログラムを用いて上記図の①～④に示す認証処理と API の実行を行います。 少し内容が長くなってしまったので、目次を見て必要な情報のところをご覧ください。 この記事の内容 その0：Googleアカウントの用意 その1：プロジェクトの用意 プロジェクトを作成する プロジェクトで使用するAPIを指定する その2：認証情報の作成 OAuth 2.0 クライアント ID を作成する OAuth 2.0 同意画面を設定する その3：APIを叩く Google Client Libraryのインストール 認証情報をダウンロード サンプルプログラムの作成 APIクライアントオブジェクトの取得 利用するAPIのサービスオブジェクト作成 サンプルプログラムの実行 （余談ですが、恥ずかしながら、この記事を書くまで、私は「OAuth」を、他のシステムで認証するから「Other Auth」の略だと思っていました。正しくは「Open Auth」ですね。。。） その0： Google アカウントの用意 言わずもがな、 API を利用して操作する Google アカウントが必要です。 詳しい方法は割愛。作成したら、ログインしてください。 その1：プロジェクトの用意 API を利用するため、 Google アカウントに紐づいたプロジェクトを作成する必要があります。 プロジェクトを作成する 使用する Google アカウントにログインしたら、 Google Cloud プラットフォーム にアクセスしましょう。 左上の ハンバーガ ーメニューから、「IAMと管理 > リソースの管理」を選択します。 リソースの管理画面に、「プロジェクトを作成」リンクがあるので、クリックします。 その後の画面でプロジェクト名を入力し、「作成」します。 これでプロジェクトが作成できました。 （少し画面表示に時間がかかることがあります。） プロジェクトで使用する API を指定する 次に、作成したプロジェクトで使用する API を指定します。 Google Cloudプラットフォームの画面上部から、先ほど作成したプロジェクトを選択した状態で、「 API とサービス > ライブラリ」を選択します。 ここでは、使用することができるGoogleAPIライブラリを選ぶことがあります。 どの API も面白そうですが、とりあえず今回は「 Gmail 」と「GoogleDrive」を利用するので、まず、「 Gmail API 」を探し、「有効にする」を選択します。 これで、このプロジェクトで Gmail API を有効にすることができます。 なお、この画面からは Gmail API のガイドやリファレンスなどのドキュメントを閲覧することができます。 同様に、「 Google Drive API 」を、 API ライブラリから探し、有効にします。 これで、使いたい API を有効にしたプロジェクトが作成できます。 その2：認証情報の作成 さて、プロジェクトは準備できましたが、 API を叩くにあたり、認証が必要です。 次は認証情報を作成し、自分が作成するアプリケーションからのリク エス トのみを受け付けるようにしましょう。 Google Cloudプラットフォームの画面上部から、先ほど作成したプロジェクトを選択した状態で、「 API とサービス > 認証情報」を選択します。 その後、「認証情報を作成」から「OAuth クライアント ID の作成」をクリックします。 OAuth 2.0 クライアント ID を作成する OAuthの設定をするにあたり、まずは API を叩くアプリケーションの種類を指定します。 今回は、「その他」を選んでください。 API ガイドに載っている「Quickstart」を使うためには、「その他」を選ぶ必要があります。 選択したら、クライアントの識別名を入力し、作成します。 OAuth 2.0 同意画面を設定する 次に、 OAuth 2.0 同意画面の設定を行うため、 「認証情報を作成」から「OAuth 2.0 同意画面」を選択します。 OAuth 2.0 同意画面とは、設定している API によってユーザのデータへアクセスするときに、表示される画面で、データへのアクセス前に認証を行う画面のことです。 この画面で認証を行うため、メールアドレスと、表示する任意のアプリ名を指定します。 ここで指定したアプリ名は、以下のように認証画面にて表示されます。 設定出来たら「次へ」ボタンを押下します。 これで認証情報の作成が完了しました。 ハンバーガ ーメニューから、「 API とサービス > 認証情報」を選択すると、認証情報が作成できていることが確認できます。 その3： API を叩く 次に、アプリケーションから Google API の認証を行い実際に API を実行します。 ここからは Gmail API の公式ドキュメントを参考にしながら進めましょう。 「 API とサービス > ライブラリ」から「 Gmail API 」を探し出し、「 チュートリアル とドキュメント」の「Learn more」をクリックし、公式ドキュメントを表示します。 表示したら、「ガイド」タブの「Quickstarts」から、使用する言語を選択します。 今回は PHP で説明します。他の言語で API を扱いたい場合は、対象の言語を選択して、頑張ってください。（←丸投げ） PHP のQuickstartでは、Step1～Step4の手順が紹介されていますが、Step1の API を有効化する手順はもう完了しているので、Step2から行います。 Google Client Libraryのインストール QuickstartのStep2です。 Google の API を使用するために、 Google Client Libraryをインストールする必要があります。 PHP の場合、composerを用いることで簡単にインストールできます。 composer require google/apiclient:^2.0 認証情報をダウンロード 先ほど作成したOAuth2.0クライアントの認証情報が記載された JSON ファイルをダウンロードします。 Google Cloud プラットフォームのメニューから、「 API とサービス > 認証情報」を選択し、先ほど作成したOAuth2.0クライアントのダウンロードアイコンをクリックすることで、ダウンロードできます。 ダウンロードしたクライアントの認証情報ファイルは、次のサンプルプログラム実行で使います。 サンプルプログラムの作成 QuickstartのStep3です。 quickstart.php という名前で以下のコードを保存します。 <?php require __DIR__ . '/vendor/autoload.php' ; if ( php_sapi_name () != 'cli' ) { throw new Exception ( 'This application must be run on the command line.' ) ; } /** * 指定した権限が付与されたAPIクライアントを返す * @return 権限が付与されたGoogle_Clientオブジェクト */ function getClient () { $ client = new Google_Client () ; $ client -> setApplicationName ( 'Gmail API PHP Quickstart' ) ; $ client -> setScopes ( Google_Service_Gmail :: GMAIL_READONLY ) ; // ※1：スコープの設定 $ client -> setAuthConfig ( 'credentials.json' ) ; // 取得したJSONファイルのパス $ client -> setAccessType ( 'offline' ) ; // クライアント証明書ファイルが存在しない場合（初回実行時）は // 認証情報JSONファイルを用いて取得する。 // 存在する場合（2回目以降の実行時）は、クライアント証明書を読み込む。 $ credentialsPath = 'token.json' ; // クライアント証明書ファイルのパス if ( file_exists ( $ credentialsPath )) { $ accessToken = json_decode ( file_get_contents ( $ credentialsPath ) , true ) ; } else { // ユーザからの認証を行う $ authUrl = $ client -> createAuthUrl () ; printf ( "Open the following link in your browser: \n %s \n " , $ authUrl ) ; print 'Enter verification code: ' ; $ authCode = trim ( fgets ( STDIN )) ; // 認証コードをアクセストークンに変換する $ accessToken = $ client -> fetchAccessTokenWithAuthCode ( $ authCode ) ; // クライアント証明書をファイルに保存する if ( ! file_exists ( dirname ( $ credentialsPath ))) { mkdir ( dirname ( $ credentialsPath ) , 0700 , true ) ; } file_put_contents ( $ credentialsPath , json_encode ( $ accessToken )) ; printf ( "Credentials saved to %s \n " , $ credentialsPath ) ; } $ client -> setAccessToken ( $ accessToken ) ; // クライアント証明書が有効期限切れの場合は更新し、ファイルへ保存しなおす if ( $ client -> isAccessTokenExpired ()) { $ client -> fetchAccessTokenWithRefreshToken ( $ client -> getRefreshToken ()) ; file_put_contents ( $ credentialsPath , json_encode ( $ client -> getAccessToken ())) ; } return $ client ; } /** * メイン処理 */ // APIクライアントを作成し、サービスオブジェクトを作成する $ client = getClient () ; $ service = new Google_Service_Gmail ( $ client ) ; // 使用するAPIごとのサービスオブジェクトを作成 // Print the labels in the user's account. $ user = 'me' ; $ results = $ service -> users_labels -> listUsersLabels ( $ user ) ; if ( count ( $ results -> getLabels ()) == 0 ) { print "No labels found. \n " ; } else { print "Labels: \n " ; foreach ( $ results -> getLabels () as $ label ) { printf ( "- %s \n " , $ label -> getName ()) ; } } 上記コードでは、大きく分けて、以下の処理を行っており、一部 API の実行目的によって変更する必要があります。 API クライアントオブジェクトの取得 クライアント証明書の取得と更新 API クライアントオブジェクトの作成 利用する API のサービスオブジェクト作成 API クライアントオブジェクトの取得 API を実行するクライアントのオブジェクトを作成します。 作成時には、先ほどダウンロードした、クライアントの認証情報を利用して、クライアント証明書を取得し、ファイルに保存します。 クライアント証明書には、特別な設定をしない限り利用期限があり、利用期限が過ぎていた場合は更新されます。 また、クライアントオブジェクトを作成する際に、「スコープ」を指定します。 「スコープ」は、そのクライアントが、 API を用いて「どこまでの操作が実行できるか」を指定するものです。（コード内コメント※1） スコープは API を使って何を実行したいのかによるため、場合によって書き換える必要があります。 スコープは各サービスオブジェクトの定数を指定するか、 API ガイドにある URI を指定することで、設定できます。 Gmailのサービスオブジェクト定数一覧 URI一覧 たとえば、 Gmail でメールを送信したい場合は以下の通りに書き換えます。 $client = new Google_Client(); $client- > setScopes(Google_Service_Gmail::GMAIL_SEND); Google Drive でファイルをアップロードしたい場合はこんな感じ。 $client = new Google_Client(); $client- > setScopes(Google_Service_Drive::DRIVE); 複数のスコープを指定する場合は、定数を配列に格納することで可能です。 $client = new Google_Client(); $scopeList = array(Google_Service_Gmail::GMAIL_SEND, Google_Service_Drive::DRIVE); $client- > setScopes($scopeList); 利用する API のサービスオブジェクト作成 取得したクライアントオブジェクトを利用して、各サービスの API を扱うためのサービスオブジェクトを作成します。 ここは各サービスごとに異なるため、ドキュメントをご覧ください。 作成したサービスオブジェクトを使うことで、そのサービスの API リク エス トが可能になります。 サンプルプログラムの実行 作成したサンプルプログラムを コマンドライン から実行します。 $ php quickstart.php 実行すると、URLが表示され、入力待ちになりますので、表示されたURLへブラウザからアクセスしてください。 アクセスすると、認証情報の作成時に設定したOAuth 2.0の同意画面が表示されますので、画面に従って実行を許可してください。アクセス トーク ンが表示されるので、 コマンドライン にコピペすることで、クライアント証明書を取得することができます。 次回実行時からは、この作業で取得したクライアント証明書をもとに認証を行うため、同意画面での実行許可は不要になります。 また、サンプルプログラムは Gmail の API ガイドから取得しましたが、この認証で今回作ったプロジェクトへの認証ができるので、他 API も利用可能になります。 これで API を実行する準備はできました。 あとは各サービスオブジェクトのメソッドを使って Gmail を送ったり、 Google Drive を操作したりできます。 例として、 Gmail でメールを送るときのコードを記載します。 *2 /** * Gmailを送信する */ public function sendGmail($client) { $data = ""; $data .= "To:xxxx @xxx .xxx.xx\n"; $data .= "Subject: メールたいとる\n"; $data .= "\n"; // ヘッダーと本文を区切る空行 $data .= "本文"; $data = base64_encode($data); //base64エンコード $service = new Google_Service_Gmail($client); $msg = new Google_Service_Gmail_Message(); $msg- > setRaw($data); $result = $service- > users_messages- > send('me', $msg); return $result; } エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com *1 : https://developers.google.com/gmail/api/quickstart/php?hl=ja *2 : https://sepg.biz/2018/03/23/post-564/

はじめに ラク スエンジニアのstrongWhiteです。今回はSwiftのextensionとprotocolについて書きます。 私がSwiftを勉強し始めたころは、この2つの概念がよくわかっていませんでした。 2つとも似ているようで全く違うので、両者について簡単にまとめてみます。 extensionとは extension（拡張）とは、特定のクラスや構造体、データ型など、名前はそのままにプロパティやメソッドを追加する機能です。 Java でいうと「継承」と似ています。 Java の「継承」はクラスのプロパティやメソッドを引き継いだ別名のクラスを作るのに対し、Swiftの「拡張」は名前はそのままになるのが特徴です。 extensionの使い方 それではextensionを使った簡単なプログラムを書いてみましょう。今回は データ型 の拡張を行ってみます。 extensionを使って、Swiftに標準で備わっているデータ型（例．Int、String）を拡張してみます。 extension String { func isLongString () -> Bool { if self .count <= 20 { return false } return true } } let text = "RAKUS Developers Blog" print(text.isLongString()) // 実行結果：true サンプルプログラムでは、String型を拡張し、文字数が20文字以上かどうかを判別する簡単な関数を定義しています。 このように、extensionを使えば、変数の値の比較や加工処理を、既存のデータ型にメソッドを追加することで実現できます。 私は今まで「データ型の定義を拡張できる」ような言語に出会ったことがなかったので、この辺りはとても新鮮な感覚でした。 protocolとは お次はprotocolです。protocolとは、クラスの挙動や振る舞いを決めたものです。クラスでは、プロパティや挙動を細かく記述していきますが、protocolでは、インタフェースのみを定義します。実際の挙動はprotocolを採用するクラス側で記述します。 protocolの使い方 ではprotocolを使った簡単なプログラムを書いてみます。今回は 列挙型 にprotocolを適用してみます。 protocol BaseProtocol { var type : String { get } } enum Blood : BaseProtocol { case AB case A case B case O var type : String { switch self { case .AB : return "AB型" case .A : return "A型" case .B : return "B型" case .O : return "O型" } } } print( "あなたの血液型は" + Blood.AB.type + "です" ) // 実行結果：あなたの血液型はAB型です サンプルプログラムでは、血液型を列挙型で定義してみました。また、ベースとなるprotocolとして、 BaseProtocol （そのままですが）を採用しています。 また、列挙型のほうで、 BaseProtocol に定義してある type 変数を宣言しないと コンパイル エラーになります。 最後に Swiftのextensionとprotocolについて、違いがよくわかっていなかったので勉強してみました。 それぞれ身近な Java を例に挙げて、extension→継承、protocol→インタフェースであると解説しましたが、Swiftを知らない人でも少しはイメージができたのではないでしょうか。 皆さんもこの辺りを勉強してみるとよりSwiftが面白いと感じるかと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

id:radiocat です。中学のとき美術の先生に美術科への進学を勧められたことがありますが、それ以降は描いた絵を褒められたことがありません（後述）。 アジャイル な開発チーム以外でも近年は「ふりかえり」を行っているチームは多いのではないでしょうか？ 従来型の 開発プロセス では「反省会」とも呼ばれますが、これまでやってきた事を振り返って未来に向けた改善アクションを見つけるという点ではどちらも同じです。そして、そのような改善に向けて振り返る会議の前にまず行うのが「チェックイン」です。 チェックインとは？ ふりかえりの「場を設定する」アクティビティの1つで、『 アジャイル レトロスペクティブズ』という書籍で紹介されています。 アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き 作者: Esther Derby , Diana Larsen オーム社 Amazon 目的 この書籍の中で、チェックインの目的は以下のように説明されています。 余計なことを考えずに、レトロスペクティブに集中してもらう。レトロスペクティブから何を得たいのかを明確にしてもらう。 ふりかえりの場に意識を集中してもらい、チームでどういう議論がしたいのかを発信して参加者の目線を合わせるための作業なのです。 やりかた 簡単な質問を1つする メンバーは順番に質問に答える たったこれだけです。例えば、ふりかえりの ファシリテーター が「今の気持ちを一言で答えてください」という質問をして、メンバーが「嬉しい」とか「悲しい」などと順番に答えます。 「場を設定する」ということ チェックインのように「場を設定する」ことについて『 アジャイル レトロスペクティブズ』の中で次のように説明されています。 部屋にいる全員に口を開いてもらう。最初に喋らなかったら、ずっと何も喋らなくてもいいという暗黙の了解を得たと思ってしまう。レトロスペクティブの肝はグループで考え、一緒に学んでいくことなので、全員参加が不可欠である。 たった一言ですが、質問に答えてもらうだけで全員に参加意識を持ってもらえます。また、答えた内容によってその人がどういう気持ちで会議に臨んでいるのかを知ることができます。例えば「嬉しいと感じているのは自分だけかもしれない」と思うと発言がしにくいかもしれませんが、全員の気持ちを知っていればそのような不安が減って発言のハードルが下がります。 つまり全員が一言ずつ喋ることで、その人自身の発言のハードルを下げるとともに、周りのメンバーの発言のハードルを下げることにも繋がるのです。 場を設定するアクティビティ このような場を設定するアクティビティには様々なやりかたがあります。我々のチームでもいくつか実践してみたので、それらの一部を紹介します。 One Word 今の気持ちを一言で表現してもらいます。実際にやってみた結果は次のような回答でした。 一言では言い表わせれなかったメンバーもいますが、そういう気持ちなんだなと受け止めます。逆に一言だと意図がわからないものもあります。例えば「早い」は開発スピードのことなのか、作った機能のことなのかわかりません。ふりかえりの目線を合わせるためにも、必要に応じてどういう意味なのか聞いてみても良いでしょう。ただし、まだ場を設定するタイミングなので議論に発展するようならいったん止めてあとで議論するようにします。 漢字1文字 今の気持ちを漢字1文字で表現してもらいます。このケースでは順番に回答していくうちに、他のメンバーと被らないようにと、色々考えて回答するようになって後半のメンバーが苦戦するというせめぎ合いも起こりました。 自分の気持ちに適した漢字を選ぼうとすると意外と難しく、色々考えることでふりかえりに向けて集中できる効果もあります。One Wordと同じで意図がわからない漢字の場合はなぜその漢字なのか聞いてみても良いでしょう。 Happiness Rader 今の気持ちを顔文字で表現してもらいます。この時はどんな顔かを聞いて ファシリテーター がホワイトボードに書きました。 参加者に自分で書いてもらっても良いですが、「どんな顔ですか？」と聞くことでどんな気持ちなのかがわかります。ただ、言葉で表現された気持ちを絵で表さなければならないので、 ファシリテーター の絵心も場の設定に影響しそうです… 絵の得意なメンバーが見かねて代わりに書いてくれました。絵心がある人が描くほうが、参加者も今の気持ちを言葉で表現しやすいかもしれません… 3 dots 今の気持ちを3段階のドットで表現してもらいます。短時間かつシンプルに表現できるのが最大のメリットです。 顔文字と違って最速で表現できますが、なんとなく物足りなさはあります。3種類しかないので複雑な気持ちを表すことはできません。チームが複雑な課題をたくさん抱えているような場合は、みんな1ドットという回答でそれぞれが抱えている気持ちの違いはわからないという結果になる可能性があります。 Good & News 良かったことと新しい気づきを共有してもらいます。 前向きな意見を集めるような場の設定に有効です。ふりかえりで課題がたくさん出ることが予想される場合にあえて最初に前向きな意見を求めてみるという使い方もあります。気付きの共有はやや時間が長くなりがちなので時間が少ない場合には向いていないかもしれません。 希望と懸念 ふりかえりに対する希望と懸念事項を共有してもらいます。 参加者それぞれがふりかえりをどういう場にしたいかが比較的わかりやすく表現されます。ただ、これも少し時間がかかるアクティビティです。 以降は我々のチームではまだ試したことはありませんが、書籍等で紹介されているものです。 DPA （Design the Partnership Alliance） 決め事を作ります（どんな雰囲気で話すかなど）。 事前にその場の雰囲気をどうするかを参加者で話し合って決めるので、スムーズに議論に入れそうです。 Keep+Wakattakoto 良かったことと分かったことを共有してもらいます。 Good & Newsと似ていますが、 KPT のKをより意識した場の設定ができるかもしれません。 連想ゲーム 起きたことを一言づつ隣の人に連想ゲームします。 漢字1文字と同じで、考えることで意識を集中することができそうです。また、ゲーム感覚で場を和ませる効果もありそうです。 おわりに 我々のチームでは、これらのアクティビティの中から1つを参加したメンバーに選択してもらっています。参加者が主体的に考えたり選択してもらうことで、ふりかえりの場が設定されます。 このような場を設定するアクティビティはふりかえりだけのための手法ではありません。議論に集中するために参加者同士で意識合わせをすることが目的なので、ふりかえり以外の会議でも活用できる場面はあります。 会議の場で次のような課題を感じたことはないでしょうか？ 発言する人が少ない 自由な意見が出てこない いつも同じ人の意見でチームの方針が決まる もし、このような課題を感じたら「場を設定する」ことからはじめてみると良いかもしれません。 参考 ふりかえりワークショップ～実践＆実践～ - Speaker Deck エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに こんにちは、新卒で入って入社3年目のnorthmkyです。 いままでの投稿では yumコマンド についてや 文字コード など実業務でも役立つ基礎知識をまとめたものを書いていましたが、今回はプライベートで Google Apps Script、略称GASに触れたのでご紹介したいと思います。 題名を「5分で理解する」などと自身でいうのもなんですが巷でよくあるキャッチーで怪しい、ほんまかいな...というようなものになっておりますが、嘘ではないと思います。 ただ前提として JSの経験がある 必要あります。逆に言えば WEB界隈でJSを触ったことがある方は学習コストがほぼ0になります。本記事を読めばやりたいことはすぐ書けます。 理由としては JSと パラダイム がほぼ一緒 JSと文法がほぼ一緒 標準でついているメソッド名が直感的でわかりやすい の3点です。 ほぼ同じ思想なので、あとは特有の押さえておくべき用語と スクリプト と操作するアプリ画面の対応関係がわかれば書けるようになります。 それでは前置きはこのくらいにして紹介に入りたいと思います。 Google Apps Script(GAS)とは 「 Google の各種アプリ( Google スプレッドシート / Google ドキュメントなど)をアプリ内ではなく外から操作できるJSライクな プログラミング言語 」です。 エクセルに対する VBA の関係と一緒です 1 。 実現できることの例としては、指定時間になったら特定のセルの値を読み出して外部アプリに渡す bot であったり、 スプレッドシート だけでなく googleカレンダー にまとめてスケジュール登録したり、などなどができます。 2 色々できるのですが、本記事では読者のみなさんに馴染みがあると思われる スプレッドシート を題材にします。 早速GASを理解する GASでは操作対象のアプリをオブジェクトとして扱います。 スプレッドシート の場合、覚えるべきオブジェクトは下記3点のみです。 Spreadsheetオブジェクト Sheetオブジェクト Rangeオブジェクト アプリと スクリプト 内のオブジェクトは下図のような関係性になっています。 ウィンドウ左はおなじみの スプレッドシート 、右はGASです。 図の スクリプト は「特定のセル範囲に値を入れる」処理をします。 実行すると下記のようになります。 好き、という文字列が指定したセル範囲(= range )に格納されました。 どうでしょうか、説明はこれだけです。 値を入れるというだけの処理の紹介ですが、これだけでもう スプレッドシート を自分の好きなように操れる気がしないでしょうか。 特別な文法を覚えたりする必要もありません。 ここでは記載していませんが、分岐/繰り返しなど基本構文はもちろんありますし、標準メソッドもあるので安心です。 「いやメソッドいちいち調べる感じじゃ...?」と思われた方、安心してください。 こちらの標準エディタは補完機能付きなので、適当にメソッド名を打っても実現したいことができるメソッドを見つけられる確率が高いです。メソッド名がわかりやすい...素晴らしい... おわりに GASの超入門として、 スプレッドシート に対して処理を行うことを通して、GASをどのように書けるかをお伝えしました。 今回はお話しませんでしたが、webAPIを叩く機能も標準でありますし、 google 本家、またそうでない人によるたくさんのGAS用ライブラリも github で公開されています。 ですので twitter /slackBotも 開発環境構築なしで Google アカウントがあれば誰でも作成できる という敷居の低さも魅力的なGAS、皆さんも試してみませんか？ 題名を裏切らない内容になっていれば幸いです。 付録: スクリプト 作成〜実行の簡単な流れ スクリプト 作成方法 ツール をクリック スクリプトエディタ をクリック これで スクリプト が立ち上がります。 実行方法 Ctrl + S ... スクリプト 保存 Ctrl + R ... スクリプト 実行 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com やや過大表現です。厳密にはGASは、エクセルに対する VBA のような、どこかのbookに紐付いて動く「Container Bound Script」と紐付かず単独で動く「Standalone Script」の2種類があるので厳密な表現ではないです。本記事では「Container Bound Script」のみを扱いますのでこのように表記しました。 ↩ ここで私は基礎を学びました。他にもいろいろな実例を平易に書いてありとてもわかりやすいです。 https://tonari-it.com/google-apps-script-manual/#toc2 ↩