2024.12.11 エンジニア組織のリアルな失敗経験から学ぶ！ 生産性向上＆チーム強化Tips
2024.12.11 エンジニア組織のリアルな失敗経験から学ぶ！ 生産性向上＆チーム強化Tips
これは Kyash Advent Calendar 2024 1日目の記事です。 2022年1月から VP of Engineering という役割でKyashの開発組織全体のマネジメントを始め*1、2024年1月から 執行役員 VP of Engineering になり1年くらい経ちました*2。 当初は「今までどおりいいプロダクトを作っていけるように行動していくだけだし大きくは変わらん」と思っていたのですが、想像以上に変化もあったので備忘として残しておきます。 ここに書ききれないこともたくさんあります。「1年近くやってこんな抽象的なことしか書けないのか」と感じられるかもしれませんが、まああまり背伸びせず反省も込めて今のスナップショットをそのまま書くことにします。 結果として事業はよくなっている Kyash のようなカード発行型の決済サービスというのは、決済単体の収益性で見ればいわゆる "
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。 [Ateam Lifestyle x cyma Advent Calendar 2018]の5日目は、株式会社エイチームライフスタイルの@gonjyu121が担当します。 はじめに最近のWEBサービス運営チームというと、事業運営や企画営業のチームと、エンジニアチームが一緒になって働く事が多いですよね。 そんな時、多くのエンジニアが、 「品質保持やリファクタリング、改善系のissue（タスク）の優先度がなかなか上がらず、着手できない・・・・・・」 といった悩みを抱えがちです。これなんですが、非エンジニアの皆さんからすると、 「エンジニアがすごいのは分かるんだけど、何をやってるか、なんでこんな時間がかかるのか、正直分からないんだよなー」 と思っていたりします。こんな話、
ここ数年、組織の拡大に伴い、過去にはやらなかった取り組みを始める機会が増えた。特に大きな変化の一つが、デザイナーやエンジニア、ライターといったクリエイターたちの作業時間や作業項目を細かく記録する「工数管理ツール」を全社導入したことである。 工数管理のメインツールとしては、freeeさんが提供している「freee工数管理」を使用している。 UIに優れた便利なツールで、Googleカレンダーと連動させることでかなりの入力を自動化できるが、プロジェクト単位や人単位の集計など、標準機能では提供されていないレポートもあったので、このツールで出力されるデータを元にプロジェクト別/人別に表示できるツールも自作した。 なお、このツールを、freeeさん協力の下、外部にも販売することになった。ご興味がある方は、文末にも掲載しているLPからお問い合わせください。 導入の経緯 業界によっては、「なんでこんな当た
決めていいと知らないどこまで決めて良いのか分からないのであれば、決めようがない。権限の委譲ができてないことが多いので、デリゲーションポーカーなどを利用すると良い。 提案を覆され続ける次のようなことを繰り返すと、「お伺いを立てたほうが早い」となる。 チームで決めたものを持っていくと「それじゃダメだ」と言われる 懸念点や問題点の起案をすると「今それは考えなくて良い」と無視される 決めた対応方針を伝えると「こうやって進めて」と別の指示がされる ある程度進めた後で全部仕事が引き継がれて全部書き換えられる 当然ながら、これが続けば「どうせ調べたり考えても無駄だから、全部最初から聞いてしまったほうが早い」となる。 決めさせる難しさ多くの場合上司の方が経験も知識も多く視野も広いため、90点がとれる案が脳内にできあがっている。一方で、部下が出してくる案は70点程度の場合が多い。そして上司は90点がとれる案
次の記事が最近公開されたので、読んでみました。 結論としては、例えば同著者の「良いコード／悪いコードで学ぶ設計入門」という書籍と比較すると、だいぶ受け入れやすい主張になっていると感じました。（以前の書籍についてのコメント記事へのリンク） ところで、私は「良いコード」についての議論や指摘や検討を積極的にやったほうがよいと思っていますが、主に「消耗しない」という観点でこの記事についていくつかの構造理解やテクニックの部分で補足できそうだったので、以下補足していきます。 ざっくりとした主張でいうと、 トレードオフに見える部分は学習・教育で解決できるケースも多くある 品質特性への還元が難しいがコードの良し悪しを定める概念がある Webアプリにおいても再利用性は必要だし、モバイルアプリでも再利用性を求めて失敗することがある 再利用性というよりは、現実に即した概念の線をどこで引くかのバランスを大事にする
マネジメントを4年くらいやっている間に、何人かにEngineering managerや採用のリードなどの役割をお願いして担ってもらってきた。何か新しい役割をお願いする時に整理して伝えている項目を雑にまとめておきたい。 以下のようなGoogle docsを作って共有し、30分のミーティングで直接伝えて考えてもらうようにしている。タイトルは「◯◯さんにxxをお願いしたい」みたいな感じ。項目や内容は相手によって適宜変えてる。 これは何 「◯◯さんにxxをお願いして一緒にやっていきたいと考えています」みたいな感じでストレートにお願いしたい役割を書く 「命令ではなく、なぜお願いしたいか、何をお願いしたいかなど◯◯さんに意思決定する材料を渡すためのdocsです」のようにまだあくまで提案ですよということも書く なぜ今お願いしたいか プロダクトや組織の状況も踏まえて、"今"お願いしたい理由を書く その役
はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回：技術的負債はなぜ生じるか。 第2回：ソフトウエア開発を「制御」する意外な処方箋 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。 第1回：技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り
はじめに 事業としてソフトウェア開発を行う企業にとって、自分たちの開発チームの生産性が十分に高いのか、あるいはそうでないのかについては大きな関心があります。 そのこと自体は、何かを計測し、改善するというのは営利企業としては健全です。一方で、ソフトウェアエンジニアリングの世界で「生産性の高さ」だと主張できる汎用性の高い指標は存在しません。こういった状況の中で、「生産性」を巡る議論は経営やビジネス部門とエンジニアチームとの間で繰り広げられ、場合によっては大きな不和や不信感につながることも珍しいことではありません。 今回は、エンジニアの開発生産性について、さまざまなステークホルダーと議論する上で把握しておきたいさまざまな論点について解説します。それによって、「我々が本当に議論すべきテーマは何か」についての共通認識をつくるための土台を構築することを目的としています。 もしかしたら改善したいことは「
社内で書いた内容から、一般化できる話だけを抜き出して書いた記事です。 TL;DR 意思決定者は、 仕様が複雑になればなるだけ、指数関数的かつ継続的にコストがかかることを理解する必要がある。 ユーザーの要求や利便性について優先順位をつける必要がある。 それらを揃えた上で「いっちゃんいいバランスで顧客要望に応える」必要がある。 コストについて サービスあるいは機能の一生 サービスあるいは機能は以下のライフサイクルを辿る 初回リリース以前 初回リリース以後、クローズ以前 クローズ 実は一番コストがかかるのが「初回リリース以後、クローズ以前」の部分。なぜならサービスの一生のうちほとんどの時期がここなので……。 初回リリース以前にかかるコスト いわゆる「初期開発」が行われる。 当然、この時に仕様がシンプルであればあるだけ初期開発にかかるコストは低くなるし、仕様が複雑であればあるだけ初期開発にかかるコ
神戸市は、行政データの利活用にいち早く取り組んできました。2022年6月には、行政データで作成したダッシュボードにアクセスできるポータルサイト「神戸データラウンジ」を庁内の職員向けに開発。庁内メンバーが閲覧できる90種類以上に及ぶ全てのダッシュボードは、職員自ら、BIツール「Tableau」で作成しています。翌年には、国勢調査のオープンデータをダッシュボード化して、一般ユーザーが閲覧可能なデータポータルサイト「神戸データラボ」で公開し、話題となりました。 自治体というレガシーなイメージのある世界のなかで、どうやってTableauを使いこなす職人集団が生まれていったのか？その根底には、技術コミュニティの理念が大きく影響していたようです。 現在最前線で活躍する職員、そして最初にTableauを庁内に導入し、たったひとりで3年間「種まき」をし続けたキーパーソン本人に、それぞれ取材しました。 ke
【エルサレム共同】米紙ニューヨーク・タイムズは18日、レバノンで一斉に爆発した民兵組織ヒズボラのポケットベル型通信機器は、イスラエルがハンガリーに設立したダミー会社で情報機関員が製造していたと報じた。
10年近く5～6人のチームで回してきて、いくつか自分で学んできたことの中で、 今でも心がけているものを紹介する。 異動により今の環境が大きく変わるため、自分自身の整理の意味も込めてまとめてみた。 優秀な部下は大勢の前ではなく、一対一のときに褒める。優秀な部下は嫌でも目立つ上に、誰の目から見ても明白な成果を継続して上げていることが多い。 そんな部下を例え大きな成果を上げたからといって、 その部下と同列の者の前で大きく褒めると、他の部下の向上心が下がりやすい。 これは対象の部下本人のためというより周りのためだ。 普段優秀でない部下の大きな手柄は、大勢の前で褒める。本人の自信にも繋がる上に、周りから能力を認められているという肯定感が強くなる。 いい意味での周りからのプレッシャーとなり、仕事に対する姿勢も変わってくる。 結果が出ない者は姿勢や努力を褒める。結果として大きな成果に繋がらなくとも、そこ
生産性向上 公開日 2022/06/09最終更新日 2022/06/09 知らず識らず陥っている「パーキンソンの法則」とは？現状のチェックと対策の実施で生産性を高めよう Share IT人材不足が課題となっている昨今、多くの企業が人員不足を感じています。しかし、その人員不足は嘘かもしれません。これは、人は時間とお金があればあるだけ消費してしまうという「パーキンソンの法則」に陥っている可能性があるためです。この状態になっている場合、対策を行うことで生産性を向上し、人材不足を解消できる可能性があります。 ここでは、パーキンソンの法則とは何か、どういう状態がパーキンソンの法則に陥っていると言えるのか、また、この法則に陥っている場合どのような対策方法があるかを解説します。 パーキンソンの法則とは パーキンソンの法則とは、イギリスの歴史学者・政治学者のシリル・ノースコート・パーキンソンの1957年の
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
リモートで働くようになって、当然だけど雑談が減った。 適度な雑談は必要だと思っている。雑にコミュニケーションとっておくと仕事で絡む時も楽だし、課題や改善の話がポロッと出たりもする。入社したばかりの人は馴染みやすくなるし、マネジメントする人はチームの状態を把握しやすくなる。HIGH OUTPUT MANAGEMENTの中でもフロアをうろついて話しかけるみたいな話が書いてあった気がする。 フルリモートになって色々工夫してみたけど対面より優れたやり方がまだ見つかっていない。現時点でやってみたことや考えてることを書き出してみる。 自由に参加できる雑談の予定を週一でセットして話す 参加するメンバーが固定化されてしまってあまりワークしなかった そもそも「雑談」という予定を入れた時点で全然雑じゃなくて、なんだか真面目な感じになるというジレンマを抱えている 入社したメンバーと職種違うメンバーを数人指名して
最近、システム開発はこうあるべきだよなって考えていたのと、他所のエンジニアリング文化についての記事を見たことから、自分にとっての今の理想と現実の間について整理して吐き出しておきたくなりました。 所詮理想ではあるものの、自身の環境におけるベストに近づけようとする思考や、ベストに程遠い状況を認識する、ということには意味があるのではないかと思う次第です。 はじめに 自分は100％WEB系出身ですが、全く異なる文化である SIer 方面のお話を読むのはわりと好きで、これらは興味深く読ませてもらいました。 誰も教えてくれないSIの本質、SIerの世界観 日本のSIerの技術力の低さの要因から考えるアメリカソフトウェアの強さ – きしだのHatena プログラミングが設計作業であるという話 – きしだのHatena ソフトウェアの「詳細設計書」とはなんなのか – きしだのHatena だいたい SIe
チームのパフォーマンスを高めるために、日々試行錯誤している方も多いと思います。私自身も、プロセス改善にこだわり続け、うまくいった部分もあれば、失敗を経験した部分もあります。今回は私のチームリーダーとしての失敗談と学びを共有したいと思います。 チームリーダーとしての責任Tebiki株式会社 エンジニアの二瓶と申します。私は Tebiki株式会社の Web アプリケーションエンジニアとして入社し、現在は tebiki現場分析 の開発を担当しています。また、チーム内では「チームリーダー」という役割 を担っています。弊社のチームリーダーのミッションはざっくりいうと「生産性とプロダクトの品質を最高の状態に保ち、プロダクトの価値を最大化できるような『チームの状態』をつくること」です。ここでいうチームとはプロダクトマネージャー、デザイナー、エンジニアを含む開発チームことです。これまで一人の開発者として手
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
