いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
VPoE handbook | エンジニア組織のマネジメントに悩んでいた三年前に戻れるなら渡したい。VPoE handbookを書き終えました (目次&サマリ付)｜Takayuki Shimizu
（この記事はVPoE handbookの目次＆サマリパートです） 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 （この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。） VPoE handbookを書こうと思った理由まずはなぜ書こうと思った？の問題意識から。 この記事にあるように、三
コロナ禍におけるクラシルの役割｜大竹雅登/dely
こんにちは。クラシルを運営するdelyの大竹です。CTO兼、EC事業責任者としてやっています。 皆さんご存知の通り、日本では新型コロナウイルス(以下、コロナ)による健康・経済あらゆるところへの影響が甚大になっています。4月のピーク期は過ぎたとは言え、東京アラートが発令されるなど第二波への警戒も行わないといけない状況が続いています。 コロナの影響で、望むと望まざるに関わらず外出を自粛する生活スタイルに人々はシフトしています。今回は、コロナ禍においてクラシルがどのような社会的役割を担っているのか、ユーザーはどんな行動をしていて、それに対してクラシルはどんな対応をしているのかを紹介しようと思います。 人間のライフラインである食に関わるサービスなので、クラシルが実施する施策の一つ一つが生活に影響しているんだという自負を持って日々開発をしています。その雰囲気を感じていただければ嬉しいです。 ①自炊ニ
「プロダクト間共通の React コンポーネントライブラリ」がどうなったか、という話 - SmartHR Tech Blog
こんにちは！ フロントエンドエンジニアの @diescake です！ 1 年程前に @nabeliwo よりこんな記事を公開しています。 tech.smarthr.jp 一言で要約してしまうと、SmartHR の各種プロダクトで一貫したユーザー体験を提供するために、SmartHR UI という React コンポーネントライブラリを実装し始めたよ！ しかも OSS として公開してるよ！ という話でございました。 github.com 本記事では、それから 1 年弱たった今 SmartHR UI がどうなっているか、という話をしつつ、現在の SmartHR UI の運用・開発体制について話をしてみようと思います。 SmartHR UI は成長しているよ！ 2019/08/01 2020/05/21 バージョン v3.9.2 v8.2.0 コンポーネント数1 30 66 ソースコード規模2 3
経験年数に応じて一般的に求められるスキルが身についてないままソフトウェアエンジニアとして生きている(いた)ことのつらみ｜ぱん
※以下、ソフトウェアエンジニアをエンジニアと省略して書いていることがあります。 プログラミングを仕事にしてから9年だ。いちおう9年ということになる。知り合ったばかりの人に「プログラミング歴何年ですか？」「プログラマー・エンジニアになってから何年ですか？」と聞かれたらこう答えざるを得ない。そしてそう答えると、「え、9年…！ベテランですね…！」と言われる。企業の採用担当（エンジニアの詳しいスキルを測ることがあまり得意ではないと思われる人が多い）からもおそらくそういう目で見られているのだろう。「豊富なスキルをお持ちの方とお見受けいたします。弊社のテックリード/リードエンジニアポジションはいかがですか」みたいな全くマッチしていないスカウトメールが時々来る（だいたいベンチャーで、色んな人に送っているんだろうとは思うけど）。ほんとうにつらい。なぜならわたしのスキルは、周囲にいる他のエンジニアと比較する
とあるUXエンジニアの働き方｜Kenta Murayama
クックパッドのクリエイション開発部の村山です。 2019年11月にクックパッドに入社した2人目のUXエンジニアです。(もう一方は重田( @sagaraya )です) 今回はUXエンジニアってあまり見ることのない職種なので、自分の仕事や職種への考え方を紹介したいと思います。 はじめに自分のことを簡単に紹介します。 一言で言えば「HCD(人間中心設計)を学んでいたエンジニア」です。 仕事はチームや会社で必要なことをやる感じでこなしてきたのでいろいろなことを経験してきました。 - フロントエンド/バックエンド/iOSアプリ - DWH/ETLの保守運用 - ユーザインタビュー設計/実施 - 新規事業の事業責任者 - ベトナムでのオフショア拠点立ち上げサービスに関することを広く、網羅的に携わってきました。そのため、どんな技術で作るかとか手法で作るかとかではなく、「どんなユーザーにどんな価値を届ける
ユーザーファーストであり続けるために開発チームオンボーディング資料を作ってみた｜坪田 朋
※クラシル開発チーム向けの資料を外向けに公開した内容です これから開発メンバーが増えてくるので、カルチャーを言語化してみた。今できている文化もあると思うし、今後の考え方を言語化したモノもある。 これをクラシル開発チームのオンボーディング資料として、継続的にアップデートしていくことにする。 これは何に使うのか・新メンバー向けのカルチャー説明 ・メンバー同士で声を掛け合ってカルチャーを浸透させていく ・採用面接やリファラル採用時の文化説明 作った背景開発部もエンジニア、デザイナーが増えて組織が大きくなってきた。常にユーザーファーストであり続けられるよう今から言語化しておく事にする。 「成長痛」とも言われるが、ベンチャー企業の組織拡大に伴い30 / 50 / 100人の壁が存在していて、組織に歪が生じやすいし、個人で成果を出すのが難しくなってくるタイミングがある。 人が増えていく過程で様々なカル
エンジニアリングとデザインの接点｜FOLIO Backstage
ーー 今回の「バックステージ インタビュー」では、前回に引き続き、フロントエンドエンジニアの大木尊紀さんをお招きしてお話をうかがいたいと思いますが、今日のテーマは、「デザインとエンジニアリング」という視点でお話をうかがいたいと思います。 FOLIOのエンジニアは、デザインチームと近い距離でプロジェクトを進めるという、他社では珍しい手法で開発を行なっていて、これが面白いシナジーを生んでいるよう。 ということで、今回は大木さんに加えて、デザイナーの松岡さんもお呼びして、座談会形式でお届けしたいと思います。 さて、早速ですが、今日はよろしくお願いします。 大木さん、松岡さん（以下、大木、松岡）： こちらこそよろしくお願いします。 デザイナーと近い場所で働くというメリット ーー エンジニアとデザイナーがこういう形でディスカッションをするというのは、なかなか珍しいかもしれませんね。 デザインとエンジ
平成Ruby会議01にフードスポンサーとして参加しました - マチマチ技術ブログ
はじめまして、こんにちは！ マチマチにJoinして2ヶ月の昭和63年平成0年生まれのエンジニア*1 @nappan23 です。 マチマチは、2019/12/14 に行われた平成Ruby会議01に、フードスポンサーとして協賛させていただきました。 heiseirb.github.io マチマチではプロダクトにRuby/Railsを採用していますが、技術イベントへのスポンサーを行ったのは初でした。 これまで、Rubyエンジニア界隈でのマチマチの認知度がいまいちではないかという体感があったので、 入社後ほどなくして、このようなイベントがあるのでスポンサーしてみてはどうかと代表に提案したところ、すぐに「やってみよう！」ということになりました。 スポンサーLT スポンサーLT資料はこちらです。 「マチマチ？知らないよ」という雰囲気になったらと心配になり、緊張して手足も声も震えてしまいましたが、思った
UI改善のためにエンジニアに仕様を構造化してもらったら再設計がめちゃくちゃ捗った話｜鈴木 健一 / PLAID & Ex.STANDARD
この記事はPLAID Advent Calendar 9日目の記事ですUI改善の前提理解、うまくできていますか？皆さんはこれまで着手してこなかった既存画面のデザイン改善をする時、どのように進めているでしょうか。 自分がプレイドで所属しているreBAISUというチームでは、タタキとして定義したスタイルガイドを旧来の画面に適用しながらUI改善する取り組みをしています。 取り組み方として、改善対象となる画面の仕様を理解しながら課題を見つけ、解決策を検討していく流れになるのですが、この仕様理解が難しいと感じていまして。 なんとか前提理解を促せる方法はないものかと検討した結果、対象画面の構成要素をひとつずつ紐解いていく方法で理解していく「デザインの逆行分析」という方法をとっていました。 デザインの逆行分析とは「リバースエンジニアリング」とも呼ばれる手法で、その考えをデザインでも応用しようというもので
デザイナーがエンジニアリングを学ぶメリットとデメリットを整理してみる - Qiita
こんにちは、sKawashima（@_sKawashima）です。 最近、たまに「開発とデザインの両方ができる人材は強い/弱い」みたいな記事を見かける気がします。 実際出来ることが増えることは良いことだとは思いますが、特にデザイナーはそれによって失うこともある気がします。 そんなわけで、「デザイナーがエンジニアリングを学ぶメリットとデメリット」を考えてみました。 少しでも自分が何を学ぶかの参考になれば幸いです。 この記事は「くふうカンパニー Advent Calendar 2019」の3日目です。 https://qiita.com/advent-calendar/2019/kufu この記事は、ルームシェア相手にして普段グラフィックデザイナーやりつつ業務としてUnityなどの開発を経験がある友人との対談を元に執筆しています。 協力ありがとう。 この記事は個人ブログの記事の転載です。 ht
メルペイ VPoE による2019年の振り返り | メルカリエンジニアリング
こんにちはこんにちは。前回のブログでお知らせしたとおり、Merpay Advent Calendar の1日目を、メルペイ VPoE の @hidek がお届けします。 はじめに 2019年もあっという間で、12月を迎えて終わろうとしています。ということで、メルペイとしての2019年を振り返ろうと思います。お題は「何かエモい話」と雑に振られたのですが、2019年に起こったことをなるべく赤裸々に淡々と書いていきます。 メルペイは2018年2月くらいから開発を開始していました。最初からマイクロサービスアーキテクチャの採用、Google Cloud Platform （GCP）を使ったクラウドネイティブな環境、と比較的モダンな思想のもとでの開発を続けています。ちなみに私が参加したのは2018年5月で、2018年中にはすでに決済基盤など大きなところの開発はかなり進んでいる状態でした。が、一方でなか
個人開発のすゝめ 第１回: 個人開発と資本主義
ここ３年以上ずっと個人開発にほとんどの自分の時間を割いていたので、真剣にブログを書くのは仕事含めほぼ2年ぶりですww 僕の考えですが、個人開発の課題の一つが専業として食べていくまでの「登り方のベストプラクティス」が体系化・言語化されていない点だと思っています。 なので、これからいくつかの記事を通して、３年半取り組んできた「個人開発に対する考え」について少しでもその言語化にトライしてみたいと思っています。 個人開発は「現代の自営業」だと、 yarukinai.fm でスガイさんが言ってたけど本当に良い言葉だなぁと思っています。 (八百屋さんのような自営業のように、もっとカジュアルにエンジニアで「個人開発」を専業にする人が増えていくと良いなという意図です) 今回は個人開発が現代の自営業としてなぜ「おすすめ」かというのを資本主義や日本の市場という視点で書いてみたいと思います。 👽 お前誰よ？フ
メドピア株式会社で働いてます
TL;DR株式会社Gunosy → メドピア株式会社※以下ダラダラと書いた雑文。興味ある人だけ読んで。 試用期間が終わってとりあえずはやっていけそうな感じなので、いわゆる在職エントリってやつを書いてみます。 Why 在職エントリ？ある程度様々な経験も積んでシニアレベルのエンジニアとして会社側の期待値も高い中での入社となり、試用期間中は黙ってひたすら期待された成果を出せるように一生懸命働いてました。 また前職はイヤだったから辞めたとかではないので、転職してお互い「あ、なんか違う」となるのがちょっと心配でした（平たくいうと「ビビってた」ということになりますw）。 試用期間を終えてとりあえずはやっていけそうな感じになったので、報告がてら本エントリを書くことにします。 あとはキラキラ希望に満ち溢れた退職エントリや転職エントリ書ける歳でもなくなってきたなーという感じもある。 前職でやってたこと前職は
%25E3%2580%258D%25E3%2581%25A7STORES_jp%25E3%2581%25AB1%25E6%2597%25A5%25E5%2585%25A5%25E7%25A4%25BE%25E4%25BD%2593%25E9%25A8%2593%25E3%2581%2597%25E3%2581%25A6%25E3%2581%258D%25E3%2581%259F)
「Discover hey(入社体験制度)」でSTORES.jpに1日入社体験してきた - lasciva blog
Discovery heyに参加してきたので、感想等をまとめました。 Discovery heyとは Discovery heyとは、heyが行っている、1日体験入社制度です。 詳しくはこちらに記載されている通りです。 note.mu 参加のモチベーション 転職活動の一環で、heyに興味があり、どんな会社なのか知りたかった 自分の働く上での価値観を改めて洗い出したかった Ruby・モール型ECで本業と環境が似ていて、開発環境とかどういう風になっているのか気になった エンジニアチームのリーダーを務めており、他のチームがどういう風に働いてるか知りたかった slack等のコミュニケーションの方法 チーム構成、PMやデザイナーとの距離感、コミュニケーション方法 体験の流れ 申し込み 私のときは、職務履歴書を送っただけで、当日まではオフィスに1度も伺いませんでした。 書類審査が通った旨をメールで連絡
【エンジニア採用】 人事向けエンジニアリング勉強会の資料を公開します！｜中島佑悟
ども、中島（@nakashimayugo）です。 僕の所属するLAPRASではエンジニア採用サービスを展開していて、人事の方から「採用時に技術用語が分からなくて大変！困っている！」というお声をたくさん貰います。 そんな背景から、「"採用用のエンジニアリング知識"って必要なんじゃないか。コードが書けるようになる事ではなく、用語がちゃんと分かるようになることを目指しませんか？」という主旨で、noteを書いたり、プログラミングスクールさん7社と共同セミナーを開催したりしています。 その取り組みの一環で以前『人事エンジニアリング勉強会』を開いたのですが、「当日の資料が欲しい」「社内研修でも使いたい」というお声をとても多くいただきまして、本記事ではその勉強会資料を公開させていただきます。（プレゼン資料だったので諸々調整してしてコンテンツ化しました） この資料だけでエンジニアリング知識が身につくという
プログラミングスクールへの期待と提案について - ペパボテックブログ
CTOのあんちぽです。このエントリでは、昨今隆盛しているプログラミングスクールに対して期待していることと提案について、エンジニア採用を担当する者として述べたいと思います。 このエントリの前提としての私の考え まずCTOとして、プログラミング教育全般に対する私（およびペパボとして）の考え方を述べます。我々は「いるだけで成長できる環境」を謳い、エンジニア教育に熱心に取り組んでいる企業であると自負しています（少なくとも相対的には）。また、インターネット産業の担い手として、この業界に多くの方がエンジニアとして活躍の場を見いだせることを心から願っていますし、微力ながら貢献してもいると思っています。 そのような我々ですので、昨今のプログラミングスクールの隆盛について、非常に好ましく思っています。特に私のような世代は、見様見真似で必死にやってきてなんとかいまがあるという感じでプログラマになりましたが、昨
みんなのコードを退職し、起業しました。｜アイヴィーさやか
自己紹介初めましての人もいると思うので、改めて自己紹介。 アイヴィーです！もともと大阪出身で、経歴はTV制作会社->ニート->グローバルNPO立ち上げ->みんなのコード->起業（今回伝えること）です。 みんなのコードは小学校プログラミング教育必修化にむけて、学校の先生の支援をしているNPOです。 約3年働いて、様々な経験をさせてもらい、2019年8月31日をもしまして独立いたしました。 IT業界のジェンダーギャップを埋めるために、女子中高生にプログラミングやスタートアップ体験ができるプログラムを提供していきます。 最後の「お願い」のところにご協力いただきたいことがあるので、ぜひそちらもご確認お願いしますm みんなのコードに入社した理由一番詳しく理由を書いた記事は下記になります。 端的にいうと、大学卒業後に就活失敗して、自分が働きたい企業がないなら起業しかないと思ったものの、実際やってみると
STEM女子を増やしたい私が、結局エンジニアを選ばなかった話。｜ぷろとん
こんにちは。ぷろとんです。 コンピュータサイエンスを勉強している修士一年で、STEM(特にcomputer science)学生の女子率をあげたいなーってここ数年ずっと考えています。 それなのに、わたしはエンジニアにはなりません。 悩んで悩み抜いて決めたことなので全く後悔していないです！ でも、今までGoogleSTEPやWomenTechMakers Scholarship, セキュキャン, CTFforGirls...などなど、engineeringを学ぶ機会をたくさんいただいているのにエンジニアにならないことにちょっとだけ負い目を感じています(勝手に)。 だから、今日はその話をしようと思います。 あくまでも私の話なので、良い悪いではなく、なるほどこんな選択をした人もいるんだな〜って思ってもらえたら嬉しいです。 エンジニアを選ばなかった理由結局は私がエンジニアに向いていなかったんだろう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
強いエンジニアという灯
