はじめに こんにちは、 @rs_tukki です。 以前 id:radiocat さんが記事にされていましたが、効率よくプロジェクトを進めるにあたって、「振り返り」を行うことは非常に大切です。 今回は、その「振り返り」の手法のひとつ、 KPT 法について話したいと思います。 tech-blog.rakus.co.jp はじめに 振り返りとは なぜ振り返りが大切なのか？ KPT法 K ~Keep:継続すべきこと~ P ~Problem:問題だと思うこと~ T ~Try:改善していくこと~ KPT法のメリット 実践例 おわりに 参考 振り返りとは 振り返る 読み方：ふりかえる (1)身体を翻して後方を見る、後ろ側を向く、などの意味の表現。 (2)過去の物事を顧みる、思い起こすこと。回顧すること。 (3)これまで行われてきた物事の一連の流れを総括すること。 引用: 振り返る(ふりかえる)の意味や定義 わかりやすく解説 Weblio辞書 今回扱う、プロジェクトを進めるにあたっての「振り返り」は、このうちの(3)にあたります。 ここまで実施したことの内容と結果、それを通じて学んだことをメンバー全員で確認することで、これから実施することを見直し、改善していく作業のことを指します。 特に アジャイル 開発を採用したプロジェクトだとスプリントごとに行うことが多いですが、開発現場に限らずとも、複数人で何かを進めていく場では、よりよい方向を目指すために役立ちます。 なぜ振り返りが大切なのか？ 「振り返り」という言葉だけでは、「反省」と勘違いされることがあります。 しかし、反省が、過去の失敗がなぜ起こったのか、という原因の追及を行うのに対して、振り返りは、 目標にしていたことが達成できたか 、 達成できたのなら次の目標はどうするか 、 達成できなかったのならどうすれば達成できるようになるのか 、という考え方のもとに進めていきます。 次の仕事をより効率よく改善していくためには、単なる「反省」ではなく、「振り返り」を実施することが大切なのです。 KPT 法 KPT 法とは、振り返りの手法として用いられている枠組みの1つです。 今までの仕事の中で感じたことを、 一人ずつ「Keep」「Problem」の二つに分けて挙げてもらい、議題とします。その中から次の改善案となる取り組みを「Try」として選び実施していきます。 元々はAlistair Cockburn氏が2004年の著書で提唱した理論を、平鍋 健児氏が KPT と呼んだのが始まりのようです。既に15年近くも使われている伝統の手法みたいですね。 tbpgr.hatenablog.com K ~Keep:継続すべきこと~ K には、実施してよかったこと、今後も継続して実施していきたいことが入ります。 例えば、新機能の開発を行うとき、複雑なコードをモブプログラミングで実装したとします。その機能が大きなバグもなく、スムーズにリリースできたというKeepがあれば、モブプログラミングの実施は効果があった、という判断ができ、またそれを提案した人が達成感を覚える機会にもなります。 P ~Problem:問題だと思うこと~ 一方で P には、失敗したこと、これから改善していきたいことが入ります。 例えば、バグの修正を行うとき、影響範囲がどこなのか、よく調べずに取り組んでしまったとします。 結果、修正に余計な時間がかかってしまった、別のところにバグが発生してしまった、というProblemがあれば、その問題を共有するとともに、改善へ向けた意識付けができます。 ここで問題なのは、先ほど書いたように 原因の追及をしない ということです。 起こってしまった問題に対して個人を攻撃するのではなく、どうすれば改善できるか、を考えることが大事です。 T ~Try:改善していくこと~ 最後に T は、今まで挙がった内容を踏まえて、次の機会にどのように実施していくかのまとめが入ります。 上記の例で言えばモブプログラミングによる効率を上げるために、より多くの機能でモブプログラミングを実践する、 あるいはバグ修正の手戻りをなくすために、修正方針をレビューしてもらう、といった形です。 そして次回の KPT では、今回Tryに挙げたことがまたKやPに入り、更なる改善を目指していくのです。 KPT 法のメリット 振り返りの手法には、有名なもので PDCA *1 がありますが、こちらではそれぞれの中で具体的にどのようなことをすればいいのかが曖昧です。 KPT 法では、 PDCA の中の CA に絞った手法を具体的に示しているので、初めて振り返りをする場合でも、何を確認して何を話し合えばいいのか分かりやすいのがメリットと言えます。 実践例 以下の画像は、私たちのチームで毎年実施しているとあるプロジェクトの KPT です。 特別な道具を用いる必要はなく、一つの Excel ファイルへメンバーが一人ひとり自由に記載してもらっています。 ここで重要なことは、 意見の被りを気にしない ことと、 プロジェクトを実施するたびに行う ことです。意見が被るということは、それだけ多くの人が同じことを感じているということですので、それだけ継続、あるいは改善の優先度が高まります。Problemの全てをTryにするのが難しい場合でも、意見の数を参考にTryにすること、しないことを判断できるのです。 また、 KPT は1回で終えるのではなく、都度繰り返し実施することで、よりよいプロジェクトになっていくのではないかと思います。 おわりに 今回は、チームのプロジェクトを進めるにあたって振り返りが必要なこと、またその手法の一つとして KPT 法を紹介いたしました。 実施したことを適切に振り返り、改善していけば、効率が格段にアップするはずですので、ぜひ一度試してみてください。 参考 Alistair.Cockburn.us | Reflection workshop 「振り返り」をするかしないか、で変わること。振り返りは、未来の自分へのアドバイス…？｜社員研修・人材育成コラム｜FCEトレーニング・カンパニー “振り返り”に役立つ5つのフレームワーク。振り返りシートの書き方や方法を押さえよう｜ferret KPTとは？ふりかえりのフレームワーク・進め方・成功のコツ・ポイント | BOXIL Magazine エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 : 計画[Plan]、実行[Do]、評価[Check]、改善[Action]を繰り返していく手法のこと。

こんにちは、fuj_takです。 今回は ラク スのサークル活動について紹介します！ サークル活動について サークル活動は、 ラク スで働くにあたって、モチベーション向上や信頼関係を築くこと、 ワークライフバランス を充実させることを目的としています。 また、サークル活動に対して会社からの補助を受ける事ができます。 業務に近い内容だけでなく、趣味を通じて交流を図るサークルなど様々で 好きなテク ノロ ジー を開発 カメラ撮影 フットサル ガンプラ などです。 その他にも多数のサークルがあります。 ボードゲーム サークル 私が参加しているサークルは「 ボードゲーム サークル」です。 平日の業務時間後、課／部署問わず色々なメンバーが参加しています。 ボードゲーム といっても、広く知られている人生ゲームや モノポリー ではなく、 カタン カルカソンヌ ドミニオン といったもので、今まで名前を聞いた事がないものばかりでした。 始めはルールに混乱するのですが、一度やってみると大体ルールを理解できるようになりました。 どれも奥が深く、日頃パソコンや スマホ にばかり目を向けている自分にはとても新鮮で楽しいです。 日頃なかなかコミュニケーションを取りづらいメンバーとも ボードゲーム を通じて交流を図れるので、社内の交流の幅も広がるし、リフレッシュにもなるんですよね。 私のおすすめは ドミニオン です！ ゲームのルールを様々なバリエーションで組み合わせられるので、毎回違った面白さがあるんですよ。 こんな名前のカードがあって、なんか心をくすぐられます。 地下貯蔵庫 宰相 海の妖婆 策士 わが子が成長したら一緒にやろうともくろんでいます。 まだ1歳と3歳なので今は一緒にできませんが（笑）。 社内に広いリフレッシュスペースも備えているため、 ボードゲーム だけでなく様々な活動で社内の環境を活用できるようになっています。 www.wantedly.com ラク スでは業務だけでなく、サークル活動などの ワークライフバランス も意識しています。 業務もサークルも楽しみながら、楽しいエンジニアライフを送っていきたいと思います！

こんにちは。エンジニアのmickey-STRANGEです。 はじめに 今回は先日、大阪オフィスで開催された11月ビアバッシュをご紹介いたします。 前回のビアバッシュ記事はこちら↓ tech-blog.rakus.co.jp はじめに テーマ発表 Mail Dealer 配配メール 楽楽精算 Chat Dealer 働くDB LT発表 街ブラUIレビュー CIフレンドリなDBドキュメント生成ツールでドキュメントの最新を維持し続ける Meetupをはじめよう おわりに テーマ発表 11月のビアバッシュのテーマは新機能特集でした。 ラク スの各製品の開発者にこんな機能作った、ここがんばったよ、ここ苦労した、というお話をしていただきました。 また、テーマ発表の後にはLT発表もあり、内容たっぷりのビアバッシュでした。 Mail Dealer 今後リリース予定の機能についての発表でした。 いきなりですが、未リリース機能なので、内容は社外秘。本ブログでお伝えすることは出来ません… ですが、求められる要件と実装面の課題との狭間での激しい闘いのお話を聞くことが出来ました。 配配メール 今年7月にリリースした配配メールv5.0の機能についての発表でした。 配配メールv5.0ではデザイン変更、複数ユーザ対応を実施したそうですが、デザイン変更は全画面ですし、複数ユーザ対応も権限など全機能に関わる部分があり、圧倒的なタスク量だったとのことです。 改修対象ソースの洗い出しや、全画面の現状確認+テストに苦労したというお話を聞くことが出来ました。 楽楽精算 楽楽精算では、ユーザ操作を自動化する機能を開発しており、その中でも iOS アプリについての発表でした。 iOS アプリは、領収書明細の自動入力を実現しています。※ 電子帳簿保存法 オプション必須の機能 図メインのスライドになると何故か右から左の資料になっている点が気になりました。 Chat Dealer 既存機能のチャットボットを強化する新機能として開発された「ボットレポート」についての発表でした。 使用中のチャットボットの設定をブラッシュアップするために使用される機能で、実際にデモを交えて解説していただきました。 チャットボットの設定画面がそこはかとなく働くDBの自動処理設定に似ている気がしたのは私だけではありませんでした。 働くDB 自動処理ジャンプパーツについての発表でした。 オプション機能ですが、ジャンプパーツを使用することによって、条件分岐後に同じ処理をする場合の設定がきれいになるそうです。 before-afterを例で挙げていただきましたが、たしかにパーツ数が減って見やすくなっている気がします。 LT発表 LT発表は3人の発表者が登壇してくださいました。 内容は自由で、テーマに関係なく、思うままに発表していただきました。 街ブラUIレビュー 以前にも街中のBAD UIを発表して下さった方が、その続編ともいえる内容での発表でした。 言い回しのおかしい説明や、何かを目立たせるための強引な注意書きは定番の内容ですが、発表の中で気になったのが下の写真です。「電光 掲示 板を見たあと絶対に時計を確認しますよね」と聞いたときのアハ体験がとても印象的でした。 CIフレンドリなDBドキュメント生成ツールでドキュメントの最新を維持し続ける 外部スライドを使用してのツール紹介の発表でした。 tbls というツールの紹介でしたが、肥大化したDBに対して、後付けでテーブル定義をすぐに作成できるというのは非常に魅力的なツールだと感じました。 speakerdeck.com github.com Meetupをはじめよう 先日開催されました、 Rakus Meetup Osaka #1 についての発表でした。 なぜ開催するのか、開催すると何が嬉しいのか、から始まり、開催するにあたっての心構えまでをまとめて発表していただきました。 おわりに 11月のビアバッシュをダイジェストでお送りいたしましたが、いかがでしたでしょうか。 各製品の新機能/オプションについて気になった方は、 ・ご利用中のお客様は、サポート窓口もしくは各製品のサポートサイト ・新規でご検討のお客様は、製品ページからのお問い合わせ にて詳細をご確認くださいませ。

最近、自宅で Laravel を使ったアプリを作成しています。 せっかく作ったアプリなので、公開しようとしたのですが、あくまで趣味の範囲であり、有料の環境を使おうとは思えず、Heroku へデプロイすることにしました。 今回は、Heroku でLaravel アプリをデプロイするための手順を簡単に説明します。 前準備 Profile の作成 .envファイルについて Heroku アプリ作成 Heroku へ push する メールの送信設定 その他 参考サイト 前準備 Heroku のアカウント作成と、Heroku CLI のインストールは事前に済ませてください。 Profile の作成 Heroku アプリの設定値を書き込む Profile を Laravel プロジェクトの直下に作成し、以下の内容を書き込みます。 これにより、Webサーバに Apache を使用し、Laravel の public ディレクト リをドキュメントルートにすることができます。 web: vendor/bin/heroku-php-apache2 public/ ファイルを作成次第、master ブランチに Profile を commit します。 .envファイルについて Laravel の .env ファイルでは、ローカルの 環境変数 を設定できます。 Heroku へのデプロイは、Git を用いて リポジトリ を Heroku へ push することで行うため、 git の管理外である .env ファイルを Heroku へ設置できません。 そのため、config ディレクト リ内の 環境変数 を Heroku 環境で使用したい値に変更しておきます。 Heroku アプリ作成 Laravelアプリの ディレクト リに移動し、 heroku login コマンドでメールアドレスとパスワードを入力し、Heroku にログインします。 その後、Heroku へ PHP アプリを作成するために、 heroku create コマンドを実行します。 > heroku login heroku: Enter your login credentials Email [xxxx.xx.xx@xxx.xx]: Password: ******* Logged in as xxxx.xx.xx@xxx.xx > heroku create my-app 実行できたら、 heroku apps コマンドを実行することで、Heroku にアプリケーションが増えていることがわかります。 Heroku へ push する Heroku へアプリが追加出来たら、作成したプロジェクトを Heroku へデプロイします。 デプロイと言えど、やることは Heroku へ master ブランチを push するだけです。 > git push heroku master 少し時間がかかりますが、push ができればデプロイ完了です。 メールの送信設定 作成していたアプリでは、メールを送信する必要がありました。しかし、Heroku から直接メールを送信することはできないので、他の方法を考える必要があります。 今回は、 Gmail に対して SMTP 接続を行い、メールを Gmail を用いて送信するようにしました。 手順としては、 Google アカウントにて、 Gmail の SMTP 接続を許可したうえで、config/mail. php の 環境変数 を以下のように変更します。 'driver' => env('MAIL_DRIVER', 'smtp'), 'host' => env('MAIL_HOST', 'smtp.gmail.com'), 'port' => env('MAIL_PORT', 465), 'from' => [ 'address' => env('MAIL_FROM_ADDRESS', 'my.gmail@gmail.com'), 'name' => env('MAIL_FROM_NAME', 'Fromの名前'), ], 'encryption' => env('MAIL_ENCRYPTION', 'ssl'), 'username' => env('MAIL_USERNAME', 'my.gmail@gmail.com'), 'password' => env('MAIL_PASSWORD', 'xxxxxxxxxxxxxxxx'), // Gmail設定時のパスワード文字列 これにより、Laravel アプリからメールを送信することができるようになります。 その他 その他、Heroku ではカスタム次第でいろいろな機能が使えます。 ちょっとしたアプリ作成や、実装の練習成果を公開する場合は、非常に便利ですね。 参考サイト qiita.com

はじめに 開発エンジニアのamdaba_sk（ ペンネ ーム未定）です。 前々回 、 前回 と弊社エンジニアへのなんちゃってインタビューで記事を書いてきましたが、今回は久々に調べものをした結果をまとめてみようかと思います。 目次 はじめに 目次 経緯 ラインエディタ ed の概要 edの機能 コマンドライン モード コマンド一覧 行指定 指定された行の操作 その他 ed を実際に使ってみた 同じedでも環境によって違うこともある おわりに 参考 経緯 実は私は自宅では非常に貧弱な性能のマシンしか持っていません。でもやっぱり家でも趣味の開発はしたいわけですが、まずエディタ選びが悩ましい。 Eclipse は動くには動くけどどうももっさりしてて使ってられない。 Atom エディタも同じ感じ。 Visual Studio Code やGeanyという軽量エディタはわりとマシだったものの、時間が経つにつれてだんだん重くなっていく…。 結果ターミナルで vim という選択肢に行き着いたわけですが、やはりあまり使いこなせない。何とか使いこなせるようになろうと vim の操作を調べるうちに、ラインエディタというものの存在を知りました。 ラインエディタ vi( vim )はスクリーンエディタというものに分類されるそうです。 テキストエディタ といえば、画面上に編集するテキストを表示し、その上でカーソルを移動させて編集を行なうものを連想しますが、そういったエディタがスクリーンエディタと呼ばれます。 対してラインエディタでは、画面上への表示は最小限です。スクリーンエディタと異なり内容の閲覧/編集はそれぞれ独立した機能であり、目的の行を抽出、編集、更新というサイクルで編集を行います。 最初期の テキストエディタ の形であり、スクリーンエディタの開発以前は主にこれが使用されていたようです。 ed の概要 ed はラインエディタの一つであり、初期の頃から存在する UNIX 上の標準的な テキストエディタ の一つです。今も事実上全てのバージョンの UNIX と Linux に装備されています。 ただ最近では vi や Emacs 、その他のスクリーンエディタにとって代わられ ed を対話的に使用することは滅多に無いようです。ただ問題が発生したときには ed が使用可能な唯一のエディタである場合もあり、そのような場合に限って ed は対話的に使用されます。 またエディタコマンドは標準入力で受け取られるので、 シェルスクリプト 内で使用することが出来、そういった用途で使われることはあるようです。 edの機能 コマンドライン ed を起動するには端末で以下のようにタイプします。オプションとファイル名を引数として指定できます。 ed [options] [file] 代表的なオプションは以下のものがあります。 オプション 長い書き方 説明 -h --help 使用法を表示して終了 -V --version バージョン情報を表示して終了 -l --loose-exit-status コマンド実行に失敗しても終了ステータス 0 を返す -p STRING --prompt=STRING プロンプトとして STRING を指定 モード ed には、コマンドモードと入力モードがあります。 コマンドモードではエディタを操作するためのコマンドを入力してテキストの編集や置換、行の削除などを行っていきます。存在しないコマンドなどを入力したなどのエラー時は、 ? と表示されます。 入力モードでは、コマンドを実行することはできません。標準入力から入力されたデータは、 直接エディタバッファへと書き込みとされます。ピリオド1つだけの行を入力すると、入力モードを終了します。 コマンド一覧 行指定 ed では常に操作の対象となる行を指定する必要があります。 ed は現在行を管理しており、コマンドに行番号が指定されない場合は、現在行がデフォルト行として用いられます。ファイルが最初に読み出された直後は、現在行はファイルの最後の行となります。一般的に、現在行はコマンドが操作した最後の行となります。 なお行番号は1始まりです。 コマンド 内容 . 現在行 n n 行目 + n 現在行より n 行後の行 + 現在行の１行後の行。 +1 と同じ - n 現在行より n 行前の行 - 現在行より１行前の行。 -1 と同じ $ ファイルの最終行 m , n m 行目から n 行目の範囲。 m , n は数字または単一行指定コマンドを使用可能。e.g., 5行目から10行目を指定する場合は 5,10 、ファイル全体を指定する場合は 1,$ , ファイル全体。 1,$ と同じ ; 現在行から最終行までの範囲。 .,$ と同じ 指定された行の操作 テキストの編集や置換、行の削除などは、行指定とコマンドを組み合わせて行います。以下の表では括弧書きした部分が行指定で、省略時のデフォルト動作を示しています。 コマンド 内容 (.) i 指定した行の前にテキストを追加。編集モードになる (.) a 指定した行の後ろにテキストを追加。編集モードになる (.,.) c 指定した範囲の行を削除して、そこにテキストを追加。編集モードになる (.,.) d 指定した範囲の行を削除 (.,.) y 指定した範囲の行をカットバッファにコピー（yank） (.) x カットバッファの内容を指定した行の後ろにペースト (.,.) m (.) 左辺で指定した範囲の行を右辺で指定した行の後ろに移動。右辺には 0 を指定できる (.,.+1) j 指定した範囲の行を連結 (.,.) p 指定した範囲の行を表示 (.,.) n 指定した範囲の行を行番号つきで表示 (1,$) g/ reg / cmd 指定した範囲の行のうち、 正規表現 で reg と一致した文字列のある行に対し、 cmd を実行 (.,.) s/ reg / rep /n 指定した範囲の行のうち、 正規表現 で reg と n 番目に一致した文字列を rep に置き換える (.,.) s/ reg / rep / 指定した範囲の行のうち、 正規表現 で reg と1番目に一致した文字列を rep に置き換える。 s/ reg / rep /1 と同じ (.,.) s/ reg / rep /g 指定した範囲の行のうち、 正規表現 で reg と一致した文字列をすべて rep に置き換える ($) = 指定された行の行番号を表示 その他 コマンド 内容 u 直前のコマンド実行をアンドゥ。 u コマンド自体もアンドゥできる P コマンドモード時に、行頭にプロンプト文字列を表示。 コマンドライン 引数で文字列が指定されていない時は、 * が使用される。 ! cmd cmd で指定したコマンドを、 sh を用いて実行 w [ file ] file に編集内容を書き込み q エディタを終了。編集内容が未保存の場合はエラー Q エディタを終了。編集内容が未保存でも強制的に終了 ed を実際に使ってみた edコマンドの使用例として、実際にファイルの編集を行ってみました。 とりあえず ed のバージョンを確認。1.1のようです。 $ ed --version GNU Ed 1.1 Copyright (C) 1994 Andrew L. Moore, 2008 Antonio Diaz Diaz. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. 適当な ディレクト リに移動します。 $ cd /some/path $ ls -a ./ ../ ファイルが何もないですが、せっかくなので ed で作ることにしましょう。 $ ed P *i hoge hoge hoge . *= 1 *a fuga fuga fuga moge moge moge piyo piyo piyo . *= 4 *w test 60 *q 最初に P コマンドを使用してプロンプトを出すようにしています。 i や a で行を追加。 = で現在行の番号を確認しています。最後は w コマンドで"test"という名前でファイルに保存しました。 確認してみると、 $ ls test $ cat test hoge hoge hoge fuga fuga fuga moge moge moge piyo piyo piyo 思った通りにファイルが作成されていました。 起動時にファイル名を指定するとエラーが表示されるのですが、最後の保存時に名前を指定しなくてもよくなるようです。 $ ed test2 test2: そのようなファイルやディレクトリはありません P *i hoge . *w 5 *q $ ls test test2 次に作成したファイルを編集してみます。 $ ed test 60 P *,n 1 hoge hoge hoge 2 fuga fuga fuga 3 moge moge moge 4 piyo piyo piyo *2c foo bar baz spam ham egg . *,n 1 hoge hoge hoge 2 foo bar baz 3 spam ham egg 4 moge moge moge 5 piyo piyo piyo *,s/moge/toto/g *,n 1 hoge hoge hoge 2 foo bar baz 3 spam ham egg 4 toto toto toto 5 piyo piyo piyo *wq 70 最初に行番号付きで現在のファイル内容を確認しました。その後 c コマンドで2行目を変更し、ついでに新しい行を続けて入力しています。再度行番号付きで現在のファイル内容を確認すると、確かに2行目が変更され、その下に行が追加されていました。手入力で行の中の一部分を変更することはできないので、仮に同じ部分があったとしてもその行は全部書き直しです。 最後の保存と終了は同時に出来るみたいです。vi も同じですね！ ed 終了後にファイルの中身を確認すると、きちんと変更されていました。 $ cat test hoge hoge hoge foo bar baz spam ham egg toto toto toto piyo piyo piyo 同じedでも環境によって違うこともある Windows にインストールした BusyBox 1.22.1に含まれる ed は、上でまとめたものとはオプションやコマンドが若干異なるようでした。 コマンドライン オプションが使えない デフォルトでプロンプトが表示されている プロンプト文字列は : P コマンドがない 他にも違いはあるかも おわりに 古くからあるがゆえに逆に知らなかったエディタ ed について調べてみました。 実際使ってみましたが、ファイル内が今どんな状態なのかがすぐにわからないのが少し不安に思いました。いくら軽量だとは言え普段使いするならやっぱりスクリーンエディタかな、というのが正直な感想です。ただ シェルスクリプト で使うこともあるかも…。 なお今回まとめたのは ed のコマンドの中でも一部にすぎません。もっと詳しく知りたいなら参考に挙げたページや、manやinfoを見てくださいね。 参考 テキストエディタ - Wikipedia Man page of ED ED - Wikipedia edを使ってみる http://www.uetyi.com/server-const/entry-271.html ラインエディタ体感ツアー――vi/vimの「動作モード」なるものの謎に迫る - 新・日々録 by TRASH BOX@Eel おすすめのLinuxフリーテキストエディタ12選！ 5-1 どんな環境でも使えるライン・エディタ - edエディタ - エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

スクラム とは こんにちは。strongWhiteです。今回は スクラム に関する解説記事です。 スクラム とは、変化の激しいソフトウェア開発の問題に対応するための開発手法です。 ソフトウェアは建築物などの三次元的な物体とは異なり、認識しにくく不透明な存在であるため、 潜在的 な問題（バグなど）を早期に察知するのが難しい性質を持っています。また、問題を認識できたとしても修正などの後戻りが難しい場合があります。このようなソフトウェア開発の問題を解決するのが スクラム です。 スクラム では、あらかじめ定めた期間内に一定の成果物を作成（開発）し、徐々にソフトウェアを構築するというアプローチを取ります。ソフトウェアに「透明性」を見出し、 潜在的 な問題を認識しやすくするのです。 今回の記事では スクラム を用いた開発を始める方向けの前提知識として、 スクラム 開発の関係者（ スクラムチーム ）と スクラム 開発中で発生するイベント（ スクラムイベント ）について解説します。 スクラムとは スクラムチーム プロダクトオーナー 開発チーム スクラムマスター まとめ（1） スクラムイベント スプリント スプリントプランニング デイリースクラム スプリントレビュー スプリントレトロスペクティブ まとめ（2） スクラム チーム スクラム 開発は、以下の役割を担う人（たち）が相互に作用し合って進捗していきます。 プロダクトオーナー 開発チーム スクラム マスター 各役割とその使命については後述します。これらの役割を担い、 スクラム 開発を進める人たちを スクラムチーム と呼びます。 プロダクトオーナー プロダクトオーナー は開発しようとしているプロダクトのオーナーであり、プロダクトの最終責任者です。 プロダクトオーナーは「プロダクトのビジネス的価値」に着目し、プロダクトで実現したいことに優先順位をつけてリスト化した プロダクトバックログ を作成・更新・管理する役割を担います。プロダクトオーナーは 開発チーム にプロダクト バックログ を公開することで、なぜそのプロダクトを作るのかというビジョンと優先順位を理解してもらうよう努めます。 開発チーム 開発チーム はプロダクトオーナーが決定した要件を成果物として実現するメンバーの集まりです。 プロダクトの開発責任を担うのが開発チームであり、プロダクトに不具合がある場合や、プロダクトオーナーの定める品質基準に達しない場合にそれらの問題解決に努めます。 スクラム マスター スクラムマスター はプロダクトオーナーと開発チームが スクラム を実行する手助けを行います。 スクラム マスターは現場の スクラム のルールを熟知し、 スクラム チームが最高のパフォーマンスを発揮できるように働きかけます。開発チームが技術的困難に遭遇している場合は解決策を提示し、プロダクトオーナーがプロダクト バックログ の更新に問題を抱えている場合はアド バイス します。また、 スクラム チームの進捗に影響を及ぼす要因の排除や、 スクラム の理解が不足しているメンバーに対して コーチン グするなど、その役割は多種多様です。 まとめ（1） スクラム 開発における各役割とその関係の理解が少しでも進めば幸いです。 「要するにプロダクトの責任者と開発チームがいて、それらのサポーターを通して開発を進めるってこと？」 ...今は恐らくこれぐらいの認識ではないでしょうか。実際に スクラム を導入されるとそれぞれの役割の重要性が見えてくるかと思います。 「役割はなんとなく理解できたけど、どのように「 スクラム を実行する」の？開発以外のイベントって何？」 それでは次章以降、 スクラム 開発で発生するイベント（ スクラムイベント ）について解説します。 スクラム イベント スクラム 開発では、単に開発を進めるだけでなく、ソフトウェアの「透明性」を見出すためのアプローチを取る必要があります。そのために規則的に行われる5つのイベントがあり、これらを スクラムイベント と呼びます。 スプリント スプリントプランニング デイリー スクラム スプリントレビュー スプリントレトロスペクティブ スクラム イベントは定期的なミーティングとは違い、自分たちの スクラム のあり方に問題があれば解決し、より良い状況を作るために行います。このようにフィードバックを織り込んだイベントを実施することで開発を円滑に進めます。 スプリント スプリント は開発の イテレーション のことです。 スクラム チーム内で適当な期間を定めますが、通常は1週間〜3週間が多いです。 決められたサイクルで開発を進めることで、 スクラム チームで完了できる仕事量を把握します。 スプリントプランニング スプリントプランニング はスプリント開始時に行われる最初の スクラム イベントです。 「スプリント期間内で何ができるか（何をするか）」を明らかにするミーティングであり、 スクラム チーム全員が参加します。プロダクト バックログ で優先順位の高いものから順に完了できそうなものを選び、選んだ項目について具体的なタスク量を明確化するために適当な単位でタスクを分割してリスト化した スプリントバックログ を作成します。 デイリー スクラム デイリースクラム はいわゆる「朝会」であり、昨日したこと、今日やること、課題を共有する場です。 主に開発チームが行う スクラム イベントであり、スプリント期間中は決まった時間に毎日行います。そのスプリントのゴールが達成できそうかと、日々の仕事の進捗を把握します。また、デイリー スクラム には スクラム マスターも参加します。 スプリントレビュー スプリントレビュー はスプリントの成果物を披露し、プロダクトについてフィードバックを得るためのミーティングです。 スクラム チーム全員が参加します。 スクラム チームの他に ステークホルダー （ スクラム チームに所属しない会社の経営陣、あるいは顧客など）を招待する場合もあります。開発チームはスプリント期間内に達成できたことと、達成できなかったことを伝え、次回以降何をどう作っていけばいいか議論します。 スプリントレトロスペクティブ スプリントレトロスペクティブ はスプリント終了時に行われる最後の スクラム イベントです。 スクラム チーム全員が参加します。 いわゆる「振り返り」であり、 スクラム チームの現状を見直し、次回以降のスプリントでより良い仕事を行うための改善策を出していく場です。開発チームと スクラム マスターが中心になって進め、次回のスプリントに向けてのアクションプランを出します。 まとめ（2） スクラム 開発の進め方が理解できたでしょうか。本当はもう少し細かい話もあるのでが、ざっくりとまとめると 計画→開発→お披露目→振り返り→（以下、繰り返し） となります。 イテレーション が設定されているおかげで問題に気付きやすくなり、改善や後戻りしやすいシステムになっています。これこそが スクラム 開発の醍醐味であり強みでもあります。これから スクラム を始める人にとって、今回の記事が少しでも参考になれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

id:radiocat です。このたび大阪Meetupの運営委員に任命されました！ 9月に東京でMeetupを開催しましたが、大阪でもやります！ rakus.connpass.com 新しくなった大阪オフィスは本当に良い環境で、広くなった セミ ナールームを早く活用したい！ということで移転直後から準備を進めてきました。 そんな大阪オフィスの様子は↓コチラをご覧ください。 www.wantedly.com テーマは『大阪開発チームのチャレンジ』です せっかくの大阪初開催ですので、大阪所属のエンジニアで トーク セッションを固めました。東京を中心として盛んに行われているITエンジニアの勉強会ですが、最近は大阪でも活発に行われていて私もよく同業他社の勉強会に参加させて頂いています。せっかく、梅田駅から徒歩5分という立地で セミ ナールームを拡充して環境も整ってきたので、我々も一緒に大阪のIT業界を盛り上げていきたいと思っています。今後はコミュニティへの会場提供もしていきたいので、この機会に新しいオフィスを覗いてみていただければと思います。 当日の トーク セッションは以下を予定しています。なお、 トーク 内容と順番は仮のものですので当日までに変更の可能性がありますがご了承ください。 チャットディーラーの高速開発を支えるLaravel 吉元和仁（よしもとかずひと） 今年夏に開催された PHPカンファレンス 関西 2018 の登壇内容をベースにお話しします。10年以上 PHP でノン フレームワーク により開発・運用されてきた主力サービス（メールディーラー）の開発チームが、新規に姉妹サービス（チャットディーラー）を立ち上げる際に Laravel を選択しました。 開発期間半年というスピードが求められる中で、Laravel での新規サービス立ち上げのチャレンジをご紹介します。 Why Mob Programming? - モブプロという働き方 - 大平直宏（おおひらなおひろ） 大阪の楽楽精算の開発チームでは、 スクラム 開発を取り入れて新機能の開発に取り組んでいます。急成長するサービスの開発を支えるためこの1年間で4人のメンバーが増えており、メンバー同士の知識共有が課題となっています。 アジャイル な開発を推進するために取り入れているモブプログラミングのチャレンジをご紹介します。 トウダン・ジャーニー 川並裕（かわなみゆう） 今年の夏に開催された PHP カンファレンス関西 2018 で、会社として初めて技術イベントに協賛し、2 名のエンジニアが登壇しました。開発組織を横断した登壇推進チームが業務として登壇プロジェクトを推進したチャレンジをご紹介します。 大阪のエンジニア同士で交流しましょう！ 今回は参加者のみなさまの中からもLTを募集いたします。テーマは同じく「チャレンジ」です。みなさまが普段チャレンジしていることを共有していただければと思います。そして トーク セッション後には交流会も開催します。弊社のエンジニアも含めて参加者同士で情報を交換し合い、エンジニア同士の交流を深めていければと思っています。 会場の場所や参加方法については以下のconnpassに掲載していますのでご確認のうえお申し込みください。みなさまのご参加をお待ちしております！ rakus.connpass.com

はじめに こんにちは、strongWhiteです。 ラク スでは毎月1回、開発チーム主催の ビアバッシュ を開催しています。 ビアバッシュとはビールや軽食をいただきながら技術内容について楽しく語り合う交流会です。 今回は10月に大阪で開催したビアバッシュの内容を記事にしたいと思います（過去の開催も記事になっていますので、よろしければ下記をご覧ください）。 tech-blog.rakus.co.jp 今回は「行ってきた特集」 大阪のビアバッシュは決められたテーマに沿って発表する「 テーマ枠 」と、自由なテーマで発表する「 自由枠 」の2セッションを設けて発表を進めます。 また、「自由枠」は質疑応答ありで15分間の発表と質疑応答なしで5分間の発表（LT枠）に分かれます。 10月のテーマは「 行ってきた特集 」であり、各々がこれまで参加した勉強会や セミ ナーの様子と、そこで得た学びを共有していただきました。 今回の記事では主に「テーマ枠」の発表の様子をご紹介いたします。 はじめに 今回は「行ってきた特集」 行ってきた特集（テーマ枠） 京都アジャイル勉強会に行ってきた ハッカソンあるある 今回から新オフィスで発表 おわりに 参考 行ってきた特集（テーマ枠） 京都 アジャイル 勉強会に行ってきた 筆者が「 京都アジャイル勉強会 」に赴き、 スクラム について学んだことを発表いたしました。 スクラム とは「ソフトウェアに変更はつきもの」という前提から、要求や仕様変更に柔軟に対応するために生まれたソフトウェア開発手法です。 もともと私の所属するチームでは スクラム による開発を推進しており、私自身の スクラム に対する知識理解の向上を目的に勉強会に出席しました。 この勉強会はディスカッション形式で、会場には スクラム を実践する人たちが集まります。特にタイムボックスはなく、開始時間になると各々が日頃から スクラム について感じている課題や疑問を議論し合います。同じ苦難や困難に立ち向かう者同士、お互いに スクラム に対する理解を深め合うのがこの勉強会の目的です。 筆者は個人的に「スプリント バックログ の作成に時間がかかる問題」を抱えており、問題解決のヒントを得るため勉強会へと足を運びました。現在は、勉強会で得た知見をもとに自身の スクラム に対する姿勢の見直しを行なっています。 ハッカソン あるある ハッカソン に参加しているとこういう場面絶対にある！という「 ハッカソンあるある 」を発表していただきました。 ハッカソン によく行かれる方は、↓と同じようなことを感じられたことがあるのではないでしょうか？ 名刺は切れる 名刺を交換すると世の中は狭いことがわかる ハードウェアがわかるとありがたがられる ネットワークはもっとありがたがられる etc... ハッカソン の場合、（テーマにもよりますが） プログラマー よりハードウェアやネットワーク面に強い方がいると心強いと思います。 突発的なネットワーク障害に遭遇した場合に、すぐに原因を究明して修正してくれると勉強会もスムーズに進行するかと思います。 筆者は ハッカソン に参加した経験はないですが、「名刺を交換すると世の中は狭いことがわかる」はよくわかります。 最近も、プログラミングの外部勉強会に参加したのですが、そこで大学時代の同期に出会いました。以前にエンジニアになったとは聞いていたのですが、世の中は狭いものです...「あるある」は共感するものがあるととても面白いです。 今回から新オフィスで発表 ラク スは9月末に大阪オフィスを毎日インテシオから 梅田ゲートタワー へ移転しました。今回のビアバッシュは引っ越し後初のビアバッシュとなりました。 年々新卒をはじめ、社員の増加に伴ってビアバッシュの参加者も増加してきたため、旧オフィスでは開催スペースの圧迫化が問題だったのですが、新オフィスでは広々とした開催スペースとなり、より新鮮な気持ちでビアバッシュを楽しむことができました。 おわりに いかがでしたでしょうか。今後も定期的にビアバッシュの様子をお伝えしていこうと思います。次回のテーマは「 新機能特集 」を予定しています。 最近の弊社商品のリリース機能を紹介できたらと思います。どのような発表になるか楽しみです。 参考 京都アジャイル勉強会 スクラム ハッカソン

はじめに こんにちは、開発エンジニアのnorth_mkyです。 先日業務にて負荷検証を JMeter で行うことになり、弊社エンジニアが書いた下記の記事を読みつつ複数のシナリオ作成を行いました。 tech-blog.rakus.co.jp ですが最初の1シナリオの作成で全然想定している動作にならず、予想よりも3倍ほど時間がかかってしまいました。。。 シナリオ作成にあたって必要な知識として、もちろんシナリオを作成する対象の画面の仕様理解も必要ですが、 思った以上に小さな設定ミスが多い です。 この記事では原因箇所に気づくまでのプチ・ベストプ ラク ティスをご紹介したいと思います。 はじめに 対象読者 シナリオ作成トラブルシューティングガイド Step0. 準備 Step1. jmeter.logを確認する Step2. リクエストパラメータの値が正しいか確認する Step3. シナリオ実行がどこのリクエストで落ちたか実行順に見て特定する おわりに 対象読者 シナリオを作成している 方には有益な記事になっていると思います。 特に少し複雑なシナリオを作成しようとしている方にはぜひ一度みていただけたらと思います。 JMeter のシナリオ実行はしたことがあるけどシナリオ作成は初めて/始めたばっかりの方 シナリオ開始から終了までの間の画面遷移が多い( サンプラー が多い) 特定のリク エス トパラメータの値を外部ファイル( CSV )から読み込んでセットするようにしている リク エス トパラメータが動的に変わる画面遷移がある CSRF トーク ン シナリオ作成 トラブルシューティング ガイド ミスの原因調査が簡単なものから除々に特定が難しい原因調査へとステップを踏むと効率的 ですのでそのような構成にしました。シナリオ デバッグ をしていると最初は直しても直しても違うエラーがでてくる...と思わせてくるところがあるのですが、多くは簡単な設定ミスなので、気にせず淡々と確認していきましょう！ Step0. 準備 まず最初に デバッグ ができるようにする設定が必要です。 テスト計画 の直下に以下2点の コンポーネント を追加します。設定を適切に行うと 実際に実行したときのリク エス ト・レスポンスの情報がすべて見れるようになります 。注意なのですが、 デバッグ 用に追加するので 実際に負荷検証を流すときには必ず無効にしてください。 正しく計測ができない可能性があります。 リスナー > シンプルデータライタ 実行結果をファイル出力する コンポーネント 。以下のような xml ファイル形式に設定する リスナー > 結果をツリーで表示 1.で出力したファイルを読み込んでリク エス ト・レスポンスをわかりやすい形で表示する コンポーネント 失敗したリク エス トは赤字にしてくれる 1 まちがっていそうなパラメータを赤字にしてくれる URL エンコード されたパラメータをデコードして表示してくれる Step1. jmeter .logを確認する ポイント 外部ファイルが正しく読み込まれているか パスの指定が誤っていないか 外部ファイルの書き方とシナリオで設定したカラムの順番、情報に誤りがないか いざテスト実行してみたものの、本来ならもっと実行に時間がかかるところが一瞬で実行が終わってしまった...という場合はそもそもシナリオを実行するための準備に不足がある可能性が高いです。そのときはまず jmeter .logを確認します。 jmeter .logは実行ログとなっており、外部ファイルの読み込みがうまく行っていない場合はエラーとして記録を残してくれます。 jmeter .logをみて原因箇所が推測できたら、 設定エレメント > CSV Data Set Config の設定内容であったり指定したファイルの形式があっているか確認し適宜修正してください。 Step2. リク エス トパラメータの値が正しいか確認する Step0 で設定した リスナー > 結果をツリーで表示 を見て実際にアクセスしたときのリク エス トパラメータを見ていきます。 このパラメータの設定のミスが割と多いので下記ポイント4つを順番に見ていくと良いと思います。 ポイント 変数名がそのまま出ていないか 適切にURL エンコード をしているか 前画面の値を取得する 後処理 > 正規表現抽出 で設定した変数名をパラメータにセットし忘れていないか 受け渡している変数パラメータの値が前画面から正しく取得されているか 1. 変数名がそのまま出ていないか リク エス トパラメータの値を見ればすぐに見つけられます。( ${hoge} ) 大抵原因は 「 サンプラー に設定した変数名が定義した変数名と違う」 「 後処理 > 正規表現抽出 の 正規表現 が誤っていて抽出結果が空」 の いづれ かになります。 2. 適切にURL エンコード をしているか マルチバイト文字であったりURLでメタ文字や利用できない文字が含まれるパラメータをURL エンコード しないでリク エス トを投げているか、逆にすでにURL エンコード しているところに誤って二重でURL エンコード を行ってしまっている場合があります。「URL Encode?」 チェックボックス を確認してみてください。 HTTPプロキシをたててリク エス トを記録した場合、よしなに JMeter がつけてくれている場合が多いですが、 正規表現 を組んだりしていくうちにチェックが外れてしまった/ついてしまったことがでてくるかもしれません。緻密な作業でミスが起きやすいので自分を責めず、そしてめげずに進めていきましょう...( 経験談 ) 3. 前画面の値を取得する 後処理 > 正規表現抽出 で設定した変数名をパラメータにセットし忘れていないか リク エス トを記録した場合、その記録していた値のままになっているかもしれません。もう一度変数の設定漏れがないか確認してみてください。 4. 受け渡している変数パラメータの値が前画面から正しく取得されているか 1.で書いた原因に似ていますが、 正規表現 抽出で前画面から抽出自体はできていても余計な文字も拾ってきていてエラーになっている可能性があります。 リスナー > 結果をツリーで表示 ではレスポンスのbodyに対して文字列検索ができるため、リク エス トパラメータにセットした値が前画面のレスポンス内で引っかかるか確認してみてください。 Step3. シナリオ実行がどこのリク エス トで落ちたか実行順に見て特定する ポイント リク エス ト/レスポンスごとに想定の挙動になっているか確認する webサーバ/アプリログなど 画面 Step1,2を確認しても解消しない場合はいよいよシナリオをしらみつぶしに確認する作業になります。複数箇所でエラーが出ている場合は、だいたい上のエラーが引き継がれてエラーがでることが多いので焦る気持ちを抑えて上から順番に見ていきます。 レスポンスでエラー画面やエラー文言があれば、そこからコケた原因を考えられるかと思います。 アサーション を適切に設定していないとエラーなのに見た目は成功を表すグリーンのアイコンになるのでより原因特定が難しくなりますよね。後世のために原因がわかったら アサーション を追加して次もし引っかかったときは失敗を表すレッドのアイコンになるようにすると良いと思います。 おわりに いかがでしたでしょうか。長いシナリオだったりパラメータの多い画面の遷移となるとシナリオに小さいミスが起きやすくなる割に原因特定に時間がかかり気味になります。 そんなときにこの記事をみていただいて皆さんのもやもやや苦痛が少しでも和らげば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 です。 スクラム は 銀の弾丸 ではないので、いつもうまくいくとは限りません。今回は私たちのチームの失敗事例をご紹介します。 以前の投稿 でも紹介しましたが、私たちのチームは1週間スプリントを採用しています。以下のように木曜に計画を立ててスタートし、翌週木曜にレビューを行う流れです。 ご覧のように開発に注力できる期間は実質4日しかありません。油断するとすぐにレビューの日を迎えるので緊張感があります。そして、その緊張感にさらに拍車をかける要素がスプリント期間中の「休日」です。 連休の狭間の期間は スクラム を進めるべきか？ ご存知の通り、2018年の9月は2週続けて月曜が休日となる期間がありました。このままだと開発が実質3日しかないスプリントが2回続きます。 さらに、この連休期間を利用して2人の主力メンバーが休暇を取ることになりました。5人チームなので開発力は半減します。チームはこの期間をどう過ごすべきでしょうか？ 連休の狭間もスプリントを進める選択 ご察しのとおり、我々はこのままスプリントを進めました。とはいえ、さすがに丸腰でこの状況に立ち向かうほどの度胸はないので、我々なりに対策を立てて取り組もうとしました。まずはその対策をご紹介します。 連休期間の スクラム イベントは中止する 全員揃っていない状態なのでスプリントレビューは1週間スキップすることにしました。ただ、連休前の金曜から着手したスプリントを中断するのはもったいないので以下のように進めることにしました。 個々の開発は進めて良い 中途半端に作業を中断して別の事をやるのも気持ちが悪いので、出社しているメンバーは出来る範囲で開発は進めておくことにしました。ただし主力不在で開発チーム内でのフォローやレビューは手薄になるので、無理せず出来る範囲で作業を進めて、主力メンバーのレビューが必要な作業などは連休明けまで保留するようにしました。 狭間の4日間で1日分の実績を目標にする 主力2人の休暇でチーム全体のパフォーマンスは低下しますが、残りのメンバーだけでも4日あれば普段の1日分ぐらいの実績は充分達成出来るだろうと考えました。そうすることで結果的に2週間の合計が4日分の実績となるので、いつも進めている1週間スプリントと同じぐらいのベロシティを目指すことになり、感覚的にもわかりやすい目標になります。主力不在とはいえ4日で1日分なので、出勤しているメンバーにも負担がかからないはずです。 プランニングと共有をいつも以上にしっかり行う 念のため、休暇の前日に改めて主力メンバーが考えているスプリント中のタスクの進め方をチームのメンバーへしっかり共有して引き継いでもらいました。 下がりきらなかったバーンダウンチャート 結果的にこのスプリントでは、残タスク量を示すバーンダウンチャートの実績が次のようになりました。 微妙な結果です。大負けというほどでもなく、微妙な感じが逆に気持ち悪いくらいです。しかし、このスプリントのふりかえりはチームに疲弊感が漂い、私も含めてみんなモヤっとした状態で改善アクションもうまくまとめられないままスプリントは終了しました。 なぜ計画どおりにスプリントが終わらなかったのか？ いったい何が問題だったのか、後日 スクラム コーチに相談してみると3つの課題が見えてきました。 スプリントを進めるのに十分な体制ではなかった 私たちのチームのメンバー構成を改めて整理すると次のようになっています。 現在進めているプロジェクトの在籍期間が1年以上のメンバーが誰もいない状況で、目に見える人数以上にチームの体制は弱くなっています。さらに実はこのスプリントの前半の主力メンバーが休暇に入る直前まで、チームを助けるべき スクラム マスターは出張先からリモートでチームの活動に参加しており、開発チームの状況を詳細まで把握出来ない状況にありました。いつも以上にしっかり共有してから休暇に入るという事前の対策は開発チーム内の個々のメンバーの感覚に託されており、客観的にみても対策できているといえる状態かどうかは誰もわからない状況になっていました。 バックログ がReadyではなかった さて、上記のバーンダウンチャートは狭間の4日間を1日の実績としてまとめていますが、これをそれぞれの日ごとの実績に分けてみると次のような実績になっていました。 主力メンバーが休暇に入った初日から実績が上がらず、残タスクが全く減っていません。すでに危険な状況に突入していることがわかります。実はこのとき、プランニング時点の想定が覆ってそのままではタスクを進められないことがわかりました。 スクラム マスターはチームの状況を察知し、いったんタスクの終了条件を見直したりスプリントのゴールを見直すなどの調整を行い、一度は残タスクが減りましたが、すぐにまた別の問題が発生して逆に残タスクが増えてしまいました。 結果的にこの時着手していた バックログ は最初からReadyではなかったのです。つまりこのスプリントは前半時点ですでにコールド負けが決まっていました。 しかし、1つ目の原因にあるとおり、チームの体制が不十分で、前半時点ではこの状況を正しく判断できるメンバーがいませんでした。 スクラム マスターはチームの状況を正確に判断出来るだけの情報をキャッチできていなかったため場当たり的な対策を取ってしまい、結果的にはコールド負けしたチームにそのまま試合続行を促すことになってしまいました。 仕掛りがたまっていて手当てが追いつかず チームはそれでもなんとかスプリントのゴールを目指そうと取り組みました。休暇が明けてから、主力メンバーの頑張りによってなんとか持ち直しますが、計画していたゴールには到達できませんでした。 バーンダウンチャートを見るとスプリントの最後で残タスクの消化が少なくなっています。実はこのとき、仕掛中のタスクがたくさ増えすぎて経験のある主力メンバーでも残りの期間で全てを手当することは出来なくなっていました。スプリント前半に発生した問題をなんとかしようとして計画時の想定とは違う進め方をしたり、いったん保留して他のタスクに手を出した結果、想定以上に仕掛り中のタスクが増えてしまったのです。 コールド負けしない鉄則 実はこれらの原因は既に スクラム コーチの吉羽さんが別の場で示されているものでした。 slide.meguro.ryuzee.com この資料の中で アジャイル 開発でコールド負けしないための5つのポイントが挙げられています。 十分条件 で開始する Readyなプロダクト バックログ 項目だけ着手する 同時の仕掛りを少なくする フィードバックサイクルを回し続ける 技術に投資し続ける 我々は5つのポイントのうち3つを犯してしまっていました。コールド負けしてしまっても仕方ないですね。スプリントを進めるにあたり、改めてこれらの3つのポイントが重要であることを痛感しました。 開始するのに十分な条件か？ バックログ はReadyになっているか？ 仕掛りが増えすぎる進め方をしていないか？ それでも、我々はこの1回のスプリントでとても大きな学びを得たとも思っています。今後はこれらをしっかり意識してチームで取り組もうとしています。 REGIONAL SCRUM GATHERING TOKYO 2019 のCfPを出しました！ 2019年1月9日〜11日に大崎ブライトコアホールで1年に1度の スクラム のビックイベント「REGIONAL SCRUM GATHERING TOKYO 2019」が開催されます。 2019.scrumgatheringtokyo.org 私たちの スクラム の取り組みを多くの方に知っていただき、そして私たち自身が学びを得るためにプロポーザルに応募しました。下記のリンクをご確認いただき、ご興味のあるかたは是非likeをお願いします（締切が10月末ですのでご注意ください）。 https://confengine.com/regional-scrum-gathering-tokyo-2019/proposal/7956/- confengine.com REGIONAL SCRUM GATHERING TOKYOでは毎回たくさんの素晴らしいセッションが行われますので、 スクラム に興味のあるかたはぜひチケットを入手してご参加いただければと思います。

初めに こんにちは！エンジニアの id:FM_Harmony です。 前回はgitのfetchコマンドについて、記事を投稿しました。 tech-blog.rakus.co.jp 今回は postgreSQL の対話型ターミナル、 psql のオプションについて紹介したいと思います。 普段の業務でも、 psql コマンドの -f オプションや -c オプションを利用してクエリを発行する機会が多いのですが、 psql には他にも便利なオプションが備わっています。 多くのオプションが存在しますが、今回はその中でも個人的に便利だと思う4つのオプションについて紹介します。 初めに -a：発行したクエリ、コメントも出力する -t：抽出結果のみ出力 -A：位置揃えを行わない -F：区切り文字を指定する 利用例：抽出結果からcsvファイルを作成する 終わりに 参考 -a：発行したクエリ、コメントも出力する psql コマンドを利用して SQL ファイルやクエリの発行を行った場合、実行結果のみ出力されます。 sample.sql --this is comment SELECT columnA, columnB FROM some_table; $ psql -U postgres -d some_db -f sample.sql columnA | columnB ---------+--------- A | B (1行) この時、 psql コマンドに -a オプションを指定することで、発行したクエリや SQL ファイルに記載したコメントも出力することができます。 $ psql -U postgres -d some_db -f sample.sql -a --this is comment SELECT columnA, columnB FROM some_table; columnA | columnB ---------+--------- A | B (1行) このオプションを使うことで、例えば SQL ファイルの実行結果ログをレビューしてもらう際など、レビュー者が SQL ファイルの実行コマンドを把握しやすくなります。 -t：抽出結果のみ出力 通常、 psql コマンドを用いて抽出結果を出力する場合、列名や出力した行を出力結果に含めます。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" columnA | columnB ---------+--------- A | B (1行) psql コマンドに -t オプションを指定することで、抽出結果から列名や行数表示を除いて出力することができます。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" -t A | B 例えば、 psql で抽出した結果を基にして何らかの繰り返し処理を行う スクリプト を作成する際など、抽出結果に列名や行数表示は必要ない場合があります。 そこで、このオプションを使うことでそれらを除いた出力結果を取得することができます。 -A：位置揃えを行わない psql コマンドを利用した際の抽出結果は、表形式に整形されて出力されます。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" columnA | columnB ---------+--------- A | B (1行) この時、 psql コマンドに -A オプションを利用することで、位置揃えなしの区切り文字を | とした形式で抽出結果を出力することができます。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" -A columnA|columnB A|B (1行) 主にこのオプションは、次の -F オプションと組み合わせて抽出結果の出力形式を変更する際に利用します。 -F：区切り文字を指定する 前述の -A オプションと共に利用することで、抽出結果の出力形式を変更することができます。 -F オプションの後に指定した文字を、抽出結果の区切り文字に指定します。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" -A -F : columnA:columnB A:B (1行) 利用例：抽出結果から csv ファイルを作成する 今回紹介したオプションの利用例として、データベースの抽出結果から csv ファイルを作成する方法をご紹介します。 この場合、 -A 、 -F オプションが有効です。 2つのオプションを組み合わせて区切り文字を カンマ にすることで、抽出結果を csv ファイルの形式で出力することができます。 $ psql -U some_user -d some_db -c "SELECT columnA, columnB FROM some_table;" -A -F , columnA,columnB A,B (1行) あとは、出力結果に対してリダイレクトなどを用いることで、抽出結果から csv ファイルを作成することができます。 また、列名は CSV ファイルに含めるが、行数は含めたくないという場合、 grep コマンド などと組み合わせて行数表示を出力結果から除くと良いでしょう。 # 行数表示を削除する一例 $ psql -U some_user -d some_db -A -F , -c "SELECT * FROM some_table;" | grep -v "行" columnA,columnB A,B 終わりに psql のオプションをいくつか紹介してみましたが、いかがでしたでしょうか。 今回紹介したオプションは抽出結果に影響を与えるものばかりですが、もちろんデータの追加や更新時に利用できるオプションも存在します。 ただ、 psql コマンドを利用する目的として多いのは、やはりデータ抽出だと思います。 なので、今回紹介したオプションを利用できる機会というのは、ほかのオプションに比べて多いように感じます。 皆さまも psql コマンドを利用される際は、今回紹介したオプションの利用を検討してみてはいかがでしょうか。 参考 psql - PostgreSQL 9.6.5文書 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

大阪オフィスの移転 を機に、生活リズムも絶賛見直し中の @kawanamiyuu です。 今回は昨年度から取り組んでいる、通称「かみせんプロジェクト」の今期の成果（の一部）についてご紹介します。 かみせんプロジェクトとは ミッション 目標 社内システムのマイクロサービス化 社内システムの概要 かみせんプロジェクト開始前 2018 年 9 月現在 マイクロサービスの結果整合性 課題感 検証内容 検証結果（得られた知見） サービスの分割は難しい 結果整合性の担保は難しい 最後に かみせんプロジェクトとは かみせんプロジェクトとは「開発の未来に先手を打つプロジェクト」の略称で、2017 年度に取り組みが始まりました。 ミッション 『継続的に新しいことに取り組み、組織要望に対して迅速にトレンド技術で応えることができるようになる』 目標 具体的には以下の実現のための技術検証や知見獲得を、社内システムのマイクロサービス化を題材に行っています。 ソフトウェア規模に比例した開発効率低下の軽減 無停止デプロイ、不具合発生率低下などの高可用性の実現 現行ソフトウェアからの段階的な移行の実現 社内システムのマイクロサービス化 社内システムの概要 LAMP ( PHP ) で構築されたモノリシックな Web アプリケーション エンジニア、 経理 担当者などが、社内からのみアクセスして利用する プロジェクト管理機能、開発稼働集計機能などを提供する かみせんプロジェクト開始前 すべての機能がモノリシックなアプリケーションとして提供されている 2018 年 9 月現在 モノリシックなアプリケーションから、一部の機能をマイクロサービスとして切り出した マイクロサービスは AWS 上でコンテナとして動作している マイクロサービスの結果整合性 マイクロサービス化を進めるとバックエンドで複数のサービスが協調して動作することになり、これまではデータベースの トランザクション 機能により担保されていたデータの一貫性について別のアプローチが必要になります。 かみせんプロジェクトの今期の取り組みの 1 つとして、マイクロサービスの結果整合性について調査や技術検証を行いました。 課題感 複数に分割されたサービス間のデータの一貫性をどのように保てばよいか データ不整合が生じた場合、どのように リカバリ ーすればよいか 検証内容 ある機能を 2 つのサービス (図中の project-service と function-service ) として切り出す モノリシックなアプリケーションを、複数（社内での利用実績がない、あるいは少ない）の言語や フレームワーク を利用して分割することも技術検証の一環 あるリソースを新規登録する際に、従来 1 トランザクション で行っていた処理 ( SQL ) の一部を、今回切り出したサービスの API 呼び出しに置き換える データの整合性はリトライ処理で担保する 検証結果（得られた知見） サービスの分割は難しい 大前提としてサービスをまたぐ トランザクション が発生しないようにサービスを分割すべき 今回のように同一 トランザクション でデータ更新をしたい処理であれば、サービス同士が 疎結合 ではないということであり、そもそもサービス分割の粒度が正しくない可能性が高い ドメイン の知識が乏しい状態では適切な ドメイン 境界を認識することはきわめて難しい ドメイン の知識が増えた中盤になってから分割し直すことも、別の意味で難易度が高そう 自動テストなど品質担保の仕組みや、作り直しに対する組織の理解の度合いで実現可能性が大きく変わる 結果整合性の担保は難しい 今回のようにリトライ（有限回数）で整合性を担保する場合、すべて失敗する可能性もゼロではなく、最終的にログなどから手動 リカバリ ーできる仕組みを考えておく必要がある 今回は時間の都合で検証していないが、メッセージキューを利用したイベントソーシングな アーキテクチャ も検討したい 分散 トランザクション （二相コミットなど）の手法を使う選択肢もあるが、システムの複雑さや難易度が一気に増加しそうで現実的ではなさそう 最後に マイクロサービスの分割や結果整合性に関する知見は、情報としては世の中にありますが、実際に自分の手を動かして検証することで、改めてその課題感を実感するとともに、現実のサービス開発にマイクロサービス アーキテクチャ を適用する難しさも明らかになりました ラク スでは現在、 HR（人事労務）領域を対象した新サービスの開発 に取り組んでおり、この「かみせんプロジェクト」で得られた知見が現実のプロジェクトで活かされようとしています。例えば ラク スが提供する クラウド サービスとしては初めて全面的に クラウド ネイティブな アーキテクチャ を採用することが決定しました マイクロサービス アーキテクチャ の採用についても検討しましたが、今回経験したサービス分割の難しさから、まずはモノリシックな アーキテクチャ で最速でマーケットに参入するという選択をしました ラク スでは現状に満足せず開発の未来に先手を打っていける仲間、HRTech に興味があるエンジニアを募集しています！ www.wantedly.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに 新卒2年目エンジニアのkasuke18です。 つい先日iOS12がリリースされました。リリースされた内容は数多くありますが、その中でも気になったのが「ショートカット」というアプリです。このアプリをうまく使えば iPhone 単体で API の実行が可能になります。実際に試してみましたので、紹介します。 もくじ はじめに 「ショートカット」アプリについて 作成したショートカット 内容 作成例 実行結果 おわりに 参考文献 付録：今回使用したアクション 「ショートカット」アプリについて リリースノート Shortcuts 2.0 release notes を見ると、「ショートカット」アプリはiOS12の以前に「Workflow」アプリとして公開されていたようです。 「ショートカット」アプリでは、 ビジュアルプログラミング言語 のように アクション と呼ばれる構成要素を組み合わせて1つのショートカットを作成します。アクションには iPhone端末の設定変更 や 他アプリの操作・データの受け渡し といったものが用意されているほか、変数・条件分岐・繰り返し（for, foreach）といった制御を行うものも用意されています。 作成したショートカット 内容 クリップボード に保存されている画像のリンクに対して OCR の API を実行し、画像内の文字をテキストに変換して出力する、ということをやってみました。今回使用した OCR の API は Free OCR API | OCR.space です。POSTパラメータやレスポンスの JSON 構成はリンク先でご確認ください。 作成例 まずはPOSTリク エス トを送信する部分です。 図1. POSTリク エス トの送信 今回POSTパラメータとして必要な情報は APIキー ・ 画像内の文字の言語 ・ base64エンコードされた画像 の３つです。このうち 画像内の文字の言語 は日本語で固定としているので、残り２つを取得する処理はサブルーチンとして別ショートカットに切り出し、それらを呼び出す方式をとっています。ではそれぞれのショートカットを見ていきます。   APIキー の取得処理です。 API キーは 環境変数 に持っておきたいのですが、さすがにそこまではできないようなので、今回は リマインダー アプリに保持・読み出すようにしています。 図2. API キーの取得 内容は API キーを保持している リマインダー を検索し、その中から今回使用する OCR.space というタイトルの項目から API キーを取得しています。 ショートカットの最後では、メインのショートカットに値を渡すため、変数から値を取り出して終了しています。   次に base64エンコードされた画像 の取得処理です。このパラメータに設定する値は data:image/[フォーマット],[base64エンコードされた画像] ですので、実際は 拡張子 と 画像をbase64エンコードしたテキスト の２つが必要になります。 まずは拡張子の取得処理です。 図3. 拡張子の取得 大きな流れとしては、まず クリップボード の内容がURL形式どうか確認し、URL形式ならその内容を取得します。さらにその内容がイメージであれば拡張子を、そうでなければ none というテキストを返却する、という処理を行っています。この none というテキストは、ショートカットを実行する側の処理で none を受け取り、エラーとして処理を終了するために利用します。 次が 画像をbase64エンコードしたテキスト の取得処理です。 図3. 画像を base64 エンコード したテキストの取得 これは 拡張子 の時とほぼ同じ処理の流れをしていて、 拡張子 を取得していたところを 画像をbase64エンコードしたテキスト を取得するように変更しただけです。   最後にメインのショートカットで 他のショートカットを実行する＆その結果を受け取る 処理と、 レスポンスJSONをパースする 処理を行います。 まずは 他のショートカットを実行＆その結果受け取る 処理です。 図4. 別ショートカットの実行 処理の流れは画像の通りです。ショートカットを実行し、その結果が拡張子ではないときは中断されたことを通知しショートカットを終了します。 続いて レスポンスJSONをパースする 処理です。 図5. レスポンス JSON のパース 「ショートカット」アプリ内では JSON は 辞書 という単語で扱われています。アクションとしては 辞書の値を取得 というもので、これは組み合わせればネストされた JSON のパースも可能です。また今回は結果出力のため、最後にメモに書きだすようにしています。 実行結果 以上のサンプルを、前回私が書いた記事の画像に対して実行した結果が以下となります。 図6. OCR で認識する画像 図7. 実行結果 おわりに 今まではちょっと API を試してみたいだけでもPCを用意する必要がありましたが、この「ショートカット」アプリを使用すれば iPhone 単体で簡単にできます。また今回は紹介していませんが、テキストに対して 正規表現 を用いたマッチングもできるので、 スクレイピング も可能です。 iPhone ユーザの方は試してみてはいかがでしょうか。 最後までご覧いただきありがとうございます。 参考文献 Shortcuts 2.0 release notes https://support.apple.com/en-us/HT209087 Free OCR API | OCR .space https://ocr.space/ocrapi 付録：今回使用したアクション アクション名とその使い方を以下にまとめました。 API 実行 URL URLを次のアクションに渡す URLの内容を取得 受け取ったURLをリス エス トし、レスポンスを次のアクションに渡す クリップボード をリク エス ト用に加工 クリップボード を取得 クリップボード の内容を次のアクションに渡す 種類を取得 受け取った値のデータ種類（イメージ・URLなど）のテキストを次のアクションに渡す Base64 エンコード 受け取った値を Base64 形式で エンコード ・デコードした値を次のアクションに渡す ファイルの詳細を取得 受け取った値（ファイル）の詳細（拡張子・サイズなど）を次のアクションに渡す JSON のパース 辞書の値を取得 受け取った JSON から指定したキーの値を次のアクションに渡す 制御 変数を設定 受け取った値を変数に代入する 受け取った値をそのまま次のアクションに渡す 変数に追加 受け取った値を変数に追加する（Listにappendするようなイメージ） 受け取った値をそのまま次のアクションに渡す 変数を取得 変数から値を取り出し、次のアクションに渡す 次の場合（if~else文） 受け取った値と指定した値を比較する（次と等しい・次を含む・より大きい・より小さい） それぞれで繰り返す（foreach文） 受け取ったリスト形式の値に対して１つずつ処理を行う ショートカットを実行 受け取った値を特定のショートカットに渡し、その実行結果を次のアクションに渡す（メソッドのようなイメージ） API キーを取得する リマインダーを検索 条件に合致するリマインダーを検索し、その結果を次のアクションに渡す リマインダーの詳細を取得 受け取った値（リマインダー）の詳細（メモ・タイトルなど）を次のアクションに渡す その他 テキスト 指定したテキストを次のアクションに渡す 通知を表示 タイトル・メッセージを指定し、その内容を通知として表示する メモを作成 受け取った値をメモに新規登録する "ショートカット"を終了 現在のショートカットを終了する 現在のショートカットに含まれる後続のアクションは実行しない エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに こんにちは。 ラク スエンジニアの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 [アクセス]