開発者達によるブログですこの広告は、90日以上更新していないブログに表示しています。Organizationへ移行しましたご覧いただきありがとうございます。今後はQiitaへ記事を作成していきます。qiita.com今後ともよろしくお願い申し上げます。Partnersでエンジニアをしております小貫です。先日、開発チームで1dayの合宿を敢行しました。合宿になると、環境を変えて、やりたいことに集中できるので定期的に開催するといいですよね。今回の1day合宿では、来期戦略の発表・議論と来期取り組みたいアクションについて実際に手を動かしてみるということをしました。今回1dayの合宿を実施した理由は、以下の2つです。チームのビジョンと役割を再確認したい来期の改善アクションを決めたい今回はサーバーサイド・フロントエンドチーム、インフラチーム、デザイナーチームにチーム分けし、それぞれが持つ課題やそれに対する改善アクションを合宿前にまずは議論し、実際の合宿日にはチーム内で決まった改善アクションを共有する場としました。以下が、今回の1day合宿のスケジュールです。古田より、主に開発チーム全体の来期戦略についての発表を行いました。現状、開発チームには以下の課題が存在しており、来期戦略にてこれらを払拭していきたいと考えています。■見積もりや実装が効率悪い■リリースの半分が計画より遅れている■開発フローで手戻りが発生しやすい■影響範囲考慮漏れによる想定外の不具合が多い■セキュリティリスクを抱え過ぎているのではないか■属人化した運用、自動化できていない作業これらの課題感を払拭するために、来期はどのような戦略で取り組んでいくのかという話があり、それについてしばらく全体で議論や質疑応答の時間を取りました。古田より来期戦略の共有があった後は、各チームがそれぞれの課題感、発表を行い、それに対し質疑応答という流れで進めていきました。サーバーサイド・フロントエンドチーム、インフラチーム、デザインチームの順番で、各チームが持つ課題、そして来期どのようなアクションを取ることで、現状の課題を解決していくのかについて話をしました。僕がなかでも印象に残ったのは、インフラチームの発表にあがった「インフラのビジネスに対する影響度」の話です。インフラを安定して稼働させることが非常に重要であるということを改めて再認識しました。今回の1day合宿では、実際に手を動かしてみることで、来期取り組みたいアクションの規模感や手を動かしたからこそ分かる問題の把握にトライしていきました。各チームが、来期アクションと照らし合わせて、もくもくする内容を発表し、お昼休憩に入ります。お昼はやっぱりバーガーもくもくタイムに入る前に、休憩も兼ねてランチをすることに。ランチはもちろんハンバーガーです。Partnersの開発チームでは、もくもく会をするときには、なぜかハンバーガーをみんなで食べるという習慣があります。みなさん久しぶりのハンバーガーにご満悦です。タイムへハンバーガーを食べ終えた後には、みんな各自で決めた課題にもくもくと作業に入ります。皆さん集中モード!!今回の1day合宿では4時間ほどのもくもくタイムを設けましたが、実際に動くものなどを開発する際には、もう少し時間をとったほうが良いと思いました。最後にはもくもく会でやったことを各チームで発表し、終了です。合宿には打ち上げがつきものですよね。1日頭を使って、取り組んだ僕らはお腹ペコペコです。そんな僕らはみんなでカニを食べに行きました。美味しそうなカニを目の前にご機嫌な皆さん。するというスタイルもかなり有意義だと感じました。考えるだけでは、実際に取り組んだ時の規模感などを把握しづらいです。それらを把握できるのは、やはり手を動かしたからこそだと思います。今回の1day合宿で決定したことや、新たに判明した課題は、後日再度議論し、来期どのような戦略で戦っていくのかを決めていきたいです。最後に最後までお読みいただきありがとうございます。Engineering)的な取り組みこんにちは。エンジニアの古田です。ポケgoをいまだに続けてます。今週初めてEXレイドに当選しましたが、人が集まらず倒せませんでした。qiita.com表題にある通り弊社でもSRE的なものへの取り組みが動き始めました。その経緯と、どうやって進めているかについて紹介させていただきます。SREとは最初はGoogleが提唱した考え方ですが、日本でも既にメルカリやfreeeなど導入企業が増えています。そのため少しググれば様々な情報がありますし、オライリーからも書籍が出ています。原点は「信頼性はあらゆるプロダクトの基本的な機能である」という考え方にあり、この運用チームが考慮することはインフラに留まらずソフトウェア領域へのアプローチや不要な手作業の自動化まで含まれます。ベンチャーの多くが、今後も使われるか分からない機能やソースコードのメンテナンスよりもスピードを優先してサービスを構築していきます。生き残り、3年ほど運用を続けた頃から技術的負債との付き合いが始まります。Googleは、信頼性を担保するために専属のチームを作りリソースを確保して可用性を向上していくという方針を取り入れました。やるの?弊社が運営するReluxというサービスは2013年にローンチしたサービスです。この4,5年の間、スピードを重視しながら様々なチャレンジもしてきました。その結果、会員数が100万人を突破するまでに成長することが出来ました。ここまで来るために、開発もスピード重視で進んできました。体制もシステムの内側もなかなかにカオスな状態です。これに対する打ち手として、先日弊社の鈴木が書いたブログにある通り、ここ1、2年で体制を改善してきたことで新しい負債は抑制されてきています。その他にも、月に1日だけ開発者の判断でやりたいことに取り組むCLEARという日を導入しました。日々の開発タスクではなかなか優先度が上がらない『重要だけど緊急度が低いタスク』に取り組む時間です。今まで15回ほど開催し、多くの改善が生まれ一定の成果を上げています。1日ではシステム設計を根本から見直すといった打ち手は実行できず、大きくなった負債の元本まで返済するには至らずでした。そんな中で引き続き、会員登録が出来ない・予約に失敗する・メールが届かない、といった致命的な不具合もちょこちょこ起きてしまっています。いったエラーは0にすべき。これだけ多くの方に使っていただけるサービスになりましたので、これからは今で蓄積されてきた負債を減らしたりうまく付き合いながら信頼されるサービスにしていくことが必要です。いうことで、一定の成長を遂げたベンチャーでは運用保守への重要性が高まってくるため、このタイミングでやり方を変えていきます。Locoの違うところSREの考え方では本来、専門のチームを組成します。DevチームとSREチームの意見を合わせるためにエラーバジェットという考え方が提唱されています。バジェットを使い切るまでは通常通り開発し、使い切ってしまった場合には開発を止めるというやり方で、バッファを明確にすることでどの程度開発側の無理を許容するかを事前に合意を取るものです。今回の取り組み、Locoでは別チームは作りません。一定の工数を意図的に確保するだけです。現状でも運用はみんなでやっています。上記のような認識合わせが必要なのは、立場の違いによる利害関係の不一致です。自分が開発し、それを自分で保守メンテするとなれば、認識を合わせる必要がないのでエラーバジェットは必要ないと考えています。チーム人数は十数名とまだ少なく、話し合いながら全員の認識を合わせることが可能なのでSRE領域のwhyとwhatを全員で認識合わせて一緒に目指します。人も固定化せず、アクションに対して得意な人がリードしていきます。どんなことに取り組んでくか以下のようなことをやっていけたらなーと考えています。リファクタリングReluxでは4つのシステムが動いています。ユーザーが使ういわゆるRelux本体(アプリ用API含む)外部パートナーと連携するためのAPI施設様が使うシステム社内オペレーションのためのシステム現在は、いずれもCakePHP2系で動いており、一部の共通機能をLaravel5.4で内部APIとして実装しています。この中でも特にCakePHP側のソースコードには技術的負債が蓄積されています。スピードを重視したためにコピペコードが散見されるだとか、フロントエンドでも不要ファイルや処理の読み込みが残っており、不具合や表示速度低下を招くといったリスクを抱えています。この状態を打破するために、根幹のアーキテクチャーを見直していく予定です。具体的には、改めて現在の機能をオブジェクト思考で綺麗に設計した上でLaravel部分へ徐々に移行していきます。検索や施設情報の参照といった機能は同じような動作となるので共通化していきます。現在はNewrelic,CloudWatchを活用し、通知はSlackへ流しています。Newrelicで無料の機能がいくつかなくなり、今後もどうなっていくのか不明なのでこの機会に別のツールも検討します。インフラ、DBのメンテナンススロークエリも放置すると障害の温床となります。今までは問題が起きてから見ることが多かったのですが、時間を確保して継続監視していきたいと考えています。スケールアップを省力化したり、プロビジョニングツールを導入したりと管理負荷を下げるといったことも検討しています。トイルの撲滅SREでトイルというのは『プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向をもつもの』だそうです。弊社でもデータ変更作業をエンジニアが手動でやっているところや、キャンペーンやランキングなど定型開発を自動化できそうです。ゴールの設定リファクタリングに関しては、最終的にどんなシステム全体像になるかをチームで話し合って決めました。あと足りないのは具体的な進め方とスケジュールです。それ以外の打ち手も含めてSLO(サービスレベル目標)がまだ決まっていません。この辺りは合宿などを行い話し合います。みんなで意見をぶつけてチームが納得感を持って取り組むことを大事にして、Reluxの信頼性を高めていきます。備忘録こんにちわ、デザイナーの唐橋です。Qiita5日目の記事です。備忘録のために、Sketchの便利なショートカットをメモしておきます。よかったら参考にしてください。新しくSketchファイルを作成できます。新規作成したファイルには、あらかじめページ1つ存在していますが、ページを追加できます。新規作成したファイルにはアートボードは存在しません。ショートカット後、右側にアートボードのリストがでるので、希望のサイズをクリックしましょう。シェイブを作成する【R/O/U/L】シェイプをつくるときに使用します。R→短形(Rectangele)O→円形(Oval)U→角丸の短形(Rounded)L→線(Line)テキストを作成する【T】テキストを入力できます。オブジェクトの操作オブジェクトの全選択【command+A】ページ内にあるすべてのオブジェクトを選択できます。全てのアートボードを選択できます。書き出しや、背景色の一括設定に便利です。オブジェクトの操作オブジェクトの全選択【command+A】ページ内にあるすべてのオブジェクトを選択できます。全てのアートボードを選択できます。書き出しや、背景色の一括設定に便利です。選択したオブジェクト、アートボードの位置を移動できます。選択したオブジェクト、アートボードのサイズを変更できます。複数選択したオブジェクトをグループ化できます。Shiftをおすと、グループ化を解除できます。マージン【option】オブジェクトが選択された状態でoptionを押すおt、他のオブジェクトやアートボードとのマージンが表示されます。名前を変更する【command+R】レイヤーの名前を変更できます。レイヤーの表示/非表示を切り替える【shift+command+H】レイヤーにカーソルを合わせると、右にレイヤーの表示切り替えアイコンが出力します。アートボードやレイヤーを検索する【command+F】レイヤーリストの下部に検索ボックスが出現して検索できます。Rulers【control+R】ルーラーの表示/非表示を切り替えられます。格子線の表示/非表示を切り替えられます。Layout【control+L】レイアウトグッリドの表示/非表示を切り替えられます。Settings...」をクリックして、グリッドの細かい設定することができます。基本的なショートカットではありますが、これだけ覚えておけば随分の作業のスピードがあがると思います。お役になれば嬉しい限りでございます。