大企業でプロダクトエンジニアとして働いたら、コーディングのスキルが下がっていた
背景 Shopifyという会社に1年半前に転職しました。あれよあれよと会社が拡大して、現在は従業員一万人弱くらいです。 画像元 公式ではない雑な情報です。あくまでイメージ その前はChartmogulという、せいぜい20人、30人ぐらいの会社にいました。 なぜ表題のようなことを思ったか 面接インタビュアー側として、出題することになるコーディング問題を自分で試しに解いていました。一年半前には自分が受ける側の立場だったので、自分の腕前の定点観測ができました。 やってみてどうだったか。 コーディングにおけるシャープさという観点では明らかに衰えているな、と思いました。問題が与えられて、それに短時間で、論理的に向き合う力とでもいうのでしょうか。 自分は現職でマネージャの立場になったわけでもないので、これはマズイ。なんとなくこの一年くらいそんな気はしていたので、これを機会にもうちょっと深堀してみます。
システム開発で曖昧な要望を形にしていく方法 - arclamp
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約（プライム） 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的：達成すべきこと 戦略：目的を確実・効率的に達成するためのシナリオ 戦術：戦略を実行するための具体
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
Spotifyモデルを導入した組織で働いて感じたこと - Yohei’s blog
アジャイルをスケーリングする方法の１つに、Spotifyモデルというものがあります。音楽ストリーミングサービスのSpotifyで導入されている組織モデルということから、この名前がついています。アジャイルのカンファレンスなどでも、Spotifyモデルを導入している企業の発表を聞くことがあります。 ただこのSpotifyモデルにはデメリットもあることが指摘されており（あらゆるものにデメリットはありますが）、特に最近 Spotify's Failed #SquadGoals （日本語訳：Spotifyは "Spotifyモデル "を使っていない）という記事が話題になっています。 私自身もSpotifyモデルを導入したITシステム部門で働いた経験があります。その組織では上の記事で指摘された問題点の一部について改善策を適用し、ある面では上手くいきましたが、問題点も残りました。 今回はこの経験に基づい
Spotifyモデルに取り組んでいる国内事例一覧 - tuneの日記
Photo by sgcdesignco on Unsplash Spotifyが2013年に発表した組織形態 "Spotifyモデル"を採用している公言する事例が増えてきたなと感じているのでまとめました。公開されている資料をベースにまとめていますが、「うちもやってるよ！」というところがあればぜひお知らせください。 まとめてみるとTribeが必要な開発規模までには至らず、Squadが自律して動くことを指して「Spotifyモデルを採用」と言っているところが多い気がします。 アクサ生命 dely for Startups,Inc READYFOR SmartNews Wantedly GMOペパボ (2020/1/4) MSD製薬 (2020/1/6) WealthPark (2021/3/13) アクサ生命 保険会社でAgile？ - アクサ生命のAgileトランスフォーメーション - 「
最速でプロダクトを成長させるために、SUZURIのプロダクトチームの開発体制を見直した話 - Pepabo Tech Portal
はじめに くろ: こんにちは黒瀧(くろ)です。SUZURIではシニアエンジニアリングリードをしています！ みるてぃ: こんにちは、みるてぃです！今年の11月から、SUZURIのプロダクトマネージャー（以下、PM）として入社しました。 くろ: 今回は最速でプロダクトを成長させるために、みるてぃさんと協力してSUZURIの開発体制をアップデートしたので、その話をします。 解決したかったこと みるてぃ：SUZURIの事業拡大に伴い、開発メンバーの人数も年々多くなり、自分が入社した11月には開発メンバーだけですでに20人を超える大人数チームになっていました。 タスクの進行について他のPMに話を聞いていると、急激にメンバーが増えたが故に、「誰が、何を、いつまでにやるのか」ということがPM側で把握しづらい状態が発生していることがわかりました。 くろ：エンジニアメンバーと1on1をしている中でも、タスク
開発のチーム体制についてまとめてみた - mic_footprints
Wed+DB PRESS Vol.60でプロジェクト運用ノウハウについて学んだのでまとめました。 アウトプットを最大化するチームづくり チームラボ(株) チーム開発の重要性 求められるアウトプットに対して最適なチームを運営する必要がある チームメンバー個人個人がサービスの目的や、最適な開発フローを常に考えてることが重要 一人一人のアウトプットの結晶が、プロジェクト全体のアウトプットにつながる 個人個人のアウトプットを担保するのがチーム チームとして品質を向上させることが必要 レビューの重要性 プロジェクトの方向性を疑うことを忘れないのが大切 プロジェクト内のみにとどまらない プロジェクト間においても横断的に、かつ定期的にレビューを行う レビューを活性化するために プロジェクトに直接コミットしていない、異なるスペシャリストもレビューに含める レビューはフラットな関係性で行う チーム分けのパタ
ドキュメント駆動開発v2
前提 ここで言っているドキュメントは仕様書ではなく、顧客向け製品ドキュメント。 ミドルウェア製品を開発 小さなチーム パッケージ製品とパッケージ製品のクラウド版 そのため顧客に提供するドキュメントが必ず必要 GitHub を利用 自分で開発する場合のフロー 作りたい機能をぼんやりでいいので GitHub Issue に追加する feature ブランチを切る デザインドキュメントをリポジトリの doc/ 以下に書く デザインドキュメントに合わせてコーディングを進めてなんとなく動くところまで作る 動かなくてもいいのでイメージを膨らませるためにコードを書いてみる デザインドキュメントは書き捨て前提で、とにかくメモを書く 製品ドキュメントを書き始めて、一旦書き終える ブランチマージに向けてコーディングを進める 書ける範囲でテストを書く ドキュメントを平行して修正する プルリクエストをだしてレビュ
『モデリングの学び方：座談会』を見たよメモ - コード日進月歩
モデリングの学び方：座談会 - connpassを見たよメモです。ディスカッション形式だったので、話の流れになぞらえてまとめていきます。 本日の話し手 この会でメインで喋られていたのは以下の方々 増田さん かとじゅんさん ミノ駆動さん hirodragonさん 藤岡さん 原田さん 高崎さん 本日の趣旨説明と増田さんの考えるモデリングに関して まずは下記の資料を使いながら今日の催しの趣旨説明と増田さんの考えるモデリングに関しての話があった。 speakerdeck.com 上記の資料にもあるが以下の話が冒頭で行われた 今回の話し手の属性に関しての話(共通的な部分もありつつも自社サービスを持つ人たち3人と、受託開発を主に行う人たち3人という構成) まずは前提の話としての増田さんのモデリングの考え方のダイジェスト説明 効果的なモデリングの考え方（要点をうまく表現する名前を見つける、認知不可の軽減
書籍「マイクロサービスアーキテクチャ」を読んでのメモと感想 - タケハタのブログ
最近「マイクロサービスアーキテクチャ」を読んだので、気になったところや学びになったところのメモと、自分なりの解釈とか感想を書いていきます。 あくまで気になったところや学びになったところなので、全部の項目に触れているわけではありません。 元から割と知ってた部分とか、「まあそうだよね」って思った部分とかで全く触れていない章もあるので、マイクロサービスについて調べたい時のちょっとした参考までにご覧ください。 www.oreilly.co.jp マイクロサービスとは？ マイクロサービスとは、強調して動作する小規模で自律的なサービスです。 とあります。 イメージ的には、プロダクトの各機能単位のシステムがそれぞれサービスとして作られているようなものです。 通常の構成(モノリシック)とマイクロサービスアーキテクチャの構成 通常のいわゆるモノリシック(一枚岩)なサービスは、下記のようになります。 全ての機
PMに技術力は不要？プロジェクトを炎上させる3つの原因 - paiza開発日誌
Photo by crudmucosa こんにちは。倉内です。 前職ではSIerでSEをしており、炎上プロジェクトにもたびたび遭遇しました。 担当したプロジェクトの規模はさまざまでしたが、途中炎上せず成功を収めたプロジェクトは残念ながらほとんどありません。 一体なぜ炎上プロジェクトは繰り返し生まれてしまうのでしょうか？私がPMを務め大赤字＆納期遅延を引き起こしてしまった炎上プロジェクトを振り返りながら考えてみたいと思います。 目次 私の簡単な経歴 炎上したプロジェクトの概要 開発工程で問題発生 表面的な原因と本当の原因 開発の遅れは開発チームに原因がある！？ 本当の原因はPMの能力不足 1. 技術力不足による見積もりと実態とのギャップ 2. 顧客コントロール不足による品質悪化原因の作り込み 3. 信頼関係の構築失敗によるコミュニケーション不全 失敗を繰り返さないための解決策 まずはプログラ
要件定義～システム設計ができる人材になれる記事 - Qiita
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間
アーキテクトを目指すエンジニアの最短ルート - エス・エム・エス エンジニア テックブログ
介護や医療、ヘルスケア、シニアライフなどの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスで、技術責任者をしている @sunaot です。2015年2月に入社して以来、技術責任者として開発組織の構築や開発基盤の整備をリードしてきました。 今まで私がソフトウェアエンジニア（以下、エンジニア）の採用面談を延べ800件ほど担当してきた経験を振り返ると、ソフトウェアアーキテクト（以下、アーキテクト）をキャリアのゴールに据えているエンジニアも多いようです。ただ、アーキテクトを目指している一方で、実際にアーキテクトになるためには、どういった会社組織でどのような経験をしたらいいのか分からないというケースも見受けられました。 今回は、アーキテクトを目指したいエンジニアの方向けに、アーキテクトになるために必要な4つの経験や、それが経験できる会社組織について紹介します。 アーキテクトと
Fintechサービスをスピーディーに立ち上げる技術スタック LINEエンジニアに和田卓人さんが聞く TypeScriptとマイクロサービス基盤 - はてなニュース
多くのユーザーに常用されるコミュニケーションアプリ「LINE」には、エンターテイメントやライフスタイル、ショッピングなど多種多様な関連サービスがあります。 その中でスマホ投資サービス「LINE証券」や、外国為替証拠金（FX）取引の「LINE FX」、個人向けローンサービス「LINEポケットマネー」、「LINE」アプリ上で損害保険に加入できる「LINEほけん」などファイナンシャル（金融）系サービスの展開も拡大しています。 こういったFintech事業に、LINEエンジニアはどう取り組んでいるのか？ 「LINE証券」を開発する3名に、事業を支える技術の詳細を伺いました。聞き手は、テスト駆動開発の第一人者でありITコンサルタント・ソフトウェアエンジニアの和田卓人（@t_wada）さん。 信頼性と高速性の両立が求められるFintech領域において、LINEはどのような工夫を行っているのでしょうか。
よくわかるSOLID原則1: S（単一責任の原則）｜erukiti
ソフトウェアエンジニアが知っているべきSOLID原則についての記事です。SOLID原則は、5つの原則の頭文字を並べた言葉で、S・O・L・I・Dそれぞれの原則について、5回に分けて説明します。 1) Single Responsibility Principle：単一責任の原則 2) Open/closed principle：オープン/クロースドの原則 3) Liskov substitution principle：リスコフの置換原則 4) Interface segregation principle：インターフェース分離の原則 5) Dependency inversion principle：依存性逆転の原則 今回はSingle Responsibility Principle（単一責任の原則 / SRP）についてです。 なぜSOLID原則が必要なのか？初回なので、なぜソフトウェア
「開発はVue.jsでしたいけど、TypeScriptを入れたい問題」をどうするか フロントエンド開発のお悩み相談
Vue.jsに関する勉強会「Roppongi.vue #2」が2019年7月31日に開催されました。Vue.jsをさまざまな角度から掘り下げ、知見をシェアします。トークセッション 「最近のフロントエンドぶっちゃけどうっすか？」に登壇したのは、フロントエンドエンジニアで活躍するpotato4d氏とkahirokunn氏。昨今のフロントエンド界隈事情をディスカッションします。 gRPC-webは伸びしろがある tadano：Q3.「みんなにもっと知ってほしい知識や、積極的に広めたいモノはありますか？」。 potato4d：それこそ今の話ですが、gRPC-webは伸びしろがあると思っています。あと、異なる言語間で通信できるというところで、IDLという概念がこれから重要になってくると思っています。BFF層も、これから過労死するぐらい使われていくことになると思う。 例えばBFF層がTypeScrip
「Go言語らしさ」とは何か？ Simplicityの哲学を理解し、Go Wayに沿った開発を進めることの良さ - エンジニアHub｜Webエンジニアのキャリアを考える！
エンジニアHub > 記事一覧 > 「Go言語らしさ」とは何か？ Simplicityの哲学を理解し、Go Wayに沿った開発を進めることの良さ 「Go言語らしさ」とは何か？ Simplicityの哲学を理解し、Go Wayに沿った開発を進めることの良さ プログラミング言語には作者の設計思想が強く現れますが、Go言語もまた後発であることを生かし、しっかりとした思想に基づいて開発されています。公式のドキュメント等で語られているSimplicityの哲学を理解し、Go言語らしさ、Go Wayに従って開発する良さについて、はてなチーフエンジニアの松木雅幸（Songmu）さんが解説します。 id:Songmuと申します。はてな東京オフィスでチーフエンジニアを務め、Mackerelというサーバー監視のSaaS開発においてプロダクトマネージャーを担当しています。 筆者が勤めている株式会社はてなでは、2
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「設計」で大事なのはこれだった！半年間で40本レビューして分かった 5つのポイント - Qiita
「問題から目を背けず取り組む」 �一休の開発チームが6年間で学んだこと
shiodaifuku.io
