音楽とお酒とものづくりと

Web初心者の新人エンジニア(園児neer)奮闘記

リモートワーク×ペアプロにトライしてみた話

結論
リモートペアプロ超快適やん!
という話です。



さて、こんにちは。

働き方改革で今年の3月くらいから全社でリモートワークを導入しました。

リモートワークについてはエンジニア交流会でもLT登壇させていただき、リモートワーク導入の話から、現在のスクラムチームでの活用方法をお話しさせていただきました。

詳細についてはこちらのブログをご覧ください。
gaiax.hatenablog.com


さて、今回のお話ですが、リモートワークしながらペアプロをしてみた話をします。

ちなみに、最近はモブプログラミングがすごく取り上げられていますね。
モブプロはまだトライしたことはありませんが、うちのチームではペアプロ・ペア作業は当たり前のように行っています。

最近はリモートワークをよくやるので、一度リモートでペアプロやってみよう、となったのでそのお話。

リモートペアプロをやってみて

リモートペアプロの際に使うのはslackだけです。

slackで音声通話しながら、画面共有機能を使って画面を共有するだけ。
ドライバーが画面を共有し、ナビはそれを見てナビする。

本当にたったこれだけなのですが、普通にペアプロ実施できました。
画質も音声もキレイにいけてました。


また、出社したとしても、自社の執務室だけでなく、同ビルの地下や屋上などで作業をすることもあります。

実際に今働いている場所がNagatacho GRIDというところです。
こちらのブログでも紹介されているように、非常に多様な働き方ができるビルです。

www.gaiax.co.jp


外部ディスプレイをわざわざ地下に運んでペアプロすることもありますが、いかんせん重たいのでめんどくさいのです。
このように、外部モニタがないときは、一緒にいるときでも、slackの画面共有機能を使ってペアプロをすることもあります。
やりとりは一緒にいるため、マイクをミュートにし、直接行います。


ちなみに音声通話の代わりにテキストでもやってみたのですが、これは微妙でした。

音声通話よりもリアルタイム性がないし、なにより文字入力がめんどくさい。
あとPCのスペックにもよるんでしょうが、slackの画面共有中のテキスト入力がすごく重かったです。


もちろん、slackじゃなくても、音声通話と画面共有ができるツールならなんでもいいと思います。

まとめ

以上、ビデオ会議ツールの画面共有機能を使ってのリモートペアプロがすごい快適やっていう話でした。
想像以上に快適に作業できたので、今後も続けていこうと思います。

アジャイルディスカッションに参加してきた!

先日アジャイルディスカッションに参加してきました!

アジャイルディスカッションについてはこちらを参照ください。
takubon.hatenablog.com


本イベントでは、アジャイルを導入したり進めていく上での悩みごとなどを共有し、ディスカションしていきます。

進め方

はじめに主催者の木村さんからのイントロダクションがあり、それぞれがディスカッションしたいテーマを列挙します。
そして4~5人くらいのグループに分かれ、グループごとにテーマを選び、ディスカッション開始となります。

なお、イベント中はビールを飲みながらのディスカッションOKというスタイルでした。

取り上げたテーマ

我々のグループは以下のテーマでディスカッションを行いました。
ウォーターフォールからスクラムへの移行について」
「失敗アジャイルの共有」

ディスカッション内容と気づき、次のアクション

V字モデルの下の方だけスクラムやっているチームが多い
これは確かに、と思いました。まさにウチのチームも同じような感じで、最初に決めた受け入れ条件を守ることを大事にしていたように感じました。実際にストーリーの実装を開始した後に、「こっちの方がいいんじゃね?」と思っても、「でも受け入れ条件がこうやから・・・」と受け入れ条件をひっくり返したりしてなかったなと。まさにV字の上の方の変化を受け入れず、下の方だけスクラムしていたように思います。

どうすれば成功するかなんて誰にもわかりません。だからこそ、実際にやってみて違和感を感じたり、もっとこうしたほうがいい!と感じたのなら、素直にそれを提案し、受け入れ条件の見直しから柔軟にやっていくべきだなと思いました。


プロダクトバックログの上から機械的にストーリーをこなすだけになってないか。スプリントゴールが「価値を届けること」ではなく、「スプリントを終わらせること」になっていないか
ただ機械的にこなすだけなら、当然ミニマムしかあげないし、ストーリーの実現に伴う副作用的な変化は排除するようにしか動かんなあと。やはりそのストーリーを提供することでどんな価値が届くのか、お客さんのどんな課題が解決されるのかをしっかり意識することが大事ですね。課題解決のための価値提供であることをしっかり認識しておけば、常に最適解を探すようになり、V字モデルの下だけスクラムとかからも脱却できるのかなあと思いました。

これからは「この価値を届けることで、お客さんの抱えているどんな課題が解決されるのか」を意識していこうと思います。具体的にはリファインメントの時に、その質問を投げてみることや、ストーリーの着手前に、この価値が届き、お客さんがどうその価値を体験するのかをストーリーベースで妄想すること、それをペア作業者と一緒にやること、などをトライしていこうと思います。


全員で一つのプロダクトを作り上げる意識
開発チームだけでなく、営業やサポート、ステークホルダー全員で1つのプロダクトを作りあげ提供していく、そこに関わるものとしての当事者意識を持つことが大事だという話も上がりました。

これに関しては、最近社内で雰囲気が少しずつ変わりつつあるように感じます。私個人としても、開発以外の視点で捉える必要があると思います。例えば、作っておしまいじゃなくて、営業の人がもっと売ってきやすくするために何ができるかなどを考えたりすることが必要かなと思いました。


失敗を恐れず行動していくためには、失敗を褒める文化を作ることが大事
これも思い当たる節がちらほら。最近完成させたストーリーの中で、あくまでストーリーの実現がメイン。それに伴う副作用的な変化はできるだけ排除しよう、という思いがありました。これは、変化による失敗を恐れていたからだなあと感じ反省しました。たとえ副作用的な変化があったとしても、より価値が届くのはどちらかを考えた結果であれば、どんどん変化を受け入れていくべきだと思ったし、行動していくべきだなと感じました。

イベント全体を通して

立場や年齢、スクラムの経験年数もバラバラの人が集まり、いろんな視点からの意見がたくさんでてきて良い会だなあと思いました。
たくさんのいい刺激をもらったので、どんどんチームに還元していきたいと思います。

次回も参加するどー!

チームのミーティングをLEAN COFFEEで実施してみた

久しぶりのブログ更新です。

先日、以下のブログを読んでLEAN COFFEEというミーティングの手法を知ったので、早速チームのミーティングで実践してみました。

LEAN COFFEEについて

アジェンダを用意せずに始めるミーティングのこと。
詳しくは以下の記事を参考にしてください。
medium.com


やってみて思ったこと

ダラダラと議論が続くことはない

やっぱりこれが一番大きいなと思いました。
タイムボックスを決めて議論するため、ダラダラと議論が続くことはありません。
時間がきたら継続判断を全員で行うので、議題の切り替えも非常にスムーズでした。

やってみると、意外と2、3回目の継続判断で次のトピックに移ることが多く、いつもよりコンパクトに議論ができた感じがありました。

また、全員の意思を確認してから次の議題へと移るので、「もっと話したかったのに・・・!」という不満がたまることもなかったように感じます。

普段は結構議論が長くなりがちなので、実施前は、今回も時間内に議論し尽くせるかな〜と若干不安でしたが、アクションプランを出すところまで含めてきっちり議論しきり、時間内に終わることができました。

全員が本当に議論したいと思っているトピックが挙がる

最初のステップで、議論したいトピックを挙げ全員で投票し、投票数が高いものから議論していくため、全員が議論したいと思っているトピックが優先度高く取り上げられます。
ファシリテーターがトピックをあらかじめ用意してくるより、良いなと感じました。

多くのトピックについて議論できる

また、ダラダラと議論しないことで、時間内に多くのトピックを取り上げることができました。

まとめ

議論したいトピックを全員で決めて、タイムボックスを切り、議論の継続判断を行う
今後も、この手法を取り入れていってみようと思います。

新卒1年目のwebエンジニアが入社から今日までを振り返ってみた

Gaiax Advent Calendar18日目です!
今日はわたくし、新卒1年目のエンジニアが入社から今日までの9ヶ月間を振り返ってみたいと思います!


入社〜研修

4月はシェア研修、5月はエンジニア研修という構成で、2ヶ月間の研修を受けていました。

シェア研修とは、合計10社ほど集まって合同で行う研修のことです。

  • ビジネスマナーなどを学ぶセッション
  • 自分の人生のミッションステートメントを考えるセッション
  • 2週間ほどで0からサービスを立ち上げるセッション

などがありました。

サービス立ち上げの研修は本当にハードで、何度も徹夜しながら会社で議論していたのを鮮明に覚えています。それでも社内のたくさんの人の協力のおかげで「この課題設定力はすごい。新卒とは思えない!」などのフィードバックを得て終えることができました。

Gaiaxの2016年度の新卒は私を含めて6人なのですが、シェア研をうけた人たちを含めると80人ほどになります。同期がたくさんいるのはホンマええことですよね。マナー研修やミッションステートメント研修でも学びや気づきはたくさん得られましたが、同期がたくさんできたことも収穫の一つです。


5月からのエンジニア研修は2社合同で実施されました。
それぞれ研修の目標を設定し、それを達成すべく研修を受けていました。内容としてはwebに関係する技術全般を広く、おいしいところをつまんでいく感じでした。web初心者な自分にとって、ついていくのが大変なことも多々ありましたが、非常に濃い内容で充実した研修でした。

またメンターの方とはほぼ毎日レビューを行っていました。このレビューも非常に濃いもので、自分の今後のキャリアなども含めて様々な気づきを得られた機会でした。ちなみに今でもよく一緒に飲みに行ったりしていて、その度にいつもハッとさせられます。本当に、感謝です。


配属〜今日まで

6月から配属。

私は、内定者フォローや女性の活躍促進などのための社内SNS「AIRY」というプロダクトを作っている、エアリー事業部に配属されました。開発は私を含め5人で、開発からサービスの運用まで行う、いわゆるDevOpsの体制をとっています。今日まで様々な機能開発、問い合わせ対応、障害対応、改善活動、他にも展示会などのイベントにも携わってきました。

個人的には、このAIRYというプロダクトを通して、世の中のすべての人が毎日楽しく仕事ができる、そんな世の中を作っていきたいと思っています。そして、それが個々のパフォーマンスの向上につながり、仕事に還元され、結果、企業の競争力の向上につながっていく。そんなサイクルを作りたいです。

この9ヶ月で学んだこと、身についたこと

レガシーコード改善のテクニック

今日までやってきて、一番大変だったのは、やはりレガシーコード改善です。

これまで人のコードをほぼ読んだことがなく、プログラミングも苦手だという自分のスキルのなさ、そもそもプロダクトにユニットテストが少なかったり、複雑度が恐ろしいことになっていたりというコードの状況など、なかなかに大変な状況でした。

このレガシーコード改善では、配属後に社内で実施してくださっていた研修の内容が本当に活きました。

OOPやTDD、レガシーコードへのテスト挿入方法やリファクタ手法、デザインパターン、言語のバージョンアップ対応など様々な研修をしてくださったおかげで、現場でも存分にレガシーコード改善を行うことができました。
これからもどんどん練習して血肉化させていきたいと思います!

チームについて

今、うちのチームではスクラムを採用しています。実際にスクラムを利用して開発を進めることで、スクラムというフレームワークに対する理解が深まったこと、また、チームとはなんなのか、なんのためにチームを組んでいるのか、というチームの本質を改めて知れたのも大きな収穫です。

チームは現在5人で、POが1人、開発チームが4人(QAと開発者が2人ずつ)という構成で開発しています(この前のレトロスペクティブで私が開発チームを兼任でスクラムマスターをやることになりました)。そしてQAとDevがペアで作業を進めるペア作業(ペアプロ)という形を採用して開発を進めています。もともとペア作業はQAとDevの知見の偏りをなくし、開発作業における属人性を排除するためにやっており、最終的にはバスファクターが4本になっている状態(4人全員がどのタスクでもとっていける状態)がゴールだと感じていました。

しかし、チームの本質を考えた時に、この理想形はすこし違うな、と感じるようになりました。バスファクターが4本になれば単純にこなせるタスクの量は増えるかもしれません。しかしそれは1人の持つ100%の力が単純に4倍にしかならないのでは、と感じます。イメージとしてはフリーランスを4人雇った状態とさほど変わりません。これではチームを組んでいる意味がありません。

1人では何もできない。そのことをどれだけ理解しているか。そしてチーム内で、自分が持っていない要素を他の人が持っており、逆に他の人が持っていない要素を自分が持っている。それを補完し合うことで1人では達成しえなかったことをこなしていく。これがチームの本質だと気づきました。ペア作業を通して、200%以上の成果を出していく。そんなチームを目指していきたいと思うようになりました。

これからについて

今後どういうキャリアを歩んでいきたいか、どういうところを尖らせていきたいかなど、入社した時よりは明確になってきたとはいえ、まだまだぼんやりした部分が大きいのが現状です。この辺りの芯をはっきりさせていくと同時に、今以上にステップアップしていきたいと思います!

合同勉強会でinnoDBのインデックスとアルゴリズムについて発表してきた

最近はもっぱらQiitaに記事投稿してばかりです。

今日は久しぶりにこちらで更新。

背景

先日3社合同で勉強会を開催しました。
最近はあまり勉強会には登壇していなかったのですが、久しぶりに発表してきました。

今回のテーマは「innoDBのインデックスとアルゴリズム」について。

最近アプリのチューニングを行うことがあり、それがきっかけで調べてみました。


質疑応答

Q. こういった勉強の時間はどうやって確保しているのか?会社としてそういう制度があるのか?
A. 完全に業務外で、個人の時間を使って調べています。ストレングスファインダーの強みとして「学習欲」を持っているのもあり、学ぶことが好きなので休みの日は一日中こういうこと調べたりとかしています。


懇親会

今回は合同勉強会ということで、いつもより出てくる食べ物も豪華でした。
いくらとしゃけの親子丼やローストビーフ丼など超いい感じでした。
f:id:takaaki_z:20161102190724j:plain


所感

久々の登壇かついつもより人数も多いので若干緊張しましたが、やっぱりプレゼンは楽しいですね。
あとは発表すると「innoDBの人ですよね!」みたいな感じで覚えてもらいやすくなるのがいいところ。
同年代のエンジニアも結構多く、いろんな人と交流できたので非常に楽しかったです。

プロのソフトウェア開発者に必要な考えとは!?Clean Coderを読んだ

ソフトウェア開発を生業とする者として、開発時に意識するべきことや行動を
身につけるべく、本書を購入しました。


Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道


本書の内容を一言でまとめると

【プロとして、自分の作るプロダクトや行動に責任を持て】

となります。


責任を持つとは?

まずは、自分が作るプロダクトに対して出来るだけバグを作らないようにすることが求められます。


何回も手術を失敗する医者にかかりたいでしょうか?
何回やっても負ける弁護士に弁護を依頼したいでしょうか?


答えはノーでしょう。


同様に、プロの開発者はできるだけバグを作らないように意識し
実装しなければならない、と本書では述べられています。



とはいえバグがないことを証明するのは非常に難しい。


バグがないことを証明することは難しいが、
すべてのコードが正常に動いていることは把握しなければならない。


そのためにはTDDを用いて実装を行うべきだと、述べられています。

(このあたり、なぜTDDなのか、という話も本書の中で説明がされています)



また、ソフトウェア開発は非常に高度な作業であり、莫大な集中力を必要とします。
そんな作業において、いかに単位時間あたりの生産性を高めることができるか。


ここにプロとしての自己管理力が求められる、と述べられています。


その他にもチームとしてどう行動すべきか、何を意識すべきかという話など
様々な観点から、プロとしての意識や行動について記述されています。


その数、14章にまでのぼります。

最後に

私自身、ソフトウェア開発を生業とする者としての意識はまだまだ足りなかったと、
痛感しました。

おそらく一度読んだだけでは身につかないものだと思うので、

繰り返し読み、自分の意識に刷り込んでいきたいと思います。

fuelphpのORMモデルによるDBアクセス時のデータキャッシュには要注意

最近がっつりハマってしまったfuelphpのORMモデルメソッド利用時の仕様について。


ORMのCRUDメソッドを利用してDBアクセスした場合、fuelのフレームワークがよかれと思ってアクセス時のデータをキャッシュしてくれます。
そして同じレコードに対するデータアクセスがあった場合には、そのキャッシュデータを返すという仕様になっているようです。


この仕様のせいでどえらいハマってしまったので、記録として残しておきます。


ORMのCRUDメソッド実行時の詳細なSQLクエリ実行の様子や、キャッシュを避けるための方法についてはQiitaにまとめて投稿しておりますので、そちらをご覧ください。
qiita.com



今回得た教訓としては、
・データの設定や実装が正しいのに、想定する結果とならない時はデータキャッシュを疑え
フレームワークを信用しすぎない
ということ。


この二つは連動しており、フレームワークの挙動を一切疑うことなく、「想定通りにいかないのは自分の実装が悪いからだ!」と信じきっていたため、原因追求に時間がかかってしまったと思います。
想定しない挙動によるエラーが起こった時には、多角的な視点を持って解決に臨むべきだと学びました。