タグ

開発と仕事に関するcalpoのブックマーク (12)

  • 「私考える人、あなた作業する人」の関係をつくっているのはあなたかもしれない

    Regional Scrum Gathering Tokyo2023 の中の moyiyuya さんの「私考える人、あなた作業する人」というセッションが大きな反響を呼んでいました。 スクラムを導入してチームとして一体感をもってプロダクト開発をよりうまくやっていきたかったはずなのに、いつの間にか「私考える人、あなた作業する人」という関係性ができてしまっていた、という相談を受けることがあります。 なぜこのような「私考える人、あなた作業する人」という関係性が生まれてしまうかについて、コミュニケーションの観点で考えてみます。 プロダクトオーナーと開発者の堺目 「私考える人、あなた作業する人」のような関係性が生まれてしまっているチームでは、開発者からプロダクトオーナーに対するコミュニケーションが以下のようになっていることが多いです。 プロダクトバックログを出してくれたらつくります 仕様を決めてくれた

  • 「勝手に学ぶ人」と「期待されて学ぶ人」の差が埋められない|柴田史郎

    ここ1年ぐらい感じていた「学びに関する格差」の話を書く。 最初にまとめ・勝手に学ぶ人は、自分の周囲にある「学びに使えそうな仕事」を探して自分の仕事にすることを繰り返す ・期待されて学ぶ人は、上司とかの期待に応えて新しいことを学ぶ ・「勝手に学ぶ人のスピード」>「期待されて学ぶ人のスピード」なので、格差が開いていく ・「早く行きたければ一人で行け、遠くへ行きたければみんなで行け」が実現できない ・勝手に学ぶ人を止める理由も見つからない ・困ったなあ(解決策わからない) では詳細を書いていく。 勝手に学ぶ人:自分の周辺にある「誰も手をつけてない仕事」を発見し、自分の学びに利用するそれぞれが自分の担当範囲の仕事をしているとする。 それぞれが自分の担当範囲の仕事をしている勝手に学ぶ人は、「誰も手をつけてない」かつ「自分の学びになりそうな」仕事を自ら発見して、自分の仕事として取り組む。 勝手に学ぶ人

    「勝手に学ぶ人」と「期待されて学ぶ人」の差が埋められない|柴田史郎
  • 技術的負債とステークホルダと説明責任と / The Debt

    Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801

    技術的負債とステークホルダと説明責任と / The Debt
  • さよならアーキテクチャ議論|Seiji Takahashi@ベースマキナ

    ポエム。 つまり?予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん

    さよならアーキテクチャ議論|Seiji Takahashi@ベースマキナ
  • 仕事を任せられるエンジニアになるために意識してほしいこと - 食べチョク開発者ブログ

    皆さんこんにちは。エンジニアの西尾です。 今日は仕事を任せられるようなエンジニアになるために意識してほしいことをまとめましたので、ここに公開いたします。 もともとは社内向けに公開したものです。 この文章は私がビビッドガーデンに入社する前の、前職での経験を踏まえて書いています。 今のべチョクエンジニアが意識できていない、という話ではありませんのでご注意ください。 意識面 作業の見積もりができる 技術力が低い(コーディングができないなど)よりも敬遠されるエンジニアは、作業の見積もりができない方です。 第一線で活躍している方は、作業見積もりが他の方に比べて正確です。 見積もりをするためには、どういう設計をして、どういう機能を作り、どういう影響範囲があるのかを正しく理解する必要があります。 見積もりができないということは、作業内容を正しく理解できていない、技術的な困難性を理解していない、不確定要

    仕事を任せられるエンジニアになるために意識してほしいこと - 食べチョク開発者ブログ
  • 心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein

    心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein

    心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
  • 組織に流れるフォースを間接的にコントロールする仕事 - @i2key のBlog

    Recruit Engineers Advent Calendar 2018 - Adventar ということで、エンジニアリングマネージャー的なことを書いてみます。1on1とか採用とか評価制度とかではなく、組織力学のような話を。 フォースを感じる 自分は普段からエンジニア組織をマネジメントする際に「構造によって発生する力学」をすごく意識しています。いま、大体100人弱の社員エンジニア組織をマネジメントしているなかで、役割上、判断する仕事がかなりの割合をしめます。その判断でどんな力学が発生して最終的に現場で何が起こるかまで可能な限り想像力を張り巡らさないとならないです。そして、この想像力において、どれだけ解像度を高くできるかこそが現場感だと思います。経験がないと何がおこるか想像すら出来ないと思うので。 ビジネスにおける意思決定で発生したフォースは徐々に伝搬し、最終的にエンジニアの現場に流れ

    組織に流れるフォースを間接的にコントロールする仕事 - @i2key のBlog
  • IT関連産業の給与等に関する実態調査結果を取りまとめました(METI/経済産業省)

    経済産業省及び独立行政法人情報処理推進機構(IPA)では、今後我が国産業の成長にとって重要な役割を担うことが期待されるIT人材の給与等の実態について、IT関連企業とIT人材の双方に対してアンケート調査実施し、その内容について分析を行いました。日、その内容を調査報告書として取りまとめました。 背景・問題意識 第四次産業革命と呼ばれる技術革新の進展の中、IT人材は、IT関連業界のみならず、あらゆる産業において必要とされてきており、人口減少とあいまって今後ますます不足することが見込まれています。優秀なIT人材の獲得競争は、業界・国境の垣根を越えて激化しつつありますが、こうした競争を制する為には、IT人材をどう評価し、処遇するかが重要な要素です。 上記の背景を踏まえて、経済産業省は、IT関連業界における給与制度や採用等に関する現状及び課題について把握し、今後の施策の検討材料とすることを目的として

  • 闇のDevOps DevOpsと業績評価 – ところてん – Medium

    ここから、DevとOpsが協力すればより効率的になる=DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか? ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート(設置作業員、サポートセンタ)には、大量の人員が必要になってきます。 したがって、組織を研究

    闇のDevOps DevOpsと業績評価 – ところてん – Medium
    calpo
    calpo 2017/02/16
    "DevOpsはOpsの仕事をDevが奪うこと"
  • 4ヶ月の間に一休.comで起きた変化 - zimathon blog

    概要 最近いろいろな方(社内、社外含め)に、エンジニアチームどうですか?良くなってますか?という質問を頂きます naoya さんってどうなんですか?やっぱりすごいですか?とも その度に「良くなってますよー」と返事をするのですが、肌感としてはあるもののしっかり言語化できていない そこで、naoya さんがCTOとして今年の春に一休に来てからをちょっと振り返ってみた 振り返ってみるとたった4ヶ月ということに驚いています :eyes: 良くなったと感じていること サービス開発の体制 技術基盤への投資 採用活動 情シスの整備 エンジニアの働く環境 それぞれについて サービス開発の体制 抱えていた課題 マーケティングとエンジニアとの間のコミュニケーションが上手くいかず、開発速度やサービスの意思決定のボトルネックになっていることがあった みんなで話して決める等、それぞれの役割が曖昧なままで開発を進める

  • プログラマが問題を解くということ - Cybozu Inside Out | サイボウズエンジニアのブログ

    サイボウズ松山開発部の門屋(@ryokdy)です。サイボウズ製品の開発をなんやかんややっています。今日は、プログラマが問題を解くということについてお話したいと思います。 問題を知る 開発チームには、日々、様々な要望が送られてきます。サポート部門からであったり、営業からであったり、時には社長から直接、この機能を搭載して欲しいと言われることもあります。 お客様からの声はありがたいもので、思いもよらなかった使い方や、製品の至らない点に気付かされることが多々あります。 ですが我々はたまに、「んー当はなにがしたいのか分かりません」と答えます。「はあ? だからこの機能が欲しいんですよ」「でもその機能で何が解決したいのか分からないんです」みたいな会話が続いた挙句、「ユーザーがそう言ってるんだから黙って作りゃあいいんだよ」みたいに怒られることもあります。 たとえば、メールにドラッグ・アンド・ドロップでフ

    プログラマが問題を解くということ - Cybozu Inside Out | サイボウズエンジニアのブログ
    calpo
    calpo 2012/11/15
    本当にやりたいことや困ってることを上手に引き出して、なんならコードは書かずに解決したい。
  • ふつうの受託開発チームのつくりかた

    "Business Model canvas", "Empathy Map", "Lean Canvas" のワークショップのスライド(仮)masashi takehara

    ふつうの受託開発チームのつくりかた
    calpo
    calpo 2012/11/12
    よくあるgithubが使えない問題の解決にも…「業務で使うライブラリをオープンソースとして作ってGithubに公開。チームメンバーはGithubアカウントを持ちそれを使ったりPullRequestしたり」
  • 1