エンジニアに求められるソフトスキルって何だろう｜nacam403
「ソフトスキル」っていうの、ありますよね。明確な定義や定量化をしやすいハードスキルに対して、定義しにくい定性的なスキルのことです。ソフトウェアのエンジニアでいうと、特定のプログラミング言語やフレームワークに関する技術力や専門性はハードスキルと言えそうです。 ハードスキルはもちろん重要です。エンジニアならコードが書けることは大前提でしょう。そして、ソフトスキルもまた重要です。良いエンジニアって、コードを書くのも上手ですが、それ以外のことも上手だったりしませんか？エンジニアが組織の中で、成果をあげる、信頼を得る、そして何より楽しく働き続けるためには、ソフトスキルも伸ばす必要があるはずです。 でもソフトスキルって結局何なのか、どうやって伸ばすのか、今ひとつ分かりませんよね。今回はいくつかの記事に分けながら、自分なりの言語化を試みていきます。 最初にざっくり大分類してみた + 1まずは大分類を挙げ
プロダクトマネージャーが意識したい8つのスキルとPM組織の編成｜ぶんた｜大枝史典
この記事は仕事の幅が広いPMにとって、よく分かりにくい大事なスキルをハードとソフトにカテゴライズし、個人としてまたは組織としての強みや弱みを分かりやすくするために書いてみました。 （こんな方におすすめの記事） ・PMとしてどういうスキルが必要か、また伸ばせばいいのかわからない ・プロダクト組織をどう編成していったらいいかわからない ・PMの採用基準が分からない どうも、ぶんたです。（@bunbuno0） 音声プラットフォームのプロダクトを作っているVoicyでPMチームのマネジメントとプロダクトマネージャーをやっています。 https://voicy.jp/Voicyでは毎週誰かがnoteを公開しているので、是非こちらもチェックしてみてください！ 今回は自分自身がPMであり、またPMメンバーのキャリアや組織について考えることも多く、PMがどうあるべきかというのは悩ましいなあと思っていたりす
半年でテック組織が10倍に成長、VPoEの役割とEMとの違い｜MIDAS Technology Review
背景コロナ禍を契機として、様々な企業でDX（Digital Transformation）の推進が求められています。そのため、エンジニアの需要がますます増加傾向にあり、それに伴って重要性が高まっているのが「エンジニア組織作り」です。近年では、多くの企業でこの課題を解決していくためにVPoE（Vice President of Engineering）を設置しています。 私は、これまでにスタートアップ企業における10名程度のチームのマネージャーや、大企業におけるテックリード兼チームリーダーとして5年ほどEM（Engineering Manager）を経験してきました。そして、現在はVPoEとしてエンジニア組織作りに取り組んでいます。本記事では、これまでの経験を元に、VPoEの役割についてEMやCTO（Chief Technology Officer）との違いをお話しします。 荒井 勇輔（@a
プロダクトマネージャーの最低限の3つの業務【業務フォーマット付き】｜Hiroki Shigemura
1万文字オーバーの記事のため、要点だけお読みになりたい方は、一番最初の「プロダクトマネージャー役割と業務内容」というチャプターをお読みください。 はじめに昨今ではプロダクトマネジメントの教科書といえるような本や記事が増えています。しかし、そういった記事にいいねを推しつつも、こんな事を思ったことありませんか？ 「プロダクトマネージャーの仕事多すぎる。。。」 そう感じられているプロダクトマネージャーの方は多いのではないでしょうか。（もちろん自分もその1人です。） そして、プロダクトマネージャーの採用活動を進めるとこの事実にも気付きます。 「教科書通りのプロダクトマネジメントを実践している人はいない。」 「面接でここまで広範囲の業務能力を評価しきれない。」 そのような事を感じた事のある方向けに、プロダクトマネージャーとして最低限果たすべき3つの業務を提言したいと思います。 私は、GENDAという
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
React部分導入時の開発・検証環境紹介｜食べログ フロントエンドエンジニアブログ
この記事は食べログアドベントカレンダー2020の1日目の記事です。 2020年も残り1ヶ月になりました。早いものですね。 この記事を執筆するのは、食べログでフロントエンドチームに所属する@hagevvashiです。 はじめに食べログではRuby on Rails(以下RoR)を用いており、サイトの大部分がRoRによってHTMLのレンダリングまで行われています。JavaScriptでの実装はほとんどがjQueryなどを用いた非宣言的なものとなっています。 歴史あるサービスなので、それなりにコード量が増えかつ複雑になっています。例えば既存のjQueryやBackbone.jsで書かれたソースコードを変更するのに予想外のコストを強いられたりします。 食べログを引き続きユーザにとって価値のあるサービスにするためには、いち早く新しい機能を届ける必要があります。そして、そういった予想外のコストを少しで
スタートアップから10年、ZOZOテクノロジーズを退職します｜あらら
2021年9月30日をもって、ZOZOテクノロジーズを退職します。元々はVASILYというスタートアップに勤めており、途中スタートトゥデイ（現ZOZO）によるM&Aがありました。吸収合併という形でVASILYが解散してZOZOテクノロジーズになったので、通年で10年勤めた会社を辞めることになります。ヤフーを辞めてスタートアップに入り、上場を目指していたところ、個人的にライバル視していたZOZOによる買収。そのZOZOがヤフーに買収される、という中々面白い10年でした。流石に10年となると感慨深いので退職エントリを書いてみます。めちゃくちゃ長くなってしまいましたが、暇つぶしにお読みください。 大手のヤフーを辞めてスタートアップのVASILYへ入社した動機 2011年の東日本大震災が人生を考え直すきっかけでした。世の中が混乱していたので目先の安定を取るという考えもありましたが、いつ何が起こるか
ソフトウェアエンジニア採用で技術面接をやめました｜sys1yagi
こんにちは、Ubie(ユビー)株式会社でソフトウェアエンジニアとして働いている八木(@sys1yagi)です。 ソフトウェアエンジニア採用といえば技術面接ですよね。技術的な経験に関するインタビューや、コーディングテスト、技術課題の提出、ライブコーディングなどを行い、候補者の経験や技術力、技術の方向性やキャリア観などが自社とマッチするかを確認するというのが一般的かと思います。 Ubieでは、このような形式の技術面接をやめることにしました。自社とマッチするという点にフォーカスしたとき、これまでの技術的な経験や技術的な方向性は、Ubieで働く上でそこまで大きく関係してこないということがわかったからです。 技術的な詳細よりも、事業をつくることの経験や考え方を知りたい Ubieには２つの組織があります。Ubie DiscoveryとUbie Customer Scienceです。私が属しているUbi
Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
VPoE handbook | エンジニア組織のマネジメントに悩んでいた三年前に戻れるなら渡したい。VPoE handbookを書き終えました (目次&サマリ付)｜Takayuki Shimizu
（この記事はVPoE handbookの目次＆サマリパートです） 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 （この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。） VPoE handbookを書こうと思った理由まずはなぜ書こうと思った？の問題意識から。 この記事にあるように、三
さよならアーキテクチャ議論｜Seiji Takahashi@ベースマキナ
ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん
視座の可視化｜kgmyshin
視座が高いってそもそもなんやねん問題 1on1で「視座を上げてほしい」って言われたり、マネージャー陣の集まりで「視座高い人がいいよね」って会話をしたりするけど、じゃぁ「視座の高いってなんぞ？」「どう見極めればええのん？」ってなりますよね。 自分も前職でエンジニアリングマネージャーしてた頃から、現職にて横断組織の一環として採用にかかわるようになって良くそれらのセリフを聞いております。 で、これが正解ってわけじゃないんですけど、自分はいつもこんな感じで可視化してますよってのを紹介してみます。 「視座が高い」を端的に言うと 自分は「視座」ってのは一言でいうと「どのレベルの課題まで、当事者でいられるか」っていうスタンスの度合いだと解釈しています。 ここで言っているレベルというのは難易度ではなく対象のスコープのことです。個人の課題なのか、チームの課題なのか、はたまた所属する会社の課題なのか。 で、「
エムスリー（MR君）で学んだ成長する事業を創るときに大事なこと｜鵜野幸太／GMOVP
僕は、前職、エムスリーで製薬企業向けのマーケティング支援事業（主にMR君）を担当していました。 当時は毎日の業務に精一杯で、なかなか気が付かなかったのですが、ベンチャーキャピタリストになってから、「MR君」を通じて、事業をスケールさせるために大事なことを学んでいたのだなと感じることが増えました。 そこで、特に大事だと思っている下記の4つを、「MR君」の事例でお話できればと思います。 1．市場選定：変化が生じている大きな市場を選ぶ 2．初期導入：適切なコンセプトを設定し、そのコンセプトに合う提供価値を実現し、プライシングする 3．継続利用：サービスを利用した効果（顧客のROI）を見える化する 4．顧客の拡大：サービスの提供価値を変化させ、ターゲット顧客を広げる ※なお僕のエムスリー在籍期間は2012年10月～2017年3月であり、現在のMR君の状況を記載するものではありません。 まず初めに、
チームが強くなるマニュアルの作り方：大事なポイントは2つだけ｜tebiki ブログ
新人教育／通常オペレーション／イレギュラー対応などのマニュアルの作り方について、「チーム作り」という人事の視点を交えて、弊社で大切にしていることをご紹介します。 弊社が提供している「現場向け動画教育システム tebiki」の重要な機能の一つはマニュアル作成で、まさにこの記事で書いたエッセンスを活かしてプロダクト開発しています。 ※tebikiは動画がメインで、現場が苦労してテキストで作っていたマニュアルを動画に置き換えるサービスです。弊社の社内マニュアルは、UIの参考にしたいこともあって、Googleドキュメント、esa、そしてもちろんtebikiの3種類を使い分けています。 本記事のスクショはすべてGoogleドキュメント。 ( 貴山 @tkiyama ) 「マニュアル」とは 一般にマニュアルというと、電気製品の取扱説明書みたいなものをイメージする人が多いと思いますが、弊社では、基本方針
エンジニア採用でやってはいけないこと/やっていること｜rapmaster1218
エンジニア採用自体は2012年頃からやっていて2013年は自チームの採用責任者をやったらスタートアップ2社でエンジニア採用の責任者をやってきました。 色々と面談をやってきて1つわかったことは面談もスキルでエンジニアとして優秀でも面談が得意とは限らないことです。 なので、面談も数をこなしてその分、振り返りをすればスキルとして身につくものだと考えています。 長年採用周りをやってきた中で見えてきたやってはいけないこととやっていることをまとめました。 やってはいけないこと人がいないからといって妥協して採用する 私も採用をやり始めた当初は結構、これをやってしまっていました。 目の前にプロジェクトがあって人がいない状況だと焦ってしまいこの人と働きたいなと思えてなくても妥協して採用してしまうことをやってしまいました。 結果、良いチームの中に1人だけ能力が追いついてない人材が入りチームが崩壊するという事が
noteという都市国家について｜深津 貴之 (fladdict)
noteもいよいよ5周年。自分の中でのnoteの設計観や、抱負などについて。 僕がnoteのお手伝いを始めたのが、2017の10月。あれからちょうど1年半。カイゼンチームの設立や、みんなの頑張り、日経さんとの提携など、色々な変化がありました。ありがたいことに、MAUは5倍ぐらい成長しています。 サービスの成長はとてもよいことですが、ちょっと急成長しすぎなのも事実。うかれすぎず、油断せず、堅実にバランスをとっていく…そんな1年にしたいと思います。 5周年目に取り組むべき課題noteにとって、これから特に重要となるのは、成長と健全さのバランスをとっていくことでしょう。 自分はnoteのサービス施策は、「都市国家」をメタファーにしながら考えています。そういった視点で考えると、noteはこの急成長成長に伴い、これからドイツの移民問題、あるいは中国の都心部への出稼ぎ問題に近い現象と、向き合っていくこ
JeSUと賞金問題について(2019/9/20更新)｜勇利(Yuri)｜note
※訂正、お詫び、補足等の記事を追加しています。 こちらから先に読んで頂きたいと思います。 ※訂正に伴い本記事の内容も追記、更新しています。(2019/9/20) 今問題として議論のただ中にあるのがJeSUのライセンス問題だ。 事件の概要を簡単にまとめると、TGSの大会で“ももち”というプロゲーマーが優勝した。しかし彼がJeSUの発行するプロライセンスを持っていないという理由で賞金が減額されたというもの。 ※彼はライセンスの取得を拒否している 理由はこちらから確認出来ます↓ https://s.gamespark.jp/article/2017/12/21/77541.amp.html?amp=twitter&__twitter_impression=trueこの事実が広まり、今現在もTwitterではトレンド1位にJeSUがランクインするほどの炎上状態にある。 今回はJeSUのライセンス制
初めてマーケに携わるなら、こんな感じで学んでいけばよさそう（4STEP+心得2つ）｜りょん
凡人の凡人による凡人のための 僕は何者でもありません。誰もが知っている企業のエース社員でもなければ、スタートアップの起業家でもありません。 この時点で読む気が失せた方は多いかと思うので、期待に沿えなかったことを謝罪いたします、申し訳ございません。 とは思いつつもこのnoteを書いている理由は、初めてマーケティングの職に携わることになったとき、何をどうすればいいかさっぱり分からず不安になった過去があるからです。 とりあえず本を読んでみたり、著名人の記事を読んでみたりしました。よく分かりません。内容は分かったけど、「で、どう仕事に活かすの？」「いや、理屈は分かるけど凡人の僕には不可能や」みたいなことが多く起こりました。 あれ、意外とマーケ初心者は困るのでは？ 「この1冊だけ見ればいい」「この記事さえ読めばいい」といった教材は割と存在する一方で、マーケターの学び方についてのコンテンツは意外と少な
採用ブランディングで考えるべき12のステップ｜野崎耕司
トラックレコードの野崎です。 下のツイートを以前出したら、ちょっと反応いただけたので、この「憧れ」をつくるための段取りを言語化してみました。 これまでのDeNAやMERYの時にブランディングをしていた時の知見を基にしたフレームワークになってます。 記入項目、記入例を記した作業用のスプレッドシートを有料でお渡しします。詳細は最下部に記載しております。 全部で12ステップあるけど、これで大体できるはず１）まずは採用ペルソナ書く ２）その人が企業にもとめているものを書き出しましょう *汎用的に活用できる例を記載してます。 ３）次に各要素に対しての評価をします。 まずは、そのペルソナの人の現職満足度を判定します。 ４）次にその人が「これがあったら応募する」ものを判定します。 ５）次にその人が「これがあったら応募しない」を判定します。 ６）そして自社の実態を評価します ７）同様に採用競合となる企業の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「シン・エヴァンゲリオン劇場版:||」についての雑感（今日における虚構の価値について）｜宇野常寛
