実装を引き受ける前に詰めておくべきWebフロントエンドの想定漏れチェックシート - Qiita
リキッドレイアウトのように幅が常に変動するレイアウトのデザインは、動かないカンプからは実際の挙動が読み取れず、デザイナーの意図が汲み取りきれないことが多い。また、複雑化するアニメーションの実装においても、カンプだけではコミュニケーションに不備が生まれてしまう。ほかにも、CMSを使った案件ではデザインカンプと実際のデータの間に齟齬がある可能性もある。 実装効率を高めてスケジュール通りに仕事を終わらせるには、とにかく事前に仕様を固めることが大事だ。ワイヤーフレームやデザインの途中の段階からなるべくデザイナーとコミュニケーションを重ね、想定外の要件が発生しないように気をつけるべきだろう。 この記事では、デザイナーやフロントエンドエンジニアが見落としがちなWebフロントエンドの課題について列挙していく。 ホバー表現を後から指示される ツッコミ 後から仕様追加されると困るから先に決めて! メモ 最近
Timely、個人もチームの時間も記録できる時間トラッキングサービス
日中にどんな作業を、どれだけの時間おこなっていたのかを自動的に記録する時間トラッキングサービスには、いくつかの定番があります。 パソコン上のすべての作業をアプリ別、アクセスしているURL別に自動的にモニターしている Rescue Time。設定したプロジェクトに何分従事したかを簡単にメモすることができる Toggl などです。 しかし、これらのサービスはスマートフォンがここまで主流になる以前に開発されたという事情もあって、少し現状に合わなくなってきている部分もあります。 そこで最近注目しているのが、Timelyという、RescueTimeとTogglを足し合わせたようなサービスです。ここに、最近発表された Memory という機能が加わって、スマートフォンとパソコンからの全方位のトラッキングがぐっと現実味を帯びてきます。 Timelyの考え方 Timelyは、記録を取りたいと思っているプロ
理想の開発チームに近づくために、この半年間チームとして取り組んだこと | CreativeStyle
この記事は Recruit Engineers Advent Calendar 2016 の23日目の記事です。 昨日はneko-nekoさんの「Terraformで始めるRolling deployment」でした。いやー、うちも試したい！ はじめに 2016年6月から11月末まで、とあるWebアプリケーション（以降、プロダクトA）の再構築プロジェクトに参画してました。（今も同じチームでエンハンス開発してます） 再構築の目的は、今後プロダクトAを事業としてさらにスケールさせるために、障壁となるシステム課題を解決・改善すること。 この記事では、再構築プロジェクトを進めながら、その後を見据えた理想の開発チームに少しでも近づくために、チームとして約半年間取り組んだことについて、ざっくり紹介してみようと思います。 なお、アーキテクチャや設計に関することは、話せば長くなるのでこの記事では言及しませ
WEBエンジニアがプロダクト開発を通じて学んだチームビルディングに関する5つのTIPS
インタ ーネットの世紀のプロダクト ・マネジャーの役割は 、最高のプロダクトの設計、エンジニアリング、開発を担う人々とともに働くことだ — 『How Google Works』 本記事は Livesenseその3 Advent Calendar 2016 の24日目の記事です。いきなり格好つけた言葉から入ってしまいましたが、クリスマスイブなので。同様に以下ポエミーかつエモ目の記事となります、ご容赦ください。 私は転職会議というWEBサービスの開発に携わっており、2年ほど前から開発チーム（エンジニア/デザイナ/ディレクタの混成チーム）のマネージャーとしてプロダクトオーナー（PLは持たない）兼エンジニアマネージャーのような仕事をしてきました（最近では二足のワラジに限界を感じてプロダクトマネージメントのみに集中していますが）。 本記事では、プロダクト開発に携わってきた中で、グロースに繋がったと思
デザイン思考は強いチームを築く
デザイン思考はイノベーションを促進するだけではなく、共通のボキャブラリー、生成物、信頼にもとづいたチーム文化を生み出すことで、チームを強くしてくれるのだ。 Design Thinking Builds Strong Teams by Sarah Gibbons on September 18, 2016 日本語版2016年12月19日公開 どんな企業も1人の能力だけで成功することは不可能だ。成功している職場のベースになっているのはチームなのである。しかし、チームでの作業にはかなり大きなコストがかかる。共通の知識や前提、ボキャブラリー、文化といった、メンバー同士の共通の土台を築くのに時間を費やさなければならないからである。強いチームというのは共通の土台がすでにできあがっているので、コラボレーションによってもたらされるメリットがコミュニケーションのオーバーヘッドを上回る。その結果、こうしたチー
フロントエンドエンジニアがサーバーサイドエンジニアとペアを組む話 - Qiita
この記事は freee Engineers Advent Calendar の1日目です。 こんにちは。freee株式会社でフロントエンドエンジニアをしている @ymrl です。freeeでは給与計算freeeの開発をしています。 僕はフロントエンドエンジニアを名乗っていますが、実際はサーバーサイドの開発もしています（freeeではフロントエンドとサーバーサイドの担当に線引きをしていません）。しかし自分としてはフロントエンドのほうが得意だし、UIを作るのが心底楽しいし、サーバーサイドに比較的苦手意識を持っています。 今日はそういう状態の僕が、どういうふうに開発しているかという話をします。 技術に自信がないのでペアを組んだ 給与計算freeeの開発チームでは、ひとつの機能を開発するときに エンジニアのペア制 というのをとっています。 かつて僕が給与計算freeeのチームに異動してすぐの頃、僕
「作ったものをユーザーに届けるまでがデザイナーの責任」クックパッド池田拓司さん
毎日の献立を考えなければならない生活者の悩みを解消してくれる、日本最大のレシピサービス「クックパッド」。サービス開始から約20年。その間、急激な成長を遂げきた同社で投稿開発部長を務めているのが、デザイナーの池田拓司さん。時代とともに変化するデザイナーの役割と必要なスキルとは？ エンジニアに認めてもらうために身につけた実装のスキル ——池田さんの経歴とクックパッドに入社された経緯を教えてください。 もともとパソコン通信をしていたこともあり、多摩美術大学在学時のアルバイトがきっかけで、インターネットの世界に足を踏み入れました。どちらかというとコンテンツやサービスに興味があったので、卒業後はニフティに入社。ポータルサイトと有料課金コンテンツの制作ディレクションをしていました。 ニフティに3年あまり勤めたところで、ブログやAdsenseなどが登場してきました。技術を自分の身につけないとこの先やって
マイクロサービスで不可欠、作業効率化ツールを使い倒せ
システムを「小さく」作る設計手法であるマイクロサービスを企業システム分野で採用する機運が高まっている。前回（業務分野でマイクロサービス採用の機運高まる、狙いは「変更の速さ」）は、マイクロサービスの利点と課題を中心に解説した。 マイクロサービスを採用すると、システム変更の影響が小さくなり、改修しやすくなるメリットが得られる一方、小さなアプリ（サービス）の集まりとしてシステムを実現するので、そのぶん運用の手間がかかる。 業務システムをマイクロサービス型で実現する場合は、運用を効率化するためにツールを使い倒す姿勢が欠かせない。今回は、作業効率化ツールと使い方を中心に見ていく。 CIツールは「共有」が前提 作業効率化ツールとして、まずCI（継続的インテグレーション）ツールが挙げられる。CIはアプリの構築とテストを繰り返す開発手法のことで、CIツールはこれらの作業を自動化するものだ。OSS（オープン
管理下にないウェブサイトを適切に改修するために - クックパッド開発者ブログ
株式会社トクバイの根岸です。みなさん、SSSランキングの調子はどうでしょうか。僕は今朝家を出たときには766位でした。一睡もしてません。 さて、今回もブラウザ拡張を作ったよという話です。"外部サイト向けバナー・リンク"という、我々の管理下にないウェブサイトに設置するウィジェットなどの管理・改修をどのように行っているのかについて書きました。 外部サイト向けバナー・リンクについて トクバイが運営しているクックパッド特売情報は、今日のチラシが見られる、お買い物をするひとたちのためのサイトです。閲覧できるチラシ情報自体は、基本的にはスーパーの店員さんによって管理がされています。 では店員さんがなぜチラシをアップロードするのかというと、単純な観点でものを言えば、販促のためです。 それでは、なぜ、販促ができるのかというと、様々な認知・再訪チャネルがクックパッド特売情報には存在し、お買い物をするひとたち
サービス成功のためにチーム開発でエンジニアができること - オールアバウトTech Blog
こんにちは、オールアバウトの筋トレエンジニア芸人の@musclemikiyaです。 普段はCafeSnapというiOS/Andorid向けのネイティブアプリの開発を行っています。 このアプリは大手チェーン以外の個性光るオシャレカフェの情報が満載なアプリですので、ぜひ使ってみてください。 さて、今回はサービスの成功可能性を高めるために、エンジニアがどのようにサービス開発に関わっていくかです。 エンジニアのサービスへの関わり方は様々だと思いますが、今回はよりサービス運営に近い立場のエンジニア（チーム）を想定しています。 ※チームの規模やフェーズによって当てはまらないこともあるので、一意見として参考にしていただければと思います。 コードを書く時間の最大化 ≠ サービスの成功 サービス開発をする上でエンジニアの重要な役割は、コードを書いて機能を実装することだと思います。 そう考えると、コードを書く
協働のためのデザイン思考の再構築 : could
2016年9月3日HTML5 Conference 2016が開催されました。1,200 人を超える参加者。6トラック同時進行という巨大イベント。どちらかと言えばエンジニア向けのセッションが多いイベントですが、そういう場だからこそ「ぜひ話したい」と思えたところがあります。 今回「協働のためのデザイン思考の再構築」という題名で話しました。以前からエンジニアとデザイナーとの間をどう繋げるかという課題について話したいという欲求がありました。ただ、こういうトピックはデザイナーばかりの場で話すのは意味ないですし、逆もしかりです。HTML5 Conference 2016 は、デザイントラックもあったことから、両方へリーチするには好都合。幸いエンジニアの方も私のセッションに参加していただいたみたいで、非常に嬉しかったです。 デザインシステムの課題 私は HTML, CSS, JavaScript は書
フロントエンド<チーム開発 />成功の裏話 - の裏話
フロントエンド 成功の裏話 - の裏話 2016 / 08 / 15 カテゴリ event JavaScript CSS フロントエンド 株式会社ビズリーチ HRMOS[ハーモス] 事業部の馬場（ @kyoyababa - Github ）です。2016年7月27日に、弊社で開催いたしました、「 フロントエンド 成功の裏話 」にご参加・ご聴講いただいた皆様、ありがとうございました。 この記事では、当該イベントの振り返り && 後日談 && 補足説明となる「フロントエンド 成功の裏話 - の裏話 」をご紹介いたします。 円滑なチーム開発のための、明文化された == ドキュメント化されたルール 「HRMOS[ハーモス] 採用管理」の画面 戦略人事クラウド と銘打って「人事から経営を変える」ことを標榜している「HRMOS[ハーモス] 採用管理（以下、「HRMOS」）」では、講演でご紹介した通り、
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
開発速度を上げるための Pull-Request のつくり方 - クックパッド開発者ブログ
こんにちは、投稿開発部の森川 (@morishin127) です。クックパッド、お料理アルバム、みんなのお弁当の iOS アプリの開発等に携わっています。 クックパッドでの開発は GitHub Enterprise 上で行われており、書いたコードをプロダクトに取り込む前には基本的に第三者のコードレビューが必須です。コードレビューはプロダクトの品質向上に貢献していますが、往々にして結構な時間と労力がかかるものです。Pull-Request を出してレビューをしてもらい指摘の修正を繰り返していると、場合によってはマージに数日〜1週間ほどかかってしまうこともあります。自分の開発速度を速めるため、また周りのエンジニアの開発速度を下げないためにレビューしやすい Pull-Request を出すことは重要です。この記事ではレビューしやすい Pull-Request のために心がけていることを紹介したい
言われたことをやらないエンジニアになるために - クラウドワークス エンジニアブログ
はじめまして。今年の4月にクラウドワークスに入社した新卒エンジニアの戸口（@Dooor）です。自分が初の新卒エンジニアなので、周りのエンジニアが全員中途で入社された方々という贅沢な環境で開発しています。 新卒が1人しかいないのもあって、周りのエンジニアをよく観察してみたりするのですが、言われたこと（だけ*1）をやらないエンジニアが多い印象を受けます。そもそもあれをやれ、これをやれ、と言っている人もいないです。 そんな環境なので「指示は特に出さない」とよく言われます。 配属後すぐに「思っているより放置されると思うよ」とか言われたりします。 昔から言われたことはしっかりできる（と思っている）僕ですが、言われたこと（だけ）をやらないエンジニアになるためにやっていることをお話します。 入社3ヶ月後に起きたこと 突然ですが、何で言われたこと（だけ）をやらないエンジニアになろうと思ったのか。 入社3ヶ
チーム開発で暗黙的に行なわれている批評というプロセス - snoozer05's blog
Pull Request を通して行うコミュニケーションに「レビュー」という言葉がつくことに違和感を感じるときがあります。 Wikipediaでコードレビューを引くと、「見過ごされた誤りを検出・修正することを目的として体系的な検査（査読）を行う作業 」とあります。もちろん、これを目的として行うやり取りもあるのですが、その手前の「コードや設計について議論し、もっと良い判断を探る」ために行うコミュニケーションもあると思います。むしろ、そちらのコミュニケーションをやりやすいことが、Pull Request というプラットフォームが提供する価値なのではと感じることが多いのが、違和感の元かもしれません。 2015年6月に O'Reilly から出版された「Discussing Design: Improving Communication and Collaboration through Crit
“いい内製化”のためのチーム作り--ビジネス強者のエンジニアが育つわけ - ZDNet Japan
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ビズリーチで取締役を務める竹内真です。現在、200人近いエンジニアやデザイナーを抱えるビズリーチでは、数々の事業をゼロベースから内製で作り、スケールさせてきました。2009年に即戦力人材と企業をつなぐ転職サイト「ビズリーチ」をはじめてから、「キャリアトレック」、地図で仕事が探せるアプリ「スタンバイ」、先日は戦略人事クラウド「HRMOS（ハーモス）」をリリースし、約7年でHR×テクノロジ領域を中心に7つ以上のインターネットサービスを立ち上げてきました。 これら全て、自社のエンジニアやデザイナーらの力を結集して作り上げたものです。 前回で、内製化を進めるにあたって、私たちが取り組んできた人事評価制度やオフィス環境についてお話しましたが、今回
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日経電子版アプリ 穴のあいたバケツ開発
iOS複数人で開発する時にこれだけはやっておけ - Qiita
少数精鋭で効率的によりよいサービスをつくるには / designer x engineer
