プロジェクトを遅らせずに現場の要望にも対応するための仕組み

サグーワークス開発チーム PM の横道です。
サービスを運用していると利用者や運営メンバーから不満や改修依頼を受けることが少なからず発生してきます。一方で、開発からも運用を楽にするための提案をしているため、優先度をしっかりと判断して進めていく必要があります。そこでサグーワークスではどうやって要望を吸い上げて対応しているのかを紹介します。

要望の吸い上げる方法

1.定常的に発生する運営メンバーからの要望や依頼

業務を行っているとシステムに関する要望や質問が出てくるはずです。そうした内容を漏らさず対応するために要望を上げるときは下記の運用ルールに沿って運用しています。

要望の内容 依頼方法 補足
簡単なデータ取得 / 変更 Google フォーム 「簡単」の目安は 30 分以内に終わる規模
質問 Slack 相談チャンネル
開発要望 Slack 相談チャンネル
システム不具合 Slack 相談チャンネル
その他 Slack 相談チャンネル どれに該当するか判断がつかない場合も該当

※どれに該当するか運営メンバー側で判断します。

Googleフォームの場合

開発へ依頼する専用の Google フォームに投函してもらい、投函された内容は当日中に開発側で対応することにしています。急遽入った依頼で丸一日時間を使ってしまうことが無いように、投函されてから長くても 1 時間以内に収まる規模にしています。
サグーワークスチームでは週末に 1 週間の開発計画を立てるようにしていて、その際に依頼への対応分も見積もりに入れているため、対応する度に予定していた開発が遅れるということは起きないようにしています。 とはいえ、時間が掛かる依頼の中で「今日中にやってほしい」とお願いされることもあります。その場合は本当に本日中にやらなければいけない依頼か判断した上で、現在行っている開発が遅れる旨を伝えて合意を取った上で作業を進めていきます。

f:id:m_yokomichi:20180606103742p:plain

Slack 相談チャンネルの場合

Slack に専用の相談チャンネルがあるのでそこで以下の流れでやり取りを行います。

f:id:m_yokomichi:20180606104550p:plain

依頼したことが無い人は Google フォームで依頼するべきことか、Slackで相談するべきことか判断がつかないことがあります。その場合は Slack チャンネルで相談してもらい、必要に応じて Google フォームに促すことで次回から正しいフローで依頼してもらえるようにしています。サービスの質問に関しては web ディレクターが回答できることは回答してもらい、システムの詳しい仕様については開発が回答する形を取っています。 開発要望やシステム不具合の場合は「開発要望リスト(後述)」に記載して、相談者に要件リストに載せて判断をしていく旨を伝えます。

2.会議中や雑談から生まれる発想

会議の時や雑談の時にアイデアが突然降りてくるときがあります。そのアイデアも他の要望と同列にした上で対応する・しないを判断する必要があります。 しかしながら、全ての思い付きを開発要件として並べると時間がいくらあっても足りません。 そこで、 web ディレクターがその要望を聞いて開発要件として並べるべきかどうか判断し、開発したほうがいい要件を「開発要望リスト(後述)」に記載していきます。
開発から出た改善案は開発チーム内で要件として立てたほうがいいか議論した上で「開発要望リスト(後述)」に記載し、他の要望と同列に判断できるようにしています。

口頭で相談するという点以外は Slack で相談が来た時と同じフローになるようにしています。

開発要望の判断

上記で登場した「開発要望リスト」を元に web ディレクターと開発でミーティングを実施して判断しています。 ミーティングは毎日 10 分~ 30 分で実施し、 1 日で上がった要望の確認を行います。

〇開発要望シート

要望内容 期待効果 対応方法【ミーティング時に追記】 対応予定工数【ミーティング時に追記】 優先度【ミーティング時に追記】
手動で行っている〇〇作業を自動化してほしい 10 h/月の運用工数削減 運用のフロー確認・開発 30 h 4
〇〇機能の絞り込み条件を追加してほしい 2 h/月の運用工数削減 検索フォームの条件追加 4 h 6
  • 開発内容  :どういった要望なのか、何をしてほしいかを記載する
  • 期待効果  :要望が達成された場合の期待効果を書く。(不具合時は対応しなかった場合も記載する)
  • 対応方法  :ミーティングで開発内容を聞き、開発時に何を対応するか分かるように開発側で記載する。
  • 対応予定工数:対応にどれくらいの工数が必要か見積もりを行う
  • 優先度   :対応内容と見積もりから web ディレクターが優先度を決める

要望の内容が不明確な場合はどういった対応を行えばいいか分からない為、発案者と web ディレクターですり合わせを行ってから開発が内容を確認します。期待効果の記載が無い場合は開発の対応工数に比べ効果が余りでない可能性があることと、期待に添えることができるかがわからないので期待効果を記載するようにしています。

こうして優先度と対応内容が確定した要件は順に開発が対応していきます。 毎月どれくらいこの要望リストに時間を当てるか計画して、優先度の高い要望が多い場合は次月以降で「開発要望リスト」の要件に割り当てる時間を増やし対応していきます。

webディレクターを窓口にしている理由

数年前は運営メンバーから直接開発に改修依頼がいく仕組みになっていました。その場合、新しく入った依頼が対応されやすくなり、本当は優先するべき依頼がないがしろにされる事がありました。 さらに web ディレクターを通していなかったので、事業サイドはどういった機能が開発されたかも把握できていないという問題もありました。
全ての依頼に対して web ディレクターを通すことで、要望を横に並べて正しく判断して対応できる仕組みにしています。

新卒研修振り返り

こんにちは。2018年度の4月に新卒で入社したエンジニアの小澤です。入社して2ヶ月が経とうとしています。 

学生時代は、情報セキュリティについて専攻している4年制の専門学校に通っていましたが、自分の作ったものが他人に使ってもらえるwebの領域に興味を持ち、在学中はweb開発をしているインターンシップなどに参加していました。

今年度は新卒14人の中から、私を含めた6人が開発グループに配属されました。入社してすぐに新卒社員全体の研修とエンジニア全体の研修があり、エンジニア研修は、「全体研修」と「チーム内研修」の2つに分かれていました。 

今回のブログでは、チーム内研修についてまとめていきたいと思います。

企画からサービスを作る「チーム内研修」

チーム内研修では、業務に慣れるためにチームで実際に使っている技術やツールを使い、サービスを1から作ってみる、といった内容で、私は趣味に関して情報発信や意見を交換することのできるSNSを開発しました。

具体的には、どんなサービスを作るか検討するところから始まり、企画から要件定義、実装、テスト、セキュリティチェックなどを経験することができました。

f:id:rikipedia-5r:20180530093856j:plain

企画・要件定義

最初にどんなサービスを作りたいか決め、ターゲットとなるユーザを仮定します。そこからユーザにどんな背景があり、どんな負を解決したいのかを定義をしていくのですが、この工程が一番大変でした。ユーザの課題から要望を抽出したものの、作りたい成果物のイメージが浮かばず、なかなか要件が定まりませんでした。なぜ作る必要があるのか、そもそも作る必要があるのかなど、根本的な定義を見直したり、メンターや先輩社員からアドバイスやフィードバックも受けつつ、少しづつですが作るべきサービスの形が見えてきました。

このように試行錯誤を何度も繰り返しながら、ユーザが抱えている負を要件に落とし込む作業を経験できたことは、今後の業務でも役に立つ良い経験になったと思います。

実装

実装では、社内で使っているCakePHPを使っていれば他は何を使ってもよい、という制約があったため次のような構成になりました。

開発期間は1週間ほどしかありませんでしたが、最低限サービスとして稼働できることを目標にしていたので、機能ごとに優先度を決めて、それを元にスケジュールを引きました。

また、私はwebフレームワークを使った開発経験があったので、CakePHPの基本的なCRUDソースコードを自動的に生成することのできる「Bake」機能は使わずに自前で実装するという制約がありました。普段はコマンド1つで実現できる機能を自分で作るのは、フレームワークの恩恵を感じる良い機会でした。

ソースコードに対するフィードバックでは、要件定義と同じように、なぜそのような実装になったのか、もっとシンプルにできないかなど、コードを書くときに意識すべきことを学びました。そして、当初に想定していたスケジュール通りに、最低限動くシステムを作り上げることができました。

発表

最後に、チームメンバーに対して作った成果物を発表して、今回の研修を振り返る場がありました。プレゼンテーション形式でサービスを作った背景から説明し、先輩方のアドバイスを受けました。その中で、自分が書いたコードやドキュメントをなぜ書いたのか、なぜ書く必要があるのかなど、何事にも意味付けが重要だと言うことを学びました。 このように、自分はどんなことができたか、どんな進め方をすればよかったのかなどを振り返りました。

また、プレゼンテーション能力が不足していると感じました。 せっかくいいものを作っても、その良さが聞き手に伝わらなければ意味がないことを学びました。この振り返りから、LT会などにスピーカーとして参加し、発表の場に慣れることを今後の目標としました。

まとめ

今回の研修で、当たり前のことを当たり前にこなす大変さを痛感しました。学生時代はお金を払って学んでいましたが、社会人はお金を頂いて、成果を出す中で学んでいかなければなりません。 その中で、いかに自分が成果を出せるか、成果を出すにはどうすれば良いかを常に考えて業務に臨みたいと思います。

また、先輩方が私たちのために業務時間を割いて、この研修を作り上げてくれたことに心から感謝します。まだまだ未熟ではありますが、一刻も早くチームの戦力になれるように精一杯頑張っていきたいと思います。

web 開発経験ゼロの新卒が新人研修に参加しました!

はじめまして、2018年入社の田島です。 今回は入社まで web アプリケーション開発にほとんど触れてこなかった私が、新人研修に参加した模様についてお届けしたいと思います!

はじめての web アプリケーション開発

web アプリケーション開発の基本の「き」も知らない私が取り組んだのは、CakePHP を利用して二週間で web サービスをシステム要件から設計して実装するということでした。すなわち、web アプリケーションの実装はもちろんのこと、どのような人を対象とした何のサービスを作成するか考え、必要な機能の洗い出しや DB の設計まで一通りの行程を全て行いました。もちろん一人では分からないことばかりであったため、メンターの先輩に適宜教えていただきつつ進めました。

実装は実際の業務と同様に実装内容をタスクに分割し、実装予定時間を決めてスケジュールを立てながら行いました。また、Bitbucket を用いてタスク毎にプルリクエストを出し、先輩方からコードレビューをいただきながら進めました。

f:id:tajima-ryo:20180523184847j:plain

成果物について

私が作成したのはユーザ投稿型の web アプリケーションであり、記事の投稿や編集、ユーザ登録やログイン/ログアウトの認証などを実装しました。 システム要件を設計した段階では色々な機能を考えていたのですが、工数との兼ね合いにより、実装は基本となる機能に絞って行いました。また、同じく工数の兼ね合いにより実装の最初の部分のみ bake を用いた自動コード生成を利用しました。

こちらが成果物のスクリーンショットです。 (デザインは CakePHP のデフォルトのものです。デザインまで手を回すことができなかったのが痛恨の極みです。)

f:id:tajima-ryo:20180523181417p:plain

作成後はチーム内で成果物発表と脆弱性のチェックテストを行いました。

感想

MVC モデルがどのようなものなのかであったり、具体的な web アプリケーションの実装方法について学ぶ非常に良い機会となりました。そして、知れば知るほど CakePHP がいかに開発者が web アプリケーションを開発しやすいように作られているかがよく分かりました(笑)脆弱性に関してもCakePHPが標準対応しているものが多く、少しのコードの追加でチェックテストをクリアすることができました。

また、今回は web アプリケーションの実装だけでなく、システム要件の設計から取り組みましたが、これも大変勉強になりました。実装をしていく中で、システム要件があいまいであったためにどのように実装すれば良いのか迷うようなこともあり、サービスの要件や DB 設計の精密さが実装に非常に影響することを実感しました。

実装面ではコーディングの姿勢という点で学ぶべきことを多く感じました。学生時代はもっぱら動作することを第一としたコーディングをしていたのですが、レビューをいただく中で、「次にそのコードを触る人が理解しやすいか」というチーム開発を前提としたアドバイスをいただくことが多く、姿勢として変えるべき点に気づくことができました。思い出してみれば昔の私のコードは時が経つと自分自身でも読めなくなっていたのでした(笑)

最後に

まだまだ社会人としてもエンジニアとしても未熟な私ですが、これから努力を重ねて成長していきたいと思います。またトピックがあり次第ここで発信していきたいと思いますので、これからよろしくお願いいたします!

【スライドあり】勉強会「PHP5.xから脱却する為の道のり」に登壇しました!

サグーワークス開発チームの池添です。

勉強会の記事が続きますが、先日05/16に サポーターズCoLab - 若手エンジニアが「技術でつながる」仲間探しサービス さんで勉強会をさせていただきました。勉強会のタイトルは 「PHP5.xから脱却する為の道のり」 ということで、サグーワークスでのPHP5からPHP7へバージョンアップした際の内容を発表しました。現場推進をした私池添の立場と、事業部を説得しバージョンアップの後押しをしてくれた横道の二人の立場でそれぞれ発表しました。

supporterzcolab.com

当日のスライドです。

speakerdeck.com

勉強会の様子です。

f:id:zoe302:20180517112607j:plain

f:id:zoe302:20180517112654j:plain

最後はサポーターズのキャラクターのサトアズさんとも写真を撮ってもらいました!

f:id:zoe302:20180517112514j:plain

最後に

今回勉強会でPHPのバージョンアップについて発表させていただきましたが、思い返すとこのPHPのバージョンアップを皮切りにテストコードの導入や、CIの導入、社外勉強会への登壇、フレームワークのバージョンアップ、Dockerの活用など、さまざまなことにチャレンジするきっかけになりました。これからもさまざまなことにチャレンジして得たナレッジをまた勉強会などで発表していきたいと思います。

【スライドあり】社内勉強会「Hacker’s GATE Plus」を開催しました!

こんにちは。ウィルゲートで開発を行っている三島です。

先日、3月23日にオルトプラス(エンジニアブログ : AltPlus Tech Blog)さんと合同勉強会「Hacker’s GATE Plus」を弊社のオフィスを使って開催しました。 この勉強会は弊社の岡田が他社との交流を通してエンジニアとしての知識を深めていくことを目的に定期的に開催しているものになります。

今回の勉強会は「アプリについて」をテーマに開催しました。 ウィルゲートからは私が「Webエンジニアがアプリを開発(運用)できるようになるまで」を発表しました。

当日のスライドは以下になります。

f:id:MikaE:20180426200124j:plain

f:id:MikaE:20180426200140j:plain

感想

私がネイティブアプリの運用を始めたときは、社内でアプリ開発を行っていなかったため、ネイティブアプリについて聞くことのできる人がいませんでした。 こういった機会で自社にない知見を得ることができるので、少しでも自分にないものを取り入れていきたいと感じています。 今後も登壇など積極的に取り組んで行きます。

開発室を成長させる4つの戦略

f:id:odoroodoro:20180502152849j:plainはじめまして、執行役員の鶴飼です。主に開発組織の戦略・ビジョン作りやトップマネジメント層の育成を行っています。 前期まではゼネラルマネージャー(以下GM)として開発組織の強化に専念していました。 執行役員になりGMとは違う一段上のステージで組織を牽引するなかで意気込みを語っていきたいと思います。

そもそも私はどんな人物か?

執行役員になるまでの経緯

ウィルゲート入社前
  • 2015年5月にウィルゲートに入社するまで、およそ14年間はweb系SIerとして4社ほど経験をしてきた
  • PM経験が豊富で、オフショアも中国とベトナムなど複数経験済み
  • 10年ぐらいはPHPの現場でやってきており、チョコチョコ書いていた
  • メインはサーバサイドだが、インフラ構築、ミドルウェアチューニング、当時ajaxがはやり始めた頃に使い始めるなどフルスタックエンジニアだったと思う
  • 他社サービスのグロースをメインで行ってきたが、自社サービスのグロースや組織作りがしたくて転職。
  • 自社サービス・組織としても成長途中である事、社長の社員に対する想いや企業理念に惹かれ、ウィルゲートに入社。
ウィルゲートに入社後
  • 最初はエンジニアとして入社希望しており開発を頑張っていた
  • 当時、自社サービス(サグーワークス)の大規模開発(25人月程度)があり、PM経験があった為、抜擢される
  • 入社3ヵ月でリーダーに抜擢
  • 自社サービスの特性など、今考えるとあまり分からぬままプロジェクトスタート
  • 自らも開発しながらプロジェクトを完遂させる
  • 10月頃から特殊案件で人員が減る中、サグーワークス、暮らしニスタなど複数のメンバー管理も行う
  • 2016年1月からマネージャに就任
  • 2016年4月からゼネラルマネージャに就任
GMになってから
  • 開発全体の戦略を纏める
  • マネージャ兼務のまま、リーダーの育成
  • 経営ミーティングに参加
  • 開発本部発足
  • 事業横断で技術ナレッジの蓄積が出来るようにフロントエンド・バックエンドなどセクションに分け、スペシャリストの育成体制の推進
  • 採用戦略の立案
  • 登壇や勉強会などのイベント開催

GMになってからの2年間でも自社技術が相当ブラッシュアップされ、環境も整備されたと思います。

tech.willgate.co.jp

tech.willgate.co.jp

これはメンバーの成長意欲に後押しされた形で体制を作ってきたものになります。 また、社内にマネジメントコースとスペシャリストコースがあり、大きくは2つに分かれているものの、”技術”というものが明確では無かったという点もあるので、 スペシャリストの中でもフロントエンドやバックエンドなど得意技術軸で成長ができるように整えてきました。

4つの戦略

長くなってしまいましたが、今期から執行役員として全事業開発の生産性向上及び技術研究をテーマに進めていきたいと思います。

ウィルゲート開発室は13期目を迎えましたが、過去最大のエンジニア人数になっています。

チームが大きくなると一人当たりの生産性は下がり、また全体の見通しが悪くなります。 自社でプロジェクトリーダーやプロジェクトマネージャーを育成しつつ、組織もプロアクティブに変更を加える事で、役割を明確にしつつ見通しのよいエンジニア組織でありたいと思います。 また、事業フェーズに合わせ、新しい技術へのチャレンジもメンバーの成長に合わせてどんどん取り入れて行きたいと思います。 やはりエンジニアは新しい技術に常に触れられる環境にいるのが最もバリューを出せると思いますし、何より自分自身が楽しくあるためでもあります。

また、それらを戦略に落とし込む時に大きな戦略を4つに分けて考えています。

  1. 事業開発戦略
    • 主に自社事業の開発する上でのチーム編成や抜擢人事、また事業のフェーズに合わせたQCDの設定などを方針を固めます。
  2. 採用戦略
    • 新卒・中途及び業務委託や外注など、開発人員の補強や中長期的な人員戦略の立案をします。
    • 母集団形成から訴求ポイントの打ち出し、リクルーターの教育まで含めて方針を固めます。
  3. ブランディング戦略
    • ウィルゲートの開発室の打ち出し方だけではなく、所属している社員に伝える為にもブランディング戦略は必要と考えています。
    • ブログのみならず、勉強会や登壇イベントなどアウトプットの方針を固めます。
  4. 技術戦略
    • 自社のコンピタンスとなる技術の追求や自社事業の中期目線で必要になる技術をキャッチアップ。
    • 開発本部のディレクターを中心に技術キャッチアップを行い、マネージャやプロジェクトマネージャが適宜、技術導入検討を行えるようにします。

戦略については、マネージャやPMOとディスカッションを繰り返し、各ユニットの戦術の形に紐づけてメンバーへ共有する形で、個人の成果が開発や事業の成果に直結するように設定しています。

まだまだ足りない技術もありますし、エンジニアの働きやすい環境が整ったとは言い難いですが、自身のWillでもある「ウィルゲートだからできるエンジニアとしての成長」にフルコミットしていきたいと思います。

Bitbucket Pipelines (CI) を使って気持ちよく開発する

サグーワークス開発チームの池添です。

今回はチーム目標「Comfortable development / 2.0」の取り組みの中から Bitbucket Pipelines (CI) の活用内容をお話していきます。 チーム目標に関しては下記記事に書いてありますのでぜひ読んでみてください。

tech.willgate.co.jp

Bitbucket Pipelines 利用に至ったきっかけ

チーム内では以前からコードレビューの時間短縮、負荷軽減のためにCIツールなどの導入を検討してきていました。

しかし、なかなか導入できなかった背景としてサービスの利用技術が古く、Composer が導入できない PHP のバージョンだったため、コードスタイルチェックのツールである phpcs やユニットテストのためのツールである phpunit が導入できないという状態が続いていました。

以前の記事でも紹介させていただきましたが、PHP のバージョンアップやフレームワークCakePHP のバージョンアップに成功し、今回 CI ツール導入にこぎつけることができました。また、チーム内にテストコードを書く文化を浸透させるためのCIツールとしての意味合いも強く、おかげで今では多くのテストコードが書かれています。

tech.willgate.co.jp

Bitbucket Pipelines とは

2016年10月から Atlassian が提供しているCIツールで、同じく Atlassian 提供の Bitbucket と連動させることができます。ビルド環境は Docker を採用しており自由にイメージを選択し、CI 環境を構築することができます。特徴としては、Bitbucket が公式で提供しているため連携のための手順が不要ですぐに使い始められることです。設定ファイルは bitbucket-pipelines.yml というものに記述していくのですが、docker-compose.yml のように記述していくことができるので直観的に書くことができとても使いやすいです。

ja.atlassian.com

他の CI ツールとの比較

導入の際に他の CI ツールとの比較もしたので載せておきます。

CIサービス名 料金体系 他と比べての目立つところ 2並列、月1500分のときの料金
Bitbucket Pipelines $10
500分まで無料
$10 / 1000分
弊社ではBitbucketを使っているので別ツール側の設定がほとんど不要, 実行時間に対して課金する(スケールは自動で行われる) $10
CircleCI $50
1並列で無料
2並列で$50
※時間はどこまで増えても金額が変わらない
最大で 24時間 * 60分 * 2並列 / day まで回せる
月あたり86400分くらい。
利用企業が多いので情報も多い
課金によって時間の制限が無い
スケールに対して課金する
$50
TravisCI $129
1並列で$69
2並列で$129
※時間はどこまで増えても金額が変わらない
最大で 24時間 * 60分 * 2並列 / day まで回せる
月あたり86400分くらい。
スケールに対して課金する
金額高め
$129
droneio 無料
ホスティング料金がかかる
自分たちでホスティングする必要がある
あまり情報が多くない
ホスティング料金
Bamboo $10
ホスティング料金がかかる
自分たちでホスティングする必要がある
弊社ではAtlassianクラウドを利用している以上はあえてBambooにする理由はない
$10+ホスティング料金
Jenkins 無料
ホスティング料金がかかる
自分たちでホスティングする必要がある
自分たちで細かな設定もいじるので運用に向けての検証などが必要
ホスティング料金
AWS CodePipeline $9.5 + 誤差
1並列あたり$1
最安インスタンスが $0.005 / 分
API Gateway, Lambda, S3 の軽微な金額が加わる
$1 + ($0.005 * 1500min)
複数のツールを組み合わせるためコストや利用がややこしい
AWSの安心ハイアベイラビリティ
$9.5+ホスティング料金

上記を踏まえ、2並列月1500分としたときの最安値を比べコストが一番かからず、かつ Bitbucket との親和性が高いという理由で弊社では Bitbucket Pipelines を採用しました。

Bitbucket Pipelines の利用例

私のチームでは下記内容をリモートブランチにプッシュしたタイミングで実行するように設定しています。自動で実行されることにより、コードレビューの負荷を下げることができています。

下記のようにステップごとに任意のコマンドを実行し、結果をコミット単位で確認することができます。 コミット単位以外にも手動実行や、スケジュール実行も可能です。

f:id:zoe302:20180413095744j:plain

また、下記のようにWebhooksを設定することでSlackなどとの連携も簡単にできます。

f:id:zoe302:20180413100854p:plain

f:id:zoe302:20180413100859p:plain

おわりに

いかがでしたでしょうか? Bitbucket Pipelines に限らず CI は日頃の開発作業を効率化するのにとてもいいツールです。

今回は社内でも一番使われている、テストの実行とコードスタイルチェック、ビルドの実行、Slack への通知を CI によって自動化し、効率化する方法を紹介しました。

紹介した内容以外にも、マージ済みのリモートブランチを削除したり、マージのタイミングで各環境へコードをデプロイしたり、スクリプトで表現できるものであれば大体自動化できるので、ほかにもいろいろ試してみるといいかもしれません。