2024.12.11 エンジニア組織のリアルな失敗経験から学ぶ！ 生産性向上＆チーム強化Tips
2024.12.11 エンジニア組織のリアルな失敗経験から学ぶ！ 生産性向上＆チーム強化Tips
先日、9月末の株主総会にて、4年半勤めたスターフェスティバルの取締役CTOを任期満了で退任し、3度目のCTOキャリアを終えました。 (直接ご挨拶できていない方もたくさんいるのですが… この場を借りてご報告させていただきます… スタフェスCTOとして大変お世話になりました。引き続きよろしくお願いします。) n回目、みたいな話に関しては、別に多い方が良いみたいなことではないので(むしろ1つの会社でCTOをやり続けている先輩などは、めちゃくちゃ尊敬している)、それ自体がどうって話ではないのだけれど、昨年 P2BCTO の LT で話した通り、様々なタイプの組織でCTOを経験をすることによって得られるものや自分自身に積み上がるものを実感したので、今日時点での自分の考えをアウトプットしておくことにしました。 なお、ver.2015 はコレで、まあ、あれから10年弱たったところ、という感じなのですが、
「オンラインミーティングでカメラをONにすべきかどうか」という議論をたまに見る。カメラをONにしたほうが視覚情報も得られてコミュニケーションを取りやすいので、"カメラON推奨" のようなルールを決めているところもあると思う。 自分は「カメラONじゃなくても反応を多めにすればいいとは思うけれど、結構むずかしいのでスキルがないならカメラONにしといたほうがいい」という意見を持っている。どういうことかを雑に書き出してみる。 実は自分の所属でも当初 カメラはできるかぎりオンにしよう という指針*1を作っていたが、3週間くらいやってみて変えた。 github.com 背景は Pull Request の description に書かれているとおり。サマリは以下。 カメラON"推奨"という全体指針は、強制力がないため結局ONにしない人も多くあまり意味をなさなかった カメラONにしたい理由は表情などの
誰かから方針を共有された時、なんだか納得できなくてモヤッとすることがある。そういう時に共有した側もされた側も不幸にならないためのお作法的な動き方があると思っていて、雑にまとめておきたい。 1. 初手でファイティングポーズを取らない 納得できないこと ≒ 背景がわからないことに対する不快感はすごくて、つい"強い"言葉を使ってしまいがち 相手も人間なので、そういった態度や口調は鏡のように反射してくる。そうすると物事を前に進めにくくなってしまう 一見して不合理な方針だと感じたとしても、その裏にはそれなりに込み入った背景がありタフな議論が積み重ねられていることも多い まずは深呼吸して初手でファイティングポーズを取りそうになるのを抑えて、「取りまとめありがとう」って感じで相手へのリスペクトを示すとよい 2. 何に納得できないか深掘りする 納得できない時、意外と自分でも何が問題なのかはっきりとわかって
エンジニアの評価シートは、業績やスキルを正確に測定し、エンジニアの成長を促すための重要な資料です。技術スキルだけでなく、プロジェクトへの貢献度や問題解決能力など、多角的な視点で評価することが求められます。 一方、評価基準が多岐にわたることから「エンジニア向けの評価シートの作成方法がわからない」「そもそも評価制度が確立しておらず、ゼロから制度を見直したい」と悩む方も多いのではないでしょうか。 本記事では、エンジニア向け評価シートの無料サンプルを配布します。加えて、評価制度の構築手順や評価シートの書き方も詳しく解説するので、ぜひ最後までお読みください。 エンジニアの評価シートを簡単に作れるツール「NotePM」 【基礎知識まとめ】エンジニアの評価制度とは？ エンジニアの評価制度とは、エンジニアの業績や能力を体系的に測定・評価するシステムのことです。この制度では、技術スキルやプロジェクトでの貢献
アジャイル型でアプリ開発を進めたところ、完成に至らなかったことについて、ベンダの不完全履行、プロジェクトマネジメント義務違反等が主張されたが、いずれも否定された事例。 事案の概要 eスポーツ事業の企画・運営等を行う原告（Ｘ）は、ゲーマー向けソーシャルアプリの開発を構想し、開発ベンダである被告（Ｙ）との間で、平成28年8月18日に、ゲームに参加する人をマッチングし、参加者同士がコミュニティを形成するソーシャルメディア機能を有するソフトウェア（本件ソフトウェア）を開発する契約（本件契約）を締結した。対価の額合計は、2450万円。その支払は1000万円、1000万円、450万円の3回にわけて行われることとされ、最後の450万円は、納品物を納入後に支払うこととなっていた。 本件契約の締結前には、Ｘは、検収に合格しなかったら、支払済みの代金を返金する条項を設けることを求めたが、Ｙは「返金を想定してお
エリート過剰生産が国家を滅ぼす 作者:ピーター ターチン早川書房Amazonこの『エリート過剰生産が国家を滅ぼす』は、もともとカブトムシやチョウといった生き物の個体群動態について研究して生計を立ててきた研究者が、複雑系科学のアプローチを人間社会の研究に応用していった結果をまとめた一冊になる。 この著者らが切り開いた分野は「クリオダイナミクス」(歴史動力学)と呼ばれ、人類史に繰り返し現れるパターンが存在することを発見し、どのような条件が揃うとあるパターン(たとえば、国家の崩壊など)が発生するのか──を歴史の定量分析を通して研究している。「エリート過剰生産が国家を滅ぼす」はたとえ話や主観的な主張ではなく、彼らの研究を通して見えてきた「国家が滅びに向かう」具体的な要因なのだ。 二〇一〇年、各分野の専門家が今後一〇年の展望を予想するという科学誌『ネイチャー』の特集で、私はつぎのように明言した。米国
チームのキャパシティを超える要求を抱えたプロジェクトが、なんの問題もなく完了するはずがありません。なんとか作り上げられた機能は、表面上は要求通りでも、どこかぎこちなさを感じます。ユーザー体験が悪く、それがユーザー価値を押し下げ、ビジネス価値を削り取ります。触るたびに新しい欠陥も見つかるかもしれません。内部品質も最低です。それが今後の追加開発の足を引っ張ることにもなるでしょう。そして、ただ消費するような働き方によって、チームは成長も達成感も感じられず、疲弊します。 詰め込み型のプロジェクトは、誰にとっても利点がなく、そのうえ持続不可能なやり方なのです。 「詰め込んでもなんとかなる」という楽観主義詰め込み型のアプローチは、組織内でプラクティス化しやすいプロジェクト計画手法です。この手法で完了したプロジェクトは、一見すると、上手くいったように見えます。多少の遅延があったとしても、概ね一通りの機能
不確実性の高いプロダクト開発や、継続的な価値提供を行なっているサービスにおいては、フロー効率を重視するのが良いとされている。ある価値が早く顧客に届く方が、早くフィードバックを得られるとか、顧客が享受する価値の総量が大きくなるとか、様々な方向からメリットは説明され尽くしている。それには同意する。 開発プロセスの文脈でもフロー効率を重視するためのプラクティスは一般的だと思う。スクラムの言葉に従えば、スプリントゴールはなるべくシンプルにひとつにしようとか、ひとつのプロダクトバックログアイテムを複数人で片付けようとか、そういった話である。チームの付加価値生産性を最大化するために、こうしたやり方を採用するのは素朴には理にかなっていると思う。しかし最近、メンバーの育成や評価に対する責任が大きくなってきて、その立場から改めてこれらのプラクティスを考えると、手放しに最高とは言い切れないなと葛藤している。
会社のミッション、あるいはビジョンやバリュー、スタイル、大事ですよね。でも、いざ決めようとするとどうしたらいいか分からない😮💨 特にスタートアップは、プロに外注せず、自分たちで決めるというほうが多いと思います。「ミッションを作りました！」という策定後の話は多くみかけますが、実際に “どう決めるのか” の策定プロセスが分かる事例は少ないです。 今年2024年ワンメディアは創業10周年を迎えまして、ミッション・スタイルを刷新しました。実は、着手から刷新まで約1年間くらいかかりました。最初はワークショップでみんなの時間を無駄に使い、一度頓挫し、その間に人事担当が退職するなど… さまざまな壁に直面しましたが、結果「良いミッション・スタイル」を策定できました。 この1年間の迷走(？)経験から「いかにポエムにならず、機能するミッション・スタイルをつくるか？」をプロセス多めで紹介していきます。特に
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 受託開発において、必ずしも発注者側がプロダクトオーナーになる必要はないですし、現実的には発注者がプロダクトオーナーになると機能しないことが多いです。 その理由は以下のようなものです。 忙しくて、プロダクトオーナーの仕事をこなすのに必要な時間が取れない発注者側の社内の関係者の影響を強く受けやすい発注側のマインドセットのままで、開発者と対立構造となってフィードバックループが形成されない上記と同じく、プロセスを無視して、要求を押し付けてしまいやすいそもそもソフトウェア開発のことに詳しくない結果的に、開発者たちがプロダクトの価値を理解できなかったり、プロダクトバックログアイテムごとの意図が分からないままに開発しなければいけないような
仕事をしていると、だんだんと抽象度の高いことを任されるようになる。 たとえば、方針も明確な小さな修正タスク => 修正方法がいくつか考えられるタスク => そもそも何をやるかから明確にしないといけないタスク といった感じで次第にふわっとした依頼になってくる。いわゆるグレード制を採用している会社において、"どれだけ抽象度の高い仕事を任せられるか" がグレードの違いの要素のひとつと言ってもいい。 抽象度の高い仕事を安心して任せられる人は何が違うのか自分もよくわからないので、自分のまわりの人がどういう動きをしているかを雑にまとめてみる。 1. なぜやるかを明確にしている わからないときはドキュメントやチャットのやりとりを探し、直接聞いたほうがよい人には自分でコミュニケーションを取っている やる理由がないと判断したら依頼者に話をして、実際にやらないこともある あとで「自分はこう言われただけなので」
リソース不足によるデスマーチは珍しくもありませんが、そうしたプロジェクトが真に崩壊する時は目標の達成の見込みが無くなった時です。 具体例として名前を出して申し訳ありませんが、過去の特許庁や京都市のシステム更改案件などが典型です。 デスマーチに陥ったプロジェクトにおいて、出来ることと出来ない事を整理し、優先順位をつけて対応するのは重要な事です。しかし、その結果目標達成の見込みや効果が見いだせなくなった時、モラルハザードに陥りプロジェクトは急速に崩壊に向かいます。 その意味で、全国のシステム標準化プロジェクトは今極めて危うい状況です。 "全国のシステム標準化事務に従事する自治体職員に伝えたい事"にも書きましたが、システム標準化の表向きの目標は標準化基準への適合ですが、真の目的は国の重点計画にあるトータルデザインの実現です。 言い換えれば、今多大な労力をかけてこのシステム標準化を遂行し、標準化基
最近、システム開発はこうあるべきだよなって考えていたのと、他所のエンジニアリング文化についての記事を見たことから、自分にとっての今の理想と現実の間について整理して吐き出しておきたくなりました。 所詮理想ではあるものの、自身の環境におけるベストに近づけようとする思考や、ベストに程遠い状況を認識する、ということには意味があるのではないかと思う次第です。 はじめに 自分は100％WEB系出身ですが、全く異なる文化である SIer 方面のお話を読むのはわりと好きで、これらは興味深く読ませてもらいました。 誰も教えてくれないSIの本質、SIerの世界観 日本のSIerの技術力の低さの要因から考えるアメリカソフトウェアの強さ – きしだのHatena プログラミングが設計作業であるという話 – きしだのHatena ソフトウェアの「詳細設計書」とはなんなのか – きしだのHatena だいたい SIe
2024/9/2 LayerX 全社週次定例 LayerX 部門執行役員 AI・LLM事業部長 中村龍矢 https://x.com/nrryuya_jp
スクラムガイドの目的 スクラムは複雑なプロダクトを開発、提供、保守する為のフレームワークである。このガイドではスクラムを定義している。定義には役割、イベント、作成物とそれらをまとめるルールが含まれている。フレームワークの各要素は特定の目的を有し、スクラムによって実現される価値と成果にとって不可欠な要素となる。スクラムの考え方や構造を変えたり、要素を省いたり、ルールを無視する事は問題を隠し、スクラムから得られる価値を限定したり、無意味な物にしてしまうのである。 Ken Schwaber と Jeff Sutherlandはスクラムのフレームワークを作る事に重要な役割を担った。 LeSS（大規模スクラム）は複数のチームでプロダクト開発をする際にスクラムを適応し、組織のシステムが変化した結果として形作られ、LeSSはLeSSルールにて定義をされている。LeSSルールは、各チームのレベルではスクラ
チームのパフォーマンスを高めるために、日々試行錯誤している方も多いと思います。私自身も、プロセス改善にこだわり続け、うまくいった部分もあれば、失敗を経験した部分もあります。今回は私のチームリーダーとしての失敗談と学びを共有したいと思います。 チームリーダーとしての責任Tebiki株式会社 エンジニアの二瓶と申します。私は Tebiki株式会社の Web アプリケーションエンジニアとして入社し、現在は tebiki現場分析 の開発を担当しています。また、チーム内では「チームリーダー」という役割 を担っています。弊社のチームリーダーのミッションはざっくりいうと「生産性とプロダクトの品質を最高の状態に保ち、プロダクトの価値を最大化できるような『チームの状態』をつくること」です。ここでいうチームとはプロダクトマネージャー、デザイナー、エンジニアを含む開発チームことです。これまで一人の開発者として手
日々多くのタスクに追われるビジネスパーソンにとって、「24時間をどう使うか」はスキル・キャリアアップのための重点テーマです。業務効率化しながら自己研鑽の時間を捻出する方法について、普段から考えを巡らせている人も多いでしょう。 会社員のかたわら、漫画家として商業誌への連載を続けてきたピエール手塚さんも、時間の上手な使い方を徹底して模索してきた一人。会社では管理職としてマネジメント業務もこなしながら、スキマ時間を漫画制作にあてることで、月2回連載を継続しています。そこには時間を作り出すためのさまざまな工夫がありました。 今回はそんな手塚さんに、日々の時間の使い方はもちろん、手の動いていない時間を減らす方法、やる気が出ない時のマインドセットなど、時間をうまく使うためのテクニックや極意を学びます。 ピエール手塚さん。会社員、漫画家。30代で漫画を描き始め、同人誌即売会に出展。同人誌『ねえママ あな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
