そんな目標を掲げて、日本CTO協会内に「テックブランディング」ワーキンググループが発足したのは、2021年の秋頃でした。 そこから半年強。協会外の企業様の力も借りてアンケートや分析を行い、2022年5月に発表したのが「エンジニアが選ぶ開発者体験が良いイメージのある企業ランキング30」です。 そしてこの度、先のアンケート結果を更に分析して概要をまとめた「開発者体験ブランド力調査レポート2022」を発表。加えて法人会員様には限定で「上位30社の個別詳細レポート」を公開しました。 これまで「DX Criteria（※1）」などを通して、各社の“実態”を調査・分析してきたCTO協会が、新たに外からの目線ともいえる“ブランディング”に注目する理由とは。ワーキンググループの理事である今村さん（株式会社BuySell Technologies 取締役CTO）と、広木さん（株式会社レクター 代表取締役）に

こんにちは！株式会社フォトラクションでCREグループのリーダーをしています脇田慎平です！ Photoruction Advent Calendar 2021の5日目の記事です。 フォトラクションのCREチームがどんなことをやっているか、紹介します！ CREとは？ Customer Reliability Engineering（顧客信頼性エンジニアリング）の略で、2016年にGoogleが提唱した専門職です。 日本でCREを組織として持っている会社だと、メルカリさんやはてなさん、アンドパッドさんなどが有名でしょうか。 CREはまだ歴史が浅く、会社によってもCREの定義・役割は様々なようです。 フォトラクションは、2021年1月にCREチームを発足しました。 開発チームが抱えていた課題 CREチーム発足以前のフォトラクションにおける開発組織の喫緊の課題として、「緊急性の高いバグ対応により、新

何かを伝えたり聞いたりする時には本人と直接話す方がよい。当たり前っちゃ当たり前なのだが、意外とうまくできていないことも多いので最近特に強く意識するようにしている。 「どうなってるか分からなくてモヤモヤする」とか「あの発言や行動ってどういう意図なんだろう」とか、内に籠もって想像だけしているとロクなことがない。直接本人と話してみると実は何の問題もなかったなんてこともある。 ただ、直接話すのは簡単なようで難しい。話す側は感情のコントロールと言語化のスキルが要求される。聞く側のスタンスも重要で、これは話す側はコントロールできない領域なのでより難易度が上がる。話す側聞く側どちらかに負荷が偏ると相手のコミュニケーション能力のせいにして余計にめんどくさいことになってしまう。組織においては、直接話して物事を解決すること自体を推奨するといった工夫が必要かもしれない。また、ある程度はスキルトレーニングもあった

はじめに ペイトナーのエンジニアの井齊です。 みなさんはシステムのテストをどのように行っていますか？ バックエンドであれば、PHPunit, RSpec, JUnitなど フロントエンドであればJestなどで行われているかと思います。 弊社のペイトナーファクタリングのシステムではバックエンドはRailsでRSpecを使っており、フロントエンドのテストとして自動E2E(End to End)テストツールである「Autify」を使っています。 paytner.co.jp 今回はその一環として、フロントエンドのテストとして導入した「Autify」についての感想や良かった点、課題などを伝えたいと思います。 結論 直感的でわかりやすい！！ AutifyのHPでも、 ノーコードと簡単な操作でスムーズにテスト作成 と紹介されておりますが、ぽちぽち画面の要素を押すだけという"簡単な操作"で、直感的にE2E

Railsの学習をサポートする書籍です。難易度としては、Railsの基礎であるCRUDの動作を解説した「Railsの教科書」(https://tatsu-zine.com/books/rails-textbook)を終え、「Railsガイド」(https://railsguides.jp)をおおよそ学んだあとに読んでいただくことを想定しています。「パーフェクトRails」(https://gihyo.jp/book/2020/978-4-297-11462-6)に掲載されている基礎レベル文章程度の難易度にできればと考えています。

ペイトナーでエンジニアをやっている脇田慎平（@shimpeee_）です！ 僕が入社した2022年5月からチーム内でペアプロ導入を提案し、実際にこれまで何度か実施して得た経験や気づきを書きます！ 結論 めちゃくちゃにイイです！！！ これからも続けていきます！！！ 以降、始めたきっかけや良かった点、苦労したことなどを書きます。 きっかけ ペイトナーには、「同期作業」という文化があります（僕がとても素敵だと思う会社文化のひとつです）。 「オンラインで繋いで、仕事の会話するもよし、雑談するもよし、黙って作業するもよし」 というものです。 業務上でのもくもく会みたいなものです。 「biz側（PM） x エンジニア」の同期作業を週2回、各30分ずつやっているのですが、これがもうすごく良くてですね。。。 ペイトナー社では現在、フルコミットメンバーは週2の出社でオフィスの席数の関係で出社日を曜日で分散させ

はじめまして！！ ペイトナーでCTOをしている三浦( @kazuman519)です。 この度、エンジニアによるブログを始めることにしました！ なぜはじめたのか ブログをはじめた目的は2つあります。 1つは定番な目的である 「採用力の強化」 、 もう1つは 「組織としての開発力の向上」 で、こちらが1番の目的です！ ペイトナーは創業してから今年で4年目の会社となり、非常に頼りになるハイスキルなエンジニアや、やる気が満ち溢れている開発意欲の高いエンジニアが集まっています。 しかし、エンジニアが組織的に開発ができるようになってきたのはここ半年間の出来事で、それまではメンバーの個の力でプロダクト開発を支えていた印象が強い状態でした。 それ故に 「組織としての開発力」 は伸ばす余地がまだまだある状態です。 なので今回メンバーと話し合い、今後さらに開発力を向上してくための投資はしっかりしていこうという

最新版 本ポストをXP祭り2017で発表したので、補足を含め要点のみを抽出してリライトしております。 i2key.hateblo.jp 本ポストはプロダクト開発における特定の文脈によるものなのですべてがそうだとは言っていませんのであしからず。バイモーダル戦略でいうところのSoE領域*1であり、学びによる改善サイクルをガンガン回していくようなモデル・フェーズを対象としております。TPSやLEANを現場で実践してる方々には今更なお話かと思いますが、DevOpsやアジャイル、リーンスタートアップを実践していく上で何周かしてまた原点の理解すると深みがますというかようやく、「ちょっとだけリーンわかる」ようになったので自分用のメモになります。 共通の価値観としての「リードタイム」 SoEライクな開発をしていると、仮説を立案し、そのための仮説を実証するための機能を実装し、リリースして計測、そして学びを得

開発生産性を高めるヒントを最前線で働くエンジニアによる取り組みから考える会 - connpassのイベントで、「今の生産性向上活動で大切にしている考え方　〜開発チームに属した改善活動から得た気づき〜」というタイトルで、開発生産性に関する発表をしてきました。 speakerdeck.com 自分はこれまで、10年近く開発チームの中からボトムアップでチーム改善・生産性改善をしてきました。例えば、GitHubを使った開発フロー改善、チームごとの開発生産性の定量化・可視化、バリューストリームマップを使った、開発フローのボトルネック発見、CIの高速化などによる生産性改善、Findy Teamsを使った生産性可視化と改善などです。 それらの活動では失敗も成功もありました。その体験から、改善活動をしているときに裏で大切にした方が良い考え方についても明確になってきました。 そこで今回は、「今の生産性向上