"開発体制"投稿一覧

jun

エンジニア

コントロールチャートを使ってざっくり各ステップのリードタイムをメンバー全員で眺める時間を作ってます。
あくまでそれは問題点や改善の糸口を探る為なので、糸口を見つけた後に深堀りしていきます。

大井竹昭

データ分析

データの利活用を中心としたコンサルをやっております。

マイクロマネジメントにならないようにするには、信用することです。

指示としては、アウトプット像、その為のアウトカム例を明示することです。
それだけで不穏な顔をする人には、実現方法をアウトカム例を実演してみせるになります。

アウトカムの実現方法は同じやり方をなぞっても良い... 続きを見る

大井竹昭

データ分析

データ利活用を中心としたコンサルをやっています。

「ITの知識がない人に、業務システムの開発」は難しいと記載いただいています。まさにその通りです。

ですが、『業務を知らない人に、システムを作ってもらう』のも正直手戻りが大量に発生します。予算や開発期間がかなり余裕を持たれている場合にはそれも良いでしょうが、実際のプロジェクトでは責任を問われて外されるのがオ... 続きを見る

大井竹昭

データ分析

私はコンサルなのでコンサル的な手法で失礼します。

クライアントサイドに立ってみると、失敗しているのは全員が自覚していますし、とは言え昔のこととは言え先輩の責任を明確に言葉にしたらそれを理由に足を引っ張られたり、と言うのが派閥のある大企業です。

そして、わからせるとありますが、これも無理です。気づかないで放置してた責任を問われているやうなものなので、うまく... 続きを見る

北山 淳也

エンジニア

- どれぐらいのものをどれぐらいの期間で作る必要があるのか
- どれぐらいの期間運用する可能性があるのか
- どんなメンバーで開発する必要があるのか
- メンバー内のスペシャリストが引っ張れそうか

「メンバー内のスペシャリストが引っ張れそうか」は割と議論が巻き起こるというか、「今はメンバー内の誰も詳しい人がいないが、（流行っている技術だから/これ... 続きを見る

Miyashita

エンジニア

まずはChatGPTの有用性や可能性を話して、ChatGPT賛同派を増やす活動をしています 笑
ちょびっとだけ触っただけだと「こんなもんか」と否定的に捉える人も多いので、味方を増やしています。

北野勝久

エンジニア

私たちの会社でも10%ルールとしてゴキゲンチャレンジという制度を運用しています！金曜日午後の時間を開発本部全体でおさえる運用をしているので、普段関わりがないチームの人といっしょに仕事する機会なんかにもつながっています。

「新しいことをみんなに気軽に試してほしい」という文化をつくりたいと思った場合に、「そういう方針・標語をどこかに打ち立てる」という選択肢もありますが、まずはみん... 続きを見る

杉田大樹

プロジェクトマネジメント

マネジメントする組織のメンバーがある程度自律して任せられる状況であれば、おおまかな目指しどころと推進イメージをインプットして任せてしまいます。（何かあったら責任はこちらで取るので思うままにやってみてほしいと伝えます。）
一方メンバーの構成要素の中でまだ未熟なメンバーの割合が多い場合はある程度マイクロマネジメントにならざるを得ないなと感じております。（タスク化を一緒にやる、悩み相談などのフ... 続きを見る

Taketo Yoshida

エンジニア

私の所属している会社にもあります。だいたいはe-learning（最近だとML）のビデオ見たりしてますね。自分の仕事では使わないところを勉強してます。

まきやま

エンジニア

まさに20%を採用しています。
時間を取って取り組むべき負債解消や、エンジニア個人のWillを実現する仕組みという位置づけになっています。

私が取り組んだものではありませんが、アプリのウィジェット対応などもこの仕組みから生まれていたりします！

厳密に20%という計測などはしておらず、プロジェクトのチケットと自身のベロシティを踏まえて自主的にやる... 続きを見る

山本隼汰

エンジニア

あまり積極的に活用できてる感はないのですが、以下の様なことはすでにやってます

・copilot 導入
・ChatGPT でドラフト版の記事作成（ブログ等）

山本隼汰

エンジニア

マネジメントしようとしないことでしょうか。変に力が入ってしまうとマイクロマネジメントになってしまうし、ぼーっとしてると放置・放任してるだけになってしまうため、ある程度、細部については無関心になりつつ、自分が相手に期待するゴールイメージを明確に持っておくことが重要かなぁと思ってます。（「うまく行った時のビジョンが見えているか」を自問自答しています）

そうするために、「最悪ここま... 続きを見る

tomo

エンジニア

20%ルールとはちょっと違うのですが、似たような感じで、チームが直接業務以外のことに時間を使って、
新しい学びを得るなど、自己・チームの成長や未来への投資になるようなアクティビティは他にも色々あります。

- ハッカソン
- ボランティア コーディング
- 自己学習の日
- 修正タイム(バグ、リファクタなど)
- ハックアワー(... 続きを見る

Dai Fujihara

プロジェクトマネジメント

レガシーなシステムの相談はよく受けています。ただ、仕事になるか？というとそうでもないなぁという印象です。なぜなら、問題が難しいからだと思います。外部からとやかくいうのは簡単ですが、現場には現場なりの問題があります。これを理解して、良い方向に持っていくのは、おっしゃるように骨の折れる作業です。

ただ、仕事上、どうにかして良くしたいので、いくつかアプローチとしてやっていることはあ... 続きを見る

Dai Fujihara

プロジェクトマネジメント

僕の場合は、マネージャになって、なんでもかんでも自分がやるには限界を感じたので、チームが自律して動ける方法を考えるようになりました。社会人であれば自立しているはずなので、個人やチームでの自律を目指します。

自律を促すためにポイントのひとつが、インプットとアウトプットです。

たとえば、インプットとして、こちらが相手に期待するものを伝えます。それはふるまいか... 続きを見る

北野勝久

エンジニア

Copilot / Copilot for Business がありますが、企業内での導入という観点だと、 Copilot for Business を利用しないと適切なルールを構築することは難しいのではないかな、と思っています。
ですので Copilot for Business 導入にあたって、参考となりそうな観点を書いてみます・・・と思ったんですが、最近、とても便利な整理をしてくだ... 続きを見る

Shoichi Namba

エンジニア

対応しないことに伴って発生する損失を数値にして明確に示してあげる必要は最低限あるかもしれません。これをやらずにそのままやるのと、やってからやるのは費用的に、時間的にこれだけ異なる、という部分です。
また求人の難しさ、人を入れてもやめていってしまう可能性の高さなどでわかりやすく。
（と言ってもだめな場合も多いと思いますが…）

北野勝久

エンジニア

毎年、読んでよかった書籍を整理していますが、次の機会にまとめるなら入れたいと思っている書籍を3冊紹介してみます。

Engineering Manager になってから身に沁みた12のアイデアと言葉
続きを見る

Dai Fujihara

プロジェクトマネジメント

10年ぐらい開発のリーダーやマネージャを経験しています。

エンジニアリングマネジメントは、エンジニアリング ＋ マネジメントになると感じています。だから、「エンジニアリングマネジメント」を学ぶ方法もありますし「エンジニアリング」と「マネジメント」を学ぶ方法もあります。
自分の場合は、後者を選びました。なぜなら、エンジニアリングマネジメントはまだ新しい分野だとおもいま... 続きを見る

山本隼汰

エンジニア

【課題】
チームのキャパシティがどれくらい、どんなプロジェクトに消費されているのかが見えないことによって、現実的にどこで遅延が発生したり、チームメンバーの非効率が発生しているかが把握できなくなっていた。それによって、非効率の感じ方が定性的なものとなっており、個人間に差異が生まれ、個人レベルで生産性効率化の施策を打つにとどまっていた。自助努力による改善ばかりが進み、目線が合わなくなっていく... 続きを見る