Wowgineer Notes

WowTechエンジニアの徒然開発日記

Wowgineer Notes

〜新たな"Wow"を生み出す〜

業務未経験で入社して3ヶ月経って感じた事

f:id:miura1213:20201216213358j:plain

こんにちは。WowDesk担当の三浦です。
今回が初投稿となります。よろしくお願いいたします。
私が当社に入社して3ヶ月が経ちましたので所感を書いていこうと思います。
ワウテックでエンジニアになりたいと思う方の参考になればと思います。

簡単な経歴

前職では、自社サービスの保守・運用・導入がメインのIT企業に約4年いました。
その後、本格的に開発に携わりたいという気持ちが強くなりエンジニアになる道を目指し、プログラミングの学習を開始しました。
そして、当社と縁があり実務未経験として入社することになります。
 

入社後の業務内容

当社のクラウド受付サービス「WowDesk」のWeb開発を担当することになりました。
最初は簡易的な機能開発や、React-Reduxの導入を実施しました。

www.wowdesk.jp

入社して感じた事

私が入社して感じた事を、苦戦した事とよかった事の2つの視点で記載していきます。 

<苦戦した事>

  1. 既存のコードが読めない
    これは知識不足で、コードの意味が全くわかりませんでした。実務未経験の最初の壁だと思います。例えば、私は基本JavaScriptを記述しているのですが、非同期処理が未知の世界でした。
    (今でも記述はしますが、100%分かるかと言われると怪しいです・・・)
    しかし、この辺りは先輩方が本当に優しくて、しっかりとフォローした頂きなんとか乗り越えていくことができました。

  2. 開発だけでなく、自社サービスの発展も視野に入れる
    開発作業だけでなく、チーム内でどういったニーズがある機能を追加するか等を議論していきます。ここの部分に関しては、前職にはなかった思考だったので今でも苦戦しています。
    単純に機能追加をするだけでなく、お客様の本質的な課題解決につながる機能をしっかりと議論していく必要があります。

  3. リモートワークのコミュニケーション
    私が入社した時には、コロナウイルスの真っ只中でした。ほとんどのメンバーがリモートワークを実施していました。
    一番苦戦したことは、コードに関する質問が気軽にできないということでした。併せて上記の知識不足の為、全く前に進めませんでした。そこで「Chrome リモートデスクトップ」を利用し、質問等がしやすくなりました。また、先輩のデバッグの仕方など直で確認できるので、取り入れて正解だったなと思います。

    support.google.com

     

<よかった事>

  1. 自由な働き方
    まずなんといっても私服!前職では毎日スーツを来ており、最初は私服がなじめませんでした。(田舎出身という事もあり、みんなおしゃれに見える・・・)
    リモートワークも早めに導入しており、ベンチャー企業らしさを感じる一面です。

  2. 開発環境が良い
    開発メンバーの椅子が最高です。個人では買うことがない椅子で業務を行うことできます。椅子だけではなく、開発PCのスペック等、エンジニアが開発する上で良い環境で業務を行うことができます。

  3. 開発メンバーが優しい ※最重要
    開発メンバーには本当に恵まれているなと感じています。実務未経験者の私でも丁寧にフォローしていただけています。
    ただ、何でも教えていただく訳でもなく、自分で考えるべき部分はしっかり指導していただけます。
    当社に入社や検討される方がいらしたらこの部分は、安心して頂ければと思います。
まとめ

ワウテックでエンジニアになりたいという方の参考になればと思っております。
また、技術的な投稿も今後は投稿していきますので、よろしくお願いいたします。

 

参考リンク

 

 

我々ワウテック技術開発部はこのような環境で開発をしています。
興味を持った方がいらっしゃればいつでもご連絡下さい。

f:id:wowtech-dev:20190313163146j:plain

 

 

Reduxのパフォーマンス改善でImmutable Dataの概念にぶち当たった話

f:id:yamamoto5555:20200821113553j:plain

Web開発チームの山本です。

以前の記事でReduxのStore設計について書いた通り、Reduxの道へと踏み出したのですが、その後パフォーマンス面での課題にぶち当たったので、今回はReduxでパフォーマンス改善に取り組んだことについて紹介します。

背景

お客様によりWowTalkを使っていただくため社内の浸透をサポートする集計機能を実装しました(詳しくはこちら)。その中の最終アクティブでは、アカウントに所属するユーザーの最終アクティブを表示しています。この最終アクティブの画面の表示が、ユーザーの多いアカウントでは遅いという問題がありました。最終アクティブ画面以外にも影響が出ていたため、早急に改善する必要がありました。

f:id:yamamoto5555:20201006105315p:plain

 

課題

今回は、4000人以上のアカウントで最終アクティブのページの読み込みが遅いのが、顕著に現れたので、Google Dev Toolsを使用し計測してみました。計測方法としては、MacBook Proを使用し、4000人ほどのアカウントで試しました。最終的には、数万人のアカウントも使用できるようにすることが今回のゴールです。

 

・計測対象の操作

サイドバーから最終アクティブをクリックするが、表示の反応が遅れるのと、最終アクティブのリストが表示されるのが遅いです。

f:id:yamamoto5555:20201013103743g:plain

 

・合計のレンダリング時間

f:id:yamamoto5555:20201013101046p:plain

 

・APIのリクエストとレスポンス時間

f:id:yamamoto5555:20201013101108p:plain

 

Reduxの仕組み

Reactで安否確認機能というサービスも開発していますが、同じ規模のアカウントでユーザーの読み込みに時間に、これほど時間がかかることはなかったため、今回はRedux起因の問題であると予想を立てました。

 

redux-loggerで出力しているLogでは、明らかにリストとして表示しているユーザー情報をStoreに更新した時の処理に時間がかかっていました。デバックしてみると、4000人のユーザー情報でループ処理が実行されていました。調べてみたところ、Reduxのimmutabilityに関係していました。

 

ReduxとImmutable Data

Redux と React-Redux は、どちらもをshallow equality checkingを採用しています。shallow equality checking(またはreference equality)とは、2つの異なる変数が同じオブジェクトを参照しているかどうかをチェックします。 また、shallow equality checkingとよく比較されるのが、deep equality checking です。deep equality checkingは、2つのオブジェクトのプロパティのすべての値をチェックします。Immutable Dataに関しては、Reduxのドキュメントにも詳しく記載されています。

今回は、このshallow quality checkingによって、Storeに4000人のユーザー情報を入れる場合、それの差分を確認するためにループ処理が実行され、時間がかかっているのではと考えました。

 

改善内容

Storeに入れてしまうと、shallow quality checkingで時間がかかってしまうため、ユーザー情報は、Storeに入れないで、グローバル変数の中に入れることにしました。local stateに入れるのは、UIなどの管理は向いているかなと思ったのですが、今回のユーザー情報は、最初に取得するだけで、そのあとに更新などは必要ないため、グローバル変数に格納することになりました。

redux.js.org

 

また、その他の改善点としては、最終アクティブの画面ではソート機能やフィルター機能があるため、毎回数万規模で部門のフィルターで時間がかかってしまうため、最初の20件のみを表示するように変更しました。

 

改善結果

上記の改善施策やその他細々した修正をした結果、2秒かからないくらいになりました。

f:id:yamamoto5555:20201030104344p:plain

 

まとめ

Reduxのshallow equality checkingによって、データ量が多いものをStoreで管理しようとするとかなり時間がかかることが分かりました。サーバーの負荷を減らすためにも、今回はフロント側での処理で対応しました。

数万人までのアカウントで利用できるようにするのが目標でしたが、今後10万人近いアカウントにも対応が必要になる可能性もあります。その時は今のやり方では限界がくると思うので、再度修正が必要です(またその時考える)。

Reduxのパフォーマンス改善をする中でも、React部分の無駄な再レンダリングなど多々あり、まだまだ改善の余地がありそうです。これからも継続的に、改善していきたいです!

 

補足:

今回が初めてのパフォーマンス改善だったので、チューニングの基礎などが書かれていたWebフロントエンド ハイパフォーマンス チューニングという本を読みました。Reduxのパフォーマンス改善には直接関係していませんが、いろいろなテクニックが書かれており、今後にも開発にも役立ちそうでした。

www.amazon.co.jp

 

参考リンク 

 

 

我々ワウテック技術開発部はこのような環境で開発をしています。
興味を持った方がいらっしゃればいつでもご連絡下さい。

f:id:wowtech-dev:20190313163146j:plain

絵文字リアクションの開発裏話

f:id:yamamoto5555:20200911113722j:plain


Web開発チームの山本です。

WowTalkに絵文字リアクション機能がリリースされ、時間が少し立ってしまったのですが、自分の中でも思い出深い機能でもあるので、今回は絵文字リアクション機能の開発裏話を紹介します。

 

絵文字リアクション機能とは?

絵文字リアクション機能は、トーク上に投稿されたメッセージに対して12種類の絵文字で反応(リアクション)することができる機能です。メッセージに対してリアクションできるため、スタンプよりもカジュアルに使うことができます。詳しくは、こちらから!

 

なぜ絵文字リアクション機能を追加したのか?

日頃から多くのメッセージをWowTalkで行なっているため、スタンプがたくさん送信された際に、メッセージが流れてしまうという課題を感じていました。また、サービスコンセプトの1つでもある「感情」と絵文字リアクションとの親和性も高く、機能を追加する後押しとなりました。

 

開発で苦労したこと

機能開発時に大変だったことは、仕様の決定でした。リアクションの種類はもちろんのこと、何個まで選択できるか、リアクションした人を見せるかなど、想像以上に決めることが多く、技術部内でも何度も話し合いをしました。またWowTalkのヘビーユーザーである社内の人の声も聞きたかったので、共有のアンケート機能を使用して、リアクションの種類について社内からも意見を募っていました。面白かったのは、技術部内ではポジティブなリアクションだけでいいのではと話していたのですが、意外と社内の人からはリアクションの感情の幅があった方が良いと言う意見があったことです。確かに現在使用する中で、喜び以外の感情のリアクションを使用することがよくあるなと思っています。

 

個人的には、リアクションの追加・削除・更新などで起こるリアクション数の変更を適切に反映させることに、とても苦労しました。ただ追加するのに1リアクション増やす、削除するごとに1リアクション減らすでは、重複などのデータの矛盾が生じるため、メッセージが持つID(下のコードでいうと"messageId1"と"messageId2"のこと)をkeyにすることで、リアクションにアクセスしやすいようにしました。今回の実装で苦手に感じていた配列やオブジェクトの使い方にだいぶ慣れた気がします。

 

{
    messageId1: {
        clapping : {
            users :  [ user1,  user2, user3 ]
        },
        heart : {
            users: [ user2, user4 ]
        },    
    },
    messageId2: {
       rose : {
            users :  [ user4,  user5, user6 ]
        }
    }
}

 

 

リリース前のハプニング?!

テストも落ち着き、そろそろリリースだとなった時に、絵文字の入れ替えが発生しました。もともとは割れたハートと泣いている顔文字を入れる予定でしたが、上からのお達しで変更することになりました。そこで新しく入れる絵文字になったのが、👌と🌹です。バラは、もともと技術部でメンテナンス時などでお疲れ様という意味を込めて、バラのスタンプを送りあっていました。そのお疲れ様の意味を込めて、今回の絵文字に追加しました。皆さんも、ぜひ相手を労う時にたくさんバラを送ってください!

 

まとめ

嬉しいことに、社内からも「絵文字リアクション便利!」というポジティブな声を聞くと、頑張って開発して良かったなと思います。まだまだ改善の余地もあるとは思いますが、ユーザーの方にドンドン使っていただけると嬉しいです。これからも更にサービスを進化させられるよう、頑張っていきます!

 

 

我々ワウテック技術開発部はこのような環境で開発をしています。
興味を持った方がいらっしゃればいつでもご連絡下さい。

f:id:wowtech-dev:20190313163146j:plain

ReduxのStore設計で気をつけたこと

                 f:id:yamamoto5555:20200821112754j:plain


 

 Web開発チームのフロントを担当している山本です。

今年リリースをした集計機能でReduxを導入しました。集計機能とは、お客様によりWowTalkを使っていただくために、社内の浸透をサポートする機能です(詳しくはこちら)。Redux導入にあたり一番頭を悩ませたのが、Store設計でした。初めての設計ということもあり、いろいろと試行錯誤したので、今回はReduxのStore設計について紹介します。 

 

公式のReduxのStore設計

Reduxのドキュメントでも、複数のデータを取り扱う時の3つのポイントが書かれています。

  • Domain data: アプリケーションが表示、使用、または変更する必要のあるデータ

  例)サーバーから取得するデータ

  • App state: アプリケーション独自の動作データ 

  例)データの選択状態やリクエスト中の状態

  • UI state: 現在のUIの表示方法を表すデータ

  例)モーダルが表示か非表示か

 

この3つの分け方は、データを取り扱う時に、明確な指針としてとても助かりました。基本的には上記のことを元に、今回の集計機能のStoreも構成しています。

 

 他のプロジェクトのStoreは?

具体的な例も参考にしたかったので、react-redux-realworld-example-appというプロジェクトを見つけました。このプロジェクトでは、Twitterのように自分で簡単なメッセージを投稿できるようになっています。reducersを見てみると、editorやProfileといったパーツごとにreducerを分けており、フラットに整理されていました(プロジェクトの大きさによるかもしれませんが)。またcommon.jsでは、ユーザー情報など共通で管理を行っているデータをまとめています。

 

正直、いろいろな具体的例を参考にしたかったのですが、その当時はなかなか見つからず。。。(私の探し方が悪かったのかな)。今は、 React Developer ToolsでStoreの中を覗けることを知ったのですが、早く知りたかったです!React Developer Toolsの使い方なども書いてあり、こちらの記事がとても参考になりました。私もこれからいろいろなStoreの中を覗いてみたいと思います。

  

集計機能のStore構成

今回の集計機能では、ページごとに表示するデータが異なるので、パーツではなくページごとにStoreを構成しました。それは、今後のことを踏まえても、ページ数をかなり増やすことは考えていなかったこともあり、ページごとにStoreを作ることに踏み切ることが出来ました。 

-cache
    |_common
-page
    |_common
    |_activeUser
    |_lastActive
-ui
    |_common
    |_activeUser
    |_lastActive

 

上記が考えたStore構成です。基本はドキュメントにあった3つのポイントから構成し、さらにページごとに分けています。ページ関係なく共通で使うものはcommonに入れて管理しています。今のところ、実装する中ではどこでデータを管理しているのかが見つけやすいです。

 

まとめ

今回はStoreの設計をしたのですが、どれが正解かは分からない部分が多かったです。集計機能では、ページごとに分けて良かったとは思っていますが、サービスによっては、やはりパーツごとに分けたほうがいいものもあり、一概にはどれがいいとは言えないと思いました。また、これからさらに集計機能を進化させたいので、その中で新たな壁にぶつかりそうな気がしています(既に壁にぶつかったので、その内また違う記事で書きます)。まだまだRedux初心者なので、積極的に他のサービスからも学んで行きたいです!

  

参考URL:

React Redux Real World Examples 〜先人から学ぶReact Reduxの知恵〜

redux-ecosystem-links/apps-and-examples.md

 

我々ワウテック技術開発部はこのような環境で開発をしています。
興味を持った方がいらっしゃればいつでもご連絡下さい。

f:id:wowtech-dev:20190313163146j:plain

 

カラーユニバーサルデザイン認証を取得した時の開発話

f:id:yamamoto5555:20140914125312j:plain

  

Web開発チームのフロントを担当している山本です。

 

昨年ワウテックは、カラーユニバーサルデザイン(CUD)認証を取得しました。(詳しくはこちらから)より良いサービスを提供できるよう奮闘する中で、CUD認証の取得は新機能とは少し違う新たな取り組みでした。今回、なぜCUDマーク取得を行ったのか、どのような変更があったのかについてご紹介したいと思います。

 

 

CUDとは 

CUD認証とは、特定非営利活動(NPO)法人カラーユニバーサルデザイン機構が発行を行う、“製品が多くの人にわかりやすい配色であることを保証する第三者認証の証”です。(※1)

人それぞれ色の伝わり方が異なるため、正しく情報が伝わるよう色の使い方に配慮しようという取り組みです。私が赤色に見えていても黒っぽく見えてしまう人もいるため、みんなにとって、より分かりやすい配色を選択していきます。

 

なぜCUD認証を取得したのか

弊社では「言語」「距離・時間」「個性」「温度・感情」「経験」という5つの視点からサービスの開発や新機能の追加を行なっています。その中の「個性」から色の伝わり方が違うことで生じるコミュニケーションの課題解決に取り組むことにしました。もともと、私が入社前の面接時より、代表の瀬沼からカラーユニバーサルの話を聞いており、会社としても取り組んでいきたいことだと前々から私も認識していました。

 

変更点

では、実際にCUD認証を取得するにあたっての変更した箇所をいくつかご紹介したいと思います。

 

1. 赤文字からオレンジへ

ワウトークで使用していた赤が暗めで黒と同じように見えてしまうため、「注意を集める、強調する、違いを表現できていない」という指摘がありました。改善案としては、明るいオレンジよりの色に変更することでした。ただ赤文字はあらゆる所で使っていたため、全てを変更するのがとても大変でした。ただ色を変更すればいいという訳ではなく、動的に色を変更しているところもあるため(例えば、クリックすると色が変化するなど)、見落としがないようにと神経を使った気がします。

f:id:yamamoto5555:20200311094711j:plain

 

2.グラフの色

 共有機能では、アンケートを取ることができ、その結果はグラフで表示されます。そのアンケートのグラフで使用している色が差が少ないということでいくつか変更しました。それぞれの項目に白縁をつけたり、グラフの項目をクリックすると情報が表示されるなど、もともと対応していたところもあり、全ての色を変更する必要はありませんでした。ただ僅かな色の変更なので、私も変更するときに色の差異を認識することが難しかったです。

 

f:id:yamamoto5555:20200311095241p:plain

 

まとめ

正直CUD認証を取得にあたって、「色の変更が多くなるのでは」、「現在の製品とかなり違う色を提案されるのでは」と不安もありました。嬉しいことに、ワウトークの強みでもあるシンプルさが使用している色にも出ており、改善箇所の指摘も多くなかった気がします。意外と文字の色をオレンジに変更しても、私の中では違和感もあまりなく、今では馴染んでいるように感じます。

 

今回のCUD認証の取得から、色自体を認識できないというのではなく、背景色との色の差が少ないため分かりずらさが生じたり、強調するなどの色の役割ができていなかったことを知りました。デザイン性だけではなく、新たな色に関する視点を意識するようになったので、今後の開発にも活かしていきます!

 

 

我々ワウテック技術開発部はこのような環境で開発をしています。
興味を持った方がいらっしゃればいつでもご連絡下さい。

f:id:wowtech-dev:20190313163146j:plain

 

駆け出しエンジニア1年目で学んだ3つのこと

f:id:yamamoto5555:20200203135617j:plain

 

Web開発チームのフロントを担当している山本です。 

最近では技術開発部の仲間も着々と増え、再来年入社の新卒採用まで始まりました。基本的に技術開発部は実務経験のある方が主なのですが、私は実務未経験からの採用でした。エンジニアを目指している人やエンジニアとして働き始めた人たちがエンジニアとして働くイメージが膨らむよう、エンジニア1年目で得た3つの学びを紹介したいと思います。

 

 

学び1: ReactとReduxの技術面での挑戦

Reactでの開発時にデータ管理の複雑さが増していき、Reduxを取り入れようという話になりました。それからWeb開発チームでも定期的にRedux勉強会を開催されるようになりました。毎回テーマを決め、各自で事前に予習をし、勉強会でお互いに学んだことを共有するスタイルで行っています。Reduxを勉強する中で、Reactの復習にもなり、初期の頃より理解できることが増えてきたのを実感できたのも嬉しかったです。

 

学び2: 機能(サービス)リリースするまでの見積もりの大切さ

機能追加などを行う中で、現在の自分の力を考慮し、実装にかかる時間を正確に見積もることが大切だとよく上司から言われます。無限に時間があればいいのですが、そういうわけにはいきません。機能実装の時に必要な作業を書き出し、それに対してかかる作業時間を見積もるようにしています。数時間で終わるだろうと思っていても実際に取り掛かると手間取り、見積もりと差が出ることがよくありました。また作業時間の見積もりは正確だとしても他の作業が発生することもあるため、それも事前に想定しながら見積もることが必要です。見積もり時間が短いからいいというわけではなく、自分の力量を知るために自分と向き合う時間でもあると思っています。

今はInstaganttでスケジュール管理をしており、タスク状況を視覚的に把握できるので便利です。他にもオススメのツールがあれば教えて欲しいです。

 

学び3: 仕様の決定からデザインについて考えるようになる

初めて機能追加する時に、仕様の可能性が無限大だということに気がつきました。ユーザーが使う時のことを考えながら、開発期間内でできることを決めていく必要があります。既存の機能のことも考慮しないといけないため、色々なケースを想定する必要があり、何度も話し合いが必要なこともあります。

 

また私の場合デザイナーにデザイン依頼する前に、自分が実現したいものを伝えるため、ワイヤーフレームを作成します。大まかな配置も伝えたいので、色々と調べたり部内メンバーからもフィードバックをもらうことがあります。ワイヤーフレーム自体は、HTMLやCSSでコードを書きながら調整したり、既にあるコンテンツをつなげながら作っています。ワイヤフレームを作るようになり、他のサイトのレイアウトなども意識するようになりました。

 

まとめ

以前のエンジニアに対して、コーディングだけが仕事内容だというイメージがあったのですが、仕様決めからスケジューリングなどコードを書く上で必要な作業があることも知りました。また未経験でも勉強すればできるようになることも増えると実感し、今後も学び続けたいと思います。 

昨年は目の前のことで精一杯でしたが、今年はES6などの基礎部分を固めたり、もう少しバックエンドのことにも挑戦したりすることで、自分でできることの幅を増やしたいです。

 

 

我々ワウテック技術開発部はこのような環境で開発をしています。
興味を持った方がいらっしゃればいつでもご連絡下さい。

f:id:wowtech-dev:20190313163146j:plain

 

ペアプログラミングを試してみた

どうもこんにちは!web開発チームのしまねです。
最近web開発チームでペアプログラミングに取り組んでみました。
取り組んだ開発はまだリリースまでいっていませんが、どのように取り組んだのか・やってみた感想などを振り返ってみたいと思います。

 

目的

目的としては大きく3つありました。

目的① レビューが十分にできていない状況を変えたい

 コードレビューの依頼は来るのですが自分の開発業務もあるため、十分にできていないなぁという思いを少し前から抱えていました。例えばある機能を実装するとしてそれに関するコードをすべてレビューするとなると、まとまった時間が必要となるためついつい後回しにしてしまっていました。そして結局十分な時間がとれず深く見れずに終わってしまうという。。
 ペアプログラミングで開発すればレビューせざるを得ないためレビュー不足な状況を変えることができるのではないかと考えました。

目的② 新卒が入った時に研修で使えるかを検証したい

 ワウテックでは新卒採用を始めていて近い将来新卒が入社します。新卒の研修の一環としてペアプログラミングはいいんじゃないかなと思っていたので、その効果を検証する必要がありました。

目的③ テスト時のバグ改修の工数を減らしたい

 開発の工数は見積もりやすいのですが、テストに出したあとのバグ改修はバグの数によって工数が増減するため見積もりにくくスケジュールが押してしまうことがありました。
 もしもテスト提出の時点で極力バグを少なくできればテスト工数の振れ幅も小さくなり見積もりやすくなるはずです。
 2人で1人分のコードしか書けないので開発スピードは遅くなりますが、2人で確認しながら進めるのでバグが減ってテスト時のバグ改修の工数では短くなるのではないかという期待がありました。

 

使ったツール

  • Live Share

https://visualstudio.microsoft.com/ja/services/live-share/

 Live Shareというプラグインを使えばVisual Studio Codeでソースコードを複数人で編集できるようになります。
 誰か1人がホストになり共同編集する人を招待し、招待された人はホストのファイルを編集できるようになります。
 他の人がどこを編集しているのかはカーソルで表示されてわかりやすかったです。

f:id:wt-shimane:20200107102151p:plain

VScodeのLive Shareでファイルを共同編集している様子

 招待したり招待されたホストに接続する際にMicrosoftアカウントかGitHubアカウントが必要です。

 

やり方

 調べてみるとペアの中でドライバーとナビゲーターという役割に分ける方法があったので参考にしました。
参考サイト: ペアプログラミングのやりかた
https://qiita.com/kanatatsu64/items/3f04d0116e22392efaca


ナビゲーターの役割
・プログラムの構成を考える
・テストを書く
・ドキュメントを書く
・ドライバーの疑問をググる
・ドライバーが書いたプログラムをレビューする

ドライバーの役割
・コードを書く

その他にはルールとして次のことを決めました。
・開始時間と終了時間とどこまでやるかを決める
・1時間を目安に休憩

 

いざ実践

 今回は僕がナビゲーターでペアのメンバーがドライバーで進めていくことにしました。
 まずナビゲーターの僕がコーディングの前に大まかな作りを説明し、処理をコメントで書いていきました。
 この間はドライバーはやることがなくなってしまうので最初だけでもこの作業はあらかじめやっておくべきでした。
 キリの良いところまで処理を書いてドライバーにコーディングを始めてもらいました。
目の前でどんどんコードが書かれていくのが面白くてしばらく見ていたのですが、「いけない、いけない。次の処理のコメント書かなくちゃ」ということでいったん次に実装予定の処理をコメントでどんどん書いていきました。
 その後はドライバーの書いたコードを見たり、疑問点に答えたり、次の実装を書いたりと進めていって最初に目標にしていた部分まで実装してその日は終わりにしました。
1回やってみた時点で、2人とも他の業務もあり今回ペアプログラミングを行ったプロジェクトだけやるわけにはいかないので週に何回か2~3時間くらいでやってみよう、また、ペアプログラミングをする部分はそのプロジェクトのコアになるようなロジックの部分にしてcssの設定等の見た目の部分は1人で進めていこうということになりました。

 

その後何度かやってみて・・・

 

  • ペアプログラミングした部分のソースコードについては考え方まで理解しているのでレビューする必要が全くなかった。
  • ナビゲーターはあまりやることがないのではないかと思っていたがドライバーとのやり取りが多く発生して想定していたよりも忙しかった。
  • 1時間を目安に休憩と決めていたがついつい進めてしまって休憩を取りそこねることが多かった。
  • どこまでやるかを毎回最初に決めておいてよかった。

 というような感想をもちました。

 

まとめ

結論① ペアプログラミングをする上でLive Shareはすごく便利

 1つのPCではなくそれぞれのPCでできるようになるのでナビゲーター側の自由度が高くなります。昔は1つのPCに2人がはりついてやっていたそうですが、それだとお互いにかなりストレスになると思います。

結論② どこまでやるかを毎回最初に決めておくことが重要
 ペアプログラミングをしていると1人でやるより疲れるので予めゴールを設定しておくと気が楽です。気が楽なだけですが続けていくには重要なことです。

結論③ 改めてコードレビューの時間をとる必要はない
 ペアプログラミングを行った部分に関してはドライバー側が書いたコードもナビゲーター側が設計しているし、議論しながら進めているためコードを書き終わった時点でもうレビューはしなくてもいい状態になっています。

結論④ 新卒の研修としてはとてもアリ
 マンツーマンでしっかりコードの書き方から見ることができるので新卒の研修時には非常に有用だと思いました。研修の際には逆にナビゲーターをやってもらってプログラムの構成を考えてもらうのもありかもしれません。

 目的③についてはまだテストまで到達していないので検証できていないです。。
 ただ現時点の感想では、仮にペアプログラミングで開発した方が工数がかかったとしてもメンバー間の知識の共有や議論して進めることでの品質のアップと他に得られるものがあると思います。

 どうやってコードを書くのかについては体系的に説明するのは難しいため、書いているところを見てもらうのが一番早いです。まだまだ慣れませんがもうしばらく続けてみたいです。
 今回はやりませんでしたがLiveShareを使えばリモートワーク中でもペアプログラミングできるかもしれないので近い将来チャレンジしてみたいです。

 

我々ワウテック技術開発部はこのような環境で開発をしています。
興味を持った方がいらっしゃればいつでもご連絡下さい。

f:id:wowtech-dev:20190313163146j:plain