読者です 読者をやめる 読者になる 読者になる

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

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

今日から始められるデザインスプリント

CrowdWorksでデザイナーをしている上田(@ueda1023)です。

創業の頃に入社し、今年で4年目。公式な露出は初めてな気がするので、緊張してます。

プロダクトオーナーやエンジニアの皆さんと一緒になって、 プロダクト成長のためにああでもないこうでもないとユーザーさんのことを考える日々です。

さて、皆さまの会社では、 エンジニア、デザイナーがしっかりと連携し、 順調にプロダクト開発を進められていますか?

よりよいプロダクトづくりに向けて悩みは尽きませんが、 私の担当したスマートフォンアプリのプロジェクトでは、 以下のような課題をデザインスプリントという手法の導入によって改善してみました。

  • スクラム開発で開発プロセスは型になってイイ感じだが、デザインプロセスが曖昧のまま
  • なんとなく全体的にコミュニケーションコストが高い
  • 実装コストの見積もりが甘く、スケジュールが遅延しがち

デザインスプリントの有効性は各所で語られているものの、 いざドキュメントを見てみると内容が複雑だったり実施コストが高かったりして躊躇しがちなのではないかと(私は最初はそうでした・・)

そのため、スマートフォンアプリチームでは、 デザインスプリントのメリットを得られる範囲で手順を柔軟に変更しつつ、 再現性あるデザインプロセスとして開発現場で実践できるようにデザインスプリントを噛み砕き、実践してみました。

最近では他チームでも導入されたりするようになったので、 今回はそんなCrowdWorksなりのデザインスプリントのHowToを紹介したいと思います。

そもそも、デザインスプリントって何でしたっけ?

平たく言うと、

  • Google Ventures 発祥のデザインプロセス
  • 意思決定者は全員参加
  • 「理解」「発散」「決定」「試作」「検証」という5つの手順を5日間かけて行う
  • アウトプットは仕様の決定とワイヤーフレームまで

といった感じです。

ちなみに個人的には、デザインスプリントを 「PO × エンジニア × デザイナーで施策の企画の段階からユーザー体験を考える手法 」と定義してみました。

はじめての方のために、定番のドキュメントのリンクを貼らせていただきました。 詳細を確認したい方は、ご参考ください。

デザインスプリントの利点

やってみた結果、以下のような効果があるなぁと実感しております。

  • デザインプロセスが型となり、新しい施策をやる度に進め方の議論をしなくて済む
  • 「それ、何のためにやるの?」というコミュニケーションがほぼなくなる
  • 差し戻しが発生しづらい
  • 全員でユーザー体験について考えるので、アウトプットの質が高まる気がする

エンジニアにとっても、デザイナーにとっても、うれしいことが多いのではないでしょうか?

CrowdWorksなりのデザインスプリントの進め方

実際の進め方としては、以下のような感じです。


参加者(スマートフォンアプリチーム全員)
  • プロダクトオーナー1名
  • エンジニア3〜5名
  • デザイナー1〜2名
事前準備
  • 施策の仮説まで決める。
    • 例:仕事を探す際の検索条件を保存して通知をメールで受け取れるようになれば、マッチング率が高まるのではないか?
    • 最初の工程でユーザーストーリーを書くので、その議論ができる下地を整える。
  • 参加者を決め、スケジュールを確保する。
    • 人数が多くなりがちなので、打ち合わせ場所まで確保しておくのが大事。
  • 持ち物を用意する。
    • 人数分のA4用紙とペン
    • ホワイトボード
#day1 理解する(所要時間:約1時間)
  • 施策の仮説を元に、ホワイトボードなどにユーザーストーリーを書き、参加者の認識を合わせます。

回数を重ねると、スムーズに進んで短時間で終わることも多いです。 短時間で終わりそうな場合は、「day2 発散する」の工程とセットにしています。

#day2 発散する(所要時間:約2時間)
  • ユーザーストーリーを元に、A4用紙とペンを使って画面ラフを書きます。
  • A4用紙を半分に折り、1枚に2画面ずつラフを書いていくようにしています。

この工程のポイントは、デザイナー以外の人も全員書き、順番に発表していくこと。 PO、エンジニア、デザイナーのそれぞれの目線でアイデアが出てくると、よい感じです。

#day3 決める(所要時間:約1時間)
  • アイデアを絞り込み、方向性をいくつか決めて打ち合わせを終了します。

「day1 理解する」と同様に、短時間で終わることが見込まれる場合は、 「day2 発散する」の工程とセットにしています。

#day4 プロトする(所要時間:約2時間)
  • 決めた方向性でデザイナーがワイヤーフレームを作成し、プロトタイプに落とし込んだ状態で 「day4 プロトする」に入ります。
  • プロトタイピングツールのProttを使い、簡易的なプロトタイプを作ることが多いです。
  • プロトタイプのレビューをします。
  • ユーザーテストで最終評価を行うプロトタイプ案を絞り込みます。

この工程まで進むと、完成形が概ね見えている状態となります。 チームとして完成形に納得感があり、検証するまでもなく実装・リリースして効果を検証しようと判断できる場合は、 次の「day5 検証する」はスキップしています。

#day5 検証する(所要時間:約2時間 × n人)
  • ユーザーテストを行い、プロトタイプ案のよしあしを評価します。
  • 評価の結果を踏まえ、最終的に案を決めます。
  • 評価を元に発見した課題はリスト化し、実装のスコープに入れられるかどうかの判断もします。
後工程
  • チームで認識を合わせるための仕様書の作成。
  • デザイナーは決まったプロトタイプを元にビジュアルのデザインを詰める。

以上、今日から始められるデザインスプリントということでHowToをまとめてみました。

もちろん、トライ&エラーを繰り返しつつ、よりよいやり方を試行錯誤して行きますが、 試してみる価値はあると思いますので、是非、今日から始めてみてください。

とくに、デザインスプリントのドキュメントを読んで、敷居が高いな・・と感じていた方は、 こちらの記事を参考にしつつ、是非チャレンジしてみていただきたいなと思っております。

We're Hiring!

クラウドソーシングのクラウドワークスでは、CrowdWorksのプロダクトデザインを強くするために力をかしてくださるデザイナーさんを募集中です。

www.wantedly.com

まだエンジニアに文言修正なんか頼んでるの?

プロダクト開発の中になぜか置いてもらっている非技術職の小林(週末は主夫、たまに会社でプロダクトオーナー)です。 日々、エンジニア OR デザイナー OR コピーライター に囲まれながら、プロダクトの成長を見守ってまっす。

ところで、プロダクトが成長していく過程で、新サービス・新機能のリリースに伴い LPや各種画面のちょっとした修正が増えていったりしませんか?

事業戦略上で重要な機能・サービスを開発をしているチームに、飛び込みでキャンペーンLPのテキストの修正依頼が・・・。 仲間としては施策担当者がなんとかしたいと思う気持ちもわかる、でも、エンハンスに集中していて細かい修正をする時間が取りづらい。 そんな時に、同じチームメンバーとして非エンジニアでも手伝えることがあるかもしれません。

クラウドワークスでは、簡単な修正であれば施策担当者(非エンジニア)が行ってしまうこともあります。 我々と同様にGitHubを導入している開発現場なら実現可能だと思うので手順を書いてみようと思います。

やりたいこと
  • エンジニアが、やろうと思っているタスクに集中できる環境を維持したい!
  • 施策担当者(非エンジニア)の要望に、迅速に応えてあげたい!
持ち物
  • インターネット・PC・ブラウザ
  • GitHubアカウント
事前に調整しておくこと
  • 施策担当者(非エンジニア)がGitHubにアクセスしてコード修正を行う承認と運用ルールの確認

私と同じような職制の施策担当者(非エンジニア)が実際に対応できるように、なるべく詳細に書くことを心がけます!

ブラウザから github.com を利用してコードを修正する手順

修正したい部分が書いてあるファイルを探す

実は・・・この段階から壁があるのです。 なので、ここからはじめます。

ファイルの場所を聞いちゃうのが早いんですが、いつもお願いしちゃっていることを理解するためにも探してみます。 同じ言葉が各所に分散しているケースの場合、依頼していることの影響範囲の大きさを再確認させられることもあります。

f:id:ebisuboz:20161101195549p:plain

Githubにログインし、担当しているサービスのコードが管理されているリポジトリ名の部分をクリックします。

f:id:ebisuboz:20161101195603p:plain

すると画面上部に「This repository」と記載されている検索窓が表示されます。

f:id:ebisuboz:20161101195613p:plain

修正したいLPや各種画面の現在のテキストの一部などを入力して検索します。 それっぽいファイルを見つけたら、近くのエンジニアさんなどをつかまえて 「fugafugaのLPのファイルって、◯◯◯.html.erbであってる?」といった確認をしてみます。 あってましたか?あってましたよね。次いきます。

f:id:ebisuboz:20161101195625p:plain

◯◯◯.html.erb のようなファイル名の部分をクリックします。

f:id:ebisuboz:20161101195637p:plain

画面左上の「Tree」と表示されている部分から「masterブランチ」を選択します。 「masterブランチ」の名前は事前に確認しておきます。 今回は「Sample」と表示されているブランチが「masterブランチ」であるとします。

現在、Web上に公開されているであろうLPや各種画面のソースコードが表示されます。 修正したい箇所を確認してみます。 ありましたか?きっと、あったはず。 では、xxx lines や xxx KB と表示されている列の右側、「History」の隣の隣のペンのマークをクリックします。

f:id:ebisuboz:20161101195647p:plain

なんと、ブラウザから修正できてしまうんです。 ということは・・・そうなんです。 関係ないところに余計なことを書くとヤバイんです。 ここからは特に慎重に作業します。何度かやっていても緊張感のある作業です。 変更したいテキスト等を修正します。

f:id:ebisuboz:20161101195753p:plain

修正の入力が完了したら画面下部の「Commit changes」という部分に必要な情報を入力していきます。 日本語で誰が読んでも変更した内容がわかるように書くように心がけています。 書き終えたら、入力欄の下の「Create a new branch for this commit and start a pull request.」の ラジオボタンをポチります。

f:id:ebisuboz:20161101195806p:plain

そして変更した内容を「masterブランチ」から分岐させる新しいブランチの名前を入力します。 今回は「blog_sample_branch」というブランチを作成します。 この画面での作業を終えるために「Propose file change」をクリックします。

f:id:ebisuboz:20161101195816p:plain

それぞれの現場で設定されている作法に則って、「Write」に変更内容をできるだけわかりやすく記載していきます。 「Label」「Assignees」なども選択します。 次に画面中断に表示されている変更前と変更後のコード(赤色と緑色の部分)に誤りがないか確認します。 問題なければ「Create pull request」をクリックします。これも何度やっていても緊張感が消えません。

作成した「Pull request」は勝手に「Merge」せずに必ずエンジニアにレビューしてもらいます。 レビューしてもらう際には「レビューオネシャス!」と元気よく声をかけましょうw 上手く修正できていれば http://lgtm.in/ などで見られるような画像が送られてくることが多いです。 「Merge」以降はエンジニアにお願いしています。

「この簡単な修正、誰かやっといてくんないかな。」といったシーンで、このエントリーをご活用いただければ幸いです。 チーム・組織全体で効率よく開発をしていくために、これからも上手にタスクを分担していきたいと思います。

We're Hiring!

クラウドソーシングのクラウドワークスでは、Android・iPhone向けネイティブアプリ開発を共に推進していただけるエンジニアを大募集中です。いいチームをつくりましょう。

www.wantedly.com

興味のある方はお寿司ランチを無料で食べながらお話してみませんか?

crowdworks.co.jp

Lambda + CloudWatch Events + KMS で AWS コンソールへの不正アクセスを秒速で検知して「平穏な生活」を手に入れる

AWS CloudWatch Events KMS

ペルソナ5にドハマリし、先日100時間以上かけてクリアした @tmknom です。 主人公の名前は吉良吉影。怪盗団の名前はキラークイーンです。ちなみに二周目に突入しました。

さて、みなさんもご存知の通り、 AWS ユーザは常にある不安を抱いています。 AWS アカウントを乗っ取られたらどうしよう。バイツァ・ダストよろしく、すべてを吹っ飛ばされたらどうしよう。という不安です。

しかし、我々は AWS を使わずにはいられないという『サガ』を背負ってはいますが『幸福に生きてみせるぞ!』という強い意思を持たねばならないのです。

そんなわけで、意思を現実のものへと体現すべく AWS コンソールへ、いつ誰がサインインしたのかSlackに通知して、 不正アクセスを簡単に検知できる仕組みを構築してみましょう。

  • はじめに
  • 事前準備
  • バージニア北部へリージョンを切り替え
  • Lambda の初期セットアップ
  • CloudWatch Events の設定
  • CloudWatch Logs の設定と確認
  • Slack で Incoming Webhooks の URL の払い出し
  • Lambda で Slack へ通知するよう修正
  • KMS でマスターキーを作成
  • AWS CLI で秘密情報を暗号化
  • Lambda の最終形を実装
  • まとめ
  • We're Hiring!

はじめに

ココで構築する仕組みは「Lambda + CloudWatch Events + KMS」で実現します。 CloudWatch Events で AWS コンソールへのサインインを検知して、それを Lambda 経由で Slack に通知します。 KMS には、Slack 通知に必要な秘密情報を Lambda に持たせる際に使用します。

f:id:tmknom:20161030123858p:plain

続きを読む

CW Tech Meetup #02: Ruby on Rails Tech Meetup を開催しました

Meetup Rails

f:id:Dooor:20161027110605j:plain

こんにちは。プロダクト開発Divの戸口(@Dooor)です。

先日クラウドワークスでは、Ruby on Railsについて利用したアプリケーション開発からRailsそのものについて気軽に情報交換できる場を作りたいということでCW Tech Meetup #02を開催しました。

cw-meetup.doorkeeper.jp

第2回ということで多くの方々からお申込みをいただき、当日も大盛況に終えることができました。
Rails5へのアップグレードやSprocketsの話など、いろいろな内容の発表があった今回のイベントにの様子をお伝えします。

続きを読む

HerokuのDataclipsを使って簡単にリアルタイムでデータを見える化した話

Heroku 分析

開発の山本です。最近いきなり寒くなってきて焼酎のお湯割りが飲みたくなる季節になりましたね!

今、私が携わっているプロダクトはHerokuで運用しており、サービスが稼働してから3ヶ月程立ちました。 実運用が始まりリリース直後のバタバタが落ち着いてくると、次のステップとして分析用にデータが欲しいという要望が当然でてきますね。
しかしながら、新規のプロダクトでは抽出のやり方も一から考えないといけず、正直アプリケーション開発に時間をかけたいので、あまり手間暇かけて仕組みを作りたくもないのが本音です。単純にCSVで落として渡すだけだと何度も依頼が来て(ノ`Д´)ノ彡┻━┻ってなることは目に見えてるのでそれも避けたいですね。

ということで今回はDataclipを使ってデータ抽出を簡単にやったよという話です。

続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.