『Rakus Meetup Osaka #1 大阪開発チームのチャレンジ紹介』のふりかえり

id:radiocat です。以前 ご案内 したとおり11/27に大阪オフィス初のMeetupを開催しました。

今回はMeetupのご報告とともに、運営で得た知見などを少しだけご紹介します。

大阪開発チームのチャレンジ紹介

今回は次の3つのチャレンジをご紹介しました。

チャットディーラーの高速開発を支えるLaravel

今年夏に登壇させて頂いた PHPカンファレンス関西 2018 の内容 をベースに、Laravel導入のチャレンジとそこで得た知見をお伝えしました。Vue.jsと格闘したエピソードでは前回登壇時には無かった開発メンバーの生の声を加えることで、大阪開発チームらしさもお伝えできたと思います。

speakerdeck.com

Why Mob Programming? - モブプロという働き方 -

モブプロに取り組み始めた経緯、はじめ方、やってみて良かったこと、悪かったことなど、アジャイルを推進する開発現場のモブプロへのチャレンジと得た知見を余すことなくお伝えしました。本編のスライドに使用されている写真は移転前のオフィスで撮影されたものでしたが、唯一、新オフィスで撮影した一番最後のスライドの「俺たちの戦いはこれからだ！」っぽい雰囲気もまたチャレンジ感をお伝えできたのではないかと思います。

speakerdeck.com

トウダン・ジャーニー

1つ目の発表にあるPHPカンファレンス関西 2018への登壇に向けて開発組織を横断した登壇推進チームを結成して取り組んだチャレンジについてお伝えしました。既に次の登壇も決まっており、社内チャットにさりげなく釣り針を落とすことから始まった登壇へのジャーニーは今後もまだまだ続きます。

speakerdeck.com

Meetupへのチャレンジ

今回、私自身はMeetupの運営にチャレンジしました。運営のチャレンジで特に大切だったことは次の2つです。

イベントのテーマを何にするか？

Meetupのテーマを何にするかは運営にとって最初の大きな課題でした。そもそもテーマを絞る必要があるのか？という疑問もありました。しかし、せっかく仕事終わりの時間を使って多くのかたに集まってもらうので、我々がどんなイベントにしようとしてるのかをイメージしてもらえる程度にテーマを絞るべきと考えました。特定の技術テーマに絞ることも考えましたが、初めてということもあるのでまずは大阪オフィスと開発チームの雰囲気を知ってもらうのが良いだろうと考えました。

「チャレンジ」というのはチャレンジそのものではなく、チャレンジを実践して結果を出したその場に価値があると思います。つまり、チャレンジというキーワードを通して「開発の現場」を知ってもらうことが大事だと考えました。そして、社内のビアバッシュで「Meetupをはじめよう」というLTを行ってこの思いを開発チームのメンバーに共有しました（ その模様は『 大阪開発ビアバッシュ～11月「新機能特集」 』で投稿していますのでご確認ください）。

今回、登壇を引き受けてくれたメンバーはその思いを汲み取ってそれぞれの視点でエンジニアの現場のエッセンスを発表に盛り込んで伝えてもらえたと思います。

LTをやりたい！

イベントの運営を引き受けるうえで、もうひとつ大切にしたかったのが次の2つを軸とした交流です。

• 大阪の梅田という地域性
• エンジニアの楽しみ

ここ数年で大阪でもたくさんの勉強会イベントが日々開催されるようになり、我々も一緒に大阪のコミュニティを盛り上げたいという思いがあります。また、社内外のエンジニアの交流を深めることで、エンジニアが楽しみながら成長していける場にしていけたらという思いもあります。社外の勉強会には私もよく参加させて頂いてたくさん情報交換させて頂いていますが、逆の立場で自社でもイベントを開催し、社外と社内が混ざり合って交流することで2つの軸はさらに強くなると思います。

そこで、LTを募集して参加者の方々にもイベントの一部に加わって頂くことで、この2つを軸とした交流をさらに深めたいと考えました。ただ、弊社が主催するイベントということもあり、本編のセッションと繋げてしまうとLTして頂く側からするとやりにくさもありそうなので、本編のセッションが終わったところで一区切り入れて交流会の中でLTして頂くことにしました。

交流会をスタートしてからLTに入るタイミングや進め方などはまだまだ改善の余地があると感じていますが、運営側の願いどおりの楽しみながら交流できるLTセッションにして頂けました。LTに応募して頂いた皆様、本当にありがとうございました。

おわりに

運営のチャレンジは始まったばかりで課題もたくさんありますが、フィードバックもたくさん頂きましたので得られたものも大きいです。今後につなげて継続的に開催していきたいと思います。

次回は2月頃に開催を予定

詳細が決まり次第、connpassに公開します。

もくもく勉強会も計画中

1月から月1回程度のペースでもくもく勉強会の開催も計画しています。こちらも決まり次第、connpassに公開します。

rakus.connpass.com

今後もこのようなイベントを企画してエンジニアを楽しくするための交流の場をつくっていければと思います。ぜひご参加をお待ちしております。

---

お知らせ

ラクス Advent Calendar 2018を実施中！

毎年恒例のアドベントカレンダーが今年も始まっています。ラクスのメンバーがこの1年間で集めたそれぞれのネタをつないでリレーしていますのでぜひご覧ください！

qiita.com

Scrum Fest Osaka 2019に応募しています

大阪では2月に Scrum Fest Osaka 2019 という大きなイベントが開催される予定で、現在セッション公募が行われています。私も楽楽精算開発チームのスクラムの取り組みをご紹介できればと思い応募していますので、よろしければ投票お願いします。

https://confengine.com/scrum-fest-osaka-2019/proposal/8554/-confengine.com

振り返りの手法を理解しよう～KPT法編～

はじめに

こんにちは、@rs_tukki です。
以前id:radiocatさんが記事にされていましたが、効率よくプロジェクトを進めるにあたって、「振り返り」を行うことは非常に大切です。
今回は、その「振り返り」の手法のひとつ、KPT法について話したいと思います。

tech-blog.rakus.co.jp

振り返りとは

振り返る
読み方：ふりかえる

(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

ラクスでは業務だけでなく、サークル活動などのワークライフバランスも意識しています。 業務もサークルも楽しみながら、楽しいエンジニアライフを送っていきたいと思います！

大阪開発ビアバッシュ～11月「新機能特集」～

こんにちは。エンジニアのmickey-STRANGEです。

はじめに

今回は先日、大阪オフィスで開催された11月ビアバッシュをご紹介いたします。
前回のビアバッシュ記事はこちら↓ tech-blog.rakus.co.jp

テーマ発表

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 へデプロイする Tips

最近、自宅で Laravel を使ったアプリを作成しています。 せっかく作ったアプリなので、公開しようとしたのですが、あくまで趣味の範囲であり、有料の環境を使おうとは思えず、Heroku へデプロイすることにしました。 今回は、Heroku でLaravel アプリをデプロイするための手順を簡単に説明します。

前準備

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

edエディタについて調べてみた

はじめに

開発エンジニアのamdaba_sk（ペンネーム未定）です。 前々回、前回と弊社エンジニアへのなんちゃってインタビューで記事を書いてきましたが、今回は久々に調べものをした結果をまとめてみようかと思います。

目次

経緯

実は私は自宅では非常に貧弱な性能のマシンしか持っていません。でもやっぱり家でも趣味の開発はしたいわけですが、まずエディタ選びが悩ましい。

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）

スクラム開発における各役割とその関係の理解が少しでも進めば幸いです。
「要するにプロダクトの責任者と開発チームがいて、それらのサポーターを通して開発を進めるってこと？」
...今は恐らくこれぐらいの認識ではないでしょうか。実際にスクラムを導入されるとそれぞれの役割の重要性が見えてくるかと思います。
「役割はなんとなく理解できたけど、どのように「スクラムを実行する」の？開発以外のイベントって何？」
それでは次章以降、スクラム開発で発生するイベント（スクラムイベント）について解説します。

スクラムイベント

スクラム開発では、単に開発を進めるだけでなく、ソフトウェアの「透明性」を見出すためのアプローチを取る必要があります。そのために規則的に行われる5つのイベントがあり、これらをスクラムイベントと呼びます。

• スプリント
• スプリントプランニング
• デイリースクラム
• スプリントレビュー
• スプリントレトロスペクティブ

スクラムイベントは定期的なミーティングとは違い、自分たちのスクラムのあり方に問題があれば解決し、より良い状況を作るために行います。このようにフィードバックを織り込んだイベントを実施することで開発を円滑に進めます。

スプリント

スプリントは開発のイテレーションのことです。スクラムチーム内で適当な期間を定めますが、通常は1週間〜3週間が多いです。
決められたサイクルで開発を進めることで、スクラムチームで完了できる仕事量を把握します。

スプリントプランニング

スプリントプランニングはスプリント開始時に行われる最初のスクラムイベントです。
「スプリント期間内で何ができるか（何をするか）」を明らかにするミーティングであり、スクラムチーム全員が参加します。プロダクトバックログで優先順位の高いものから順に完了できそうなものを選び、選んだ項目について具体的なタスク量を明確化するために適当な単位でタスクを分割してリスト化したスプリントバックログを作成します。

デイリースクラム

デイリースクラムはいわゆる「朝会」であり、昨日したこと、今日やること、課題を共有する場です。
主に開発チームが行うスクラムイベントであり、スプリント期間中は決まった時間に毎日行います。そのスプリントのゴールが達成できそうかと、日々の仕事の進捗を把握します。また、デイリースクラムにはスクラムマスターも参加します。

スプリントレビュー

スプリントレビューはスプリントの成果物を披露し、プロダクトについてフィードバックを得るためのミーティングです。スクラムチーム全員が参加します。
スクラムチームの他にステークホルダー（スクラムチームに所属しない会社の経営陣、あるいは顧客など）を招待する場合もあります。開発チームはスプリント期間内に達成できたことと、達成できなかったことを伝え、次回以降何をどう作っていけばいいか議論します。

スプリントレトロスペクティブ

スプリントレトロスペクティブはスプリント終了時に行われる最後のスクラムイベントです。スクラムチーム全員が参加します。
いわゆる「振り返り」であり、スクラムチームの現状を見直し、次回以降のスプリントでより良い仕事を行うための改善策を出していく場です。開発チームとスクラムマスターが中心になって進め、次回のスプリントに向けてのアクションプランを出します。

まとめ（2）

スクラム開発の進め方が理解できたでしょうか。本当はもう少し細かい話もあるのでが、ざっくりとまとめると

• 計画→開発→お披露目→振り返り→（以下、繰り返し）

となります。イテレーションが設定されているおかげで問題に気付きやすくなり、改善や後戻りしやすいシステムになっています。これこそがスクラム開発の醍醐味であり強みでもあります。これからスクラムを始める人にとって、今回の記事が少しでも参考になれば幸いです。

---

• エンジニア中途採用サイト
  ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
  ご興味ありましたら是非ご確認をお願いします。
  
  https://career-recruit.rakus.co.jp/career_engineer/

• カジュアル面談お申込みフォーム
  どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
  以下フォームよりお申込みください。
  forms.gle

• イベント情報
  会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com