近年のソフトウェアプロダクト開発組織の活動単位としてよく言われるのは、「少人数で安定したチーム」であろう。表現は違えど、どの文献でもそのように述べられる。 それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計できるかと言えば、そんなはずもない。他にも要件があるはずだ。 そこで、チームに共通して必要だと考える要件を、設計に関わったこれまでの組織から抽出して言語化し、原則としてまとめてみた。それが、「安定」「アトミック」「非兼務」「少人数」「流動性」「イテレーティブ」の6つだ。 初期に携わった組織には欠けていた要素もあるが、何度も失敗を重ねるうちに見いだしたものだ。組織設計のプラクティスとしてよく聞くものもあるが、いずれも実体験を経て必要だと感じたものばかりである。 なお、本記事で取り上げる6つのチーム設計原則だけでは、組織設計として不十分だ。チームにどういった機
ヘルプデスク業務を楽にするためにSlackとGitHub Projectを同期するヘルプデスクツールを自作した - MNTSQ Techブログ
こんにちは。MNTSQの下村です。 コーポレートエンジニアとして、MNTSQ従業員の生産系向上施策等を実施していたりします。 ( Twitterもやっている のでフォローしてもらえると嬉しいです！ ) 本日は社員からの問い合わせ業務 いわゆる ヘルプデスク業務について効率化するためのツールを自作した 話を書いてみます。 この記事の要約 一人目コーポレートエンジニアとして参画したがヘルプデスク業務が非効率だったので効率化した。 質問に対して特定のemojiを押すとGitHub ProjectsのItemを作成するようにした。 SlackスレッドのコメントとGitHub ProjectsのItemを双方向同期するようにした。 Azure OpenAIも利用して効率化した。 きっかけ 2023年5月からMNTSQの一人目コーポレートエンジニアとして参画しています。 情報システムを色々と整備してい
「リーダーにしたら絶対アウトな人」の特徴ワースト10
株式会社北の達人コーポレーション代表取締役社長 1968年、神戸生まれ。株式会社リクルート勤務後、2000年に北海道特産品販売サイト「北海道・しーおー・じぇいぴー」を立ち上げる。 2002年、株式会社北海道・シー・オー・ジェイピーを設立（2009年に株式会社北の達人コーポレーションに商号変更）。 2012年札幌証券取引所新興市場「アンビシャス」、2013年札幌証券取引所本則市場（通常市場）、2014年東京証券取引所の市場第二部（東証二部）、2015年東証一部と史上初の4年連続上場。2017年、時価総額1000億円。2019年、「市場が評価した経営者ランキング」第1位（東洋経済オンライン）。日本政府より紺綬褒章7回受章。 「びっくりするほどよい商品ができたときにしか発売しない」という高品質の健康食品・化粧品で絶対に利益が出る通販モデルを確立。「北の快適工房」ブランドで、機能性表示食品「カイテ
この記事はNuco Advent Calendar 2023の1日目の記事です。 はじめに 2023年最新のフロントエンド開発環境についての紹介記事です。 分野別に、おすすめツール群と、その特徴などを紹介していきます。 デファクトスタンダードとみなせるようなツールや、最近盛り上がりを見せているものなどをラインナップしました。 これからフロントエンド開発を始めたい人はもちろん、長くご経験のある人にもプラスになる情報がきっとあるため、ぜひ参考にしてもらえると嬉しいです。 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 フロントエンド開発おすすめツール集 エディタ エディタやIDEは好みの問題も大きいので、メジャーなものを簡単
見積りとは何か？
見積りとは何か？2023年12月2日この記事は 10X アドベントカレンダー2023 という企画の2日目（12/2）の記事です。 1日目（12/1）の昨日は岡野さん（@operandoOS）による「CIを高速化する技術⚡️」でした。 はじめに この記事の内容は以下の本の第一章とほぼ同じ内容となります。この記事の読んで見積りについて興味が湧いたらぜひ以下の書籍に目を通してみてください。 出典 ソフトウェア見積り 人月の暗黙知を解き明かす 早速ですが見積りしてますか？おそらくソフトウェアエンジニアの方であれば、こんな感じで会話して見積りした経験が1度はあるんじゃないでしょうか？ プロダクトマネージャー「機能xyzの件だけど、開発期間はどのくらいだと見積もってる?」 ソフトウェアエンジニア「1ヶ月ですね。」 プロダクトマネージャー「長すぎる。1週間で何とかならないか。」 ソフトウェアエンジニア「
依頼、調整、合意、承認、etc. こういったコミュニケーションがチーム境界を越えて頻発すると、ソフトウェアプロダクト開発のフローは遅々として進まなくなります。いずれも、機能追加や機能改善を進める上でのクリティカルパスを引き伸ばす要因を生み出すからです。 機能追加や機能改善といったひとつひとつの開発は、アイデアを生み出し、それを価値に変えるまでのフローです。フローが進む過程で、組織内の様々な人の手で、様々なタスクが実行されます。その全てを1つのチームで完結することは、プロダクトの規模が大きくなるほど困難になり、より多くの人々が関わるようになります。そこに、チーム境界を越えた「依頼、調整、合意、承認」といったコミュニケーションが発生するのです。 開発フローのクリティカルパスを悪化させるこのようなコミュニケーションの頻度をどれだけ減らせるか。組織設計、チーム設計で最も注視すべき観点の1つは、そこ
東京都初のアジャイル型開発はいかにして導入され、実践されたか – 調達、スクラムの工夫、展望を聞いた - Agile Journey
「初！都庁職員、アジャイル型開発に参加する」 東京都デジタルサービス局デジタルサービス推進部の公式note（2023年1月公開）には、かつて“試みたことのない開発手法”であったアジャイル型開発を東京都が採り入れ、複数のソフトウェアを開発した経緯が綴られています。 これまでAgile Journeyでは、さまざまな組織、企業のアジャイル導入事例を紹介してきましたが、それぞれの組織がそれぞれのモチベーションを持ち、課題に向き合いながら、導入に取り組んできました。では、それが自治体の場合では？ 東京都がアジャイル型開発を導入し、運用していくための動機、準備、事業者との契約の方法、そして実践のありようを、東京都デジタルサービス局の石川秀之さん、下家昌美さんに聞きました。 コロナ禍で浮き彫りになった、「迅速」の重要性 「システムをアジャイル型開発で作ってみませんか」メールで呼びかけ、アジャイル型開発
エンジニアからマネージャになったときにあるだろうなぁってことを想像して遊ぶ - Mitsuyuki.Shiiba
ソフトウェアエンジニアの話ね。想像して遊んでるだけね。 スキルは高い まず、マネージャになってほしいって言われる時点で「仕事を任せられる」というエンジニアなんだろうな。それは、つまりコードを書くことに加えて、プロダクトをなんとかしてリリースする力と責任感をもっていて、それが会社にとってプラスになっている。 だから、チームを任せて同じようなエンジニアを育てて欲しいと期待されている。自分自身も、自分のスキルをもっと会社の役に立てるぞー！とやる気になっている。 任せたい そういう人がマネージャになって、あるだろうなぁと思うのは「どう任せたらいいんだろう？」という悩み。 自分が手を動かせばプロジェクトがなんとかなるのは分かっている。でも、自分はマネージャの仕事があるし、そこは自分の役割ではないし、実際のところ手を動かす時間なんてない。それはメンバーにやってもらわないといけない。 ただ、だいたいの場
「わし詳細設計書書くのやだよ」システム開発で細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない話に賛否両論
しのゆ𝕏酒くずエンジニア @shinoyu 新宿で社長やってるソフトウェアエンジニア18年生のおかまちゃん / 💻技術🎧 V系 🎀ロリィタの人 / 170スペ110 スプリング、骨ウェーブ、顔ソフエレ / 絡みない鍵とスパムは🚫 / 原則IT関連業のみフォロー /たまに会えるかも @shinjukudist しのゆ𝕏酒くずエンジニア @shinoyu わし詳細設計書書くのやだよ(￣･ω･￣) 細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない。 必要なのは完成に必要要件がまとめられたもの。それを元に受け入れ試験書がつくられる。それクリアすればどう作ってようが構わんわけだ 改修コストを下げるための設計になってることは前提だけどね。 だけど、詳細設計書が必要となる現場はこの設計することはできない。だってそれできてたら詳細設計書
つつむだ つつむ🦖 @GNS_ttmdttm 元ADさんに話を聞いて、イラストとかキャラデザの仕事のこれこれこういう内容をまとめたいんですよね～何か参考になる話ありませんか、って話をしたら、相当な鬱憤が溜まっていたのか文字に起こせないレベルの闇ばっか聞いてしまった。心の中の群馬県民が「ກະລຸນາຢຸດມັນແລ້ວ」って泣いてる。 2024-05-23 00:14:42 つつむだ つつむ🦖 @GNS_ttmdttm ADさんに話聞いた時の、仕事でのキャラデザトラブルあるある「キャラデザ頼んでるのにイラストを描かないでほしい」をまとめたら面白かったので、キレてる気持ちも交えて校歌にした 2024-05-25 13:51:50
書評：GitHub Copilot とのペアプロ TDD でつくるローグライク RPG - 若くない何かの悩み
本記事は「GitHub Copilot とのペアプロ TDD でつくるローグライク RPG」の書評です。題名にローグライクRPGとあるのでゲーム開発の本なのかなと思ってしまいますが、本題は仕様の端的な表現をもたないシステムを LLM を使って真っ当に開発する方法の解説だと思います。タイトルにローグライクRPGと書いていることでゲーム開発に興味のない人の興味を失わせてしまい損をしている気がします。 背景 最近の LLM の流行を受けて私も Chat-GPT や GitHub Copilot といった LLM を開発で利用しています。端的に仕様を表現できるシステムは LLM に質問して実装を得る方が自分で実装するより圧倒的に速く正確であるという感想を抱いています。ただ端的に仕様を表現できるシステムばかりではありません。えてして価値を生んでいるシステムというのは端的な仕様の表現が存在しないもので
このブログは、 IVRy 紅白Advent Calendar 2023の白組・17日目の記事です。 白組16日目は PdM佐瀬さん「IVRyなら上流からUX/UIデザイン業務が実践できます！」でした。明日はIVRyのVPoE近藤さんの「IVRyにおける開発生産性へのアプローチ～SPACEフレームワークの視点から～」についての記事が出ます。乞うご期待。 この記事について タイトル通り、2023年に提案されて改善した事を発表するのですが、裏返すと「そんなこともできてなかったのか」と見える内容もあるかもしれません。ネガティブに受け取られる可能性もあるかもしれませんが、IVRyのオープンな社風や、常に改善と変革に前向きな姿勢をアピールするためにも、この記事を執筆することにしました。 なお、課題を発見・解決しながら会社を大きくしていきたいエンジニアの皆さんは、ぜひブログ一番下のIVRyの採用情報から
フランスでは、日本人建築家が高い人気を誇り、数々のコンペティションを勝ち取っている。だが、日本の大規模プロジェクトでは、彼らの活躍の幅は意外にも狭く、個人や海外からの発注に逃げ場を見つけているという。そのことに気づいた仏紙記者が、日本の建築事情を深掘りする。 日本は「建築の国」なのだろうか。最近のニュースからすると、そう言えそうだ。2024年3月、日本人建築家の山本理顕がこの分野の最高の賞であるプリツカー賞を受賞した。日本でこの栄誉ある賞を受賞したのは山本が9人目で、これによって日本は建築分野を率いる存在になった。世界中が口々に日本のスター建築家を称えている。 特にフランスでは、日本人建築家の人気は高く、権威あるコンペティションをいくつも勝ち取っていて、象徴的な建造物を多く生み出している。たとえば妹島和世と西沢立衛による建築家ユニット、SANAAは「ルーヴル美術館ランス別館」（ついでに言え
ソフトウェア開発プロジェクトは、「兼務」を用いるチーム編成が多用されやすい対象ではないでしょうか。エンジニアであれば誰もが経験したことがあるでしょう。1人で複数のプロジェクトやチームを掛け持ちするあれです。マネージャーであれば、組織の人的リソース配置を考える時の手段の1つとして用いたことが何度かあるはずです。 しかし、兼務が引き起こす様々な弊害や問題については、あまり意識されないまま多用されているように感じます。 たとえば、兼務者本人にとってプロジェクトの掛け持ちは、仕事のマルチタスク化やミーティングの増加に苦しむ原因になります。組織の観点からも、兼務への依存は、知識の偏りや負荷の偏りという弊害をもたらすことに繋がりかねません。プロジェクトの観点から見ると、兼務という形での「人的リソースの共有」は、プロジェクト間での「リソースの競合」を引き起こしやすく、それが市場投入までの時間を長くする要
富士通株式会社（Fujitsu Limited）公式 @FujitsuOfficial スーパーコンピューター「#富岳」の先代となる、「京」の開発に挑んだ技術者のストーリーが放送されます。ぜひ、ご覧ください！ NHK：新プロジェクトX ～挑戦者たち～ 世界最速へ 技術者たちの頭脳戦 ～スーパーコンピューター「京」～ 日程：6月15日（土） 19:30～20:15 okt.to/YdAXab 2024-06-11 16:00:19 Takashi I @DAHL_SAM プロジェクトX見た。京の開発責任者で、その後富士通と道を違えた父が一切出ず、直属の上司や部下で、今も富士通との関わりが深い人たちのみが登場する内容には、家族としては非常に複雑な気持ちである。集合写真で真ん中でガッツポーズ決めてたのに。 2024-06-15 20:22:21
本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 ronjeffries.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 ストーリーポイント再考 私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。 もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及している
1時間でさわって学ぶDocker
Dockerを触りながら学んでいく、初心者向けの記事です。 用語の解説等はほとんどせずに、とにかく触ってみることを目的としています。 Phase 1: Dockerの基本 コマンドを試しながら基本操作を学びます。 Phase 2: Dockerfileをもう少し書いてみる Dockerfileを使って、簡単なWebアプリケーションを作成します。 Phase 3: Docker Composeを使ってみる Docker Composeを使って、複数のコンテナを一括管理します。 Phase 1: Dockerの基本 Dockerの基本的な操作を試してみます。 プロジェクトフォルダの作成 次のコマンドを実行して、プロジェクトフォルダを作成します。
【入門】事例で学ぶ要件定義 - Qiita
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 本記事について Findy様の「要件定義 先達に学ぶ今日から使える実践テクニック Lunch LT」で登壇した内容を元に作成しています。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像
Q．28歳エンジニアです。プロジェクトの進捗遅延で先月は3回、休日出勤しました。休日に休むのは当然なので、上司に対し、今月の休日出勤を拒否すると発言しました。それ以降私に出勤要請はなかったのですが、休日出勤する他のメンバーが不公平だとしてクレームを申し立てたようです。後日、上司から「協調性を重んじてほしい」と言われました。意味が分かりません。休日出勤が必要なプロジェクト管理しかできない上司の責任です。 厳しい上司批判ですね。質問者は、この4月に社内システムの運用部門から顧客対応部門に異動したとのことです。異動前に休日出勤はほぼ無く、休日出勤した場合は、振り替え休日があったと言います。 IT企業に勤める筆者の友人（部門長）は、20代の若手エンジニアにはなるべく長時間残業にならない配慮をしていると話します。長時間働いて元気がなくなる様子が見て取れて、メンタル面を心配してしまうということでした。
デロイト トーマツ コンサルティングが入居する丸の内二重橋ビル（「Wikipedia」より／Kakidai） 5月30日付「ダイヤモンド・オンライン」記事は、ユニ・チャームで一部商品の納品遅延を起こしているシステム障害について、システム更新作業の主幹事ベンダが外資系のデロイト トーマツ コンサルティングであると報じている。デロイトは4月初めに障害が発生した江崎グリコのシステム更改作業でも主幹事ベンダを務めており、外資系ベンダを起用するリスクがにわかに注目されつつある。業界関係者の見解を交え追ってみたい。 ユニ・チャームは5月16日、一部商品について注文集中による出荷が遅延している旨をアナウンスしていたが、27日付「日経クロステック」記事によれば、ゴールデンウイークに実施した基幹システムの更新で新基幹システムと物流システムの接続でデータ連係に不具合が生じたという。 システム障害による出荷トラ
アジャイルでも、ウォーターフォールでもない。リクルートの新決済システムは「異色のコラボ」で作られた - はてなニュース
アジャイル・スクラム開発とウォーターフォール開発──開発手法を巡ってしばしば対立項に置かれるこの二つのスタイルは、考え方はもちろん、段取りやマネジメントの方法もまるで異なります。そんな全く異なるスタイルをとる二つのチームがコラボレーションし、開発プロジェクトを推進していくことは現実的に可能なのでしょうか？ そんなコラボレーションを、決済というミッションクリティカルな領域で実現し、新たなシステムのリリースにこぎ着けた実例がリクルートにはあります。 英語や英会話の学習を支援する『スタディサプリENGLISH（以下、スタサプENGLISH）』では、今や主流となりつつあるサブスクリプションモデルに決済システムが対応できていないという課題がありました。そこで、決済・金融関連のシステムを開発するチームと共同で、新たな決済システムの開発に取り組みました。 『スタサプENGLISH』のチームは、内製の開発
？「プロジェクトでよく使うコマンド Makefile に書いたろー」 ？「docker compose up -d --wait っと…」 👮♀「 Makefile警察 だ！」 👮♀「 Makefile は、ソフトウェアのビルドプロセスを自動化するためのファイルだ！」 👮♀「多目的なタスクランナーとして使うな！」 ？「せやったんか。誠にごめんなさい。」 Makefile は広く使われていますが、時々目的外に使われてしまうことがあります。しかし、そのような使い方にはより適した代替手段が存在します。この記事では、 Taskfile というツールについて解説します。 Makefile のつらみ Makefile は主にビルドプロセスを自動化する目的で生まれましたが、様々なコマンドをまとめて実行する便利さから多目的なタスクランナーとしてもよく使われます。しかし、次のような問題があります
ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268％も高いという調査結果が発表されました。 268% Higher Failure Rates for Agile Software Projects, Study Finds - Engprax https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds 268% higher failure rates for Agile software projects • The Register https://www.theregister.com/2024/06/05/agile_failure_rates/ 今回の調査はコンサルタント会社「
Broken Ownership
Have you been in any of these situations? Managers make decisions that’s out of their leagues and everyone else in the team ends up paying for it. Knowledgeable people passively observe without bothering to contribute. Sometimes they are denied access to the room. Developers act like code monkeys, throwing the code over a metaphorical wall for the QA to test and “DevOps” to run. In “you build it,
プロパーがSIerさんを侮辱した結果SIerさんがブチギレて全撤退する現場があるらしい「ときどきある」「似たようなトラブルに巻き込まれた」
ごっつ@平凡なフリーランス @dekiruengineer プロパーがSIerさん侮辱した結果、SIerさんブチギレて全撤退するそうだ。そのプロパーは懲戒くらって、プロジェクトこれ完全に延期だな。 電話でもメールでもSIerさん下に見てて、毎回バカにしたような態度と文章だったから自業自得って感じ。 コンプライアンス守れない１人のせいで、プロジェクトが止まるって関係者はたまったもんじゃないな… 2023-12-14 22:19:05 ごっつ@平凡なフリーランス @dekiruengineer 僕がSIerだった時代にも客が傍若無人で理不尽すぎて30人ぐらいのチームごと抜けるかって話挙がったけど、会社の主要顧客だったから結局抜けられなかった。 今回の件は昔っからの悪態ぶりだったから社員を守ったSIerさんは英断だね。 2023-12-15 07:55:36 ごっつ@平凡なフリーランス @dek
一年の計は元旦にあり！ Udemy新年のビッグセールで2024年に学びたいこと、挑戦したい資格、新しいスキルを見つけよう - はてなニュース
※ Udemy「新年のビッグセール」は終了しました。はてなによるAmazonギフトカードプレゼントキャンペーンもそれにあわせて終了しています。ご応募ありがとうございました。 あけましておめでとうございます。これまでもUdemyの大きなセールでは目玉の講座を紹介してきた当ニュースですが、2024年1月1日から1月10日まで開催される「新年のビッグセール」では、新しい年にふさわしい夢とキャリアが広がる講座を紹介します。 各種資格試験の対策講座をはじめとして、マスターしたいプログラミング言語や開発手法、昨年から引き続き話題の生成AI、ウェブ解析やプロジェクトリカバリ、簿記や会計、英会話など多様なビジネスキャリアに直結する講座をピックアップ。映像制作や3Dモデリング、GA4や3Dアニメーション制作といった講座も取り揃えています。 一年の計は元旦にあり。みなさんが2024年に挑戦したい目標や習得した
【書評】「プロジェクトマネジメントの基本が全部わかる本」の輪読会を開催していただいたので参加しました | DevelopersIO
コーヒーが好きな emi です。 7 月末～ 11 月末にかけて、私が所属しているチームのマネージャー 横田慎介 さん主導で「プロジェクトマネジメントの基本が全部わかる本」の輪読会を開催いただきました。おかげさまで一人では読み切れなかったであろう本が読み切れて嬉しいです。 本記事では開催いただいた輪読会の進め方と、私が「プロジェクトマネジメントの基本が全部わかる本」を読んだ感想を記載します。 既に書評ブログがありますので、詳細はこちらもご参照ください。 書籍タイトル : プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで 著者 : 橋本 将功 出版社 : 翔泳社 出版日 : 2022/11/08 出版社の書籍情報リンク：プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積
AGIラボは、最高のAI情報をお届けするためのマガジン・コミュニティです。GPTsを筆頭にClaude 3やSoraなど注目のAIについても詳しく解説、今日から使えるAI活用情報を一番わかりやすくお伝えします。他に限定コミュニティへのアクセス、限定イベントへの参加権が含まれます。
スクラムとデッドライン壊れゆくチームをつなぎとめるもの/Scrum and Deadlines
循環する学び～現場とコミュニティの境目で考える～/Learning Cycle between a team and a community
追記(04/14)今時点で頂いているトラバもブコメもすべて目を通しました。 はてなの皆さん、増田の皆さんたくさんの反応ありがとうございます。 どうしたもんかと悩んでる状況の中で、エージェントの人に話してもあまりピンと来ない反応が返ってくるし、周りに相談出来る人もいないしで、かなり勇気づけられました。 とりあえず今時点で返せる分だけお返事返しておこうと思う。 フィヨルドブートキャンプやれば？ 恥ずかしながらこんなサービスがあるのを知りませんでした。 今の状況では1000時間学習してから転職ってのは難しいんだけど、転職活動終えたら利用してみたいなという気持ち。 開発に夢見すぎ 自己評価低い その通り、かもしれない。 技術記事とか書いてアウトプットしてる同世代以下の優秀な技術者たち見てて、自分とのスキルギャップに絶望してたところだったんだ。 5年弱ぐらいローコードじゃなくて、コーディングで実務経
複数事業に携わるPM組織のスキル成長と評価について、コングロマリットな経済圏を持つDMMのPMから聞く「複数事業を跨ぐPM！なんでもやるDMMに聞く、PM組織の成長と評価の話【開発PM勉強会vol.21】」。ここで合同会社DMM.comの金築氏が登壇。PjM能力の可視化について話します。 金築氏の自己紹介 金築英雄氏：では私から始めます。今回私からは「可視化から始まるPjM育成」といった話をします。まず自己紹介させてください。名前は金築英雄と申します。経歴としてはアプリエンジニア、チームリーダー、諸々の経験を経て、現在プロジェクトマネージャー（PjM）として仕事をしています。 2023年にPMP（Project Management Professional）を取得して、さらにプロジェクト推進とかPjM採用、PjM育成に熱を上げています。今回は可視化がテーマなので、私のステータスなんかも書
「開発組織全員が自ら学んで成長していく組織づくり」という内容で、Senior Engineering Managerの上原が、Lancers Agent様との2024/06/19のイベント（https://peatix.com/event/3959065/view ）で発表させて頂いた資料となります。 …
こんにちは。Findy Freelanceの開発チームでエンジニアをしている2boです。 この記事では私が開発生産性を上げるために開発をする前に考えていることについて書きます。 ここで「開発をする前」というのは次のようなタイミングを指します。 PdMなどから新規施策の仕様について相談を受けたとき 起票された開発Issueを最初に確認するとき 自分がIssueを作成するとき なぜこのタイミングで考えるかというと、開発を進める上での方向性を間違える可能性を減らし後から軌道修正をしやすくするためです。 なおこの記事においては、開発生産性を「開発成果物の提供価値を投入リソースで割ったもの」とします。 いくら頑張って開発をしても、そもそもやるべきことの方向性を大きく間違えると提供価値が0に近づくため開発生産性が低下します。 特に開発が高速なチームで方向性を誤ると高速に間違った方向へ進んでしまうことに
開発要望タスクの優先度が「高」ばかりで悩んでませんか？ - CARTA TECH BLOG
CTO室 相談室でCARTAの各部署の技術メンター・コーチをしている前田@brtriver です。 自分の仕事内容を説明するのが難しいですが、スタッフエンジニアでいう右腕です！ いろんな部署のサポートをしていると開発要望タスクのリストを確認する場面がよくあります。 そして、その中の「優先度」という項目で正しく優先度をつけることができていない現場が多いと感じます。 そこで、今回はどのように「優先度」を考えればよいかについて私自身が意識していることをまとめてみるので、ぜひ一緒に考えてみましょう。 優先度が「高」だらけになってしまう チケット管理において優先度が「高」だらけになってしまう現象を目にしたことはありませんか？ チケットは困ってる本人が書くため、基本とその優先度は「高」が多くなります。 チケットに残すために書いたとしても、優先度低いタスクはそもそもやらないという判断されることが多く、そ
プロジェクト管理はNotionしか勝たん！MLチームのスプリント管理を改善した話 - LayerX エンジニアブログ
こんにちは、バクラク事業部のMLチームでソフトウェアエンジニアをしているTomoakiです。 今回はMLチームのスプリント管理におけるタスク・プロジェクト管理にNotionの新概念であるProjectを導入してみたら嬉しいことがたくさんあったので、それらを紹介したいと思います。 イントロダクション Notionの2.30リリースでプロジェクトという概念が登場し、プロジェクトの管理のテンプレートが公開されるなど大きなアップデートがありました。 www.notion.so 本記事でも紹介しますが、このリリースで紹介されているテンプレートが優秀すぎるので、まだみてない方は是非見てみてください。 MLチームでは5月末ごろから、ちょうどスプリント管理に課題感を感じており、早速NotionのProjectを取り入れて6月中に運用してみましたかなり良かったので、本記事では我々目線でのその効果を紹介したい
こんにちは。バクラク申請・経費精算チームでエンジニアリングマネージャーをしているsh_komineです。 7月はLayerXエンジニアブログを活発にしよう月間 ということで、今日は最近自分が「開発チームのマネージャーとして意識しているチームのCapability 」について話をしようと思います。LayerXのテックブログでは数少ないマネジメント系の話です。 私自身、エンジニアリングマネージャー歴自体は1年ほどなので、まだまだ足りない面もあると思いますが、誰かの参考になればと思います。 開発チームとCapabilityの定義 開発チームの単位もいろいろとありますが、基本的にはチームとして意思決定し、開発活動を続ける最小単位のチームを想定しています。開発エンジニアにプロダクトマネージャー、チームによってはデザイナーやQAなども含みます。自分の場合は職能横断型のプロダクト・顧客に向き合うチームを
成長しない日本のソフトウェアスタートアップ 国内競争を促進してエコシステムを創出する | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
IPA調査分析ディスカッション・ペーパー2023-01 公開日：2023年9月14日 独立行政法人情報処理推進機構 調査分析室 鷲見 拓哉 当機構が日米のソフトウェアスタートアップを対象に実施したアンケート調査により、アンケートに回答した日本のソフトウェアスタートアップの多くは、創業後10年間でほとんど成長していないことが明らかとなった。 本ディスカッション・ペーパーでは、成長するビジネスモデルを見いだす「ビジネスモデル探索活動」に特に着目して、日本のソフトウェアスタートアップが抱える課題とその解決策について考察する。 1．はじめに 昨今、ディスラプターの出現により企業の競争環境は急激に変化している。経営においても、業務効率化、コスト削減等の従来から言われる観点に加えて、外部環境変化に如何に迅速に対応し事業を展開するかという「アジリティ」の観点が求められるようになった。顧客に対して如何に早
本記事の要約 ドキュメントを書かない事は、企業やチームの「負債」になる ドキュメントを書かない事は、自身の学びや振り返りの「機会損失」になる そういう文化が根付く前に、負の連鎖を断ち切ろう！ はじめに 世の中のプロジェクトには、ドキュメントが足りていない、と感じています。 でも残念な事に、ドキュメントをどうしても書きたい人は「ほとんどいない」と思います。 その一方で「ドキュメントを書いた方が良い」という事は、 何となく分かっている人も多いと思います。 やりたくない事をやらなければならないのは、嫌ですよね。 そんな気持ちは分かりますが、これを機に一度改めてみませんか。 何故なら、ドキュメントを書かない事はチームに「負債」を生むからです。 勤め人ならば少なからず一度でも、体験した事があると思います。 「どうして必要な過去の資料が無いんだ」って。 あるはずの歴史の一端がソースコードからしか分から
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog
2023年度版フロントエンド開発環境構築徹底解説 - Qiita
チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する｜mtx2s
新しいMicrosoft Teamsアプリ「Meet」が発表、増大する一方の会議の負担を軽減【20:45追記】／準備やキャッチアップといったミーティングアクティビティを一元化・効率化
"キャラデザ"を依頼しているのに"イラスト"を納品してしまう人に送る校歌を作った人の話
2023年・新しく入ったメンバーの提案で開発チームが良くなったこと5選
仏紙が問う「なぜ日本の建築家は、自国において亡命状態にあるのか」 | 日本は建築の国なのに…
兼務による体制構築はプロジェクトの効率を損なわせる｜mtx2s
NHKがSNS時代の令和に平成のノリで昭和の幻影を追いかける新「プロジェクト」Xを敢行している件
(翻訳) ストーリーポイント再考 - forest book
休日出勤を拒否する28歳エンジニア、他のメンバーがクレーム
デロイト、グリコに加えユニ・チャームでもシステム障害…ベンダ能力に疑問も
Makefile警察「ぐぬぬぬ…」 - Qiita
アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明
VS Codeをフォーク | AI時代の最強コードエディタCursorの使い方を紹介｜ChatGPT研究所
市場価値のない無能が勢いでSES企業を辞めたのでご相談
“高効率で”強いプロジェクトマネージャーを目指すために ステータス表でわかる2つのことと、活用してできる2つのこと
開発組織全員が自ら学んで成長していく組織づくり
開発生産性を上げるために開発をする前に考えていること - Findy Tech Blog
国産の日本語生成AIの無料デモ版が公開 ～「GPT-3.5 Turbo」に匹敵する性能を達成／東大初のELYZA社が700億パラメーターのLLM「ELYZA-japanese-Llama-2-70b」を開発
開発チームのマネージャーとして意識しているチームのCapability - LayerX エンジニアブログ
ドキュメントを書かないことは「負債を生む」ということ - Qiita