TECH PLAY

スマヌトキャンプ株匏䌚瀟

スマヌトキャンプ株匏䌚瀟 の技術ブログ

å…š226ä»¶

スマヌトキャンプの゚ンゞニア瀧川です。 匊瀟では昚幎から゚ンゞニア合宿を䌁画しおいたしお、今幎は10月15日から17日たでの2泊3日で実斜したした 合宿のテヌマや党䜓感は別蚘事でたずめるかなず思いたすが、3日の限られた時間で1チヌム(4人)1぀のプロダクトを䜜り、成果ずしお発衚する必芁がありたした。 この条件だずあたり技術的なチャレンゞもできないな...ず感じおはいたのですが、どうしおもチヌム内でGraphQL觊りたい欲求が高たっおしたったので、なんずか負荷があたりかからない圢で導入できないか調べお芋぀かったのがPrismaずいうツヌルでした 本蚘事ではPrismaを詊した際のメモ、Tips、所感を曞いおいきたす (公匏でPrisma2がアナりンスされおたすが、ほが別物なので今回はPrisma1に぀いお曞いおいたす) (倚分最終的な成果物の進捗は、慣れ芪しんだツヌルを䜿った堎合ずほが同じだったかなず思っおいたす) GraphQLずは Prismaずは むンストヌル 初期化 起動 ク゚リ Mutation Query Tips Seedを実行する たたにDBをResetする必芁がある 所感 GraphQL ずは GraphQLずは、Web APIのための芏栌の぀で、「スキヌマ定矩」ず「ク゚リ定矩」によっおサヌバずクラむアントの通信をサポヌトしたす。 「スキヌマ定矩」で暙準化された型付きのスキヌマを定矩し、それに則ったク゚リをクラむアントから発行するこずで、安党で柔軟にデヌタ取埗が行えたす。 詳しくは公匏ドキュメントなどお読みください。 たた、GitHubが倖郚向けAPIずしおGraphQLを採甚しおいるので、こちらで詊すのも良いず思いたす。 developer.github.com Prisma ずは むンストヌルし、GraphQLのスキヌマ定矩をするだけで、以䞋ができるようになる䟿利なツヌルです。 起動甚docker-compose.yml生成 デヌタ管理アプリ(Prisma Admin) CRUDの自動生成(GraphQLサヌバの実装) DB(MySQL/PostgreSQL)ぞのMigration Seed定矩 CRUDにアクセスするクラむアント(JavaScript, TypeScript, Golang)生成 むンストヌル たず、以䞋のようにpackage.jsonを定矩し、 yarn install などで䟝存解決したす。 package.json { " name ": " prisma-sample ", " devDependencies ": { " prisma ": " ^1.34.8 ", " ts-node ": " ^8.4.1 ", " typescript ": " ^3.6.3 " } } 初期化 Prismaはinitコマンドがあり、それにより必芁なファむルを自動生成しおくれたす。 以䞋のように yarn prisma init ず実行するず、「デヌタベヌスの接続先をどうするか」「デヌタベヌスの皮類はなにか」「Prismaサヌバにアクセスするためのクラむアントを生成するか」の質問がでたす。 以䞋では、LocalのDockerでMySQLを新芏で起動し、TypeScriptのクラむアントを生成するようにしたした。 $ yarn prisma init ? Set up a new Prisma server or deploy to an existing server? Create new database ? What kind of database do you want to deploy to? MySQL ? Select the programming language for the generated Prisma client Prisma TypeScrip t Client Created 3 new files: prisma.yml Prisma service definition datamodel.prisma GraphQL SDL-based datamodel ( foundation for database ) docker-compose.yml Docker configuration file Next steps: 1 . Start your Prisma server: docker-compose up -d 2 . Deploy your Prisma service: prisma deploy 3 . Read more about Prisma server: http://bit.ly/prisma-server-overview Generating schema... 25ms Saving Prisma Client ( TypeScript ) at /Users/takigawa.yosuke/projects/personal/prisma-sample/generated/prisma-client/ ✹ Done in 31 .93s. 実行埌に以䞋のファむルが生成されおいればOKです。 prisma.yml Prisma党般の蚭定を蚘述する datamodel.prisma GraphQLのスキヌマ定矩 docker-compose.yml Prismaサヌバ、DBなど起動甚 起動 $ docker-compose up -d $ docker-compose ps Name Command State Ports ---------------------------------------------------------------------------------- prisma-sample_mysql_1 docker-entrypoint.sh Up 3306 /tcp, 33060 /tcp mysqld prisma-sample_prisma_1 /bin/sh -c /app/ start .sh Up 0 . 0 . 0 .0:4466- > 4466 /tcp localhost:4600/_admin でPrisma Admin(Sequel Proみたいなデヌタ閲芧、アップデヌトなどできる)にアクセスができたす。 ( localhost:4600 でおなじみのGraphQLのPlaygroundにもアクセスできたすがPrisma Adminのほうが䜿い勝手がよさそうです) datamodel.prisma に初期状態で User が定矩されおいるので以䞋を実行し、Prismaサヌバを曎新するずPrisma AdminでもUserが確認できるず思いたす。 $ yarn prisma deploy これでほが準備は完了です ク゚リ 詊しにデヌタ定矩を以䞋のように修正しお、「Create」「Read」のク゚リを䜜成しおみようず思いたす。 ナヌザの所属する䌚瀟を远加する想定でのスキヌマ定矩を远加したす(Company has_many Usersですね) ID! @id でナニヌクか぀むンデックス远加をしおくれおいるようです @hogehoge はPrismaのアノテヌションでいく぀か皮類がありそう 関連定矩をする際に、盞互に参照定矩するほうがク゚リを曞く際に楜そう datamodel.prisma type Company { id: ID! @id name: String! users: [User!]! } type User { id: ID! @id name: String! company: Company! } ※ datamodel.prisma曎新埌は、Prismaサヌバに yarn prisma deploy で反映しおください Mutation 詊しに Companyを1぀、Userを2぀生成しおみたす。 mutation { createCompany(data: { name: "スマヌトキャンプ", users: { create: [ {name: "瀧川スマ倪郎"}, {name: "瀧川スマ次郎"} ] } }) { id } } Prisma Adminでク゚リを実装するず、補完がしっかりず効いおいおすばらしいですね createCompany などはPrismaによっお自動生成されたものです。 createCompany の ブロック {} はmutation成功時に返华しおほしいデヌタを蚘述しおいたす。 なので実行埌のResponseは以䞋のように自動付䞎されたIDが含たれおいたす。 { " data ": { " createCompany ": { " id ": " ck2q06vkc006n07980p4l1av0 " } } } Query 生成したCompanyずUserをすべお取埗するク゚リを䜜成したす。 query { companies { id, name, users { id, name } } } 結果がこちらになりたす。 { " data ": { " companies ": [ { " id ": " ck2q06vkc006n07980p4l1av0 ", " name ": " スマヌトキャンプ ", " users ": [ { " id ": " ck2q06vmf006o07989z7b6e1s ", " name ": " 瀧川スマ倪郎 " } , { " id ": " ck2q06vmo006p0798yllvbja7 ", " name ": " 瀧川スマ次郎 " } ] } ] } } このク゚リずレスポンスのわかりやすさはGraphQLのメリットの぀ですよね。 ちなみにPrismaでは、デヌタの絞り蟌み甚の関数も組み蟌たれおいたす(䜿い勝手は少しむずかしいですが...) 䟋えば「䌚瀟名がキャンプを含み、ナヌザ名の埌方が次郎ではない」のような条件だず以䞋のようになりたす。 query { companies(where: { name_contains: "キャンプ" }) { id, name, users(where: { name_not_ends_with: "次郎" }) { id, name } } } このようなPrismaによっお生成されおいるものは非垞にたくさんあるので、公匏ドキュメントや補完をよくみお慣れおいく必芁がありそうです。 Tips Seedを実行する 以䞋のようにTypeScriptのPrismaクラむアントを生成し、それを䜿った seed.ts をts-nodeで実行しおやるだけですね。 prisma.yml generate : - generator : typescript-client output : ./generated/prisma-client/ seed : run : yarn ts-node ./seed.ts seed.ts import { prisma } from './generated/prisma-client' async function main () { await prisma.createCompany ( { name: 'スマヌトキャンプ' } ) } main () . catch ( e => console.error ( e )) $ yarn prisma seed たたにDBをResetする必芁がある スキヌマ定矩で関連を倉曎したり、Seedを2回実行などが゚ラヌになるため、リセットする必芁が出おきおしたいたす。 ロヌカルでは以䞋のコマンド䞀発ですが、プロダクションではどのように運甚するずいいのでしょうか... 怖いですね $ yarn prisma reset 所感 GraphQL自䜓は、凊理がクラむアントに寄せられお、必芁なデヌタを郜床取埗できるのでやりやすさを感じたした。 たた、型があるので、Prismaのような自動生成するタむプのツヌルでも補完が効き、導入障壁は䜎く感じたした。 なによりも今回小さなアプリケヌションを䜜成したのもありたすが、サヌバサむド実装芁らなくおフロント実装だけで枈んだのは新しい可胜性を感じられたした... ただ耇雑なデヌタを取埗する堎合、それなりにク゚リが耇雑になるのず、Prismaの仕様、GraphQLの仕様䞊うたく取埗できない条件があったり(知識䞍足もあるず思いたすが)難しさも感じたした。 (あず、公匏ではPrismaずフロント゚ンドずの間にもう1階局GraphQLサヌバかRest APIサヌバを挟むのを想定しおいるようなので、そのあたりも今回は無芖した難しさがありたすね) たたバルクむンサヌトできないずかパフォヌマンスチュヌニングできない、スキヌマの倉曎をした際にresetせざるを埗なくなるなど、ツヌルずしおの成熟床はただただ䜎いかなず感じたした。 ただ、GraphQL自䜓䌞び始めたずころで、ようやくプロダクション導入もちらほら聞こえ始めたので、これから倧いに飛躍するず思いたす。 Prisma2はたた毛色が違っお、よりスモヌルで実甚的なツヌルになっおいるようなので、そちらも今埌远っおいきたいなず感じたした。 なにはずもあれ、GraphQL、Prisma、新感芚でおもしろかったです 合宿最高でした
スマヌトキャンプの゚ンゞニア瀧川です 先日、 B2B SaaS゚ンゞニアMeetup - SharingIssues ずいうむベントを匊瀟で開催させおいただきたした。 様々な぀ながりから発衚枠も埋たり、参加者も圓初想定20人でしたが、 結果40名匷 もの方にお越しいただき、ずおも充実した䌚だったず感じおいたす。 私も䞻催者偎ではあるものの、発衚が面癜く聞き入っおいたので、 今回は䞀参加者ずしおのレポヌトを公開しようず思いたす ちなみにむベントの抂芁は以䞋で玹介しおいたす。 定期開催予定なので、ご興味あればチェックいただければず思いたす。 tech.smartcamp.co.jp 「B2B領域における開発組織䜜り 〜採甚線〜 」スマヌトキャンプ株匏䌚瀟 ゚ンゞニアリングマネヌゞャヌ 米元さん 抂芁 感想 「開発リヌダヌが結果的にPMず呌ばれるたで」 スマヌトキャンプ株匏䌚瀟 PdM 郷田さん 抂芁 感想 「B2Bサヌビスを䜜る䞊で心がけおいるこず」株匏䌚瀟マネヌフォワヌド VPoE 枋谷さん 抂芁 感想 「むンタヌナルマヌケティングで織り成すマルチプロダクト開発」株匏䌚瀟リンクりェル CTO 戞本さん 抂芁 感想 「B2BSaaS開発におけるモチベヌションマネヌゞメント」A1A株匏䌚瀟 曜根田さん 抂芁 感想 「B2B補品開発における7぀の倱敗」株匏䌚瀟シャノン CTO 堀さん 抂芁 感想 党䜓通しお ※ メディアに掲茉されたした(2019/11/25远蚘) 「B2B領域における開発組織䜜り 〜採甚線〜 」スマヌトキャンプ株匏䌚瀟 ゚ンゞニアリングマネヌゞャヌ 米元さん speakerdeck.com 抂芁 自己組織化したチヌム + 再珟性を目指しおいた 管理者がいなくおも動ける 採甚が課題(マネヌゞャヌになっおから実瞟0名だった) 芁求が高いのか やり方が間違っおいるのか 有識者にヒアリングしおわかったこず 方向性は悪くない 各方面でやりきるしかない 採甚をマヌケティングの考えを応甚しおやりきる Lead Generation 母集団を増やす Nurturing(今回これだけ話す) 志望床を䞊げる 䌚瀟資料公開 開発組織説明資料公開 プロダクトごずの説明資料公開 ゚ンゞニアブログ メンバヌのこずを知っおもらう 党員のストレングスファむンダヌ共有 党員の性栌蚺断共有 䜓隓入瀟 Closing 採甚承諟を埗る Onboarding 定着・掻躍しおもらう ​- たずめ 組織党員で採甚に打ち蟌む ずにかく䌝える努力 匱みを理解する 感想 採甚がうたくできなかったずきに、採甚の各フェヌズで斜策を考えお実斜した話でした。 B2B䌁業はプロダクトを目にする機䌚もすくなく、゚ンゞニアリングに぀いおも衚にあたり出ないので、採甚にも圱響しおいるず感じたす。 自瀟ですが、瀟員のストレングスファむンダヌの結果なども候補者に䌝えおいるのはずおもおもしろいず思っおいたす。 「開発リヌダヌが結果的にPMず呌ばれるたで」 スマヌトキャンプ株匏䌚瀟 PdM 郷田さん speakerdeck.com 抂芁 六本朚PMでも発衚した内容 PdMになりたい゚ンゞニアに向けた実䜓隓を語る発衚 新芏プロダクトのBiscuetのPdM 開発する䞭で2床の越境(圹割が倉わったこずを自芚したきっかけ) ​- プロダクトの方針ずか明確にする人がいない 採甚するか自分がするか -> じゃあやりたす 成果を残すために開発をしないず決める 䜕よりも早く垂堎に出す やった斜策(重芁床ず優先床のメトリクスを䜜っお実斜) ドメむン知識向䞊 最小限っおなんだろうがわかりたい Expo, カンファレンス, セミナヌ 開発メンバヌぞもTheMODEL勉匷䌚を実斜 etc... 感想 プロダクト開発をする䞭で、必芁な圹割を自分でやっおいったら、それがPdMずいう圹割だったずいう発衚。 ドメむン知識を倚く必芁ずするB2B業界で、早く䟡倀を届けるために、営業のセミナヌぞの参加、チヌムぞのTheMODELの普及など掻動しおいるのが印象的でした。 「B2Bサヌビスを䜜る䞊で心がけおいるこず」株匏䌚瀟マネヌフォワヌド VPoE 枋谷さん speakerdeck.com 抂芁 開発者ずしおやっおよかった取り組みを玹介 BtoB 業務フロヌに取り蟌たれおいるためサヌビスが止たるず仕事が止たる マラ゜ンっぜい開発 120%よりずっず80%開発の方が良さそう そのための取り組み 和英蟞兞のようなものを䜜る(瀟内Wiki) payment allowance family name last name dept_id department_id 衚蚘ゆれを防ぎたい モクモク䌚 䌚議宀を専有しお䞀緒にやるだけ 声に出せば解決するかも環境を䜜る やる決定よりやらない決定 がんばろうずしおいる 10の仕事を終えれば3生たれる 瀟内の他の取り組み 瀟内甚語集が充実 党瀟甚語集 プロダクト甚語集 業界甚語集 新卒今さら聞けない甚語集 **さんの甚語集 歎史オリ゚ン 過去の負債 懺悔ずずもに未来どうしおいきたいかを䌝える䌚 パルスサヌベむ & オンボヌディングFB 今の課題に気づくため dmemo運甚しおる ヶ月に䞀回未来組織図䌚議 この人がこれくらい䌞びおくれるはず ポゞション倉曎や採甚に掻かす 感想 かなり具䜓的に取り組みを玹介しおいただきたした。 甚語集、dmemoなどは、やったほうがいいが運甚(远加・曎新)が課題ずなっおしたうので、それが瀟内で定着しおいるのがすごいず思いたした(もう少し詳しく聞きたかった) 過去の負債を颚化させないように、プロダクトの歎史オリ゚ンを実斜する取り組みは匊瀟でもやっおみようず思っおいたす。 「むンタヌナルマヌケティングで織り成すマルチプロダクト開発」株匏䌚瀟リンクりェル CTO 戞本さん speakerdeck.com 抂芁 埓業員13名 ゚ンゞニア6名 ​- 病院を䜜っおいる䌚瀟 予玄最適化、薬リモヌト賌入など プロダクトが耇数あり、メンバヌのモチベヌションも高く、あっちもこっちも手を出す ディストピアトヌクになる 発散しおしたう 原因は個人の意識にプラむオリティがない ポゞションを取らせようずした どこを誰が担圓するか うたく行かない 党郚に関わりたい 信念がある 取り組み: むンタヌナル・マヌケティングを実斜する 瀟内にもなぜを説明する 取り組み: 「今日䞀぀しかできないならなにをしたい」ず問いかける 本人に䞀番を芋぀けおもらう 本人のやりたいこずにやるべきこずを重ねる動き(自発的に) 垌望がかぶったら... 採甚から意識しおるのであたりかぶらない 小さい組織だからなんずかする だれもやらないなら自分がやる 感想 小芏暡な組織で党員がモチベヌション高い状態がマむナスに働く事䟋は共感できたした。 「今日䞀぀しかできないならなにしたい」を問いかけるのアプロヌチはなるほどず感じたした。 䜙談ですが、スラむドのむラストが絶劙で面癜い発衚でした。 「B2BSaaS開発におけるモチベヌションマネヌゞメント」A1A株匏䌚瀟 曜根田さん speakerdeck.com 抂芁 B2B Horizontal SaaS どこの䌚瀟でもあるだろう業務を提䟛 Vertical SaaS 業界特化 むメヌゞ B2Cに比べおクリ゚むティブじゃない 受蚗倚そう 技術チャレンゞ少なそう むメヌゞを芆したい Vertical SaaS 情報収集が難しい 賌買意欲ずか 参考になるアプリケヌションが少ない 実業務が難しい ゜リュヌション セミナヌ ドメむン゚キスパヌトぞのヒアリング 芁望が倚い・倚様 補造業も倚様 ゜リュヌション 課題の远求 AsIs/ToBeシヌト ストヌリヌマップ 仮説怜蚌が難しい フリヌミアムプロダクト少ない アップデヌトに慎重(ABテストずかむずかしい) 䞀床のミスがクリティカル ゜リュヌション PMF ディアルトラックアゞャむル ​ 技術チャレンゞ B2B SaaSのデヌタモデリングずか GraphQLにチャレンゞ 倚蚀語察応 MicroService BigQuery, TreasureData, DataDog 必芁性に応じおチャレンゞング ​ 深いドメむン理解 颚呂敷を最倧に広げた䞊でのミニマムな蚭蚈 未来を描いた技術チャレンゞ ​ モチベヌションは満たせる 感想 芁望が倚い、フリヌミアムプロダクトが少ないなど、B2Bならではの課題に察しお、様々なアプロヌチを真摯に実斜しお解消しおいる印象でした。 やりがいを感じ、モチベヌションを匷く感じおいるのがずおも䌝わる発衚でした。 各課題に察する゜リュヌションも、業界の成長や技術の進歩などで増えおいるず感じおいるので、より䞀局楜しみな領域なんじゃないかなず思っおいたす。 「B2B補品開発における7぀の倱敗」株匏䌚瀟シャノン CTO 堀さん speakerdeck.com ※ 远蚘:2019/11/06 資料をアップしおいただきたした 抂芁 7぀の倱敗 倱敗を螏み抜いおるので共有 顧客ごずにカスタマむズ受けちゃう 売䞊でるず蚀われるずやるしかないか... 心を鬌にする 課題の突き詰める 開発はたくさん、営業・マヌケが少ない 少ないお客さんにフィットさせにいこうずなりがち 補品にフィットするお客さんをコストかけお探すべき 営業が機胜の存圚意矩を説明できない むンタヌナル・マヌケティング 目的が重芁 営業・マヌケ・開発を橋枡しする人が必芁かも 目指すアヌキテクチャず組織図がずれおいる Perlモゞュヌル郡これは死ねる リプレむス組織を分けちゃった 組織ず技術的なアヌキテクチャは䌌おくる 朜圚的に人は組織に準拠する行動を取る 重芁な課題を解決しおない スコヌプが広く芁望が倚様化 蚀っおるものず欲しいものは違う お金を出しおたでほしいかずクラむアントに聞くず、いや...ずなる 掘り䞋げる 技術的負債に向き合っおない GoogleDriveで怜玢するずめっちゃある(匕き継ぎ資料にも負債が) 小さい負債は開発サむクルに盛り蟌む 倧きい負債はビゞネス課題に盛り蟌む なんでもポリシヌを決めるのが倧事 自動テストなく幎䜍眮ビッグバンリリヌス 郜床リリヌスがいいよ KPIで党瀟の意思疎通が図られおない 売䞊以倖にも興味を持っお、党瀟の方向性を知るべき 仕事を芋おいるが人を芋おない ゚ンゞニアは人に興味ない(人もいる) 倧きいこずをするためには人ず向き合っお投資する その人が䌚瀟の方向性ず考えがマッチしおいるか 感想 圧巻の倱敗事䟋集でした。 どの項目もB2B業界で開発をしおいる人は共感できたのではないでしょうか。 シンプルに倱敗ず孊びを玹介されおおりわかりやすく聞けたした。 再床いく぀かに絞っお、発衚しおいただきたいなず感じたした。 党䜓通しお どの発衚も共感できる内容で、か぀面癜い察策をされおおり興味深かったです。 発衚や懇芪䌚の䞭で、開催のきっかけでもある「B2Bっおあたりノりハりが衚に出ない」「B2Bはドメむンが倚様で難しい」ずいった感芚をみなさん持っおいるこずがわかり、開催しおよかったなず感じたした。 これからも続けおいくこずで、B2B SaaS開発でのハマりどころが、ここに来れば解決する堎を䜜っおいきたいですね 次は12月開催を目指しおいたす ※ メディアに掲茉されたした(2019/11/25远蚘) Find careersさんに蚘事にしおいただきたした ずおも読み応えの内容になっおいたすので是非読んでいただければ嬉しいです www.findcareers.jp
スマヌトキャンプの郷田です。 私は Biscuetビスケット ずいう新芏SaaSのプロダクトマネヌゞャヌをしおおりたす。 Biscuetでは開発プロセスに課題を感じおいたため、倖郚から アゞャむルコヌチの倩野さん をアドバむザヌずしお召喚し、スクラムの導入を進めおいたす。 そこで今回は、Biscuetチヌムで先月から導入を進めおいるスクラムの珟状を、たくさんの画像を甚いおたずめおみたいず思いたす スクラムの圹割 開発チヌム プロダクトオヌナヌチヌム スクラムマスタヌ スクラム党䜓像 スクラムのセレモニヌ PBLProduct Backlog SBLSprint Backlog 朝䌚Daily Scrum モブプロスペヌス KPTSprint Retrospective その他 最埌に スクラムの圹割 開発チヌム 開発チヌムぱンゞニアの3人が䞭心ずなっお開発を進めおいたす。 それぞれがバック゚ンド、フロント゚ンド、むンフラず、違う匷みの持぀メンバヌずなっおいたす。 各゚ンゞニアバック゚ンド〜フロント゚ンドたでの開発は基本的には行うこずずしおいたす。 開発チヌムにはデザむナヌを兌務しおいる゚ンゞニアも所属しお、デザむンの改修たで開発チヌムで行えるようにしおいたす。 プロダクトオヌナヌチヌム プロダクトオヌナヌは、プロダクトマネヌゞャヌ私ず、営業マヌケティングのマネヌゞャヌの2名䜓制ずしおいたす。 2名にするこずで開発〜営業たでの広い情報を元に意思決定を行えるようにしおいたす。 スクラムマスタヌ スクラムマスタヌの圹割は召喚しおいるアゞャむルコヌチの倩野さんが担っおいたす。 業務の目的をアゞャむルの思想を甚いた業務効果の最倧化ずするこずで、スクラムマスタヌがスクラムだけにずらわれず自由に動けるようにしおいたす。 自瀟にあわせたスクラムの萜ずし所を芋぀けるために密にコミュニケヌションをずりながらスクラムの導入を進めおいたす。 スクラム党䜓像 Biscuetではスクラムの党䜓像をこの図で衚しおいたす。 PBLずSBLの管理に Asana を掻甚しおいたす。 党瀟員がAsanaのアカりントを持っおいる ため、Biscuetのセヌルスや別プロダクトのメンバヌがい぀でも芋れるようになっおいたす。 スクラムのセレモニヌ Biscuetのスクラムは1週間スプリントで、月曜日にSprint Review、Sprint Planningを入れおいたす。 スクラムマスタヌは月曜のみ出瀟しおいたす。 Refinementは火〜金に30分ず぀実斜するこずで、1週間の内2時間をRefinementに確保できるようにしおいたす。 Sprint Reviewはセヌルスも含めた党おのプロダクト関係者が出垭し、今のプロダクトずこれからのプロダクト方針が共通認識ずなるようにしおいたす。 PBLProduct Backlog PBLはプロダクトオヌナヌチヌムが管理しおいたす。 SprintごずにAsanaのセクションを切るこずで、Sprintのベロシティが自動で合蚈されるようにしおたす。 Asanaのカヌド内に受け入れ条件やナヌザヌストヌリヌを蚘述する圢で利甚しおいたす。 PBLのアむテムごずのステヌタスは、プロダクトの開発状況が゚ンゞニア以倖でも理解できるように、リリヌス状況を衚すステヌタスずしおいたす。未着手、䜜業䞭、リリヌス枈み SBLSprint Backlog SBLは開発チヌムが管理しおいたす。 Planningで蚈画したアむテムは、PBLずは別のAsanaプロゞェクトでSBLずしお管理しおいたす。 ゚ンゞニアは、SBLのアむテムにアサむンされ、アむテムごずにGithubのPRを䜜成する運甚ずしおいたす。 SBLのアむテムごずのステヌタスは、開発チヌム内での共有がしやすいよう、開発状況を衚すステヌタス管理にしおいたす。未着手、wip、review、merge 朝䌚Daily Scrum GoogleカレンダヌずSBLを芋ながら、開発チヌム党員のその日の方針を確認するようにしおいたす。 プロダクトオヌナヌも必ず朝䌚に参加するようにしおおり、Sprintに圱響がありそうな課題の共有がその堎でできるようにしおいたす。 毎回必ずタむマヌで15分はかり、超えたらできる限り匷制的に終了するこずずしおいたす。 モブプロスペヌス 52むンチのテレビを昇降付きの台に茉せ、3人が同時に䜿えるサむズの昇降付きの机を開発チヌムが垞に䜿えるようにしおいたす。 AppleTVを蚭眮し、コネクタの差し替えも䞍芁で画面共有ができるようにしおいたす。 過去モブプロ文化はありたせんでしたが、スクラム導入埌からモブ業務が埐々に増え、今でぱンゞニアの5割以䞊の時間は、ここでモブ業務をするようになっおいたす。 モブスペヌス正面の窓からは東京タワヌが芋えたす。 机の䞊に眮いおあるもの Refinementでストヌリヌポむントを付けるために、プランニングポヌカヌmixiさんのノベルティを垞にモブプロスペヌスに眮いおいたす。 耇数人業務での利䟿性向䞊のため、ワむダレスのキヌボヌドずマりスも眮いおいたす。 KPTSprint Retrospective Sprint Retrospectiveは、KPTのフレヌムワヌクを利甚しおいたす。 Keep、Problem、Tryは、それぞれ曞く時間・発衚する時間で区切り、タむマヌで枬っおKPTを進めおいたす。 実斜が決たったTryは、SBLに乗せお、開発チヌムが実斜できるようにしおいたす。 付箋ず氎性ペン ディスカッションが捗るように、付箋ず氎性ペンをポヌチに入れおたずめお持ち運べるようにしおいたす。 ディスカッション䞭に付箋が剥がれるず非垞にストレスなので、匷粘着の付箋を䜿っおいたす。 その他 スクラムの参考文献 スクラムのフレヌムワヌクを実務に取り入れるずぶ぀かる壁がずおも倚いため、スクラムガむドずSCRUM BOOT CAMPをすぐに手に取れる堎所に眮いおおき、原則を芋返せるようにしおいたす。 オフィスの呚りの様子 隣のBOXILボクシルチヌムもモブやっおたす。BOXILチヌムはスクラムではないため、たた別でたずめおくれるず思いたす。 スペヌスの区切りはキャスタヌ付きホワむトボヌドを利甚しおおり、ホワむトボヌドがい぀でも䜿えたり、゚リアを広げたい堎合はすぐに動かせるようにしおいたりしたす。 最埌に 匊瀟のスクラムはいかがだったでしょうか スクラムは取り入れたばかりで、珟状Sprintも#66週間分しか進んでいないため、今埌も改善を繰り返しおいくこずになりそうですが、䞀旊スクラムでのプロダクト開発が回るようになっおきたため、瀟内倖問わずなにかの参考になればず思い珟状を蚘事にたずめおみたした。 最終的にはアゞャむルコヌチの倩野さんが居なくおもスクラムが回る自己組織化したチヌムを目指しおいるので、今埌のスクラムチヌムの成長がずおも楜しみです 最埌に告知ではございたすが、B2Bのマネゞメントに぀いお匊瀟meetupでLT登壇させおいただきたすので、ご興味があれば以䞋リンクをご参照ください。 smartcamp.connpass.com
スマヌトキャンプで゚ンゞニアをしおいる井䞊です。 今月の10/29に匊瀟で゚ンゞニアむベント B2B SaaS゚ンゞニア Meetup - Sharing Issues #1 を開催するこずになりたした 匊瀟はBtoBでSaaSを扱う䌁業ずしお、 なぜこのむベントをやろうず考えたのか 、 むベントを通しお実珟したいこず をこの蚘事で玹介しようず思いたす。 蚘事を読んでいただき、興味が湧いた方は以䞋から参加登録しおいただければ幞いです smartcamp.connpass.com むベント趣旚 なぜこのむベントをやるのか なぜmeetupなのか 今埌やっおいくこず 最埌に むベント趣旚 以䞋に該圓する方に集たっおいただき、B2B業界で働く゚ンゞニアならではの課題や解決方法などを共有しお、ディスカッションをする堎を提䟛したいず思いたす。 B2B業界で゚ンゞニア・デザむナヌずしお働いおいる B2B業界に興味がある 同じ業界の情報亀換・議論がしたい 正盎課題があり困っおいる 課題解決が奜き ...etc 毎回少しず぀テヌマを倉えようず思いたすが、今回は マネゞメントに関する課題・解決 をテヌマに決定したした。 なぜこのむベントをやるのか BtoBの領域ではビゞネス職ずのやり取りや様々な郚眲が関わるからこその調敎、䌁業盞手だからこそ考慮しなければいけない問題など、BtoCの領域ずは少し異なる課題があるず感じおいたす。 私達は「良い人のずころには、良い情報が集たる」ず考えおおり、むベントずいう圢で情報共有する堎を䜜り育おおいくこずで、自瀟゚ンゞニアの成長そしおBtoB業界の゚ンゞニアの生産性向䞊を目指したいず思っおいたす。 なぜmeetupなのか BtoBずいっおも業界やプロダクトによっお倧きく内容がこずなるので、参加者それぞれが共有する堎、解決する堎を䜜り出しおいっおほしいずいう意味でmeetupにしおたす。 今埌やっおいくこず どのような人が集たるかにもよるのですが、テヌマごずの匷いコミュニティに掟生させおいき、課題はそのコミュニティに聞けば分かる状態にしおいきたいです。 䟋えば持ち寄った課題解決のワヌクショップなどをむベント内で行い、それぞれ最適な解決策を耇数出せるようなものが出来ればず考えおいたす。 最埌に これからさらに成長しおいくBtoB SaaS業界で、゚ンゞニアが課題に぀たずく事なくよりよいサヌビスぞず䌞ばしおいける状態を䜜るため、䞀緒にコミュニティを育おおいければ嬉しいなず思いたす 今埌ずもよろしくおねがいしたす
スマヌトキャンプの゚ンゞニアむンタヌン生の高砂です 高砂枉ず曞いお、たかすなじょうず読みたす(䌚瀟ではじょにヌず呌ばれおたす) 私はスマヌトキャンプでむンタヌンを始めお半幎ほど経ちたすが、むンタヌンを始めたばかりの頃、オフィス来客察応に非効率さを感じおいたした。 そこで、Slack APIずGASを䜿っおオフィス来客時の手動䜜業の自動化に取り組みたした。 本蚘事ではどのように考えお、実装ず改善をしおいったかをお話ししようず思いたす 来客察応における課題ず芁件 来客察応の手順 具䜓的な課題 䜜成方針 実装 GASで事前に今日1日の予定を取埗 Slack APIで蚪問通知取埗 GASが察応する予定を怜玢 Slack APIで予定を通知 Slack botの反響ず改善 同僚の反応ず远加機胜の芁望 远加実装、利甚、芁望、ヒアリングのサむクル 終わりに 来客察応における課題ず芁件 来客察応の手順 スマヌトキャンプでは基本的にむンタヌン生がお客さたを䌚議宀にお通ししおいたした。 お通しする際には「お客さたのお名前」「䜿甚する䌚議宀」「担圓者の名前」が必芁なのですが、埓来では Slackに受付システムのbotから「お客さたのお名前」が通知される お名前に察応する予定をGoogleカレンダヌ䞊で目芖で探す 芋぀けたら「䜿甚する䌚議宀」「担圓者の名前」を蚘憶する お客さたを䌚議宀に案内した埌、担圓者を呌び出す ずいうフロヌでした。 具䜓的な課題 䞊蚘手順では「目芖で探す」「予定情報を蚘憶する」など間違いが起きやすいのに加え、䞀床のオペレヌションに時間がかかる事が課題でした。 たた、䌚瀟が成長䞭で日に日に瀟員が増えおいく為、その負担が増しおいっおいるずいう問題もありたした。 そこでこのフロヌを自動化したいず思い、趣味ずしお取り組みたした🙌 䜜成方針 䞻に以䞋のような流れで実装するこずにしたした。 たた、実甚䞊の課題ずしお、Receptionistに入力された名前や、カレンダヌに入力された名前の挢字が間違っおいるこずもあり、挢字のよみがなを取埗できる よみたん ずいうよみがな怜玢システムのAPIを甚いおいたす。 お客様が受付で名前をReceptionistに入力 ReceptionistがSlackに通知するのをGASでキャッチ Googleカレンダヌから予定を怜玢 よみがな怜玢APIで名前を Slackに通知 実装 GASで事前に今日1日の予定を取埗 たずは䌚議宀ごずに耇数あるGoogleカレンダヌの予定䞀芧を取埗しおきたす。 この取埗時に、 よみたん のAPIを利甚し、よみがなも取埗しおいたす。 たた、この取埗には時間がかかるので、業務時間開始1時間前に取埗するようにトリガヌを蚭定したした。 yomi-tan.jp コヌドは以䞋のようになりたした。 var scheduleSheetId = PropertiesService.getScriptProperties().getProperties().sheetId; var spreadsheet = SpreadsheetApp.openById(scheduleSheetId); var calendars = [ CalendarApp.getCalendarById( 'カレンダヌID1' ), CalendarApp.getCalendarById( 'カレンダヌID2' ), CalendarApp.getCalendarById( 'カレンダヌID3' ) ] ; function main() { var scheduleList = setSheet(scheduleSheetId); var today = new Date ( new Date ().toLocaleDateString()); var tommorow = new Date ( new Date ().toLocaleDateString()); today.setDate(today.getDate()); tommorow.setDate(tommorow.getDate()+1); //耇数のカレンダヌから取埗 for ( var room = 0; room < calendars.length; room++) { var lastRow = scheduleList.getLastRow() var events = calendars [ room ] .getEvents(today, tommorow); var scheduleListValues = scheduleList.getDataRange().getValues(); //予定の数だけ繰り返し for ( var i = 0; i < events.length; i++) { var title = events [ i ] .getTitle(); var startTime = events [ i ] .getStartTime(); var endTime = events [ i ] .getEndTime(); var location = events [ i ] .getLocation(); var patternList = [ /.{2}様/g , /.{1}様/g , /.{3}様/g , /.{4}様/g ] var kanaList = '' ; //蚪問予定の堎合 if ( /様/ .test(title)) { patternList.forEach( function (pattern) { kanaList = arrangeScheduleInfo(pattern, title, kanaList) } ) //蚪問予定では無い堎合 } else { var kanaList = [ undefined ] } var scheduleInfo = [ title, startTime, endTime, location ] ; scheduleList.appendRow(scheduleInfo); } } } function setSheet(scheduleSheetId) { var scheduleList = spreadsheet.getSheetByName( 'main' ); scheduleList.clearContents(); var scheduleInfoTitle = [ '予定名' , '開始日時' , '終了日時' , '堎所' ] scheduleList.appendRow(scheduleInfoTitle) return scheduleList } function arrangeScheduleInfo(pattern, title, kanaList) { var kanjiList = title.match(pattern); try { kanjiList.map( function (kanji) { var kanji = kanji.slice(0,-1); var kanaCandidates = translateIntoKanaArray(kanji); kanaList = kanaList + kanaCandidates + ',' ; } ) } catch (e) { kanaList = kanaList.concat( undefined ); Logger.log( '右蚘予定名はよみたん䞍可' + title) } return kanaList } function translateIntoKanaArray(name) { var apiUrl = 'http://yomi-tan.jp/api/yomi.php?ic=UTF-8&oc=UTF-8&k=k&n=5&t=' + name; var kanaCandidates = UrlFetchApp.fetch(apiUrl); return kanaCandidates } Slack APIで蚪問通知取埗 実際にお客さたが来瀟された際、ReceptionistからSlackの特定のチャンネルにメッセヌゞが送られたす。 このメッセヌゞに察しおSlack APIを反応させ、来客名を取埗したす。 var scheduleSheetId = PropertiesService.getScriptProperties().getProperties().sheetId; function doPost(e) { var receptedName = extractName(e.parameter.text); var scheduleList = getActiveSheet(scheduleSheetId, 'main' ); searchSchedule(receptedName, scheduleList) } function extractName(receptedText) { var regex1 = / の.+? 様/ ; var regex2 = /から.+? 様/ ; var regex3 = /に、.+? 様/ ; if (regex1.test(receptedText)) { var name = receptedText.match(regex1); } else if (regex2.test(receptedText)) { var name = receptedText.match(regex2); } else if (regex3.test(receptedText)) { var name = receptedText.match(regex3); } name = String (name).slice(4,-3); return name } GASが察応する予定を怜玢 事前に取埗しおいた予定䞀芧ず照らし合わせお、察応する予定を決定したす。 function searchSchedule(receptedName, scheduleList) { scheduleList.forEach( function (schedule) { var now = new Date (); var startTime = new Date (schedule [ 1 ] ); var earlyTime = new Date (startTime.setMinutes(startTime.getMinutes() - 20)); var lateTime = new Date (startTime.setMinutes(startTime.getMinutes() + 20)); if (earlyTime < now && now < lateTime) { nameMatchCheck(schedule, receptedName) } } ) } function nameMatchCheck(schedule, receptedName) { var scheduledNames = schedule [ 6 ] ; if (scheduledNames !== 'undefined' ) { var scheduledNamesList = scheduledNames.toString().split( ',' ); scheduledNamesList.each( function (name) { if (!name) { return ; } else if (name.length === 1) { //1文字は誀刀定が倚いのでスキップ return ; } else if (receptedName.indexOf(name) === 0) { //名前䞀臎 postSchedule(schedule, name) return ; } } ) } return false ; } Slack APIで予定を通知 決定した予定の内容を通知したす。 function postSchedule(scheduleInfo, scheduledName) { var name = scheduleInfo [ 0 ] ; var startTime = scheduleInfo [ 1 ] .toLocaleTimeString().slice(0,-7); var endTime = scheduleInfo [ 2 ] .toLocaleTimeString().slice(0,-7); var place = scheduleInfo [ 3 ] ; var guests = scheduleInfo [ 5 ] ; var message = 'こちらの予定でしょうか \n ' + name + ' at ' + place + '\n' + startTime + ' ~ ' + endTime; postMessage(message) } function postMessage(message) { var postUrl = PropertiesService.getScriptProperties().getProperties().postUrl; var jsonData = { "username" : "お茶たろう" , "icon_emoji" : ":johnny:" , "text" : message } ; var payload = JSON.stringify(jsonData); var options = { "method" : "post" , "contentType" : "application/json" , "payload" : payload } ; UrlFetchApp.fetch(postUrl, options); } Slack botの反響ず改善 これらによっお、通知に察しお情報を出しおくれるSlack botが完成したした。 このbotによっお20秒皋かかっおいた手動での業務が1秒に短瞮されたした 同僚の反応ず远加機胜の芁望 反響も予想以䞊に倚く、瀟員の方々から「お茶たろうツヌルの愛称の人」ず芚えられるたでになりたした(笑) それず同時に、曎に色んな方から芁望を頂けたした。 もっず反応率を高めお欲しい 1぀の予定に察しお耇数のお客さたがいる堎合も党員に察応しお欲しい 担圓者をメンションSlackの呌び出し機胜で呌び出しお欲しい 担圓者が耇数人いる堎合、䞍参加の人は呌び出さないで欲しい 口調を可愛くしお欲しい 远加実装、利甚、芁望、ヒアリングのサむクル その埌も新しく貰った芁望を基に実装し、実際に䜿い、それに察する芁望を瀟員からヒアリングするずいう圢匏の開発を3ヶ月ほど続けたした。 その結果、反応率は高く、瀟員の芁望にも適合した良いプロダクトずなりたした🀗 終わりに このbotに蟌めた想いは、スマヌトキャンプのPRメディアで話しおいるので良ければそちらもご芧ください。 スマヌトキャンプの「来客察応」の非効率を解決内定者むンタヌン生が開発した ”お茶たろう” に迫っおみた #Ownership #新卒 | .▲.tent
スマヌトキャンプの゚ンゞニア入山です。 皆さんは、AWS Lambdaを知っおいたすか知らない方でもサヌバヌレスずいう単語は聞いたこずがあるのではないでしょうか。 Lambdaはいたたでプログラムを実行する䞊で必芁䞍可欠だったサヌバを甚意構築・運甚しなくおも、実行したいプログラムをLambda関数ずしお䜜成・登録するだけで、プログラムを動䜜させるこずが可胜なサヌバヌレスコンピュヌティングサヌビスです。 2014幎にサヌビスが公開されおから着実にアップデヌトを重ねおおり、珟圚では柔軟か぀幅広い甚途で利甚するこずができたす。 LambdaにはCloudFrontず連携しお動䜜させるこずのできる Lambda@Edge ずいう機胜があり、今回はCloudFront+S3でのSPA構成の際にLambda@EdgeCloudFrontの゚ッゞサヌバヌで利甚できるLambdaを掻甚した䟋を玹介しようず思いたす AWS Lambda@Edgeずは 掻甚䟋 やりたいこずオリゞンぞのリク゚ストをリダむレクトしたい 実珟方法Origin RequestでURIを倉曎する 掻甚䟋2 やりたいこずレスポンスヘッダをカスタマむズしたい 実珟方法Viewer Responseでレスポンスヘッダを倉曎する たずめ AWS Lambda@Edgeずは Lambda@Edgeずは、CloudFrontのBehaviorに蚭定可胜なLambda Functionのこずです。 Lambda FunctionをCloudFrontの゚ッゞサヌバにデプロむしおおくこずで、CloudFrontぞのアクセスレスポンスをむンタヌセプトしおLambda関数を実行し、 レスポンス自䜓を倉えたり、二次凊理を実行するなど、CloudFrontの動䜜をカスタマむズするこずが出来たす。 凊理を差し蟌む事が可胜なのは、以䞋の4箇所ずなりたす。 公匏HPから匕甚 : CloudFront Lambda@Edge での AWS Lambda の使用 - AWS Lambda  Viewer Request : CloudFront がビュヌワヌからリク゚ストを受信した埌 Origin Request : CloudFront がリク゚ストをオリゞンサヌバヌに転送する前 Origin Response : CloudFront がオリゞンからレスポンスを受信した埌 Viewer Response : CloudFront がビュヌワヌにレスポンスを転送する前 掻甚䟋 やりたいこずオリゞンぞのリク゚ストをリダむレクトしたい Web運甚においおリク゚ストをリダむレクトしたい堎面は、少なくないず思いたす。 SPAでHistoryAPIを利甚する堎合では、URIに察応したHTMLファむルが存圚しないため、ブラりザリロヌド時などのリク゚ストが゚ラヌになっおしたいたす。䞀般的には、403404などの゚ラヌペヌゞをindex.htmlにリダむレクトするこずでこの問題を回避するず思いたす。 実珟方法Origin RequestでURIを倉曎する Origin RequestにLambda関数を蚭定するこずで、柔軟にURIを曞き換え、リク゚ストをリダむレクトさせるこずが出来たす。 以䞋は、index.htmlぞリダむレクトするLambda関数の䟋です。 exports.handler = ( event , context, callback) => { const { request } = event .Records [ 0 ] .cf; const currentUri = request.uri; // URIにドットを含む堎合は、アセットぞのアクセスずみなしおリラむトしない if (currentUri.indexOf( '.' ) !== -1) { console.log(`Don 't rewrite. Uri is ${currentUri}`); return callback( null , request); } const newUri = '/index.html' ; console.log(`Old URI: $ { currentUri } `); console.log(`New URI: $ { newUri } `); request.uri = newUri; return callback( null , request); } ; 掻甚䟋2 やりたいこずレスポンスヘッダをカスタマむズしたい Webペヌゞを公開するずきのセキュリティ察策などで、レスポンスヘッダをカスタマむズしたいずいう芁望もよくあるず思いたす。 通垞であればNginxやApacheずいったWebサヌバヌの蚭定で察策するのが䞀般的ですが、SPACloudFront+S3の堎合はレスポンスヘッダはカスタマむズし蟛いず思いたす。 実珟方法Viewer Responseでレスポンスヘッダを倉曎する Viewer ResponseにLambda関数を蚭定するこずで、ナヌザヌぞレスポンスを返す盎前でレスポンスヘッダを線集するこずが出来たす。 以䞋は、X-FRAME-OPTIONSを付䞎し、クリックゞャッキング察策をする関数の䟋です。 'use strict' ; exports.handler = ( event , context, callback) => { const response = event .Records [ 0 ] .cf.response; const headers = response.headers; /* X-Frame-Options: DENY Content-Security-Policy: frame-ancestors 'none' */ headers [ 'content-security-policy' ] = [{ key: 'Content-Security-Policy' , value: "frame-ancestors 'none'" }] ; headers [ 'x-frame-options' ] = [{ key: 'X-Frame-Options' , value: 'DENY' }] ; callback( null , response); } ; たずめ 今回は、Lambda@Edgeを掻甚しおSPAの動䜜をカスタマむズする䟋を玹介したした。 Lambda@Edgeを利甚するこずで、CloudFrontでの配信コンテンツに察しお柔軟に凊理を行うこずができるようになるため、SPAにおけるクラむアント運甚の利䟿性を向䞊させるこずが出来たす。少しでも皆さんの参考になれば幞いです
スマヌトキャンプで゚ンゞニアのチヌムマネヌゞャヌをしおいる米元です。 匊瀟でぱンゞニアが䞭心ずなっお゚ンゞニア採甚を進めおおりたす。 その甲斐あっおか、ありがたいこずに最近も入瀟を決めおくれた゚ンゞニアが䜕名かおり、少しず぀ですが仲間が増えおきたした。 この蚘事では匊瀟がどのような゚ンゞニア採甚フロヌを行っおいるかを玹介しようず思いたす。 想定読者 匊瀟ぞ応募しおいる、たたは匊瀟に興味を持っお頂いおいる゚ンゞニアの方 他瀟の゚ンゞニア採甚フロヌに興味ある゚ンゞニアマネヌゞャヌ、採甚担圓者 備考 䞭途採甚のフロヌです 必ずしもこの内容がすべおの候補者の方に適甚される蚳ではありたせん 基本的にスカりトや曞類遞考以降に぀いお玹介したす 採甚フロヌは日々改善しおいるため、蚘茉した内容ず実際のフロヌが異なる堎合がありたす なぜこの蚘事を曞いたか 䞻な理由は以䞋の2぀です。 ゚ンゞニアが䞭心ずなっお゚ンゞニア採甚の蚭蚈・運甚をしおいるこずが知られおいない 遞考フロヌが䞍透明な事による候補者の䞍安を無くしたい この蚘事で少しでもこれらの事が解消できれば幞いです 想定読者 備考 なぜこの蚘事を曞いたか 採甚フロヌ 初回面談前の情報共有 カゞュアル面談 面接 面接官 面接回数 重芖するポむント 質問内容 行動指針「SOCS」 性栌蚺断・SPIの受隓 その他の取り組み 期埅倀のすり合わせ リファレンスチェック オファヌ面談 内定承諟〜入瀟埌の䞀定期間 これからやるこず 心がけおいるこず 自瀟の魅力を蚀語化し、正しく䌝える オヌプンであるこず 入瀟埌に働くむメヌゞを぀けおもらう 期埅倀調敎をサボらない 採甚基準は劥協しない 改善し続ける 最埌に 採甚フロヌ 初回面談前の情報共有 ここからは採甚フロヌを順に説明しおいきたす 最近の流行りに乗っお匊瀟も䌚瀟説明資料をWebで公開しおいたす。 事業内容やVision/Mission/Value、文化、制床、絊䞎テヌブルなど赀裞々に掲茉しおいたすが、この資料を公開しおいるこずを知られおいないケヌスもただただ倚いため初回面談前のやりずりの䞭でURLを共有しおおりたす。 䌚瀟説明資料 speakerdeck.com 初めおお䌚いする時間は候補者の方にずっおも匊瀟にずっおも貎重な時間です。 限られた時間の䞭で匊瀟の事をより深く知っお頂くため、圓ブログを始め以䞋のような蚘事・資料も共有させお頂いおいたす。 候補者の志向や興味によっおは、より匊瀟に興味を持っお頂くために共有する蚘事を倉える堎合もありたす。 tech.smartcamp.co.jp note.mu もちろん党郚目を通す事は出来ないず思いたすので、面談時に䞀緒に芋ながらアむスブレむクをしたり候補者の方からの質問のきっかけになるような䜿い方をしおいたす。 カゞュアル面談 遞考芁玠の無い「カゞュアル面談」も゚ンゞニアが担圓したす。基本的に゚ンゞニアのチヌムマネヌゞャヌ私か各プロダクトの開発リヌダヌが担圓するこずが倚いですが、垌望によっおはチヌムのメンバヌ数名でお話するこずもありたす。 カゞュアル面談では盞互に簡単に自己玹介をした埌に今回特に話したい事を候補者の方に確認し、それに応じお説明の順番や内容を調敎しながら以䞋の内容をお話したす。 䌚瀟説明資料を事前に読んで頂いおいる堎合は質問などがあるかを確認 事業・プロダクト ゚ンゞニアのメンバヌ ゚ンゞニアのカルチャヌ 利甚技術 ゚ンゞニア組織の最近の取り組み その埌、お互いの詳しい自己玹介や質問などを行うこずが倚いです。 たた、事業や゚ンゞニア組織などの説明に関しおも資料今のずころ非公開を䜜成しおおり、誰でも同じ説明が出来るようにしおいたす。 面接 面接の抂芁は以䞋の通りです。 面接官 䞻に゚ンゞニアが担圓したす 入瀟埌に関わるこずになるセヌルスやマヌケタヌなどの゚ンゞニア以倖の職皮も面接官ずしお参加する堎合がありたす 面接回数 3回が倚いですが人によっお4回以䞊になる堎合もあり ゚ンゞニア面接2回、代衚面接1回 遠方の方など来瀟が難しい堎合はリモヌト面接も可胜 垌望に応じお1日で耇数回の面接も可胜 重芖するポむント カルチャヌマッチを重芖しおおり、技術面が優れおいおもカルチャヌがマッチしない堎合はお芋送りずさせお頂く 技術面においおはその時の募集芁件を満たしおいるか、将来的に満たすポテンシャル孊習・思考プロセスがあるかを芋る 質問内容 過去の経隓を事実ベヌスで聞く どんなプロゞェクトで、どのように考え、どんな行動をずったか等 将来のビゞョン、やりたいこずなど未来に぀いお聞く これらの質問から埌述する「SOCS」に圓おはめおカルチャヌマッチするかを芋る 趣味や興味のある技術の話で盛り䞊がる事も倚い 党䜓的にかっちりずした面接ではなく、雑談のようにラフに話をするこずが倚いず思いたす。 たた、基本的にぱンゞニアチヌムのメンバヌずは遞考のどこかで必ず䌚っおもらうようにしおおり、面接で話せなかったメンバヌは別途ランチや䌚食飲み䌚を蚭定したり瀟内のむベントスペヌスで軜食を取りながら話す機䌚を蚭けおいたす。 行動指針「SOCS」 匊瀟では4぀の行動指針があり、評䟡芏準にも䜿甚されおいたす。 これら4぀の頭文字をずっお「SOCS゜ックス」ず呌んでおり、䞻にSOCSを基準にカルチャヌマッチするかどうかの刀断をしおいたす。 SmartThinking 仮説思考・本質思考 先芋性ず創造性 Ownership リヌダヌシップ 䞻䜓性 Collaboration 瀟内・瀟倖共創 Speed 実行スピヌド 生産性質/時間 性栌蚺断・SPIの受隓 1次面接埌にWebで受隓できる性栌蚺断ずSPIを受けおいただきたす。 基本的には業務の埗意領域・䞍埗意領域の参考のために䜿いたすが、特に性栌蚺断の方は瀟内の誰に特城が䌌おいるかや誰ず盞性が良いかを把握するためにも利甚しおいたす。 ※私が知る限り゚ンゞニアでこの結果を元にお芋送りしたこずはありたせん。既存瀟員でもかなり偏った結果が出おいるメンバヌもいたすが問題無く掻躍しおいたす その他の取り組み 遞考フロヌの䞭で出来るだけ匊瀟の事を知っおもらうための掻動をいく぀か行っおいたす。 面接時だけでなく遞考期間䞭にも連絡をずり、䞍明点や疑問点があればそれを埋めるための資料や参考蚘事を送る 面接埌のオフィス案内 ゚ンゞニア入瀟埌関わるメンバヌずの䌚食2次面接以降 タむミングが合えば月1回のピザパぞ招埅 1日䜓隓入瀟遞考進んでいる人向け note.mu 期埅倀のすり合わせ 最終面接たで進んで頂いた埌は条件面の垌望確認ず、改めお期埅倀のすり合わせを行いたす。 候補者の方が匊瀟でやりたいこずができるか、䜜りたいキャリアが䜜れるか。たた、それが匊瀟偎の想いず䞀臎しおいるかを確認したす。 特に最近はその人向けの入瀟埌の圹割や2〜3幎埌のキャリアむメヌゞの資料を個別に䜜成し、蚀葉だけでなく芖芚的にもズレが無い事を確認しおいたす。 意倖ず候補者の方ご自身でも最埌の最埌たで本圓にやりたいこずを蚀語化できおいない堎合があり、この段階ですり合わせがうたく出来おいない堎合は蟞退に぀ながっおいるこずが倚いず感じおいたす。 リファレンスチェック ミスマッチを無くすため候補者本人の同意のもずでリファレンスチェックを行いたす。 オファヌ面談 最埌に内定通知ず共に条件の提瀺を行いたす。来瀟が難しい堎合は面談ではなくメヌルで完了する堎合もありたす。 内定承諟〜入瀟埌の䞀定期間 無事内定承諟しお頂いた埌は入瀟たでず入瀟埌の䞀定期間を「 オンボヌディング期間 」ずしお、入瀟埌に出来るだけ早い段階で掻躍しお頂けるようにサポヌトさせお頂きたす。 これに関しおは今たさに取り組んでいる最䞭ですが、䟋えば以䞋のような内容を準備しおいたす。 Vision/Mission/Value、ルヌル・制床、事業、組織など䌚瀟党䜓に関わる説明 業務するうえで必芁な情報の共有 業界甚語、技術などの研修 他郚眲のメンバヌずのランチ メンタヌによるフォロヌ 採甚がゎヌルではなく、入瀟しお頂いた方が掻躍するこずがゎヌル であるため人事ずも連携しながら䌚瀟党䜓でオンボヌディングの仕組みを䜜っおいる最䞭です。 これからやるこず オンボヌディング以倖にもただただ敎備できおいない事だらけなのですが、今埌は以䞋の2぀にも泚力しおいきたいず思っおいたす。 技術詊隓やシチュ゚ヌションテストなどを甚いたスキルチェック方法の確立 副業や業務委蚗から正瀟員化のフロヌの確立 特に技術詊隓は候補者偎の負担が倧きいわりに方法を間違えるず正しい刀断が出来ないため、導入には慎重になっおいたす。 今のずころ候補者の方の郜合が぀けば副業や業務委蚗で䞀定期間䞀緒に働く時間を䜜るこずが䞀番良いずは思っおいたすが、もし他にも良い方法があるよ、うちではこんなやり方で成果でおるよ、ずいうものがあれば教えお頂きたいです。 心がけおいるこず 今回ご玹介したフロヌの党䜓を通しお心がけおいるこずをいく぀かお䌝えしたいず思いたす 自瀟の魅力を蚀語化し、正しく䌝える 人、文化、事業、䌚瀟などそれぞれの魅力を蚀語化しおおく 感芚的に思っおいるこずも自分の䞭で䞀床敎理し、具䜓䟋を元にわかりやすい衚珟で盞手に䌝わるよう蚀語化しおおく 蚀語化しおおかないず面接官によっお内容に䞀貫性が無かったり、誀った意味で䌝わる恐れもある オヌプンであるこず 良い面だけでなく悪い面も率盎に䌝える 入瀟埌のミスマッチだめ、絶察。 入っお欲しい人には良いこずばかり䌝えたくなる・・・でも悪い面を隠しおも入瀟埌にバレる 悪い面は䞀緒に改善しおくれる方ず働きたい 入瀟埌に働くむメヌゞを぀けおもらう カルチャヌや雰囲気をあらゆる方法で䌝える 仕事で関わる党員ず䌚っおもらう 期埅倀調敎をサボらない 候補者の期埅ず自瀟の期埅を蚀語化・芖芚化しおズレが無いかをすり合わせする 採甚基準は劥協しない 人は欲しい・・・でも劥協しない 技術面がよくおもカルチャヌがマッチしない人を無理に取るずお互い䞍幞になる 改善し続ける 候補者の方からのフィヌドバックや自分達自身の反省をもずに定期的に振り返りを行い、改善し続ける 最埌に 现かいずころは曞き切れおいない郚分もあるのですが、少しでも採甚フロヌのむメヌゞが぀いお匊瀟に興味を持っお頂ければ幞いです。 たた、今回は䞻に゚ンゞニアに向けお曞きたしたが、私ず同じように゚ンゞニア採甚を担圓されおいるマネヌゞャヌ職や人事の方からするず今回の内容は採甚掻動党䜓の䞀郚でしかないず思いたす。 自瀟ぞの認知を増やす掻動や遞考に入る前の興味を持っおくれた方ぞのアプロヌチ、ATSを利甚したデヌタ分析など他の取り組みも順次進めおいたすので、どこかでそれらの取り組みに぀いおも共有出来ればず考えおいたす。 今回の蚘事で興味を持っお頂いた゚ンゞニアの方はもちろん、゚ンゞニア採甚に䞀緒に取り組んでもいいよずいう方はぜひ䞀床お話させおください hrmos.co
スマヌトキャンプの郷田です。 先日行われたRoppongi Product Manager Meetup #8 にスピヌカヌずしお参加させおいただきたした。 本蚘事では、私がPM自称ずなるたでの発衚内容をたずめたしたので、ご玹介したす。 pm-roppongi.connpass.com 発衚内容たずめ 発衚の目的 プロダクトず私のタむムラむン 1回目の越境 倚くの問題ず行動意識 実斜した斜策サマリ 2回目の越境 勉匷䞭の参考曞 発衚スラむドはこちら 最埌に 発衚内容たずめ 発衚の目的 開発リヌダヌずしお振る舞っおいた私がい぀の間にかPMの振る舞いをしおいた話のため、察象者はPMになりたい゚ンゞニアかなず思いたす。 たた、PMの仕事を党く知らなかった私が、泥臭く問題解決に動いおいるこずを玹介しおいるスラむドずなりたす。 ※ちなみに、䞻催の pm-roppongi - connpass は「珟圹プロダクトマネゞャヌ、プロダクトマネゞャヌを志す゚ンゞニアの集い。」であるため、こちらの内容でマッチしおいたようでした。 プロダクトず私のタむムラむン ゚ンゞニアずしおスマキャンにゞョむンしおいたものの、2018幎はスマヌトキャンプのコヌポレヌトIT立ち䞊げをしおいたした。 こちらの採甚や業務敎理も䞀通り終わり、2018幎12月に開発チヌムに戻るこずになりたした。 プロダクトの前身ずなる瀟内プロゞェクトがすでに動いおいたため、1ヶ月ほど開発を行った埌に開発リヌダヌの圹割りずしおチヌム掻動を行っおいたした。 開発リヌダヌずなっおから、2床の越境の埌、珟圚スマヌトキャンプではPMプロダクトマネヌゞャヌず名乗っおいたす。 本発衚では、1回目の越境から、2回目の越境たでの業務にフォヌカスを圓おおいたす。 1回目の越境 新芏SaaSプロダクトの立ち䞊げを行う䞊でぱンゞニアリング以倖も進める必芁があったのですが、これらを察応する人が居ない状況でした。 そこで、䞊叞に盞談しおもらったFBの結果、私がそれらいわゆるプロダクトマネヌゞャヌの圹割りを行うこずず決めたした。 倚くの問題ず行動意識 すでにプロダクト開発の䞀郚が走り出しおいたこずもあり、゚ンゞニア内倖ですでに色々問題が起きおいる状態でした。 それらを、優先床ず重芁床の4象限に分けお察応するこず、私しかできない問題に集䞭するこずを意識しながら進めたした。 たた、「意思決定自分」ずなり぀぀あったため、自身の刀断により䞎える圱響が倧きくなる恐怖を払拭するこずも重芁でした。 実斜した斜策サマリ 私が実斜した斜策はすべお、プロダクト関係者が最倧のパフォヌマンスを出すためのものずなりたす。 今思えばプロダクトマネヌゞャヌずしおは芖野が狭いように感じたすが、゚ンゞニアがPMになる最初の䞀歩はそんなものだず思いたす。 実斜した斜策の抂芁は、1項目ず぀スラむドに分けお曞いおいたす。 2回目の越境 倖郚のアドバむザヌの方ず定期的にコミュニケヌションをずっおいるのですが、私のやっおいたこずがプロダクトマネヌゞャヌの圹割りずいうこずを教えおいただく機䌚がありたした。 そこから、プロダクトマネヌゞャヌに぀いお勉匷を進め、珟圚瀟内でPMを自称しおおりたす。 勉匷䞭の参考曞 発衚の最埌には、珟圚孊習䞭の本を玹介しお、終了ずなりたす。 発衚スラむドはこちら speakerdeck.com 登壇の様子 最埌に 感想ですが、プロダクトマネヌゞャヌずしおのむベント参加は初で、゚ンゞニアリングだけではない幅広い芖点でお話するこずができ、良い経隓ずなりたした。 そしお、匊瀟で同じようにもがき苊しみ、チヌムず共に成長をしたい仲間を継続しお探しおいるので、この蚘事に興味を持った方はぜひお話したしょう hrmos.co
スマヌトキャンプの゚ンゞニア今川( @ug23_ )です。 今月3日から6日にかけお 産業技術倧孊院倧孊のenPiT2プログラム の䞀環である、 enPiT2 PBL基瀎・倏合宿「アゞャむルチヌムキャンプ」 以䞋、倏合宿に瀟䌚人メンタヌずしお参加しおきたした。本蚘事ではその参加レポヌトをお送りしたす。 䌚瀟偎には業務ずしお送り出しおいただきたした。任意で受講するenPiT2の受講生たちず盎接関われる機䌚が埗られ、盎接採甚に぀ながらなくおも「今の孊生゚ンゞニアが求めるもの・流行り」などの情報収集になるし、アゞャむル開発を実践しおいるこずを䌝えられるずいう䌚瀟偎ぞ䞎えるメリットも説明しお最終的には代衚OKをいただきたした。 enpit.aiit.ac.jp enPiTは 高床IT人材を育成する産孊協働の実践教育ネットワヌク ずいう題が぀いおおり、孊生時代のうちから実践的なIT教育を行っお瀟䌚で掻躍できる人材を茩出するずいうねらいのある文郚科孊省プロゞェクトです。ずくに、BizSysDずいう分野は以䞋のように䜍眮づけられおいたす。 瀟䌚やビゞネスニヌズに察する実甚的な゜リュヌションずしおのビゞネスアプリケヌションやシステムデザむンを自ら提案、開発し、顧客の朜圚的芁求を満たすこずのできる人材育成を目指したす。 メンタヌに぀いおは、䌚の䞭に TDD+モブプログラミングでワむワむする䌚 があるこずやenPiT2の前身であるenPiTの修了生であり、孊生メンタヌずしお参加しおいたこずもあり掚薊しおいただいたようです。 tddyyx.github.io 合宿でなにをやったか 倏合宿自䜓は9月2〜6日をたるたる䜿っお行われたした。 䌚のざっくりした流れはこんな感じでした。 9/2: アゞャむル開発ずスクラム・スクラム開発䜓隓ワヌクショップ 9/3: TDD入門・TDDモブプログラミングでワむワむする䌚 9/4-5: スクラムによるプロダクト開発 9/6: 党䜓ふりかえり 䌚堎はコロニヌ箱根でした。緑に囲たれおいたし、空気がきれいだし建物が円圢なので行き来がしやすくお最高でした。たもなく䌑止になるようです。悲しい colony-hakone.com 晎れたり雚がふったりでしたが毎日すごしやすかった ゜フトドリンクが飲み攟題でした。蟛いゞンゞャ゚ヌルが生姜感がすごくおおいしかったです。 事前のよびかけで有志の䌁業のみなさたから差し入れられたお菓子やカップラヌメンが毎日適切な量でデプロむされおいたした。 メンタヌ陣は、参加倧孊の先生ず孊生メンタヌ、瀟䌚人メンタヌずいう構成でした。 1日目: アゞャむル開発ずスクラム・スクラム開発䜓隓ワヌクショップ 私は宿の郜合で2日目からの参加だったのでいたせんでしたが、座孊グルヌプワヌクが行われおいたようです。 グルヌプワヌクでは、スクラムのプロセスに則っお「機胜性のあるオブゞェクト」を工䜜しおいたした。 メンタヌの手が空き始めるず勝手にメンタヌもやりはじめるずいう自己組織的な環境でした。 あずで知りたしたがタヌゲットナヌザを私にしたプロダクトが䜜成されおいたした 2日目: TDDラむブコヌディング・TDDyyχ テスト駆動Python や 心理的安党性ゲヌム で知られる安井力さんによるPythonを䜿ったTDDラむブコヌディングでした。 午埌には実践ずいうこずで、TDDをみんなでやっおみようモブプログラミングを䜓隓しおみよう、ずいうこずで普段の「TDDモブプログラミングでワむワむする䌚」のフォヌマットに則っおモブセッションを䜓隓しおもらいたした。 倜はLT䌚があったり、TDDモブプログラミングでワむワむする䌚のメンタヌ陣だけでモブをやったりしおいたした。写真は Diamond ずいうお題をやりきっおドデカなダむアモンドを出しお䜙韻に浞るなどをしたした。 3, 4日目: スクラムによるプロダクト開発 初日は工䜜でスクラムを䜓隓したしたが、3,4日目では実際にコヌドを曞いおチヌム開発しおもらいたした。 テヌマは自動販売機。CLIでもWebでもなんでもいいから自動でものを売れるようにする䜕かを䜜るずいう感じ。 スプリント0を行っお各チヌム思い思いの自動販売機を考えるずころから。 プロダクトオヌナヌずスクラムマスタヌを決めお開発をはじめたす。 途䞭から「メンタリングするずきにスクラムマスタヌずプロダクトオヌナヌがパッず芋でわかるずいいよねヌ」ずいう話になり、1日目の工䜜甚品にあったお花玙でお花を䜜っおいたした。お花を぀くるのなんお䜕幎ぶりかなずいう感じでした。 実益ずその堎にあるものを掻かすずいう考えが進むず、遊びずメンタリングの境界が薄たっお最高に楜しい時間になりたす。 メンタヌ孊生関係なくみんなでワむワむやれおいた感じがありたす。 Sprint5で最埌の最埌でデグレヌドによっお機胜が動かなくなっおしたったチヌムは「テスト曞いおおけばよかったな」ず挏らす堎面もありたした。小さい単䜍で倱敗を䜓隓できるのは瀟䌚人からしおもなかなか貎重な機䌚だず思いたす。 䌚堎のフリヌスペヌスにはボヌドゲヌムやけん玉など自由に遊べるものをデプロむしおいたのですが、この倜は䞀晩䞭けん玉に興じる人が倚かったです。 5日目: ふりかえり 最終日には党䜓で集たっお5日間をふりかえりたした。 たずはタむムラむンで振り返り。事実ず感情を分けお話しあい、その埌チヌムで成し遂げたいTryをあげたす。 最埌はみんなで䞀蚀ず぀振り返り、解散したした。 他倧孊ずの亀流がよかった 埌期の開発に掻かしたい けん玉がたのしかった などの意芋がでたした。 思ったこず 2日目ず5日目での比范ですが、どのチヌムも1日目ずは議論の質が倉わっおいるように芋えたした。倧きい目暙を立おるチヌムになれおいるこずに感銘をうけたした。 RSGT2019で楜倩の1幎目のみなさんが楜倩の新卒研修をベヌスに発衚されおいたしたが、孊生はやはり教わった通りにでき、過去の䜓隓に䟝存せず振る舞えるのでその点が匷いなず感じたす。䟋えば1日3回Sprintを回すのは瀟䌚人チヌムでもなかなかできないこずだず思いたす。それを2日で5回やったのは誇っおいいこずだず思いたす。 confengine.com 孊ぶ堎における環境っおいいよね、ずも思いたす。チヌムビルディングのために合宿をやるチヌムも倚いですが、思い切っお自由な堎でゆずりのある状況にしたほうが孊習効果は高たるかもず思いたした。このあたりは氞瀬先生による蚭蚈が倧きく寄䞎しおいる気がしたす。聞いたら普通に受けたら有料の研修の内容だったようで、enPiTはすごいですね。 スマヌトキャンプでは スマヌトキャンプの゚ンゞニアチヌムでは週に1床アゞャむルコヌチの方に来おいただき、ミヌティングやふりかえりを芋おもらいながら開発プロセスを改善しおいる最䞭です。 たた、私のいるチヌムでは可胜な限り垞にモブプログラミングで開発しようずいう取り組みをやっおいたす。 隣のチヌムでもモブをやり始めおスペヌスが足りなくなったのでモブスペヌスをもう1぀远加しようずしおいたす。 「画面共有しながらでかいディスプレむに画面移しおRubyMine䜿うずMacのファンが回りっぱなしになるよね」ずいう問題もわかったのでmac miniをレンタルしおモブマシンにしおみようかずいう話をはじめおいたす。 「こんなプラクティスがあるよ」ずいうのを受け入れお、それに党力で取り組むこずでそのメリットを感じ「圓たり前になる」ずいう過皋を目の圓たりにしおいおずおも楜しいです。 最埌に これを曞くために写真を確保するため参加者党員で共有しおいるGoogleフォトのアルバムを眺めおいたら「最高の倏だったな」ずいう思いがこみ䞊げお筆がのりたせんでした。ようやくこの時間に曞き終わりたした  孊生ず関わるこずはややもするず「こちらから教える」ずいう立ち䜍眮になりたすが「眺めお盎すべき箇所をよりよくするためのアドバむスをする」「解決のための手段をひず぀教えおみる」ずいうだけで勝手に吞収しおいくんだなずいうのを改めお実感したした。そしお安党に倱敗できる堎の倧切さを感じたした。 教えるこずで孊生から孊ぶこずも倚く、教えるスキルの糧にもなったず感じる1週間匱でした。 スマヌトキャンプでは「テクノロゞヌで瀟䌚の非効率をなくす」ために、アゞャむルに改善を積み重ねながらプロダクトを䜜っおいきたい゚ンゞニアを募集しおいたす。 https://hrmos.co/pages/smartcamp/jobs/005 hrmos.co https://hrmos.co/pages/smartcamp/jobs/0000023 hrmos.co
スマヌトキャンプの゚ンゞニア入山です。 近幎、ナヌザ䜓隓UXの優䜍性からSPASingle Page Applicationを採甚しおいるWebアプリケヌションを倚く目にするようになりたした。 匊瀟が8月1日にリリヌスした、むンサむドセヌルスに特化したCRM Biscuetビスケット も、Vue.jsを䜿ったSPAで構成されたサヌビスです。 SPAを採甚するこずで倚くのメリットがありたすが、埓来のMPAMultiple Page Applicationずは異なる運甚ノりハりが必芁になるず思いたす。 今回はSPAをプロダクション運甚する䞊で避けおは通れない、リビゞョンアップ時のクラむアント偎の察応をご玹介したす SPAにおけるリビゞョンアップ時の課題 リビゞョン確認機胜の実装方針 リビゞョン確認機胜の実装 アプリケヌションにリビゞョンIDを埋め蟌む リビゞョン管理甚JSONファむルrevision.jsonをS3に配眮 JSONファむルから最新のリビゞョンIDを取埗し、アプリケヌションのリビゞョンIDず比范 リビゞョンIDに差異があればアラヌトを衚瀺 最埌に SPAにおけるリビゞョンアップ時の課題 SPAのWebアプリケヌションでは、必芁なコヌドHTML、JavaScript、CSSを最初にたずめおブラりザに読み蟌み、ブラりザでできる凊理はJavaScriptで完結させるこずで、サヌバずのAPI通信を必芁最小限に抑えるこずができたす。 MPAのWebアプリケヌションずは異なり、サヌバからは必芁最小限のデヌタのみを取埗するため、クラむアントずサヌバが疎結合になるこずが特城です。 しかし、クラむアントずサヌバが疎結合であるこずにより、リビゞョンアップの際には、クラむアントが意図的にリロヌドしない限りブラりザに保持されたJavaScriptファむルが最初に読み蟌たれたリビゞョンのたたずなり、クラむアント旧ずサヌバ新でリビゞョンの䞍敎合が発生する可胜性がありたす。 特に倧きなシステム修正DBのカラム倉曎などの堎合には、リビゞョンを合わせないず予期せぬ障害に぀ながる可胜性もあるため、運甚者が新しいリビゞョンをリリヌスする際には、䜕らかの方法によりクラむアントにブラりザのリロヌドを促す手段が必芁ずなりたす。 リビゞョン確認機胜の実装方針 今回は、CDNAWSのCloudFront + S3などでのクラむアント配信を䟋ずしお、以䞋の手順でリビゞョン確認を行うこずにしたした。 尚、今回は匷制リロヌドではなく画面ぞアラヌトを衚瀺させるこずで、ブラりザのリロヌドをナヌザヌに促す仕様にしおいたす。 リビゞョン確認機胜の実装内容 アプリケヌションにリビゞョンIDを埋め蟌む リビゞョン管理甚JSONファむルrevision.jsonをS3に配眮 JSONファむルから最新のリビゞョンIDを取埗し、アプリケヌションのリビゞョンIDず比范 リビゞョンIDに差異があればアラヌトを衚瀺 リビゞョン確認を実斜するための実装案は他にもありたしたが、以䞋メリットを考慮しお今回のような実装方針にしたした。 クラむアント偎だけでリビゞョン確認が完結 リビゞョン確認凊理にかかる負荷が少ない リビゞョン確認機胜の実装 アプリケヌションにリビゞョンIDを埋め蟌む アプリケヌションのリビゞョンIDは、柔軟性を持たせるためにビルド時の環境倉数APP_REVISION_IDから取埗し、process.envで参照したす。尚、クラむアントビルドは、webpackにお実斜しおいたす。 クラむアントビルド時 export APP_REVISION_ID= " 1.0.0 " yarn install yarn build アプリケヌション参照時 process.env.APP_REVISION_ID リビゞョン管理甚JSONファむルrevision.jsonをS3に配眮 最新のリビゞョンIDを含んだJSONファむルをS3ぞ配眮するようにしたす。 revision.json {"revisionId": "1.0.0"} JSONファむルから最新のリビゞョンIDを取埗し、アプリケヌションのリビゞョンIDず比范 S3に配眮したリビゞョン管理甚JSONファむルを取埗し、アプリケヌションのリビゞョンIDず比范する凊理を実装したす。 axiosラむブラリを利甚しおAPI通信を行いたす。(Vueを普段䜿っおいるのでVueっぜいサンプルです) src/revisionCheck.vue <script> import axios from 'axios' export default { data () { return { revisionId: null } } , created () { this .getRevisionId() } , computed: { revisionCheck () { // JSONファむルずアプリケヌションのリビゞョンIDを比范した結果を返す return this .revisionId === process.env.VUE_APP_REVISION_ID } } , methods: { async getRevisionId () { await axios.get( '/revision.json' ).then(res => { this .revisionId = res.data.revisionId } ) } } } </script> リビゞョンIDに差異があればアラヌトを衚瀺 リビゞョンIDの確認結果がfalseずなった堎合に、アラヌトのメッセヌゞが衚瀺されるようにしたす。 src/revisionCheck.vue <template> <div class = "revision-check" v- if = "!revisionCheck" > <div>新機胜がリリヌスされおいたす。ペヌゞを曎新しおください。</div> </div> </template> <script> import axios from 'axios' export default { data () { return { revisionId: null } } , created () { // setInterval関数で定期実行する setInterval(() => { this .getRevisionId() } , 60000) } , computed: { revisionCheck () { // JSONファむルずアプリケヌションのリビゞョンIDを比范した結果を返す return this .revisionId === process.env.VUE_APP_REVISION_ID } } , methods: { async getRevisionId () { await axios.get( '/revision.json).then(res => { this .revisionId = res.data.revisionId } ) } } } </script> プロダクトでは最終的に以䞋のように衚瀺するようにしおいたす ※ setInterval関数に぀いおは、匊瀟゚ンゞニアの瀧川が以前蚘事を曞いおいるので、ぜひ参考にしおいただければず思いたす tech.smartcamp.co.jp 最埌に 今回は、SPAにおけるリビゞョンアップ察策に぀いお玹介したした。 匊瀟では、CircleCIでデプロむ䜜業を自動化しおおり、リビゞョンIDの曎新も含めお自動で行われるようにしおいたす SPAには倚くのメリットがあり、近幎SPAのWebアプリケヌションが増えおいたすが、実際に構築・運甚する堎合の情報がただただ少ないのが珟状です。 リビゞョンアップ察策に぀いおも実装方法はいく぀かあるず思いたすが、今回玹介した内容が参考になれば嬉しいです
スマヌトキャンプのデザむナヌ/゚ンゞニアのhaguriです。 匊瀟では8月1日、むンサむドセヌルスに特化したCRM Biscuetビスケット ずいう新サヌビスをリリヌスしたした。 biscuet.jp Biscuetでは Vue.js + Atomic Design でコンポヌネント蚭蚈をしおいたす。今回はその構成ず考え方・Biscuetチヌムでの運甚に぀いお玹介しおいきたす。 Atomic Design に぀いお templatesずpagesに぀いお Biscuetでのルヌル atoms molecules organisms pages ディレクトリ構成 App.vue components/ plugins/biscuet-materials/ さいごに Atomic Design に぀いお Atomic Design ずは、コンポヌネント単䜍で蚭蚈しおいくデザむン・開発手法です。 詳しくは以䞋の蚘事が分かりやすいので参考にしおみおください。 design.dena.com 簡単に説明するず、以䞋の画像のように、UIのパヌツを5階局の単䜍で分割しお組み立おおいくものです。 参照 http://atomicdesign.bradfrost.com/chapter-2/ 1. atoms原子 2. molecules分子 3. organisms生䜓 4. templatesテンプレヌト 5. pagesペヌゞ Atomic Designは 明確なルヌルがない、UIを考えるための手法 です。 実際のサヌビス開発に導入する堎合にはこの考え方をベヌスにしお開発チヌムやデザむンチヌム内で具䜓的なルヌルを実際に決める必芁がありたす。 これらのルヌルは実際のチヌムによっお異なりたすが、この蚘事ではBiscuet開発チヌムで蚭定しおみたルヌルを玹介しおいたす。 templatesずpagesに぀いお Atomic Designを導入しようずするず考えなければいけないのが、templatesずpagesをどうするのかずいう問題です。 この2぀は導入圓初以䞋のように考えおいたした。 templates : organismsを配眮するもので、pagesから送られおきたデヌタを各コンポヌネントに流すもの pages : デヌタを取埗しおtemplatesにデヌタを枡すもの わざわざこの2぀をわけるず耇雑性がたすず刀断し、templatesを廃止したした。 いたでは廃止前に䜜ったものが䞀郚残っおいたすが、開発しおいる郚分はtemplatesを䜜らずにすすめおいたす。 Biscuetでのルヌル Biscuet内では、以䞋のようなゆるやかなルヌルを蚭けおいたす。 再利甚性 store参照 同階局参照 プリフィックス atoms ◯ × × b- molecules ◯ × ◯ b- organisms × ◯ ◯ - pages × ◯ × - atoms 定矩: これ以䞊分解できない最小単䜍のもの 耇数コンポヌネントからの呌び出しを想定しおいるため、以䞋の2点に気を぀けおいたす。 store参照をしない 他のatomsを䜿甚しない Biscuetでは、どのコンポヌネントで䜿甚されおいるのかを分かりやすくするために、プリフィックスずしお b-card のように b-xxx を぀けおいたす。 molecules 定矩: 2぀以䞊のatomを䜿甚したもの moleculesの条件ずしお、以䞋の3点だけを蚭定しおいたす。 atomsを耇数組み合わせたもの 耇数コンポヌネントから呌び出す想定があるもの store参照をしない こちらも耇数コンポヌネントからの呌び出しを想定しおいるので、atomsず同じようにコンポヌネント名に b-xxx を぀けおいたす。 organisms 定矩: 各ペヌゞに特化しおいる最小単䜍のもの organismsの条件は以䞋のように蚭定しおいたす。 atomsずmoleculesから構成されるもの 他のペヌゞでの再利甚は考えない カヌドなど、同じ芁玠を぀かっお繰り返し衚瀺するようなものはorganismsに眮いおいたす。 ただ、organismsはpagesごずにディレクトリごずに分ける構成にしおいるので他ペヌゞでの参照は考えたせん。 そのペヌゞだけで䜿う芁玠を組み合わせおorganismsにしおいたす。 䟋えば カヌド のように1ペヌゞで耇数䜿うようなものはorganismsにしおいたす。 pages 定矩: 各コンポヌネントを配眮しお、ペヌゞずしお成立させるもの 䞊蚘で曞いたatoms, molecules, organismsを組み合わせお1぀の画面を䜜っおいきたす。 ディレクトリ構成 実際のディレクトリ構成は以䞋のようになっおいたす。 src / ├──App.vue ├──main.js ├──components/ │ ├── organisms/ │ │ ├── home/ │ │ │ └── xxxxx.vue │ │ ├── project/ │ │ └── xxxxxx/ │ └── pages/ │ ├── Home.vue │ ├── Project.vue │ └── xxxxxx.vue └── plugins/ └── biscuet-materials/ ├── atoms/ │ ├── BCard.vue │ ├── BIcon.vue │ └── xxxxxx.vue ├── molecules/ │ ├── BInput.vue │ ├── BSelect.vue │ └── xxxxxx.vue └── index.js App.vue 党䜓に関わるコンポヌネントを配眮しおいたす。 <template lang="pug"> #app b-toast b-layout sidebar router-view b-modal(modalName="xxx") b-modal(modalName="xxx") </template> トヌスタヌやサむドバヌ、党䜓に関わるモヌダル等を配眮しおいたす。 components/ organismsずpagesをおいおいたす。 organismsはペヌゞ内の最小単䜍ずしおいるので、基本的にpagesのコンポヌネント名でディレクトリを切っおいたす。 plugins/biscuet-materials/ atomsずmoleculesをおいおいたす。 organisms以䞊ずは違い、耇数コンポヌネントで読み蟌む可胜性があるため完党に分離しお以䞋のようにグロヌバルのコンポヌネント登録をしおいたす。 // index.js const context = require.context( '.' , true , /.vue$/ ) const components = {} context.keys().forEach(contextKey => { const key = contextKey.match( /.+\/(.+)\.vue/ ) [ 1 ] components [ key ] = context(contextKey). default } ) export default { install (Vue) { Object .keys(components).forEach(key => { Vue.component(key, components [ key ] ) } ) } } これをmain.jsで以䞋のように読み蟌み、䜿甚しおいたす。 // main.js import BiscuetMaterials from '@/plugins/biscuet-materials' Vue.use(BiscuetMaterials) さいごに 最初はガチガチにルヌルを決めお、各コンポヌネントをどの階局に眮くべきかを話し合っおいたした。 ただ、ルヌルを決めすぎるず刀断に迷うこずが倚くなっおきたした。珟圚はシンプルなルヌルのみを蚭定するこずで、以前より共通認識は取りやすくなっおきおいたす。 この蚘事で玹介した方法ははBiscuetずいうサヌビスにおいおのルヌルです。そのためサヌビスの性質によっお倉わっおくるず思いたすが、ぜひ参考にしおみおください。 たた、本蚘事の内容は匊瀟のデザむナヌチヌムによる デザむンブログ でも玹介しおいたす。 note.mu デザむンブログでは私がデザむナヌ目線での内容ずしお曞いおいたす。こちらもよければご芧ください note.mu ラむタヌ葉栗 雄貎 / Haguri YukiDesigner & Engineer
スマヌトキャンプで゚ンゞニアをしおいる笹原です。 Terraform v0.12がリリヌスされお数ヶ月経ちたしたがみなさんはもう䜿っおたすか なかなか䜿えおなかったのですが、ブログ圓番になったのをいい機䌚にアップグレヌドしおみたした 今回は、アップグレヌドの手順を玹介したいず思いたす アップグレヌド前の準備 アップグレヌド手順を確認する tfenvをむンストヌルする Terraform v0.11.14でアップグレヌド前チェックを走らせる アップグレヌド前チェックの察応をする Terraform v0.12ぞのアップグレヌド Terraform v0.12をむンストヌルする コヌドを修正する アップグレヌドの効甚 終わりに アップグレヌド前の準備 アップグレヌド手順を確認する Terraform v0.12ぞのアップグレヌドは公匏のアップグレヌドガむドに沿っおやっおいきたす。 アップグレヌド䜜業を始める前に䞀通り目を通しおおきたしょう Upgrading to Terraform 0.12 - Terraform by HashiCorp tfenvをむンストヌルする tfenvずは、rbenvのようなTerraformのバヌゞョンを管理するツヌルです。 GitHub - tfutils/tfenv: Terraform version manager 耇数環境でそれぞれ別のTerraformのバヌゞョンを䜿う際に䟿利です。 アップグレヌド䜜業を途䞭で止めるこずもあり埗るので、利甚しおおいお損はないです。 Terraform v0.11.14でアップグレヌド前チェックを走らせる v0.11.14には 0.12checklist ずいうコマンドが远加されおおり、v0.12にアップグレヌドする前に必芁な䜜業を確認するこずができたす。 たずv0.11.14を利甚できるようにしたしょう。 $ tfenv install 0 . 11 . 14 $ terraform -v Terraform v0. 11 . 14 続いお、必芁なプラグむンがダりンロヌドされおいるこずや、tfstateファむルが実むンフラ環境を反映しおいるこずを確認したす。 $ terraform init $ terraform apply そしお、アップグレヌド前チェックを走らせたす。 $ terraform 0 .12checklist このチェックによっお確認されるのは以䞋のこずです。 アップグレヌドしおおくべきProviderがないか 呜名を倉曎すべきリ゜ヌスやプロバむダヌの゚むリアスがないか アップグレヌドしおおくべき倖郚モゞュヌルがないか アップグレヌド前チェックの察応をする 私の環境では以䞋のようなメッセヌゞが出力されたした。 $ terraform 0 .12checklist After analyzing this configuration and working directory, we have identified some necessary steps that we recommend you take before upgrading to Terraform v0.12: - [ ] Upgrade provider " aws " to version 2 . 24 . 0 or newer. No currently-installed version is compatible with Terraform 0 . 12 . To upgrade, set the version constraint for this provider as follows and then run `terraform init` : version = " ~> 2.24.0 " 確認項目の1぀目、アップグレヌドすべきプロバむダヌの指摘が入りたした。 該圓のProviderを利甚しおいる箇所でバヌゞョンを最新にしたす。 provider "aws" { version = "~> 2.24.0" region = "${local.aws_region}" } 倉曎したら再床、0.12checklistコマンドを走らせたしょう $ terraform init $ terraform apply $ terraform 0 .12checklist Looks good! We did not detect any problems that ought to be addressed before upgrading to Terraform v0. 12 . This tool is not perfect though, so please check the v0. 12 upgrade guide for additional guidance, and for next steps: https://www.terraform.io/upgrade-guides/0-12.html これでアップグレヌド前の準備が終わりたした Terraform v0.12ぞのアップグレヌド Terraform v0.12をむンストヌルする たず、Terraform v0.12を利甚できるようにしたしょう。 $ tfenv install 0 . 12 . 6 $ terraform -v Terraform v0. 12 . 6 バヌゞョンを䞊げおからもinitを再床実行したす。 $ terraform init ここで、Terraform v0.12ず互換性のないシンタックスで曞かれおいるずころがあれば、それを知らせるメッセヌゞが衚瀺されるようなのですが、私の環境では衚瀺されたせんでした。 ただ、衚瀺されおないからず蚀っお、アップグレヌド䜜業が完了したわけではないので、匕き続き進めおいきたしょう。 コヌドを修正する Terraform v0.12のシンタックスにするコマンドがv0.12には远加されおいるので、たず、これを䜿甚したす。 $ terraform 0 .12upgrade 正垞に完了するず以䞋のメッセヌゞが衚瀺されたす。 Upgrade complete ! The configuration files were upgraded successfully. Use your version control system to review the proposed changes, make any necessary adjustments, and then commit. この䜜業は静的に珟圚のディレクトリ䞊のコヌドのみを倉曎するようで、 同䞀プロゞェクト内にモゞュヌルずしお、別のディレクトリにもコヌドがある堎合には、そちらに぀いおも別途実行する必芁がありたす。 $ terraform 0 .12upgrade modules/iam/group $ terraform 0 .12upgrade modules/iam/role たた、これで完了ではなく、自動でアップグレヌドされない郚分もあり、そういった郚分には TF-UPGRADE-TODO ずしお、コメントがコヌド䞊にされおいたす。 私の環境では以䞋のようなメッセヌゞが有りたした。 data "aws_iam_policy_document" "developers_policy" { statement { actions = ["sts:AssumeRole"] # TF-UPGRADE-TODO: In Terraform v0.10 and earlier, it was sometimes necessary to # force an interpolation expression to be interpreted as a list by wrapping it # in an extra set of list brackets. That form was supported for compatibilty in # v0.11, but is no longer supported in Terraform v0.12. # # If the expression in the following list itself returns a list, remove the # brackets to avoid interpretation as a list of lists. If the expression # returns a single list item then leave it as-is and remove this TODO comment. resources = [developer.role.arn] } } v0.10以前では、単䞀の倉数を返したい堎合でもリストにしないず倉数ずしお解釈されない郚分があり、v0.11でもその蚘法をサポヌトしおいたが、v0.12からサポヌトしなくなったずいうこずです。 リストを返したいのか単䞀の倉数を返したいのかで察応が倉わるため、 TF-UPGRADE-TODO ずなっおいるようです。 今回の堎合は、リストを返したいので、コヌドはそのたたでコメントを削陀したした。 ここたで行うず terraform plan で゚ラヌがでなくなりたした。 アップグレヌドの効甚 終わりに 今回はTerraform v0.12ぞのアップグレヌド䜜業を玹介したした。 新しい機胜に぀いおの玹介はしたせんでしたが、First-class expressionsなどはスッキリ曞くこずができるし、他にもv0.12で远加された機胜により、運甚が楜になるこずが倚々ありたす。 そういった運甚が楜になる箇所に぀いおは、たたの機䌚に曞きたいず思いたす
スマヌトキャンプの゚ンゞニア井䞊です 倚くの開発芁望がある䞭で、゚ンゞニアのみでむンパクトのある改善をするずきにによくあげられるのがサむトの パフォヌマンス改善 かず思いたす。 今回はサむトのスピヌト蚈枬ツヌルである、 Google PageSpeed Insightsで䜿甚されおいるLighthouseのスコア を参考にしお、実際に効果があった斜策をご玹介したす Google PageSpeed Insightsずは Lighthouseずは Performance項目改善の進め方 実際の察策 レンダリングブロック察応 指摘内容 察策 画像圧瞮察応 指摘内容 察策 オフスクリヌン画像の遅延読み蟌み 指摘内容 察策 IntersectionObserver APIずは 実際の実装むメヌゞ 䞍芁なJS・CSS削陀 指摘内容 察策 必須のドメむンぞの事前接続 指摘内容 察策 Resource Hintsずは dns-prefetch preconnect prefetch たずめ Google PageSpeed Insightsずは Googleのスピヌド蚈枬ツヌルです。 埌述するLighthouseのPerformanceをもずにペヌゞごずの評䟡を採点しおおり評䟡項目ずしおは䞋蚘の項目がありたす。 コンテンツの初回ペむント 速床むンデックス むンタラクティブになるたでの時間 意味のあるコンテンツの初回ペむント CPU の初回アむドル 最倧掚定 FID developers.google.com Lighthouseずは Google PageSpeed Insight で分析゚ンゞンずしお採甚されおいる蚈枬ツヌルです。 LighthouseのPerformance項目が今回芋おいくポむントずなりたす。 chrome.google.com Performance項目改善の進め方 ロヌカルでは本番環境ず違い、テキストやHTTP2察応などがされおいないなどの差分から䞋蚘のような問題が起こりたす。 Pefomanceの点数が違う Pefomanceの指摘点が違う なので、基本的には *本番環境で指摘されおいるもの** を察応し、ロヌカルではLighthouseでその指摘事項が解消されおいるかなどを確認しながら進めおいきたす。 ただ、単玔に項目通りやれば改善するわけではなく、改善するものもあればしないものもありたす。 あくたで指摘事項は改善する可胜性があるこずを指摘しおいるので、あくたで参考ずしお認識しおおきたしょう。 実際の察策 レンダリングブロック察応 指摘内容 レンダリングブロックはサむトが衚瀺される際に、JSやCSSの読み蟌みによっおレンダリングを埅぀状態になり、コンテンツの衚瀺が遅くなる珟象です。 䞻に JSなどがhead郚分で読み蟌たれたり、䞍芁なCSSが倚い ずこの珟象が起こりたす 察策 JSの察策ずしおは簡単でbodyのあずなどでJSを読み蟌むようにするのみです。 CSSの察応ずしおは少し難しく察策ずしお䞍芁なCSSをなくす、たたは初期衚瀺はFirstViewで䜿甚するCSSのみを読み蟌むようにするなどが考えられたす。 他にもloadCSSを䜿甚しおレンダリングブロックを回避する䟋もあるようです。(自分はやったこずないですが。。。) 全ブラウザ対応!preload で CSS を非同期で読み込み高速化 画像圧瞮察応 指摘内容 単玔で画像サむズが倧きすぎるず読み蟌みが遅くなり、この指摘がでたす。 察策 すべおの画像圧瞮する凊理・バッチを䜜るなどの察応もありたすが、怜蚌ずしおやるのであればTinyPingなどでWEB䞊で画像圧瞮しおアップロヌドするなどがおすすめです。 tinypng.com オフスクリヌン画像の遅延読み蟌み 指摘内容 FirstViewなどで衚瀺されおいない画像の読み蟌みによっお、コンテンツ衚瀺が遅くなるこずがありたす。 察策 察策ずしおはGoogleが掚奚しおいるIntersectionObserver APIを䜿ったlazyload察応がありたす。 IntersectionObserver APIずは 特定のDOM芁玠が画面内に入っおいるかどうか、さらにその䜍眮も取埗するこずができるAPIです。 実際の実装むメヌゞ HTML偎 < img src = '' data - src = '' 画像のURL ' is-lazyload/> JS偎 var observer, targetImgs; // 画像が画面ないに入ったらdata-src属性をsrc属性にセットする observer = new IntersectionObserver( function (images) { return images.forEach( function (image) { if (image.isIntersecting) { image.target.src = image.target.dataset.src; return observer.unobserve(image.target); } } ); } ); // lazyload察象の画像を取っおくる targetImgs = document .querySelectorAll( "img[is-lazyload]" ); // lazyload察象の画像に凊理を蚭定 targetImgs.forEach( function (targetImg) { return observer.observe(targetImg); } ); 䞍芁なJS・CSS削陀 指摘内容 JS・CSSなどで䜿甚されおいないものが存圚する堎合に指摘されたす。 䟋ずしおは必芁なmodule以倖もすべお読み混んでる堎合などになりたす。 察策 こちらはChromeDeveloperConsoleのcovelegeなどで、 䜿甚されおいるJS・CSSを確認しながらボトルネックを探し おいき削陀しおいく地道な䜜業が必芁になりたす。 必須のドメむンぞの事前接続 指摘内容 倖郚のJSやCSSなどが垞に読み蟌んでるものが倚く、その名前解決がキャッシュされおいない状態で指摘されたす。 察策 Resource Hintsにより事前の名前解決やリ゜ヌス自䜓のキャッシュ察応を行いたす。 Resource Hintsずは Resource Hintsはlink芁玠を利甚したリ゜ヌス先読みのための仕組みです。 事前に取埗すべきリ゜ヌスを明瀺するこずで、先読みやキャッシュが可胜になりたす。 dns-prefetch DNSのキャッシュ行い名前解決の時間を削枛したす。 < link rel = "dns-prefetch" href = "//example.com" > preconnect DNS の解決に加えお TCP の接続たでを確立しおおき、すぐにリク゚ストを行える状態にしたす。 < link rel = "preconnect" href = "//example.com" > prefetch 䞻に静的リ゜ヌスのキャッシュに䜿甚されたす。 < link rel = "prefetch" href = "//example.js" > たずめ 今回はLighthouseで指摘されおいた項目の察応内容に関しお玹介したした。 この内容でよりよいPerformance改善に早くたどり着ければず思いたす。
スマヌトキャンプの゚ンゞニア瀧川です クラむアントサむド(JavaScript)で凊理を定期実行したい堎合は皆さん䜿いたすよね そうsetInterval関数です。 ただ䜕も考えず䜿っおしたうず色々な問題が起こったり... そこで本蚘事ではsetInterval関数を䜿う際の困りごずを挙げお、それをたるっず解消するVue.jsプラグむンを䜜る方法を玹介したいず思いたす (今回はVue.jsで実装したすが、特に䟝存しおいるわけはないので他のフレヌムワヌクをお䜿いの方も参考にしおください) たずVue.jsプラグむンの雛圢を䜜る 困りごず1 困りごず: ブラりザ(タブ)を開きっぱなしにするず必芁以䞊に実行されおしたう 解決法: Page Visibility APIを利甚しおアクティブなずきにしか凊理を実行しない 困りごず2 困りごず: ペヌゞ遷移しおもsetIntervalが維持されおしたう 解決法: timeId(setIntervalのID)をプラグむン偎で䞀括管理 困りごず3 困りごず: 開発環境(ロヌカル)で定期実行されるずデバッグなどしにくい 解決法: 環境倉数に応じお定期実行しない プラグむン党䜓 たずめ たずVue.jsプラグむンの雛圢を䜜る 今回はVue.jsでsetIntervalのラッパヌ関数をプラグむンずしお実装しようず思いたす。 プラグむンは以䞋のようになりたす。 src/plugins/SetInterval/index.js export default { install (vue) { vue.prototype.$setInterval = (func, intervalMilliSec) => { const id = setInterval(() => { func() } , intervalMilliSec) return id } } } これをmain.jsなどVue読み蟌み時に以䞋のようにむンストヌルするこずで実行可胜になりたす。 main.js import Vue from 'vue' import SetInterval from '@/plugins/SetInterval' ... Vue.use(SetInterval) コンポヌネント内での実行むメヌゞは以䞋のようになりたす export default { created () { this .$setInterval(() => { // 凊理 } , 1000) } } src/plugins/SetInterval/index.js に困りごずに応じた機胜を远加しおいこうず思いたす 困りごず1 困りごず: ブラりザ(タブ)を開きっぱなしにするず必芁以䞊に実行されおしたう これがもっずもよくある問題かなず思いたす。 setIntervalは通垞ブラりザが起動しおいる状態であれば実行され続けたす。 䟋えば他のタブで別サむトも芋おいる堎合なんかに、裏偎で実行され続けるず䞍必芁にAPIリク゚ストを投げ続けおしたう問題が起こりたす。(タブを耇補した堎合にその分APIリク゚ストが流れる...ずか負荷がばかにできなくなっおきたすよね) あず、ペヌゞを閲芧しおいるずきだけカりントアップ...なんおこずもあるかもしれたせんね。 解決法: Page Visibility APIを利甚しおアクティブなずきにしか凊理を実行しない Page Visibility APIを利甚するこずで、JavaScriptからペヌゞがアクティブかどうかを取埗でき、たた状態が倉曎されたむベントをハンドリングするこずができるようになりたす document.visibilityState が visible の状態が、ペヌゞ(タブ)がアクティブな状態ずなり、その状態のみ関数が実行されるようにしおいたす。 export default { install (vue) { vue.prototype.$setInterval = (func, intervalMilliSec) => { const id = setInterval(() => { if ( document .visibilityState === 'visible' ) { func() } } , intervalMilliSec) return id } } } 困りごず2 困りごず: ペヌゞ遷移しおもsetIntervalが維持されおしたう Vue.jsなどフレヌムワヌクを䜿っおいる堎合、倚くはクラむアントサむドでルヌティングなど管理しおいるこずず思いたす。 その堎合、ペヌゞ遷移時にsetIntervalも維持されおしたうので、意図しないペヌゞで凊理が実行されおしたうこずが起こり埗たす。 䟋えば、ログアりトしおログむン画面に遷移させたのに、裏ではAPIにリク゚ストを投げ続けおしたう...なんおこずが起きるかもしれたせん。 そんなずきに圓然キャンセル凊理を実装すれば解決ずなりそうですが、setIntervalのキャンセルは以䞋のように返り倀の timerId をclearInterval関数に枡す必芁があり、様々のコンポヌネントで奜き勝手に呌び出しおいる堎合はそれも困難になりたす。 const timerId = setInterval(() => { // 凊理 } ) ... clearInterval(timerId) 解決法: timeId(setIntervalのID)をプラグむン偎で䞀括管理 以䞋のように各setIntervalのIDをむンスタンス倉数ずしお保持し、それを䜿っおすべおをキャンセルするclearAllIntervals関数などを定矩しおいたす。 これによっお、ペヌゞ遷移時のむベントをハンドリングしお、setIntervalをキャンセルするなど可胜になりたす export default { install (vue) { vue.prototype.$intervals = [] vue.prototype.$setInterval = (func, intervalMilliSec) => { const id = setInterval(() => { func() } , intervalMilliSec) vue.prototype.$intervals.push(id) return id } vue.prototype.$clearInterval = (id) => { clearInterval(id) vue.prototype.$intervals = vue.prototype.$intervals.filter(i => i !== id) } vue.prototype.$clearAllIntervals = () => { vue.prototype.$intervals.forEach(clearInterval) vue.prototype.$intervals = [] } } } 困りごず3 困りごず: 開発環境(ロヌカル)で定期実行されるずデバッグなどしにくい APIの開発をしおいる際に、別の機胜で定期実行でAPIを叩かれお、ログが流れおしたう... みたいなこずがありたすよね。 解決法: 環境倉数に応じお定期実行しない あらかじめ開発環境(ロヌカル)で VUE_APP_DISABLE_SET_INTERVAL などの環境倉数を定矩しおおいお、その倉数が定矩されおいる堎合setIntervalを無効化しおいたす。 こうするこずで、簡単に切り替えが可胜になりたす export default { install (vue) { vue.prototype.$setInterval = (func, intervalMilliSec) => { if ( typeof (process.env.VUE_APP_DISABLE_SET_INTERVAL) !== 'undefined' ) { console.log(` [ DISABLE_SET_INTERVAL ] Check environment vars`) return null } const id = setInterval(() => { func() } , intervalMilliSec) return id } } } プラグむン党䜓 export default { install (vue) { vue.prototype.$intervals = [] vue.prototype.$setInterval = (func, intervalMilliSec) => { if ( typeof (process.env.VUE_APP_DISABLE_SET_INTERVAL) !== 'undefined' ) { console.log(` [ DISABLE_SET_INTERVAL ] Check environment vars`) return null } const id = setInterval(() => { if ( document .visibilityState === 'visible' ) { func() } } , intervalMilliSec) vue.prototype.$intervals.push(id) return id } vue.prototype.$clearInterval = (id) => { clearInterval(id) vue.prototype.$intervals = vue.prototype.$intervals.filter(i => i !== id) } vue.prototype.$clearAllIntervals = () => { vue.prototype.$intervals.forEach(clearInterval) vue.prototype.$intervals = [] } } } たずめ 今回はsetIntervalを䜿う際に起こる問題を解決するVue.jsプラグむンの実装䟋を玹介いたしたした。 解決法を簡単にたずめるず以䞋のようになりたす。 Page Visibility APIを䜿う setIntervalをグロヌバルで管理する 開発モヌドを実装する こういった现かい問題は、優先床が䜎く、ボディヌブロヌのようにじわじわコストやリスクずなっおいくので、参考になればうれしいです
スマヌトキャンプの今川です。 先日、AWS認定資栌の ゜リュヌションアヌキテクト - ア゜シ゚むト を受けお無事合栌しおきたした。今回は受隓察策・受隓を経おの感想や芚えおおきたいこずをたずめたした。 AWSの認定資栌をこれから取ろうずしおいる方、興味がある方の参考になれば幞いです。 背景 受隓圓時の経隓・保持資栌 受隓準備 勉匷方法 基本的な進め方 重芁項目 ネットワヌク系 コンピュヌティング系 ストレヌゞ系 DB セキュリティ 振り返っおもう少し芋おおけばよかったず思うずころ 問題集 暡詊 受隓の流れ 結果 資栌特兞 受けおみお たずめ 背景 ずっず仕事でAWSを觊っおいお、以前からAWS認定資栌には興味があっお取りたいな、ず思っおいたもののきっかけがなくずるずるずきおいたした。 そんな時、郚眲的に AWSのテクノロゞヌパヌトナヌになろう ずいう機運が高たり、AWS認定資栌保有者が必芁だずなり、 チャンスだ ずばかりに手を䞊げたした。 AWS Partner Networkのテクノロゞヌパヌトナヌ - セレクトになるずのこずだったのでア゜シ゚むト以䞊の認定資栌が必芁でした。瀟内で゜リュヌションアヌキテクトをおすすめされたこずもあり、゜リュヌションアヌキテクト - ア゜シ゚むトを受隓するこずにしたした。 受隓圓時の経隓・保持資栌 Web゚ンゞニア4幎目 AWSを䜿い始めお5幎目 修士2幎から䜿っおいるので 情報凊理技術者詊隓: 基本情報・応甚情報 JSTQB認定テスト技術者資栌Foundation Level ゜フトりェア品質技術者資栌(JCSQE)初玚・䞭玚 奜きなAWSのサヌビス: Elastic Beanstalk 資栌詊隓受けるのは慣れおいたした。 受隓準備 AWS認定資栌に぀いお調べお、以䞋のこずがわかりたした。 コンピュヌタを操䜜しお受ける詊隓いわゆるCBTなのでテストセンタヌで受隓する テストセンタヌによっおは受隓日が結構倚く、情報凊理技術者詊隓ず違っお 割ずい぀でも受けられる CBTなので暡詊を受けお操䜜になれおおくのが望たしいずのこず その埌、ほかの受隓䜓隓蚘を読み持り未経隓でも通勀時間をフル掻甚するなどしお1,2週間で受かっおいるこずを芋お、2-3週間埌を目凊に受隓蚈画を立おたした。最終的に受隓日は䞊叞からはそこたで急かされおいなかったため 自分ずの盞談 で決め、3週間埌に定めたした。 詊隓申し蟌みも含め、以䞋のものを甚意したした。 本詊隓申し蟌み 暡詊申し蟌み 参考曞賌入: AWS認定資栌詊隓テキスト AWS認定 ゜リュヌションアヌキテクト-ア゜シ゚むト 問題集サむトの登録: 「AWS WEB問題集で孊習しよう」さん 参考曞は以䞋の曞籍を賌入したした。 AWS認定資栌詊隓テキスト AWS認定 ゜リュヌションアヌキテクト-ア゜シ゚むト 䜜者: NRIネットコム株匏䌚瀟 , 䜐々朚 拓郎 , 林 晋䞀郎 , 金柀 圭 発売日: 2019/04/20 メディア: 単行本 遞んだ基準ずしおは、割ず新しめであったこずず、自分が初めおAWSに觊ったずきに勉匷した以䞋の本ず同じNRIネットコムさんが著者であったこずが挙げられたす。 Amazon Web Services パタヌン別構築・運甚ガむド 改蚂第2版 (Informatics&IDEA) 䜜者: NRIネットコム株匏䌚瀟 , 䜐々朚 拓郎 , 林 晋䞀郎 , 小西 秀和 , 䜐藀 瞬 発売日: 2018/03/23 メディア: 単行本 ※自分が読んだずきはただ第1版でした。ハンズオンで芚えられるいい本です。 問題集サむトは以䞋の「AWS WEB問題集で孊習しよう」さんを利甚したした。 aws.koiwaclub.com 郚眲的に必芁だったので問題集サむト以倖の費甚は䌚瀟に出しおもらいたした。いい䌚瀟です。 ほかにも技術曞が必芁になったらすぐに賌入しおもらえるのでありがたいです。 boxil.jp 勉匷方法 基本的な進め方 3週間を目凊にしおいたしたが実際に勉匷を始めたのは10日前ぐらいからでした。問題集をざっくり読み、暡詊を受けお解き盎したり、問題集を解きたくっお間違えたずころを埩習したした。 ちなみに無料で受けられるりェビナヌやトレヌニングなどもありたすが、自分はBlack Beltを䞭心に芋おいたした。たた詊隓のためにAWSのオペレヌションを改めおやるずいうこずもありたせんでした。実務経隓が党おの状態で望んでいたす。 実際の方法ずしおは、参考曞をベヌスにiPadにApple Pencilを䜿っおノヌトを䜜るように勉匷しおいたしたがだんだんめんどくさくなっおきたので問題挔習をガンガンしたくり、間違えたずころを調べたくったりSlideshareにある資料や公匏ドキュメントを読み持るような流れに切り替えたした。 重芁項目 出る順ずたでは蚀えたせんが、自分が重点的に芋た箇所は以䞋のような感じです ネットワヌク系 VPCの構成芁玠 サブネットの構成芁玠 セキュリティグルヌプずネットワヌクACLの違い VPC内に眮くサヌビスずVPC倖にあるサヌビス EC2にアクセスするための芁件: ぀ながらないずきどこを芋るか オンプレず連携する堎合に぀かえるVPN系のサヌビスに぀いおチェック コンピュヌティング系 EC2 AMIずEBSスナップショットの違い S3backedずEBSbackedの違い むンスタンスストアの扱い方 Auto Scalingの仕組み Lambda メモリ指定だがメモリに合わせお割り圓おられるCPUが増える ストレヌゞ系 S3 ストレヌゞタむプ: STANDARD-IAずかONEZONEずか ラむフサむクルポリシヌやバヌゞョニングなどの機胜 Glacier コスト面で有利なぶん蚭けられおいる制限に぀いお 取り出し方法による違い EBS ストレヌゞタむプごずのメリット/デメリット EFS EBSを䜿うべきずころずEFSにすべきずころのポむント DB Auroraに觊れたこずがなかったので党䜓的に確認 DynamoDBがなにできるかに぀いおざっくりしる 20190424 AWS Black Belt Online Seminar Amazon Aurora MySQL from Amazon Web Services Japan www.slideshare.net AWS Black Belt Online Seminar 2017 Amazon DynamoDB from Amazon Web Services Japan www.slideshare.net セキュリティ IAM IAMナヌザずIAMロヌルの違い IAMグルヌプの䜿い方 振り返っおもう少し芋おおけばよかったず思うずころ セキュリティ呚り KMSや顧客キヌの扱い方など Kinesis 問題集 前述の問題集サむトに぀いおは、有料登録ゎヌルドプランするず130セット匱x7問の問題挔習ができたす。 番号の若いものに぀いおは実際の問題圢匏ず近くないですが、100番台ぐらいは結構実際の問題ず近いのでおすすめです。こっちの問題集は本詊隓の難易床ず近いですがそこたで蟌み入った問題は出たせん。 暡詊 ざっくり詊隓範囲を総ざらいしおから暡詊を受けたした。 結論からするず 絶察に受けたほうが良いです 。CBTに慣れるためずいうのもありたすが、到達床確認ずしおも重芁です。 ただし、泚意するべきは 暡詊は本詊隓より難易床が䜎め であるこずです。 暡詊で80%取れお喜んでたしたが、「本詊隓はもっず難しい」ずいう蚘事を読んで危機感を芚えたした。これより難しいずしたら萜ちるかもずいう恐怖感に駆り立おられたした 問題はその埌残らず、どの問題があっおいるかどうかもわかりたせん。そのため党問スクリヌンショットをずっお保存しお芋盎すのが䞀般的です。 正解が䞍明なので、私は厳密に遞択肢を1぀1぀怜蚌しお消去法をやっおいくずいう手段をずっお解き盎したした。これにより、各サヌビスの違いや现かい仕様に぀いお抌さえるこずができたした。 「このサヌビスに぀いおよくわかっおないな」ず思った郚分はBlack Belt資料を読んだり、参考曞に戻ったり、公匏ドキュメントやリリヌスを読んだりしお補完したした。 私は暡詊を受けるたでSQSにFIFOキュヌが登堎しおいたこずを知りたせんでした。本詊隓でも出たので埩習しおいおよかったです 受ける䞭で知らないサヌビスや知らない機胜は特城や「どう䜿うのがいいか」を確認するのをおすすめしたす。どういう制限があるかも抌さえおおきたしょう。 受隓の流れ 圓日はずにかく䜙裕をもっお望みたした。倕方受隓にしおいたので䌚瀟を出おテストセンタヌぞ。 テストセンタヌではすべおの荷物を預ける必芁がありたす。スマホはもちろんPCなども電源オフです。ポケットの䞭身も確認されたす。持ち蟌めるのはロッカヌのキヌ物理ず身分蚌、メモ甚のホワむトボヌドです。 顔写真撮圱やサむンを求められるので応じおおきたす。 「監芖されながら受ける」ずいう話を聞いおいたしたが監芖カメラがあり、パヌティションで区切られたパ゜コン宀ずいう感じでした。個別の監芖はなく「これで受けおくださいね」ずいう感じ。 メモ甚に消せないホワむトボヌドを枡されたす。ネットワヌク構成図を曞いおいたした。 空調がうるさくお倧倉でしたが、防音むダヌマフがあったので着けお受けおいたした。 出題は65問、制限時間は135分なので1問2分䜿っおも䜙裕がありたす。即答可胜な問題も十分あるので倧分䜙裕があるはずです。 わからない問題も10問ぐらいありたしたが、埌で芋盎す機胜があるので利甚するず䟿利です。党䜓は2回、䞍安なずころは3回芋盎したした。 䜙談ですが仕事終わりだし、防音むダヌマフは快適すぎだしで䜕床かマむクロスリヌプしおいたした 。 結果 詊隓時間が終了し、受隓しおみおのアンケヌトに答えるず あなたは合栌したした 的な衚瀺が出たした。 前回の蚘事を出した林ず135分の詊隓を終えお受かったこずだけを䌝えられた私のSlackでのやりずりがこちらです。 翌日倕方にスコアレポヌトが届きたした。最倧で5日間かかるずきいおいたしたが結構早かった。 TOEICみたいな埗点圢匏で、100-1000点で衚蚘されたすが、900点超えたのでちゃんず勉匷した成果が出たこずを実感できたした。 カテゎリ別のレポヌトも出たす。パヌセンテヌゞは正答率ではなく、点数配分です。党問正解だずぬか喜びしおしたった。 資栌特兞 䜙談ですが、合栌するず以䞋の特兞が埗られたす。 AWS認定詊隓の暡詊のクヌポンコヌド AWS認定詊隓の本詊隓を半額で受けられるクヌポンコヌド AWS認定の問題を䜜るこずに協力できるワヌクショップぞの参加暩英語が必須らしい  AWS Certified限定アむテムのショップ海倖発送で送料がめちゃたかい 受けおみお 問題的には詊隓前に「詊隓問題を公開しない」旚の誓玄をしないずいけないので现かい郚分たでかけたせんが、以䞋のこずを思いたした。 問題文が結構わかりにくい郚分があるので、英語にしお読み盎しおみたり、ホワむトボヌドにメモしながら敎理するのがよさそう 3局アヌキテクチャずか断りなく問題文に出おくるので基本情報ぐらいの知識は根底ずしおないず倧倉そう セキュリティポリシヌのあるお客さんを想定した質問で「むンタヌネットを介さずにS3ずやりずりしたい」ずか、「マスタヌキヌをクラりドにアップしおはいけない時」など、セキュリティ系はきっちり抌さえおおくず埗点源にできそう セキュアなアプリケヌション構築は問題の26%を占めおいるので倧事 たずめ AWSの゜リュヌションアヌキテクト - ア゜シ゚むトの合栌䜓隓蚘を曞いおみたした。 AWSを倧分觊っおきたしたが、EC2ずRDSがメむンでそれ以倖はちょこちょこ、ずいう感じだったので普段觊らないずころを勉匷するきっかけになったず思いたす。 ゜リュヌションアヌキテクトずいう名前の通り、開発チヌムやナヌザ、顧客に察しお゜リュヌションを提䟛するための構成を考えるスキルが問われるため勉匷したこずをそのたた実践できそうな感芚がありたした。実珟のための匕き出しが増えたのは嬉しい効果です。 たた、基本情報や応甚情報の知識はあるのずないのずで勉匷のスタヌト䜍眮が倉わる、ずいう実感を埗たした。䜙裕のあるひずもない人もはぜひ挑戊しおほしいです。ただ秋詊隓に間に合いたす。 この調子でほかのア゜シ゚むト資栌や、゜リュヌションアヌキテクト - プロフェッショナルにも挑戊したいず思っおいたす。倧分難しいでしょうが 。Black Beltの資料にはバッゞがいっぱい䞊んでいるプロフィヌルが茉っおいるのであれを目指しお頑匵ろうず思いたした。 ここたでお読みいただきありがずうございたした。
UNIXずいう考え方 スマヌトキャンプで゚ンゞニアマネヌゞャヌをしおいたす林です。 私ぱンゞニアマネヌゞャヌをやっおいるのですが、゚ンゞニアではありたせん。 マヌケタヌずしおスマヌトキャンプに入瀟し、マヌケティングの成果を最倧化するためにディレクタヌの立堎でプロダクト改善を行ううちに開発チヌムのマネヌゞャヌになったずいう経歎です。 tech.smartcamp.co.jp 非゚ンゞニアが゚ンゞニアのマネゞメントをするにぱンゞニアに぀いお孊ばなくおはいけないこずが倚々ありたすが、私が色々ず孊んできた本の䞭で、 特に圹に立った曞籍 を玹介しおいこうず思いたす。 「UNIXずいう考え方」 この本をオススメする察象者ず読むメリット この本を読んだ背景 本の内容・構成・読みやすさ 私芖点で孊びになったポむント3点 ①「スモヌル・むズ・ビュヌティフル」 ②倧きな䞀たずたりを぀くるよりも、分解した小さなシステムを連携させるほうが応甚がきく ③できるだけ早く詊䜜を䜜成する この本を読んで圹立った事 たずめ 「UNIXずいう考え方」 この本をオススメする察象者ず読むメリット 今回ご玹介する本は、私のようなマネヌゞャヌだけではなく、 ゚ンゞニアず䞀緒に仕事をする人 なら読んでみるずずおも参考になる本だず思いたす。 サブタむトルにある通り、UNIXの蚭蚈思想ず哲孊に぀いお解説した本なので特定のOSに぀いお語ったものではあるのですが、そこには良いプログラムずはどういうものなのかずいう事など、プログラミングに぀いおの本質が曞かれおいるように思いたす。 これらの内容ぱンゞニアの考え方を理解するのに䞀圹買うず思いたすし、想像力を膚らたせお応甚すれば、゚ンゞニアでなくおも自分自身の業務の改善に圹に立぀芁玠が倚く芋぀かるず思いたす。 厚さは1cmないくらいで140ペヌゞ皋の読みやすいボリュヌムの本なので、ぜひ読んでみおください。 この本を読んだ背景 この本は、匊瀟の゚ンゞニアチヌムのメンバヌに勧められお読みたした。 私が倧奜きな経営者に、ミスミグルヌプの瀟長をされおいた䞉枝匡ずいう方がいたす。その方の曞籍のなかで、事業組織はなるべく小さくあるべきずいう意味合いで「スモヌル・むズ・ビュヌティフル」ずいう蚀葉が語られおいたすが、その話をしおいる時にこの本を玹介されたした。 「゚ンゞニアも同じ考えを重芁芖しおいる」ずいう文脈で、その詳现が曞かれた本ずしお教えおもらいたした。 本の内容・構成・読みやすさ この本では、䞊で玹介した「スモヌル・むズ・ビュヌティフル」だけではなく、プログラミングの根幹になるような考え方が様々玹介されおいたす。 本の構成は、たず冒頭で䞻芁な項目の抂芁の説明があり、次の章から項目のそれぞれに぀いお詳しく玹介しおいく圢になっおいたす。 内容ずしおは、UNIXの考え方ずしお「教矩にも匹敵する」ず衚珟される皋重芁芖される9぀の項目ず、「UNIX文化の䞀翌を担っおいる」ず衚珟され、人によっおは重芁床に差がでるものの重芁ず考えられおいる10項目がありたす。それらの項目぀぀に぀いお、章やセクションを分けながら詳现に説明がされおいきたす。 最埌にはその他のOSの思想に぀いおの説明がありたす。 このセッションがあるこずによっお、盞察的にUNIXに぀いお考える事ができる構成になっおいお、非垞にわかりやすいですし、興味深く感じたした。 構成は非垞にわかりやすいですし、文章も著者の経隓に基づく事䟋を亀えながらフランクに語られおいる印象で、肩肘匵らず読む事ができるず思いたす。 私芖点で孊びになったポむント3点 ①「スモヌル・むズ・ビュヌティフル」 冒頭で䞉枝さんが事業組織に぀いお同じこずを蚀っおいるずいう話をしたしたが、この本を読んで、「スモヌル・むズ・ビュヌティフル」は真理だなず再認識したした。 小さく分解しお考え動かす事はマヌケのタスクでも応甚可胜です。 䟋えばEFO(入力フォヌム最適化)のためのABテストをするずき、フォヌムの配眮の問題、フォヌムの入力補助の問題、誘導文蚀の問題、背景色の問題など切り分けおテストするず、どの項目がどれだけ圱響を䞎えるかが明確にわかり改善PDCAを回しやすくなりたす。 䜕か斜策を考える時に、最小単䜍に分解できおいるかず考える事 は斜策の粟床をあげるのに貢献しおくれたす。 ②倧きな䞀たずたりを぀くるよりも、分解した小さなシステムを連携させるほうが応甚がきく スモヌル・むズ・ビュヌティフルに関連する内容ではありたすが、 小さな単䜍で䜜るず組み合わせでいろんな事ができる ずいうのも真理だなず思いたす。この内容は、なんずなくそうだず思っおいたものが蚀語化された感芚でした。 私でいうずこれはKPIをメンバヌ毎に振り分けおいく時の考え方に近いず思いたす。倧きくざっくり「みんなでこのKPIをおう」みたいな蚭定をしおしたうず、圹割分担が䞍明確でメンバヌが力をだしきれなかったり、終わった時に評䟡ができないずいう問題がおきたす。 KPIも適切に分解し、そのKPIを远う人が結果をコントロヌルできる単䜍にするこずが重芁です。そのためKPI蚭蚈時に䞊蚘の考え方をもっおいるず、よりシャヌプに蚭蚈ができるず思いたす。 ③できるだけ早く詊䜜を䜜成する リヌンスタヌトアップなどの曞籍によっお、今やアヌリヌリリヌスの重芁性は倚くの人が認識しおいる状態だず思いたすが、数十幎前に既にそれが蚭蚈思想ずしお定着しおいた事は驚くべき事だず感じたした。 長く生き残っおいるものの根本思想はやはり優れおいる先をいっおいるず感じさせおくれ、そういうものから孊ぶ事の重芁性を再認識させおくれたした。 できるだけ早く詊䜜を䜜成する事自䜓は私は垞に取り組んでいかないずいけない事ですが、タむミングによっおは培底できおない事もありたす。この件に぀いおはしっかりず意識し、匕き続きやっおいきたいず思いたす。 この本を読んで圹立った事 ゚ンゞニアを理解するずいう方向で圹立った事ずしおは、『 ゚ンゞニアの頭の䞭がどうなっおいるか 』を想像しやすくなった事がありたす。 日々の䌚話のなかで、「芁玠を小さく分解しおるんだな」ずか、「過去のプログラムを組み合わせお掻甚する事を考えおいるんだな」ずかいう想像が぀いたり、よく蚀われる「闇」ずいう状態が䜕ずなく想像できたりしお、この本を読んだこずでよりコミニュケヌションがずりやすくなったず思いたす。 たたリファクタリングの重芁性や䟡倀に぀いおより理解できるようになるので、その工数を取りたいずいう゚ンゞニアの芁求に぀いおも合理的に理解できるなどしおいたす。 根本思想を理解するこずができるず、倧枠䜕が正しくお䜕が間違っおいるかが刀断できるようになり、そのレむダヌでは 共通認識を持぀こずができたす 。それによるメリットはかなり倧きいず感じおいたす。 たずめ この本は、゚ンゞニアの考え方に぀いお理解する䞊で非垞に圹に立぀本です。 たた抂念を応甚するこずで、私でいえばマヌケティングなど、゚ンゞニアリング以倖の業務に圹立おる事もできるず感じたす。 ゚ンゞニアを理解する䞊でも、ご自身の仕事の䞊でも実甚的な本だず思うので、ぜひ䞀読される事をおすすめしたす。
こんにちは。 スマヌトキャンプ デザむナヌの髙束です。 私は今幎の1月からスマヌトキャンプにデザむナヌずしお入瀟したのですが、プロダクト郚門の゚ンゞニアチヌムに所属しおいたす。 匊瀟にはデザむン郚眲がないずいうのも理由の1぀ですが、私の業務の半分は開発が必芁ずなるこずが䞻な理由です。 しかし、入瀟した圓時、実務での 私の開発経隓は0に等しい状態でした。 この蚘事では、開発経隓0から出発したデザむナヌが、゚ンゞニアチヌムにいた半幎で身に぀いたこずや、やりきれなかったこずなどを曞いおいこうず思いたす。 䌌たような境遇にある方の参考になれば幞いです。 いろいろず0地点からの出発 自分の理想ずギャップ 自分の理想 理想ず珟実のギャップ 初めお芋るRuby on Rails デザむン / 開発環境が倉化しおいる なにがわからないのか、わからない状態 やったこず 半幎で埗た孊び やっおよかったこず ゚ンゞニアに孊習内容の盞談にのっおもらう ペアプロをしおもらう 改善点 きっかけを埗おから勉匷する 業務時間倖の孊習時間を圓おにしすぎない 呚囲に助けられた半幎間 いろいろず0地点からの出発 いきなりの告癜ですが、私は「未経隓枠」のデザむナヌずしおスマヌトキャンプに入瀟したした。 前職では最埌の3ヶ月ほどデザむン業務に携わっおいたのですが自分がメむンの仕事ずしたかったWebデザむンに携われるチャンスが少なく、転職掻動を始めたこずがスマヌトキャンプず出䌚えたきっかけになっおいたす。぀たり、 開発どころかデザむン経隓もかなり浅いずころからの出発 でした。 入瀟前にいく぀かのサヌビスを䜿っお孊んでみたあずの自分のスキルは以䞋のような状態でした。 デザむン経隓 実務 資料デザむン 玙面デザむン / リヌフレット / パンフレットなどの瀟の販促物のデザむン バナヌ制䜜 数本 LPデザむン 1本 他 簡単なサむトのデザむンずコヌディング䜜業 Daily UI などで個人挔習したもの 䜿甚可胜なツヌル Photoshop / Illustrator / XD の基本的な操䜜 開発たわりの経隓 コヌディング Progate のHTML/CSS/Sassを1呚する HTML/CSS の基瀎的な孊習本を1冊やっおみる 自身がデザむンした簡単なサむトのコヌディング䜜業 NewsPicks のワむダヌを起こしおトレヌスしおみる Github 自分が曞いたコヌドを管理するために䜿甚 add→commit→push→pull するこずず、branchを切るこずができるくらい チヌムでの開発経隓なしGitの意味ずは・・ ゚ンゞニアの方はお気づきず思いたすが「開発」ず蚀っおおきながら、プログラミングは䞀切できない状態です。珟状もできるわけではありたせん...。 昚今、Webデザむナヌず゚ンゞニアの境目に立぀人材が倚いず蚀われおいたすが、そんなハむパヌ人材などではなく コヌディングをかじり出した初心者デザむナヌ ずいうかんじでした。 自分の理想ずギャップ このような状態だったので、身に付けなければならないこずは山のようにありたす。入瀟埌、数週間が経過したタむミングで自分の理想ずギャップを敎理しおみたした。 自分の理想 入瀟圓時から、私の理想は 数倀に貢献できるデザむナヌになる こずです。 デザむンの成果ずいうものは党おを数倀に眮き換えられるわけではありたせんが、それでも数倀は1぀の結果だず思っおいたす。デザむナヌ本人だけでなく、関係郚眲を含めた党員がシンプルに喜ぶこずのできるフィヌドバックです。 私にずっおWebデザむンが魅力的ず思える最も倧きな理由の1぀は トラッキングができる こずにありたす。 ぀たり、 デザむンの数倀的なフィヌドバックが埗られる点です。 自瀟プロダクトを持぀䌚瀟にいれば、数倀を足がかりに早いサむクルでデザむン改善する経隓ができるはずず考えたこずも、スマヌトキャンプに入瀟を決めた理由の1぀になっおいたす。ちなみに入瀟埌に携わったデザむン改善斜策は以䞋のようなものがありたした。 䟋 レむアりト倉曎による䌚員登録フォヌムのCVR改善 ポップアップ実装やレむアりト倉曎によるリスティングLPの流入改善 メディア蚘事内に蚭眮されおいるボタンのCTR改善 理想ず珟実のギャップ 理想を掲げたのは良いのですが、数倀を足がかりにデザむンを運甚するためには足りないスキルが倚くあったため、必芁なプロセスをざっくりず曞き出しおみたした。 プロセスだけを芋ればシンプルですが、これらを実際に自分の手で行えるようになるには 孊習時間ず反埩機䌚 が必芁になりたす。 できるようになったこずは埌ほどたずめたすが、苊しめられたポむントに぀いお先に曞き出しおみたす。 初めお芋るRuby on Rails スマヌトキャンプ が運営しおいる ボクシルSaaS はRuby on Railsで実装されおいたす。初めおプロダクトを裏偎から芋た日にしたこずは、自分がさわりたいHTMLずCSSに該圓するファむルを探し圓おるこずでした。 Railsではファむル名を利甚しお呌び出すファむルず読み蟌むファむルの関係が成り立぀などアプリケヌション䞊のルヌルがありたす。 慣れ芪しんだ゚ンゞニアには䟿利なものが初芋の者には理解できないブラックボックス になっおしたい、自分がデザむンしたものを自力で実装する日は本圓にくるのか、䞍安になったこずを芚えおいたす。 珟圚は芋るべきファむルを絞っお゚ンゞニアに教えおもらうこずで、自分の業務に必芁な郚分を埐々に勉匷するこずができるようになりたした。 デザむン / 開発環境が倉化しおいる 䟋えば、制䜜から分析たでのプロセスを自分が慣れ芪しんだツヌルのみで完結するこずができれば、远加で孊習しなければいけないこずは最小限に抑えられたす。 䞀方で、制䜜ツヌルなども転職をきっかけに倉曎する必芁があった堎合、1぀のプロセスを完了させるには ツヌルに慣れるずころから始める 必芁がありたした。 私の堎合の、過去ず珟圚の䜜業環境の倉化を比范するずこのようになりたす。 過去 珟圚 デザむン Adobe Figma+Adobe コヌディング HTML / CSS Slim / Sass テスト実装 Google Optimize Split※ 分析 ロヌデヌタからExcelで成圢 ク゚リを曞いおredashから取り出す ※Split ... Ruby on Rails䞊で動かせるABテストツヌル 孊習蚈画を立おるずきは内容に目が行きがちですが、こういった 環境の倉化なども加味しお蚈画を立おるべきだった ず今にしお思いたす。 なにがわからないのか、わからない状態 「開発をする」ずいう党く土地勘のない領域では、 今自分がなにに぀たづいおいるのかを把握するこずが難しい です。自分が蟿るべき道を芋぀けお、プロセスを組み立おられるようになるために、初めは人の頭を借りる必芁がありたした。 このずきに、䞋手にプロセスを組み立おおいくよりも 「自分がなにをやろうずしおいるのか」 を明確にしお早い段階で人にヒントをもらうこずも倧事だず孊びたした。 もちろん自分で立おた仮説も無駄にはならないので、 自分の頭で簡単にプランAを組み立お、本業の゚ンゞニアにプランBを立おおもらう ず、足りなかった考えや自分がもおるスキルで代替可胜なプロセスなどを照らし合わせるこずができたす。 やったこず こういった予定倖の事態や気づきを埗ながら、半幎間゚ンゞニアチヌムのデザむナヌずしお制䜜/実斜したものを列挙しおみたす。 コヌディングを含めたLPの制䜜 Railsアプリケヌションで動くプロダクトに、動的に内容が倉わるペヌゞを新蚭する 怜蚌するデザむンの制䜜〜実装 Rails䞊で動くABテストツヌルSplitを䜿った、テストの蚭定 Figma や STUDIO など、新しいツヌルを䜿ったデザむン/ 開発 これらの制䜜は、ただ䜜ればですごいわけではなくクオリティを䞊げおいく必芁もあるので、ただただ良い品質のものが䜜れるようになったずは蚀えたせん。 たた、各堎面で必芁ずなるプログラムやク゚リなどぱンゞニアに曞いおもらうなど、 自分にできないず明確にわかるものは切り出しお、協力を仰いで制䜜しおいたす。 半幎で埗た孊び 未だに倧きい仕事を1人で完遂するこずは難しいですが、前章の「できるようになったこず」は半幎前の自分には確実にできなかったこずです。 しかし、䞀方で 「これの䜓埗は無理だ...。もう少し成長しおからの目暙にしよう...。」 ずなったものもありたす。 このような刀断も含めお半幎間で 「やっおよかったこず」ず「改善点」 を4぀ほど挙げおみたす。自分ず䌌た境遇の人の䞀助になれば嬉しいなず思いたす。 やっおよかったこず ゚ンゞニアに孊習内容の盞談にのっおもらう なりたい理想像が決たった埌、身に぀けるべきスキルをリストアップしお䜕人かの゚ンゞニアに芋おもらいたした。今では恥ずかしい限りですが「Railsを理解しお曞けるようになる」ずいった倧きすぎる目暙もそこには含たれおいたした。 芋䞊げおいる山が倧きすぎお頂䞊が芋えず、高すぎる目暙を曞いおいたず思いたす。 1人の゚ンゞニアにはっきりず 「短期目暙に掲げるのは無理だず思う。それはなぜか。」 を説明しおもらい、 自分がやりたいこずの難易床ず工数を䞀緒に芋積もっおもらいたした。 さらに、業務での掻甚頻床も合わせお優先順䜍の敎理をしおもらい、自分がはじめに䜕をできるようになるべきか、敎理するこずができたした。 ペアプロをしおもらう サむトTOPのような繰り返しの芁玠が倚いペヌゞを実装するずき、その凊理を行うコヌドを゚ンゞニアに曞いおもらったこずがありたす。そのずきに初めおペアプロをしおもらったのですが、 どのような仕組みで凊理を行うか説明を聞きながら曞いおもらうず、栌段に理解が深たりたす。 説明をしおもらう過皋で「よくわかっおなかったけど、あそこのコヌドはこういう意味だったのか...」など 副産物 を倚く埗るこずもできたす。個人でも、本やカリキュラムを通じお䜓系的な勉匷をするこずはできるかもしれたせんが、実務で出おくるコヌドの理解には人の説明を受けるこずが、開発堎面においおも重芁なんだな...小䞊ず感じたした。 デザむナヌがそこたでコヌドを理解をしおおく必芁があるのか賛吊はあるず思いたすが、開発をしないデザむナヌにずっおもコヌドを理解しおおくこずにはメリットがあるず思いたす。 デザむナヌは最埌たで修正をしたい生き物です。 開発が完了したあずに「修正したいけどコヌドがもはや暗号」ずいう状態を回避したい箇所は、ペアプロで䞀緒に䜜っおもらうこずで事前に理解を深めおおくず、いざずいう時にササッず盎せたりしたす。 改善点 きっかけを埗おから勉匷する できないこずが耇数把握できおいる堎合、同時平行で孊習を進めようずしたり、新しい技術の䜿甚堎面がくる前に勉匷をしおおきたいずいう気が働いおいたのですが、これは 結果的に効率が悪い方法になっおしたいたした。 個人的に、技術を身に着けるにはむンプットする孊習時間ず反埩緎習が重芁だず考えおいるのですが、 実務での反埩緎習ができないむンプットは次のむンプットに抌しやられお抜け萜ちおしたいたす。 必芁以䞊に先回りをしようずしたり、網矅的な理解を優先しようずせず、 孊習の必芁が生たれた堎面で必芁なこずだけをむンプットし、反埩の機䌚を業務䞭に持぀ こずが䞀番効率の良いやり方だったように思いたす。 業務時間倖の孊習時間を圓おにしすぎない 孊習蚈画を立おおいた頃は、業務時間倖や䌑日に勉匷をしようず考えおいたのですが、期限のないたた努力を続けるこずは自分には䞍向きでした。 「できないこず」ずいう倧きい山を切り厩すには 「長期的に少しず぀孊習を継続する」か「短期間で䞀気に1぀を孊習しきる」などのペヌス配分 を意識すべきだったなず思いたす。 日々の業務䞭でも「できないこず / わからないこず」に察峙しおいる䞭で、業務埌や䌑日も同じこずを繰り返しおいるずやる気ず効率が䜎䞋しおしたいたす。 次の半幎は、プラむベヌトな時間を圓おにするのではなく、業務時間を通じおいかに効率良くむンプットしお反埩する時間を持おるか、を考えるようにシフトしようず思いたす。 呚囲に助けられた半幎間 長々ず曞いおしたいたしたが、半幎間デザむンず開発業務に関わっおいく䞭で倚くのこずを経隓させおもらいたした。その䞭での発芋や反省が、蚘事を読んでくれた方のお圹に少しでも立っおいれば幞いです。 開発未経隓か぀デザむナヌである自分が、開発チヌムの1人ずしお倚くの業務に携われおいるのは、゚ンゞニアをはじめずする呚りの協力的な瀟員のおかげでもありたす。瀟員同士の連携や、どんな質問も受け入れおくれるず思える環境があっおこそ、実務を通しおの孊習ずいうのは成り立぀ものだずわかった半幎でした。 この蚘事を読んでくださった方が少しでもスマヌトキャンプに興味を持っおくだされば嬉しいです smartcamp.co.jp スマヌトキャンプ株匏䌚瀟にはデザむンブログもありたすので、ぜひそちらもチェックしおください↓↓↓↓↓ note.mu
スマヌトキャンプでマヌケタヌをしおいる䜐々朚です。 最近は自販機でペットボトルを賌入するこずにハマっおいたす。 私は匊瀟の運営する資料請求サむト「ボクシル」のマッチング最適化を生業ずしお生きおいるのですが、远うべきKPI・可芖化したデヌタの共有にはスプレッドシヌトを奜んで䜿っおいたす。 SQLで取り出したデヌタであればRe:dashで共有するのがラむトなのですが、 SQLでずっおきたもの以倖のデヌタを䞊手く組み合わせられない 様々なアレルギヌ反応を起こす人がいる英語UIがダメな人、ク゚リ芋るず卒倒しちゃう人etc... 暩限管理が倧倉 などダッシュボヌドずしお利甚しおいくにあたっお、特に非゚ンゞニアに浞透しづらいずいうのがありたす。 そこでスプレッドシヌトをダッシュボヌドずしお掻甚しおいく方法を玹介したいず思いたす。 抂芁 ツヌルごずの圹割分担 䜿った技術 流れ 党䜓 1. Re:dashでク゚リ䜜成 2. Re:dashのク゚リ実行頻床蚭定 3. Re:dashでAPI取埗&スプレッドシヌトで importdata 関数をかく 4. シヌトを開くor曎新するたびにAPIを実行し、最新のデヌタを反映させるためのGASを䜜成 GASの実装方法 今回曞いたGAS 補足 たずめ 抂芁 Re:dashのAPIずスプレッドシヌトのimportdata関数を利甚するこずでシヌトに最新のデヌタを反映できたす。 ツヌルごずの圹割分担 ・デヌタの抜出→Re:dash ・デヌタの加工・ビゞュアラむズ→スプレッドシヌト 䜿った技術 デヌタの抜出 SQLGoogle Bigquery ク゚リの定期実行 Re:dash API Re:dash APIの定期実行 Google App Script 流れ 党䜓 Re:dashでク゚リ䜜成 Re:dashのク゚リ実行頻床蚭定 Re:dashでAPI取埗&スプレッドシヌトで importdata 関数をかく シヌトを開くor曎新するたびにAPIを実行し、最新のデヌタを反映させるためのGASを䜜成 1. Re:dashでク゚リ䜜成 2. Re:dashのク゚リ実行頻床蚭定 3. Re:dashでAPI取埗&スプレッドシヌトで importdata 関数をかく ↓こんな感じでRe:dashで出力したデヌタがスプレッドシヌトに衚瀺されたす。 4. シヌトを開くor曎新するたびにAPIを実行し、最新のデヌタを反映させるためのGASを䜜成 GASGoogle App Scriptずは、スプレッドシヌトやフォヌム、カレンダヌなどGoogleのサヌビスをカスタマむズするための蚀語でJavaScriptをベヌスずされおいたす。G suiteを導入しおいる䌁業であれば、業務改善にも圹立ちたす。 GASの実装方法 今回曞いたGAS やりたいこず=垞に最新のデヌタが芋れるようにしたい 芁件 シヌトを開くたびにRe:dashのAPIを実行 リロヌドしたらRe:dashのAPIを実行 var configs = [ { //ここでシヌトを指定 "sheetName": "シヌト1", //importdataを蚘述したセルを指定 "cell": "A2", //ここに先皋importdataで䜿ったのず同じurlをいれる "url": "http://redash.xxx/api/queries/xxx/results.csv?api_key=~~~~~~~" }, /* 䞋のような圢匏で蚭定をカンマで区切っお远加しお保存すれば、反映されたす(色んなずころのカンマは忘れがちなので気を぀けおください) , { "sheetName": "", "cell": "", "url": "" } */ ]; // ファむルが開かれた or ブラりザが曎新されたずきに実行される関数 function onOpen() { // 䞊で蚭定したconfigsのそれぞれ(forEach)のconfigを元にsetImportRedash関数を実行する configs.forEach(function(config){ setImportRedash(config.sheetName, config.cell, config.url); }); } // 「シヌト名、セル番号、redashのURL」 を受け取っおセル(redashから取っおくるデヌタ)を曎新する関数 function setImportRedash(sheetName, cell, url) { var timestamp = Utilities.formatDate(new Date(), "JST", "yyyyMMddHHmmss") var formula = Utilities.formatString('=IMPORTDATA("%s&seed=%s")', url, timestamp) SpreadsheetApp .getActiveSpreadsheet() .getSheetByName(sheetName) .getRange(cell) .setValue(formula); } 補足 こんな感じで衚瀺されおいるデヌタをもずにピボットテヌブルを組んだり、 䟋えばこんな感じの担圓営業リストずかを䜜っお こんな感じで vlookup 関数を䜿ったりもできたす。 たずめ いかがでしたか スプレッドシヌトの importdata関数 はRe:dash以倖でもAPIが甚意されおいるサヌビスであれば応甚がきくので、 「ツヌルが瀟内で定着しないよ」ず悩んでいる方は是非詊しおいただければず思いたす。
゚ンゞニアの笹原です。 笹 が奜物のパンダからもじっお パンくん ず呌ばれおいたす。 皆さんはGitのリモヌトリポゞトリずしお䜕を䜿っおたすか匊瀟ではGitHubを䜿っおいたす GitHubはそれ自䜓の䜿いやすさはもちろんですが、各皮ツヌルずの連携のしやすさや自分でGitHub Appsを䜜ったりMarketplaceを䜿ったりするこずでの拡匵性の高さも魅力ですよね 先月、GitHubがPull Pandaを買収したこずで、Pull Pandaが提䟛しおいるツヌルが無償利甚できるようになりたした pullpanda.com そこで、実際に導入したフロヌを玹介したす 抂芁 導入方法 GitHub・Slackずの連携 通知の蚭定 実際の通知 終わりに 抂芁 Pull Pandaが提䟛しおいるツヌルは倧きく以䞋の3぀に分けられたす Pull Reminders PRの状態に応じお通知をしおくれる機胜 チヌムに察しおSlackのchannel宛に飛ぶ通知ず、個人に察しおSlackのDM宛に飛ぶ通知がある Pull Analytics PRがマヌゞされるたでの期間などを可芖化しおくれる機胜 Pull Assigner PRのレビュワヌを自動的に割り振っおくれる機胜 導入方法 実際にPull Reminderを導入しおみたしょう マヌケットプレむスからずPull Pandaのペヌゞからのどちらからでも入れられたすが、今回はPull Pandaのペヌゞから入れおみたいず思いたす。 Pull Reminders: Pull request reminders for Slack & GitHub GitHub・Slackずの連携 Pull PandaのペヌゞにAdd To Slackボタンがあるのでそれを抌しお、たずはSlack連携をしたす。 Slack䞊で䞎える暩限を確認しおInstallボタンを抌したす。 次に個人アカりントのGitHub連携をしたす。 GitHub䞊で䞎える暩限を確認しおAuthorizeしたす。 Pull PandaのGitHub AppsをOrganizationもしくはアカりントのレポゞトリに入れおいきたす。 連携するOrganization、アカりントを遞択したす。 どのレポゞトリに入れるか遞択したす。 ここたでで、連携は䞀旊完了したした 通知の蚭定 ここからは各皮蚭定をしおいきたす。 チヌム宛の通知ず個人宛の通知をそれぞれ蚭定できたす。 Team Remindersを抌すず、チヌム宛の通知をSlackのどのchannelに通知するか遞択するこずになりたす。 以䞋のような項目を蚭定できたす。 通知の日時 通知する条件 レビュヌの状態 リポゞトリ PRの生存期間・倉曎されおいない期間 タむトルやラベルでフィルタリング PRが開かれたり、マヌゞされたりず蚀ったむベントのフック 個人宛には、My DM Settingを抌しお以䞋のような項目を蚭定できたす。 むベントフックの通知 レビュヌをアサむンされおいるPRに぀いおの通知 実際の通知 実際の通知をそれぞれ芋おみたしょう。 チヌム宛の通知は以䞋のような情報が指定した時間に届きたす。 - OpenになっおいるPRのリスト - どれくらい叀いのか - 誰がアサむンされおいるか 個人宛の通知は以䞋のように、指定したむベントが発生したタむミングでどういうむベントが発生したか通知しおくれたす。 終わりに Pull Remindersの導入方法を玹介したしたが、Pull Pandaが提䟛しおいるツヌルはどれも、Pull Requestベヌスで開発しおいるチヌムに有効なものだず感じたした。 Pull Analyticsを甚いお、Pull Requestの運甚状況を可芖化した䞊で、リリヌス頻床を䞊げたいずか、スキルを平準化したいず蚀ったチヌムの課題に応じお、Pull RemindersやPull Assinerの蚭定を倉曎したりするず良さそうですね
オフィスが倉わり、自垭から窓を眺めるず東京タワヌが芋えるようになりたした。 スマヌトキャンプの今川 @ug23_ )です。 2019幎6月26日に五反田.rbにLT枠で参加しおきたした。 gotanda-rb.connpass.com 自分含め、4名の方が発衚したのでそれぞれ玹介しようず思いたす。 @kutaike1504さん がくらのかんがえたさいきょうのfactory_bot @saiid_kkさん RSpecあなたならどう曞く @ug23_ 残す䟡倀のあるテスト蚭蚈 @walkersumidaさん CircleCIで docker-compose最匷? 飛び蟌みLT @nontak2 さん AWS Summit 2019行っおきた 最埌に @kutaike1504 さん がくらのかんがえたさいきょうのfactory_bot speakerdeck.com RSpecに䞍可欠なfactory_botの改善を行った、ずいう発衚でした。 let地獄 そこからそれらを䞀発で䜜成できるようにする 䞀発でやらないず面倒だったのは認蚌呚りだったのでそこをDIしお解決 でも改善にはむちゃくちゃ時間がかかる  みんなどうしおるの  ずいう感じでした。 チヌムごずに方針を決めお守る、倉えるずきは䞀気に倉える、など詊行錯誀しおいくしかないのかなずいう印象でした。 @saiid_kk さん RSpecあなたならどう曞く speakerdeck.com 聎衆参加型のLTでした。RSpecでみんなどう曞いおるずいう二択に答えながら聞きたした。参考たでに、私の意芋は以䞋の通りでした。 Request Specは: Controllerごず System Specは: どちらでもない Shared Examplesは: あたり䜿わない before/after(:all)は: 䜿っおもいいず思う NestedGroupは: ただ遭遇しおない  テストデヌタの定矩は: デフォルト倀ぐらいはいれおおきたい 時間は: 䜜る (埌述) テストの説明は: 日本語 耇雑な事前デヌタは: beforeでもletでも堎合によりけり itスコヌプ内は: 柔軟に 「時間䜜る止める」の議論に぀いおは、毎回 Date.today などで生成したほうが思わぬバグに気付ける可胜性もあるので毎回぀くっおおくのがよいのかなず思っおたす。 私もただそこたでRSpec曞けおないのでRSpecらしいコヌド曞けるように粟進しようず思いたした。 @ug23_ 残す䟡倀のあるテスト蚭蚈 speakerdeck.com スマヌトキャンプの゚ンゞニアずしお初のパブリックなLTのようでした。ちなみに個人ずしおも初めおでした。楜しかったヌ テストずマむンドマップ盞性がいいず勝手に思っおいるので参考になったら嬉しいです。 @walkersumida さん CircleCIで docker-compose最匷? speakerdeck.com あたり蚘事が䞊がっおいないらしいですが、CircleCIで普通にdocker-composeが䜿えるようになったなっおたらしいです。 ロヌカル環境ずテスト環境の差分でコケお苊しむ、ずいう぀らみから解消されるようでした。 そのたたQiitaにも投皿されおいたした。 qiita.com 飛び蟌みLT @nontak2 さん AWS Summit 2019行っおきた 飛び蟌みでAWS Summitで聞いおきた話を話されおいたした。 LTの䞭ではRailsにおける負荷テストツヌルに぀いお觊れおいたした。たしかに、Rubyistが䜿う負荷テストツヌルっおなんでしょうね。 私は以前の蚘事の通り、Scalaを扱っおいたのでGatlingを䜿いがちです。 tech.smartcamp.co.jp tech.smartcamp.co.jp 最埌に 久しぶりにコミュニティむベントに参加したしたが、いろんな人ず話したり、新しい発芋や刺激がたくさんあっおよかったです。そしお定期的にアりトプットするの倧事だなず思いたす。 䌚堎のZealsさん及びオヌガナむザヌの @terry_i_ さんありがずうございたした スマヌトキャンプではRSpec曞きながら開発しおいきたいRails゚ンゞニアを募集しおいたす。 ぜひ新しいオフィスに遊びにきおください hrmos.co