Septeni Engineer's Blog

セプテーニ・オリジナルのエンジニアが綴る技術ブログ

ペアプログラミングの勧め

みなさま、こんにちは。

昨年、11月に中途で入社しました堀越というものでございます。

つい最近のお話ですが、業務でペアプログラミングなるものを実施しました。

良いなと感じる点が多かったので説明も兼ねて共有します。

ペアプログラミング

2人のプログラマが1台のワークステーションを使って共同でソフトウェア開発を行う手法である。一方が単体テストを打ち込んでいるときに、もう一方がそのテストを通るクラスについて考えるといったように、相補的な作業をする。

引用元:ペアプログラミング - Wikipedia

ペアプログラミング実施の背景

弊社では、4月よりスクラムの取り組みを改善する施策をしており、

目標の一つに複数の開発チームがそれぞれが所有する開発タスクを

チーム間を跨いで対応可能にするというものがあります。

ただし、その為には他のチームが抱えるプロダクトや業務に関する知識が備わっている前提となるため、

この課題に対する一部アクションとして他チームメンバとペアプログラミングの実施に至ったという背景があります。

ペアプログラミングを始める前に

1. パートナーを探す

ペアプログラミングは1人ではできません。

勇気を出して気になるあの子を誘ってみましょう。

2. ドライバーとナビゲータに分担する

ペアプログラミングは2人で作業を進めるとはいうものの、

端末を一台しか使いませんのでドライバーとナビゲータを決めましょう。

ドライバはコードを書く人、ナビゲータは作業指示をする人というのが私の理解ですが、

ナビゲータは作業指示ではなく、作業を促すようなコメントをするのが良いとする文献もあるようです。

3. ドライバーとナビゲータの交代サイクル

作業分担が長時間同じだと疲れてしまうので、

ドライバーとナビゲータの交代時間を決めましょう。

私の場合、おおよそ30分間隔だったと記憶しています。

4. 着手する作業を決める

作業を開始してから何するか考えるのは時間がもったいないですね。

あらかじめ着手する作業内容を決めておきましょう。

その際、どこまでの作業をゴールとするのか目標設定しておくと尚良いでしょう

実際にやってみて良いなと思った点

開発Tipsを共有できる

CUI のコマンドや、IDEのショートカットに何を使うか等の

細かいキーボード操作や、仕事の仕方など実際に一人で作業していると

なかなか共有する機会が無いと思います。

ペアプログラミングをしていく中でパートナーの作業風景から

得るものが少なからずあると思います。

私はこの結果、生産性が3倍向上した気持ちになりました。

一人よりも二人のほうが問題解決できることが多い

1人で作業していたら時間がかかっていた、ハマっていたであろうことが、

2人で立ち向かうことでさほど問題にならないことが多いと思います。

何かの問題に直面した際、パートナーに状況を説明することで、

頭が整理されて自己解決したなんてこともあると思います。

プルリクに出すコードの品質があがる

ドライバーがコードを書いている最中、ナビゲータはコードレビューする形になるので、

実装不備があった時点ですぐに指摘することができます。

そのため、プルリクを出す時点である程度品質が担保された状態になります。

所感

個人的には自身の成長につながる部分が多かったのでペアプログラミングお勧めです。

ただし、成果物を出すのに2人分のリソースを割くので全体での時間はかかっているかもしませんし、

一人で作業することを好み、自身の作業スタイルを貫きたいエンジニアにとっては、

ストレスに感じてしまうところもあるかもしれません。

メリット、デメリットを考慮して、必要に応じて実施するのが良いのではないでしょうか。

最後に

僕とペアプロ…、しませんか?

お誘いお待ちしてます。

Solarizedで目に優しいターミナル

こんにちは。エンジニア2年目の大北です!

最近同期がtigを導入していたので、私も入れてみました。 こんな感じです。 f:id:sachipapi423:20170616131239p:plain

tigの機能は素晴らしくて、1行だけgit addしたり、addしたやつを戻したりなどが自由にできるんですが、かなりカラフルで目がチカチカしてきます。。

そこでターミナルの色を綺麗に整えてくれるSolarizedを入れてみることにしました!

続きを読む

GANMA!チームのScrumについて

GANMA!開発エンジニアの盛岡(@morizooo)です。
3月からScrumへの取り組み方を変えており、形になってきたので、
どのような変化があったかを共有したいと思います。

背景

今までの開発手法としてはSCRUM BOOT CAMPを読んだ後に独自で考えた手法で、
以下のように行っていました。

既存の開発で大きな問題はないように感じてはいたのですが、
チームリーダーがScrum AllianceのCSM研修を受講する機会があり、
Scrum Allianceが提唱するScrumについての説明を受け、フィードバックを受ける機会がありました。
そのフィードバックを踏まえて現在の問題点を考えて、
良くなるかもしれないなら新しい手法にTryしてみる価値があるんじゃないかということで挑戦しています。

f:id:morizo999:20170609162552j:plain

現在の開発の流れ

  • 1週間Sprint
  • タスクのアサインはしない
  • タスクの詳細をチームで考えて30min/60minの粒度に分割する

スケジュール

1週間Sprintを下記のスケジュールでセレモニーを行っています

  • 毎日 17:00~17:15 Daily Scrum
  • 火曜 16:00~17:00 Product Backlog Refinement
  • 木曜 13:00~13:30 Sprint Review
       13:30~14:30 Sprint Retrospective
       15:00~18:00 Sprint Planning
  • 金曜 10:00~13:00 Sprint Planning 予備時間(木曜で終わらない場合の延長時間)   

Sprint Planning

一番大きく変わった部分がSprint Planningなので、このセレモニーを自分たちのやり方と合うように、
どのように実行しているかを説明します。

  1. POともに次スプリントの開発するタスクを決める(この段階では詳細検討は行われていない)
  2. 次スプリント中にやらなくてはならない技術タスク(開発チーム管理のタスク)を次スプリントのタスクに追加する
  3. ポイント振りはProduct Backlog Refinementで終わっているはずだが、
    
緊急対応などの何らかの理由で見積もっていない物があればこの場で見積る
  4. チーム全員でDDDをやっているので、
    ドメイン設計・テーブル設計等全体で考慮するタスクがないか確認する。
    全体で考慮するタスクが存在する場合は全員で検討する
  5. 詳細検討を行いチーム全員でタスクの分割を行う
  6. 詳細検討が終わり次第、POに確認をしてもらい作業開始。1人1日4時間を予定時間として計算する。
    詳細見積もりで予定時間を超過しているようであれば、スプリントの開発タスク量を減らす相談をPOと行う。

詳細検討について

詳細検討後は30min/60minのタスクしか存在せず、チーム誰でもできるような作業に分解します。
(現状は、Android/iOSのプラットフォームの違いがあるので全員が出来る状態ではありませんが、誰でもできる状態を目指しています)
開発優先度の高いタスクから以下の作業を、一番そのタスクに一番詳しい人から行っています。

  1. タスクの内容を確認する
  2. 空コミットでチケット番号をいれてブランチを作成する(Bambooでコミットログでトラッキングできるため)
  3. 必要なタスクをチーム全員でソースコードを見ながら30min/60minで出来るチケットを作成する
  4. 変更が必要な所にTODOコメントをつけてプッシュ
  5. 一通り切り終わった後に、全員が出来るように曖昧な点がないか確認し実装イメージを共有する

方針が立たないようなタスクの場合には、以下の方法を使う場合もあります。

  1. 各々が自分で思う作業順を付箋に書き出す
  2. 説明しながら付箋をホワイトボードに貼る
  3. 全員が貼り終わったら、分類分けをする
  4. タイトルを付け、30min/60minかを相談する

www.ted.com

所感

現在もまだまだ完成しておらず、Sprint Retrospective毎にルールが進化しています。
最初はSprint RetrospectiveやSprint Planningだけで一日が終わる日があり、
エンジニアなのにコード全然かけてないぞ〜?という日々を過ごしていたのですが、
現在はある程度高速化が進んでおり、上記のスケジュール感で回るようになってきました。 30min/60minの詳細に分割するのは大変なのですが、体調不良等で急に休むことになってしまった時や、
思うように進まなくてハマっている場合でもタスクの渡しやすくなったので、チームとして助け合いできる環境になったと思います。  

今後もScurmをやっていくぞー!というわけではなく(Scrum Slavesにならない)、
チームとして最適な手法を模索していきたいと考えています。

というわけで、開発手法含めて一緒に考えて開発する人を募集していますので、よろしくお願いします! www.septeni-holdings.co.jp

ScalaでDeeplearning4jを使い自動運転で峠を攻める!

こんにちは。菅野です。

最近、AIとか機械学習とかが話題ですね。
AIに仕事を奪われる職業がどうとかの記事もよく見かけます。
このブログ記事もAIが書いてくれたら良いのにと思っている今日この頃です。

…でも思ってるだけでは仕事を奪ってくれないので、やっぱり何かしら自分で作るしか無さそう。
という訳で、今回はJavaディープラーニングが出来るDeeplearning4jを使って機械学習を試します!

プロジェクトD

さて、何を作りましょう?
最終的には私の仕事を勝手にやってくれるAIを作りたいです。
でも、はじめは簡単なものから少しずつ作っていこうと思います。
よくディープラーニングでネタにされるのは手書き文字の識別ですが、正直面白くないので道路上を自動運転するAIを作ります!

続きを読む

vue-playとvue-styleguide-generatorでVueコンポーネント開発

こんにちは、丸山です。

JavaScriptフレームワークのひとつVue.jsの主な機能のひとつに、コンポーネントがあります。
コンポーネントはUIの部品のようなもので、(最初から特定の機能のために使われることが想定されている場合以外は)なるべく独立して再利用可能な状態を保つべきです。
また、そういったコンポーネントは作った人以外が使用することも多々あるので、どのように使うか、どういう機能を提供しているかといった情報が簡単にわかれば、開発の手助けになるかと思います。

そこで今回は、そういった場面でVueコンポーネントの開発を助けるライブラリを紹介します。

サンプルコンポーネント

今回下記のようなコンポーネントを用意しました。内容は簡単なMarkdownエディタです。

<template>
  <div id="editor">
    <textarea v-model="input"></textarea>
    <div v-html="markedText"></div>
    <button v-on:click="deleteText">delete</button>
  </div>
</template>

<script>
  var marked = require('marked')

  export default {
    name: 'marked-editor',
    props: {
      defaultInput: {
        type: String,
        default: 'Hello!'
      }
    },
    data () {
      return {
        input: this.defaultInput
      }
    },
    computed: {
      markedText: function () {
        return marked(this.input)
      }
    },
    methods: {
      deleteText: function () {
        this.input = ''
      }
    }
  }
</script>

<style scoped>
  html, body, #editor {
    margin: 0;
    height: 100%;
    font-family: 'Helvetica Neue', Arial, sans-serif;
    color: #333;
  }

  textarea, #editor div {
    display: inline-block;
    width: 49%;
    height: 100%;
    vertical-align: top;
    box-sizing: border-box;
    padding: 0 20px;
  }

  textarea {
    border: none;
    border-right: 1px solid #ccc;
    resize: none;
    outline: none;
    background-color: #f6f6f6;
    font-size: 14px;
    font-family: 'Monaco', courier, monospace;
    padding: 20px;
  }

  code {
    color: #f66;
  }

  button {
    margin-right: 50px;
  }
</style>

f:id:to_maruyama:20170531223149g:plain

vue-play

vue-playコンポーネント単位でのデモを可能にするライブラリです。
コンポーネントのデモができることで、そのコンポーネントが単独で動くことを保証したり、そのコンポーネントの使い方を知ることができます。

まず、

yarn global add getplay

でインストール後、自分のvueのプロジェクト内に移動します。そこで、

getplay

を実行すると、playフォルダがプロジェクト内に作成されます。このフォルダ内にあるindex.jsを次のように修正します。

import Vue from 'vue'
import { play } from 'vue-play'
import MarkedEditor from '../src/components/MarkedEditor.vue'

Vue.component('marked-editor', MarkedEditor)

play('MarkedEditor')
  .name('MarkedEditor')
  .displayName('The MarkedEditor Component')
  .add('default', { template: '<marked-editor></marked-editor>'})
  .add('Pass parameter', { template: '<marked-editor defaultInput="# Hello!"></marked-editor>'})

MarkedEditor.vueはサンプルコンポーネントのファイルです。
ここにはデモをする対象のコンポーネントの登録と、どのようなデモを行うか(シナリオ)を書きます。今回はパラメータを何も渡さずデフォルト状態で表示させるデモとパラメータを渡す場合のデモを書きました。

上記の修正を行ったら、

npm run play

を実行して、http://localhost:5000/にアクセスします。

f:id:to_maruyama:20170531231315g:plain

ブラウザにvue-playの画面が表示されます。index.jsに書いたシナリオが左側に表示され、そこをクリックすることで、デモの内容が表示されます。

vue-styleguide-generator

vue-styleguide-generatorコンポーネントの一覧とそれぞれの概要が書かれたhtmlファイルを出力するライブラリです。
コンポーネントの情報をまとめておくことで、開発者はソースを読み込む前にそのコンポーネントのことを把握することができます。

npm install vue-styleguide-generator --save-dev

でインストール後、

node ./node_modules/vue-styleguide-generator/ --src src/compone
nts/ --dest preview

を実行します。
--srcで指定しているのは情報を取得したいコンポーネントがあるディレクトリ、--destで指定しているのは、コンポーネントの情報が書かれたファイルを出力する先です。
実行後、プロジェクト内にpreviewフォルダが作成されます。その中にindex.htmlがあるのでこれをブラウザで表示させれば、コンポーネントの情報が見れます。 さらに、コンポーネントと同じ階層に.mdファイルを作成し、そのなかにコンポーネントのさらに詳細な情報を書くこともできます。

今回src/components/配下は以下のようになっています。

src
└── components
     ├── MarkedEditor.vue
     └── README.md

README.md

このコンポーネントはMarkdownエディタです

のみが書かれているファイルです。

以下がブラウザで表示したindex.htmlです。

f:id:to_maruyama:20170531233902p:plain

画面にはコンポーネントのプロパティやメソッド等の情報が表示されます。.mdファイルに書いた情報はReadmeに表示されます。

参考

Vue.js Component Style Guide