クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

AWS Chatbot を使って AWS Personal Health Dashboardの通知をいい感じにSlackに通知する

みなさんこんにちは。SREチームの @kangaechu です。

8月23日に発生したAWSの障害は大丈夫でしたでしょうか?弊社のサービス crowdworks.jp は障害が発生したAZを使用していたものの、幸いにもサービス停止などの大きな被害を受けることなく乗り切ることができました。でも心臓にはよくないですね。

そんな障害時にも活躍するのがPersonal Health Dashboardです。 Personal Health Dashboardは自分のAWSアカウント上のリソースに影響する障害や、ハードウェアメンテナンスなどの対応が必要なイベントをお知らせしてくれる機能です。 AWSマネジメントコンソールの上部に表示されている🔔のアイコンですね。

f:id:kangaechu:20190906091220p:plain:w200
AWS Personal Health Dashboard

Personal Health Dashboardは便利なのですが、AWSマネジメントコンソールにログインしないと見ることができません。メールでの通知はあるのですが、Slackのインテグレーション経由で見ると長々と文面が表示され、要点が掴みづらいという問題があります。また、SNS経由でメール通知も試してみましたがJSONが潰れて表示され、可読性がよくありませんでした。

f:id:kangaechu:20190909155038p:plain:w400
SNS経由でのメール通知で SlackにPostしたもの。みづらい⤵️
2019年7月にAWS Chatbot のパブリックベータ版がリリースされました。

aws.amazon.com

AWS ChatbotはSlackへの通知をサポートしています。またAWSの他サービスからの通知の受信をサポートしています。現時点では以下のサービスが対応しています。

  • AWS Billing and Cost Management (for AWS Budget Alerts)
  • AWS CloudFormation
  • Amazon CloudWatch
  • AWS Config
  • Amazon GuardDuty
  • AWS Health
  • AWS Security Hub
  • AWS Systems Manager

今回はAWS Personal Health Dashboardの通知をSlackに通知してみましょう!

続きを読む

リファクタリング専門チームによるお金周りリファクタリング

こんにちは、エンジニアの @MinoDriven です。 今年2019年4月にリファクタリング専門チームを発足しました。 crowdworks.jp の最重要機能であるお金周りの機能に関して、どのような技術アプローチでリファクタしているかを紹介致します。特に、Railsには適用困難と言われているドメイン駆動設計の考え方を取り入れた手法を解説致します。


目次

  • 背景
  • リファクタリング専門チーム発足
  • 技術的負債
  • リファクタリング対象選定
  • どのようにリファクタしたか
    • 手法①:Concern側メソッドのinterface化
    • 手法②:ドメインオブジェクト
    • 手法③:コンテキスト分解
  • 成果
    • 構造before→after
    • 技術的負債が低減した
    • ロジックの見通しが良くなった
    • 仕様が見える化された
  • 苦労してること
    • 影響範囲調査が大変
    • 仕様不明瞭
    • テストが大変
  • その他リファクタリングする上で重要な考え方
    • 理想の設計を追い求めること
    • 既存コードを一切信用しないこと
  • We are Hiring!!

※本記事は下記スライドと関連します。ご参考にどうぞ。

www.slideshare.net

背景

過去記事 にあるように、crowdworks.jpはサービスインから7年経過し、30万行を超えるモノリシックRailsアプリになっています。

f:id:yo-iida:20190611210040p:plain:w600

コード増加量やファイル変更数が低下し、開発生産性が低下傾向にあります。 技術的負債の蓄積により、事業継続性や成長性を考える上での課題となっております。


リファクタリング専門チーム発足

技術的負債に対しては、外から見た挙動を変えずにコードを整理する「リファクタリング」で解決する必要があります。 しかし新機能追加案件に比べると優先度が落ちてしまうなど、力学上どうしても後手後手になりがちです。

そこでプロダクト開発と同じプライオリティでリファクタリングを遂行できるように、2019年4月にリファクタリング専門チーム「バグハンター」を発足しました。 チーム名は、私が制作した、リファクタリング技術によりバグを退治するゲーム「 バグハンター 」に由来しています。

バグハンターは一般的には「セキュリティ脆弱性を発見し賞金を得る専門家」という意味で使われますが、ここでは「バグやバグになりやすい設計を退治する専門家」という意味合いで使っています。 「バグが生まれてからバグ退治するのは退治にあらず。始めからバグが生み出されない、バグを根絶やしにする構造に作り変えるのが真のバグ退治」という想いも込めています。

私を含めチーム人数は2名。 両名ともエレガントなコードや設計が大好きで、なにより私自身は リファクタリング専門要員として採用され 、2019年2月にクラウドワークスにジョインしました。


技術的負債

様々な技術的負債を抱える中、目下最大の課題はFat Modelです。

f:id:DaiyaDriven:20190829174906p:plain:w300

crowdworks.jpではActiveRecordの多くがFat Modelとなっています。 Railsのお作法ではFat Modelがあるべき姿なのかも知れません。しかし実際には巨大化複雑化しすぎていて、下記にあるような技術的負債を抱え、開発生産性に悪影響を及ぼしています。

続きを読む

認定スクラムマスターになりました!

f:id:flatba:20190822183816p:plain:w450

お久しぶりです。気づけば入社してから1年以上の時が経ちました。
プロダクトDiv. カスタマーサクセス でエンジニアをしております @lemtosh469 です。

2019年3月、認定スクラムマスターの資格を取得しました!

認定スクラムマスターを取得してから少し期間が空いてしまいましたが、 改めて記事としてまとめることで、 クラウドワークスにおけるスクラムマスターの活動の様子が少しでも社外に伝われば幸いです。

クラウドワークスでは、アジャイルにプロダクト開発を行っており、 主にスクラムフレームワークを採用しています。 (スクラムとXPのハイブリット*1が多い印象です。)

これまでもスクラムを採用したアジャイル開発自体は活発でしたが、スクラムの手法に責任を持つ役割(ロール)のスクラムマスターの認知はそれほど高くはありませんでした。 しかし、ここ最近急速に スクラムマスタースクラムマスターに興味を持つ人 の数が増えつつあります。

今回は、

をまとめて記事にできればと思います。

目次

  • 認定スクラムマスター研修のこと
  • スクラムマスターになって行ったこと
    • 社外コミュニティに出ていく
    • 具体的に起こした3つの行動
      • 1.ビジネスサイドのチームにエンジニアとして入る
      • 2.全社横断のスクラムブートキャンプ読書会の開催
      • 3.社内スクラム知見共有会の開催
  • おわりに

認定スクラムマスター研修のこと

認定スクラムマスターとは

認定スクラムマスター(CSM: Certified ScrumMaster)とは、 ScrumAllianceの提供する2日間の研修講座を受講してWebテストに合格すると取得できる資格です。

www.scrumalliance.org

スクラムマスターは、主に下記のような役割が定義されています。

スクラムマスターがやること

  • ROIを最適化する文化と環境を維持する
  • スプリント計画を運営する
  • スプリントレビューミーティングを招集する
    • スクラムチーム以外のひとがやってくる(チーム外の人など)
  • 外部からの撹乱からチームを守る盾となる
    • (スプリント期間中に)プロダクトバックログアイテム以外の作業をさせない
  • 進捗に対する障害を取り除く
  • チームに指示しない、チームが何をすべきか言わない、という場合もある
  • 振り返りを促進すべき

また、スクラムガイドと呼ばれるルール集などを規範としてスクラムチームを支援します。

https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

認定スクラムマスター研修とは

研修は、2日間に渡って行われます。 座学とワークショップを繰り返しながらスクラム開発について身体で学んでいきます。

www.jp.agilergo.com

僕の参加した回では、 ジェームス・コプリエン氏と川口恭伸(@kawaguti)さんを講師として、 スクラム開発を実践していくための基本的な知識の理解や心構えを体得していきました。

ちなみに、ジェームス・コプリエン氏は『組織パターン』の著者です。

組織パターン (Object Oriented SELECTION)

組織パターン (Object Oriented SELECTION)

基礎から学べるとはいえ、ソフトウェア開発の用語や考え方、 実際に現場でスクラム開発を実践されている方が多く参加されているので、 事前知識や具体的なスクラムの実戦経験があるとより実りのある研修になるのではないかと思います。 (質問の時間もありますので、日々の実践で湧いてくる疑問も講師に聞いてみることができます。)

ランチタイムや自由時間は、基本的にフリーに過ごすことができますが、積極的に他の人に話かけるほうがよいです。 社外のスクラム実践者/経験者、アジャイルコミュニティの有識者と知見の交換や考えを知ることができる貴重な時間でもあります。

僕はおしゃべりが得意な方ではないので「意外と弁当お美味いっすね!」くらいを入り口にして、席の近い人とお話をさせていただきました。

余談ではありますが、アジャイル系のコミュニティのイベントは、 基本的にOST形式*2が取られていることが多く、ディスカッションを通じてアジャイルスクラムの理解を深めていきますので、積極的に話すことに慣れていくほうが圧倒的に得られるモノが多いです。

*1:スクラムフレームワークにXPのプラクティスを組み合わせてアジャイル開発をしている

*2:OST(Open Space Technology)は、参加者が議論したい課題を自ら提案し、自主的に話し合いを行う手法です。

続きを読む

クラウドワークスのアプリ開発チームでQAを導入した話

こんにちは、アプリチームの @tkoshida です。

昨年末より弊社ではQA(品質保証)担当の方(以降、QAさん)をチームに迎え入れたので、弊社アプリチームのQAさんがいる状態でのチーム開発の取り組みを紹介してみたいと思います。

f:id:tkoshida:20190801165146p:plain

続きを読む

スクラムマスター2年生のスクラム観

こんにちは、 @yizknn です。 2018年1月にLSMスクラムマスター認定を受けまして、スクラムの手法で強いチームを作ろうと日々もがき続けています。

今回はこれまで3つのチームでスクラムした中で出来上がってきたスクラム観について語りたいと思います。 あくまで1人のスクラムマスターとしての意見であり、団体としての総意ではないことをここにご了承ください。

アジャイルスクラムの用語は流行り廃りやチーム内の造語で置き換えがよく発生します。 この記事では意味がズレないように、スクラムガイドの用語を使用します。 スクラムガイドは日本語訳のpdfも配布されています。 https://www.scrumguides.org/index.html

スクラムとは

f:id:yizknn:20190717183103p:plain スクラムの概要を1分で理解できるイラスト【2018版】 | Ryuzee.comより

スクラム(名詞):複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価 値の高いプロダクトを生産的かつ創造的に届けるためのものである。

表現が少し濃いですが、私は「共通のゴールに到達するため、開発チームが一体となって働くこと」がスクラムだと考えています。 1人よりもチームで強くなることで生産性が上がり、楽しく仕事が進められるようになるという理想の職場環境です。 仕事が順調に進むとモチベーションを高く維持できるので、会社で働くことが楽しくなってくるでしょう。

なぜスクラムを取り入れたいのか

不確定要素の多い開発の場合、「素早く価値を提供する」ことが求められます。 その価値が目論見通りの価値になるか分からないので、素早く提供して反応を見ながら訂正していくのです。 スクラムフレームワークの定義が整っていて、すぐに手法を実践できるため、試しながら効果を実感できます。 共通言語として用語へのイメージも固定されるので、学習コストも低くなります。

気になったら試しに始めて、組織的に取り組むとなったらスケールを広げられるのも魅力です。 スクラムは明確な改善意識を育てる手段でもあるので、指摘を受けて襟を正すのではなく、自立して問題に立ち向かえるようになります。

プロダクトバックログは開発の外を意識する

「顧客にどんな価値を提供できるか」を主題にすると上手く機能しました。

1つの製品または機能に対する要求をユーザーストーリーに分割して、優先順位を付ける方法がシンプルで運用しやすいと感じました。 例えば、「庭で気軽に遊びたいので家の木を使った遊具で遊べる」のようなタイトルです。 顧客は何が得られるのか、実装されると何が嬉しいのか、実装の目的を明確にすると実現方法を想像しやすくなります。 タイトルに全て詰め込むと長くなってしまうので、補足事項として背景や何が目的なのかは別に文章化しておきましょう。 例えば、気軽に遊ぶというのは安いものでいいのか、運用するのが楽なものがいいのか、などの設計で重要なことを明確にします。

ここでは実装方法は問わずに価値を主題にすることで、プロダクトオーナーとチームメンバーで話が通しやすくします。 プロダクトバックログを管理して完了を宣言するプロダクトオーナーが、ビジネスサイドとして価値があるか判断しやすくなれば齟齬も生まれにくくなります。 有名な画像にもあるように、顧客の要望とその要望に対応する価値は一致しないことが多いです。 本当に必要なものを考えるためには、なぜそれが必要なのかを知る必要があるのです

f:id:yizknn:20190718105014j:plain Project Cartoon: Japanese

スプリントバックログは開発の作業を意識する

「価値を生むために何をするのか」を主題にすると上手く機能しました。

ユーザーストーリーを実際の作業に落とし込んで、1日で終わるようなサイズに分割します。 この1日の匙加減は適当でよく、MTGが特に多くなければ長くても3~5時間程度で終わる量を想定するとタスクが終わりやすかったです。 それ以上の大きさになるようであれば、レビューの難易度やタスクの属人化を考慮してペアプログラミングやモブプログラミングで片付けたいです。

タスクはなるべく翌日に持ち込まないようにして、タスクの属人化とモチベーションの低下を防ぎましょう。 意味のあるコードとして無理にまとめようとすると、リファクタリングなど修正範囲が膨らむ事になり、時間が掛かると中途半端にマージして別のリファクタリングを挟む事になります。 そうなると、1つのタスクに縛られ過ぎて仕事が進んだ心地になりません。 同じような結果になるのであれば、どこまで進んで何が障害になるのか分かるような区切りにして、着実に進んでいる実感を得られた方が良いと感じました。

スプリントプランニングでゴールを決める

次に何が完成したら目的達成となるかを主題にすると上手く進むと感じました。

プロダクトバックログを上から眺めて、完了させたいユーザーストーリーをスプリントバックログに移します。 そのユーザーストーリーたちの完了条件を決めて、全て終わらせたらゴールすることを確認しましょう。

可能であれば作業期間となるスプリントの日数も決めない方が良いかもしれません。 目指すゴールに辿り着いた時がスプリントの終わりとなった方が、次々と加速して前進していくように感じれます。 ゴールを追い抜いた後はボーナスステージではあるのですが、明確な目的が消えてしまうので実の所モチベーションが上がらないことが多いです。

見積もりの手順が抜けていますが、見積もりはしない方が良いと考えています。

見積もりは作業の目安にしてやり過ぎない

まず、ソフトウェア開発は不確定要素が多く、作業時間を予測して管理することに向いていません。 再現性が低く、異なる状況に対応する必要があるからです。

見積もりの精度は作業が進行するにつれて上がるため、最初からスケジュールを定めて引こうとしてもうまくいきません。 もし見積もりが正しく働いていると感じているなら、それは見積もりを正しく見せるために動いていて危険な状態かもしれません。 パーキンソンの法則である「仕事の量は完成のために与えられた時間をすべて満たすまで膨張する」になっていたり、ベロシティが人事評価に繋がるようになって実際以上の成果を作るようになってしまうことがあるのです。

何より見積もりには膨大な時間が掛かります。 不確定要素が多い時に抜けが無いように時間を掛けても、いずれ何かしら忘れていたことが発見されて再見積もり、スケジュールとズレてくると再見積もり、と際限がありません。 それだけの時間を消費して敏捷さを損なっている状態でアジャイル開発だと言えるでしょうか。

www.industriallogic.com 2012年の古い記事ですが、既にモダンアジャイルの提唱者も見積もりを辞めるべきと書いています。 Regional Scrum Gathering Tokyo 2019では、Chris Lucian氏が何年も見積もりの無い状態「No Estimate」で仕事をしていて、とても良くチームが機能していると話してくれました。 何年も前からアジャイル開発者の中には見積もりは必ずしも良い手法ではないと気付いて実施していない人たちがいました。 ビジネスサイドからすればリリースのスケジュールが引けないので頭の痛い問題ではありますが、より良いものを早く提供していれば約束が無くても顧客の信頼を勝ち得ることは成功者が証明しています。

個人的には見積もりは作業の大きさが分かる目安にして、個人でやれるか協力してやるのかを決めるくらいにした方が効率も上がるので好みです。 ただし、お互いに信頼があり技術力も高まっている「強いチーム」でなくても実践できるかはまだ試せていませんので、実戦経験などある方がいましたら教えてください。

デイリースクラムをチームの成長に繋げる

デイリースクラムとは、開発チームのための 15 分間のタイムボックスのイベントである。

スクラム会議の目的は、進捗の障害と解決策をチームで話し合い共有することです。 自分のタスクの進捗を報告するのではなく、なぜ遅れているのか、早く進んでいるなら何を前倒しにできそうかを話し合う場になると、チーム全体の進捗が良くなるので成長に繋がると感じました。

スクラムでは輪になって順番に報告していくスタイルを提案していますが、話すのが苦手な人にも順番が必ず回るという利点もありつつ、自分の番以外には興味を失って黙り込む欠点もあります。 かんばんスタイルでタスクを管理している場合は、人ではなくステータスを順に見てタスクを移動させられるか話し合う方が活気付いて良かったです。 特に物理的なかんばんボードがあるなら、止まっているタスクがあるとみんなが注目してタスクをどうするか話し合いやすいのです。 順番に話していくと人に注目しがちなので、ともすれば個人に責任や問題が転嫁しない工夫が必要です。

スクラムの定義では15分とされていますが、30分程度まで伸ばして振り返りの要素を入れてあると良いように感じています。 スプリントレトロスペクティブまで待つのではなく、改善できることは早く見つけて忘れずに対応するためです。

スプリントレビュー

スクラムでは、チームが一丸になってスプリント毎に設定したゴールを目指します。 そのゴールに辿り着いたかを関係者にお披露目するのがこのレビューです。

スプリントレビューを開催しないスクラムチームの多くは、タスクを消化することがモチベーションに繋がってしまい、個々人のタスク消化に執着することが多いように感じています。 チームが提供できた価値を正しく評価されることが、モチベーションやチームの一体感を育てる最も良い方法だと考えています。

そのため、場合によっては他部門や別チームの人も呼んで盛大にお祝いした方が良いでしょう。 お互いにリラックスした状態で仕事が出来れば、より良い発想や協力関係になっていくからです。 良い議論をするためには、遠慮なく意見を言い合える関係性が不可欠です。

ドーナツとコーヒーを用意して集まるだけでも雰囲気が良くなるかもしれません。

スプリントレトロスペクティブは小まめかつやり過ぎない

スプリントレトロスペクティブは用語が長いので、以下から「振り返り」と呼びます。 短い時間でも1日に1回振り返りをする方が、もっと長い間隔で開催するより効果的だと感じました。 1週間に1回の振り返りでは直近または個々の記憶に残る出来事に引っ張られてしまいます。 チームに関わる問題を意識的に思い出すことは難しく、記憶に残るきっかけも異なるので大事な改善要素が消えていきます。

毎日KPTを書き溜めてチームの振り返りで発表する方法は、気に掛かる点を忘れないという点では有効でしたが、週末に大量のTRYが出ても実践できずに捨ててしまう結果になりました。 中には実施しなくて良いこともあるので、TRYがあれば良いというものでもないですが、無かったことにはせずにTRYの駐車場を作る方が良かったですね。 あとから見回して必要なくなったら取り除けば良いのです。

振り返りはチームが成長する時間です。小まめに丁寧な手入れを続ければ、チームは強くなっていくでしょう。 ただし後から話した方がいいことは後回しにして、話し合いに疲れないくらいの適度な量に調整しておきましょう。 もう疲れたよと誰かが言ったら笑って止められるくらいが丁度いいです。

最後に

スクラムは初めてアジャイル開発する時に強力な助けとなります。 しかし、全員がスクラムしたいという意識が揃わないと上手く回らず、スクラムは合わないとなってしまうことも多いです。 結局のところ、スクラムは開発運用の助けであってチームの関係性を変えるものではないので、コミュニケーションは別枠で考えて大事にしていく必要があります。 そうした問題を乗り越えたチームで働いてみたくて今日もスクラムしています。

クラウドワークスではチームと共に成長したいエンジニアを募集しています。

www.wantedly.com

© 2016 CrowdWorks, Inc., All rights reserved.