前提として、私は営業組織でも開発組織でも働いた経験があります。 営業組織で学んだこと私は新卒でリクルートに入社し、キャリアの最初は「カーセンサー」という中古車メディア(当時からWEBが中心)の広告営業でした。 新規顧客開拓では都内の中古車店にひたすら飛び込む中で辛い経験も味わいながらも、噂に聞いていたリクルートの営業部隊を現場で体感できたのは非常に学びが多かったです。 私が働いていた当時、大規模な顧客向けシステムのリプレイスがありました。当時はシステムのことなど何もわからず、営業の立場として聞いたときには、「なんでこれまで慣れてきた画面を変えるんだ!」と思いましたし、リリース後にバグがあると「なんでこんな品質のものを開発部隊は当たり前に提供するんだ!」と激怒していたものです。「せっかく俺たちが(売上を)作っているのに・・・」と飲みながら話すことがよくありました。 何よりも、今動いているシス
はじめに 研究開発第二部リードセキュリティエンジニアの一瀬です。セキュリティエンジニア同士の会話では、「"シサ"が最近またレポート出していて…」とか「"アイピーエー"から注意喚起出てたね」といった、初学者には謎の単語がたくさん出てきます。本記事では、そういった会話に出てくる単語のうち、国内外のセキュリティ関連の主な組織についてまとめました。セキュリティに興味があれば、ここに挙げた組織と、その組織が関わる政策や活動について、事前に抑えておいて損はありません。これからセキュリティを学ぼうという方の参考になれば幸いです。 なお、記載した情報はすべて執筆時点 (2023 年 6 月) のものです。 【2023/06/30 追記】NISC および ENISA の日本語名称を修正、CISA の読み方について修正・追記、NCSC について追記しました。 はじめに 中央省庁 内閣サイバーセキュリティセンタ
こんにちは、ログラスの布川です。 メディアにもスタートアップ関連の記事が最近増えていますね。良くも悪くも、スタートアップという存在が大きくなってきており、世間から注目を集める存在になりつつあることを感じます。 今回は、マネーフォワードCEO・辻さんの記事を引用して、スタートアップが採用基準を下げるとはどういうことか?について記述します。 想定読者スタートアップ転職希望者 スタートアップ経営者 スタートアップマネージャー・人事スタートアップの採用基準はどのように決まるか?大企業と比較すると、スタートアップの採用基準は独特になることが多いです。人数が少ないことから、特定のミッションに向けて阿吽の呼吸でも理解しあえる状態を作ることがマネジメントコストを引き下げ、本質的な課題解決に向かう土壌を作ることができます。 採用基準の設定には明らかな答えがある訳ではありませんが、私が複数のスタートアップとデ
こんにちは。ユーザープラットフォーム開発本部(UP部)の原です。 あなたのチームの雑談チャンネルは1日あたり何回ぐらい発言がありますか? 小さい仲良しチームなら頻繁に発言があるかもしれませんが20人,30人あたりになってくるとだんだん発言が少なくなってきますよね。 チームメンバーのエンゲージメントや生産性を高めるためには少なくともお互いがどんな人なのかを知っているようにしておくべきです。 JMDCは数百人いる組織だし、私の所属するUP部だけでも20名以上の社員が所属しており、しかもほぼ全員リモートで仕事をしている状況なので、いかに "チームメンバーがお互いにどんな人なのかを知っている状態" を作り出すかが課題になっています。 GitLabのリモートワークガイド参考にする 自らを “A world leader in remote work” と呼んでいるGitLabも雑談を重要なものと捉え
はじめに 2020年の1月から執行役員CTOに就任し、そこから数年間「CTOの役割は何か」を自問自答してきました。 就任当初から「CTOの役割とは、経営とソフトウェアエンジニアリングを接続することである」という考えはありましたが、上手く言語化できずにいました。 最近になってようやく他者へ説明できるレベルまで言語化できるようになったので、現時点での考えを残しておきたいと思い、4年ぶり(!)にブログを更新する1ことにしました。 本ブログポストの要旨 筆者の考えるCTOの役割は、「ソフトウェアエンジニアリング組織の日々の活動が企業価値の向上に繋がっている状態を作ること」です。 企業価値の向上のためにソフトウェアエンジニアリング組織が行うべき取り組みは、コーポレートファイナンスの視点を導入することで論理的に導けます。 そして、ソフトウェアエンジニアリング組織の日々の活動がこれらの取り組みに自然と向
この記事を読んだ。 note.com よーある話だなと思いつつ、「業務委託はダメで、社員ならOK」という話はちょっと話が雑だなあと思ったので、コメントを書く。 スクラムチームで人の出入りが激しいとキツイ これはそう。 ただ、スクラムかによらず、出入りが激しいとキツイけど… 業務委託では、高パフォーマンス人材は単価つり上げがきつく、結果契約打ち切りになる 実際の事象としてはよくある話。ただし、業務委託のみの話ではなくて、社員でも「会社に不満があったからやめた」は良くある話。 たぶん、ここが気になるのは、このあたりの違いだとは思う。 報酬の見直し頻度 社員だと給与体系の見直しが年1回であるのが普通 業務委託だと契約期間ごと(業界慣習的に3カ月単位が多い認識) 条件交渉者が本人なのか営業なのかの違い 営業の仕事は売上を上げることなので、当然ガンガン言ってくる 対して社員が自分の雇用条件について、
エンジニアのタイプは、技術が好きか、プロダクトが好きか、組織が好きかの3つに大きく分類できる。技術の人は技術の本質を追求しテックリード/アーキテクト、プロダクトの人は技術を手段と割り切りフルスタックエンジニア/PdM、組織の人は開発生産性を高めようとEM/PMOを目指すことが多い — 山本 正喜 / Chatwork CEO (@cwmasaki) February 9, 2022 思っていた以上の反響をいただいて、いろいろと「このケースはどうなんだろ」というコメントも多数いただくので、この分類にいたった背景や考察などを、しっかり記事にしてみようと思います。140文字だと伝えきれない・・! エンジニアとしての志向性を技術・プロダクト・組織のどれが好きかで分類すると、目指すキャリアパスを考えやすいよねという話で、私がよくエンジニアの若手に話している内容をツイートしたものでした。 3つのタイプ
市場規模1兆円を超えるリユース市場において、業界の覇者として躍進を続けてきたメルカリ。「新たな価値を生みだす世界的なマーケットプレイスを創る」という揺るぎないミッションを掲げる同社は、今年で創業9年を迎える。そんな彼らが次のステージとして見据えるのは、世界に引けをとらない「グローバルテックカンパニー」の地位だ。本特集では、進化を続けるメルカリの現在地と未来をお届けする 2022年1月1日、株式会社メルカリの国内事業を統括するメルカリジャパンのトップが交代。2018年から3年にわたりCEOを務めた田面木宏尚氏から、CPO兼Analytics担当の執行役員を務めてきたJeff LeBeau(ジェフ・ルボー)氏に引き継がれた。 リユース市場を独自に切り開き、創業から9年で急成長を遂げてきたメルカリだが、同社の目線はまだはるか先にある。Jeff氏が見据えるのは「真のグローバルテックカンパニー」。世
CTOアドベントカレンダー2021の12日目の記事です。 今の時代、様々な組織の情報透明性が上がっています。 有名スタートアップが自社のエンジニア組織についてメディアで発信している情報を見たり、流行りの本でGAFA・米国ユニコーン企業のエンジニア組織で採用されている最新の概念を勉強したりできます。 しかし成功している素晴らしい会社の話を聞いていると、どうしてもそれが唯一の正解だと思ってしまいがちなので、注意が必要です。 それらは成功して大きくなった後の組織の話であり、またブランディングとして良い側面だけをクローズアップして拡散しています。 そしてタイトルの通り、事業内容により必要なエンジニア組織は大きく異なります。 成長途上のスタートアップでは名もなき戦略を自分達でゼロベースで考えながら、それを泥臭く改善していく必要があります。 具体的に、事業内容によって必要なエンジニア組織が変わるとはど
ストックマークの開発体制は、プロダクトの成長フェーズに合わせて、2021年夏に大きく進化しています。本エントリでは、何が課題でどう進化したのか?を紹介いたします。本エントリを読むことで、スタートアップの開発体制で発生する課題と、その解決方法の1つを理解できます。 サマリ開発チームのパフォーマンスが最大化できていなかった開発チームに自由と責任を委譲し、より自律的な行動を促進したスクラムを辞めて、カンバンを主軸とする開発へその結果、開発スピードが大きく向上し、より迅速にアウトカムを提供できるようにどんな課題が存在していたのか?大きく分けて、開発チームに関する2つの課題が存在していました。 課題1: リソースの偏りストックマークの以前の開発体制(〜2021年8月)では、Anewsの開発チームは大きく分けて、 以下の2つが存在していました。 情報収集機能を開発するチームコミュニケーション機能を開発
はじめに この半年くらいで初めて本格的にチーム開発を行い、今では日常的に GitHub の Pull Request を使っています。 チームの方々には、基本的なことから応用的な部分まで様々な観点からレビューをしてもらって、大いに勉強になりました。 ただ、時には「新人にとっては厳しいレビュー」をいただき、1 人で傷つきモチベーションを落とすこともありました。 もちろんそれは悪意のあるものではなくて、新人とレビュワーのスキルのギャップによって意図せず生み出されてしまうものです。 そのような不幸なレビューによって苦しむ新人が減ることを願って、新人を不用意に傷つけてしまう恐れのあるレビューをまとめていきたいと思います。 新人教育の場に少しでも役に立てていただけると嬉しいです。 前提条件 今回の対象とする「新人」は、本格的な開発経験が1年未満の方を想定しています。 個人で少しプログラミングはしてき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く