自立自走型チームの構築と心理的安全性を高める施策 - Qiita
はじめに ※大層なタイトル書いてるけどただの日記みたいなもんです ※あくまで個人の見解であり、所属する団体・組織の見解ではありません 現在自分は客先常駐型でエンジニアの派遣を行う事業をメインとする会社で、小規模ながら社内で受託開発を行う部署に在籍している。その組織の仕組みは「プロジェクトマネージャー」と「組織の管理職という肩書としてのマネージャー」が兼任になることが（自分も含め）ほとんどだった。なんでもできるマネージャーがタスクを分解、できそうなメンバーにアサインし、メンバーはタスクをこなすのみに注力という構図で、以下のような問題が起こっていた。 マネージャーが非常に多忙でSPOFになるケースが多々。とてもじゃないが休めない できる人のみにタスクが集中し、できない人は本当に何もしてない メンバー間での責任の押し付け合い マネージャーからメンバーに対する高い圧力 やる気があるメンバーのモチベ
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
「ソフトウェア開発データが語るメッセージ2017」を公開～ソフトウェアの信頼性は向上するも生産性は低下傾向～：IPA 独立行政法人 情報処理推進機構
概要 独立行政法人情報処理推進機構ソフトウェア高信頼化センター（以下、IPA/SEC）は2018年3月6日、「ソフトウェア開発データが語るメッセージ2017」（以下、本書）を公開しました。 本書は、「ソフトウェア開発データ白書2018-2019」（2018年10月発行予定）作成用に収集した最新のプロジェクトデータに基づいて、ソフトウェア開発の傾向を分析したものです。 分析の結果、ソフトウェア開発の信頼性は向上しているものの、ソフトウェアの品質に対する要求の高まりにより、生産性は低下傾向にあることが分かりました。また、生産性・信頼性の向上には定量的管理を推進し、品質要求レベルに見合った生産性目標を設定すべきこと、さらに、要員の人材育成が重要であることが分かりました。 背景と目的 近年、ソフトウェアの大規模化／複雑化が進む一方、信頼性向上、生産性向上、開発期間短縮等の要求は高まっています。この
選定した技術が1年で死んだ話 | そど
今年の夏頃から、特にサービスとして出すわけではなく、社内で使っているシステムのリプレースを行う事になりました。主な目的はレガシーすぎる設計をある低度モダンにする事、そして他のシステムと連携出来るようにする事、です。 対象のシステム 見積書や請求書などを管理・発行している。機能はそれなりに多いがUI操作はFormベース、テーブルタグで諸情報を表示するシンプルな物。ノンフレームワークで1画面1PHPファイルな古き良き時代のコード。おそらく10年ぐらい？稼働している。当初はPHP 5.1、PostgreSQL 8.x系だったが、現在はPHP 5.6とPostgreSQL 9.6で稼働しています。 その他の社内システム かつてはノンフレームワークだったり、太古のバージョンのCakePHPだったり、PHPが4系だったりしたが、概ねCodeIgniter 3系最新版 + PHP 5.6～7.1 + P
イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ
「社内横断の技術組織を終わらせました」から8カ月。あの経験から見えた「組織課題の解決法」と「無価値にならないエンジニア」の条件 - GeekOutコラム
「社内横断の技術組織を終わらせました」 こんな告白エントリーに見覚えのある方もいるのではないでしょうか。 このエントリーの主は、サイバーエージェント子会社のCyberZ所属で、国内No.1スマホマーケティングツール「F.O.X」サービスマネージャーの門田矩明さんです。 門田さんは、2017年の1月にこのようなエントリーも書いています。 ■CyberZ全社横断の技術組織「技術戦略室」はじめました 残念ながらこの技術組織は3カ月ほどで解散してしまいますが、その後に書いた「記録」としてのエントリーが多くの人の心に響き、広がっていきました。しかし、この後どうなったのかについては、あまり語られていないように感じられます。 そこで、今回は門田さんへ「横断組織が終わった後」について、お話しいただきました。 インタビューの中で見えてきたのは、自身の経験を踏まえたうえで門田さんなりに考えた「横断組織論」、そ
長時間練習…それでも体育会系指導が勝てないワケ : 深読みチャンネル : 読売新聞（YOMIURI ONLINE） 1/5
【読売新聞】 「根性」「忍耐」「絶対服従」……。いわゆる「体育会系」的な体質を特徴としてきた中高生らの部活動が、変革を迫られている。スポーツ庁は、部活動の「休みが少ない」などの問題を改善するためにガイドラインを作成し、「スポーツを楽
「ずっとむなしい、なにもなく終わる･･･」 マツダの天才エンジン技術者、大逆転の軌跡（前編） | 日経 xTECH（クロステック）
日本の自動車技術者で、最も有名な一人が人見光夫だ。エンジン一筋38年。マツダ躍進の中核を担う、「スカイアクティブ（SKYACTIV）」エンジンの開発を率いてきた。世界シェアが2％に満たない“小兵”のマツダが、世界のエンジン開発競争で先頭を走る――。10年前、誰が想像しただろう。 人見がマツダに入社したのが1979年。スカイアクティブの実用化が2011年だ。57歳になっていた。会社人生の最終コーナーで、華々しい成果を生み出した。天才技術者とも称される。だが入社して長い間、ふてくされていた。 モチベーションなんて、なかったですよ。ずっとむなしいだけ。金くれるんだからまあいいわ、くらいに思って働いてました。 ひとみ・みつお。1954年生まれ。岡山県出身。1979年東大院修了後、東洋工業（現マツダ）に入社。一貫してエンジン開発に携わり、2000年パワートレイン先行開発部長。2011年執行役員、20
社名変更のお知らせ
Fringe81株式会社は2021年10月1日より、Unipos株式会社として生まれ変わりました。 コーポレートミッションを「感情報酬を社会基盤に」と新たにし、ピアボーナスをさらに発展させ、感情報酬を社会実装して社会の基盤とすることを最上位の目標として掲げ、邁進して参ります。 5秒で自動的に切り替わります。切り替わらない場合は以下のボタンをクリックしてください。 Unipos株式会社サイトへ
「マネジャー・管理職」を外注化する流れが始まっている。
こんにちは。コワーキングスペース「Basispoint」の運営会社、AscentBusinessConsulting代表者の北村です。 コワーキングスペースを運営していると、数多くのコンサルタントや、フリーランスの技術者、起業家などにお会いします。 最近は働き方改革の影響もあり、そういった方々から「働き方」についての話を伺う機会も多いのですが、その中で、特筆すべき最近の動きは「マネジャーの外注化」です。 どういうことかというと、言葉そのままなのですが、「プロパーのマネジメントを、外注にやってもらう」という会社が増えているのです。 プロパーのマネジメントを、外注にやってもらう これは、従来の常識から言えば、「ありえない」選択肢でしょう。 マネジャー、つまり管理職は社内で「出世」した結果、ありつけるポストとされているからです。 しかし、最近ではどうも様子が異なるようです。 例えば、成長途上のベ
「巨大プルリク1件vs細かいプルリク100件」問題を考える（翻訳）
本記事では、昔ながらの問題である「巨大なプルリク1件と超細かいプルリク100件、どっちなら戦う気になれる？」に対する回答を示したいと思います。チームの一員としてよりよいコードを書くためのガイドラインについてもある程度解説します。今回の記事は、すべて以下のツイートから触発されました。 10 lines of code = 10 issues. 500 lines of code = "looks fine." Code reviews. — I Am Devloper (@iamdevloper) November 5, 2013 何が問題だったか 私は、Fullscript社で行われているコードレビューが今ひとつ活用されていないことに気づきました。featureブランチが長期間取り残されていることがしょっちゅうでした。featureブランチのコードは数千行にまで肥大化し、まともなフィードバ
「アジャイル導入」や「プラクティス導入」といった大きい一歩を踏み出してうまくいかないと嘆くあなたに送るたったひとつのアドバイス
はじめにこの記事は一年くらい前に書きかけて放置していたのだけど、市谷さんが同じようなことを言ってるスライドをアップしていたので、二の矢として挙げることにする。 プラクティス導入がうまくいかない！！これまでも多くの人がそうだったし、これからもきっと多くの人が同じような状況に陥ると思われるのでメモしておく。 「現場でXXXを実施してみているのだがうまくいかない」という話は、色々なところで耳にする。XXXXはプラクティスでもいいし、スクラムでもいいし、ツールの導入でもいい。 例えば、プラクティスというのは、名前がついていて、各所で実践した例もいろいろあって、希望に満ち溢れているようにみえる。なので、ついつい手にとって試してみたくなる。TDD、ペアプロ、リファクタリング、カンバン、あー、たまらない！早くヤリたい！試してみたい！！ しかし、ぐっとこらえて、考えてほしい。 あなたが、その「キラキラ」し
企業内イノベーションの実現に向けた7つの提言 | Japan Innovation Review powered by JBpress
前回まで、イノベーションの「鶏卵問題」（ニーズが先かシーズが先か）に取り組むリーンスタートアップ手法、その中心にある「アジャイル開発」の歴史、そして、日本企業での課題について考えてきた。 （バックナンバー） 第1回「企画と開発が責任を押し付け合う会社の前途は暗い」 http://jbpress.ismedia.jp/articles/-/51448 第2回「『開発手法』だったアジャイルはここまで進化した」 http://jbpress.ismedia.jp/articles/-/51870 第3回「ビジネスに追いつけない日本のシステム開発の構造欠陥」 http://jbpress.ismedia.jp/articles/-/52025 イノベーションの創出には、スタートアップのような「小さなチーム」を作り、潜在顧客のニーズ探索と小さな製品開発から始めることが必要である。これは、欧米企業がシ
請負開発やめました
佐藤 潤です。 パソナテキーラは、請負開発を1年前にやめました。我々が得意とするアジャイル開発と請負契約との相性があまりに悪く、トラブルが避けられないと考えたうえでの決断でした。それによって、最初は取引のあったお客様が離れてしまったり、請負でないと提案すらできない商談もありましたが、1年かけて改革を進めた結果、自信を持って提案をすればお客様にも理解していただけるということに確信が持てるようになりましたので、あらためてなぜ請負をやめたのか、今回はちょっと詳しく書いてみようかと思います。 SIというビジネスの商習慣への疑問 請負契約の状況は悪化している 以前よりSIという日本独特のビジネスには違和感を持っていました。多くのシステム開発プロジェクトにおいて、構築するシステムの内容が決まっていないにも関わらず、サービス提供者（SI事業者）が要件定義から開発までを請け負いますが、なぜこんな商習慣にな
「プログラマの三大美徳」と「HRT」を使い分ける - 「コードを憎んで人を憎まず」 - TechとPoemeの間
TL; DR 「プログラマの三大美徳」はソフトウェアに向けるものであり，人に向けるものではない． 「HRT」は人に向けるものであり，ソフトウェアに向けるものではない． プログラマの三大美徳 プログラマの三大美徳というものがある．Perl を開発した Larry Wall が提唱したもので，「怠慢」「短気」「傲慢」からなる． 詳しくは上述のリンクにある各解説記事に譲るのだけど，例えば「怠慢」とは，「エンジニアとして手間を省くために最大限の努力をする気質」を指す．元の Larry Wall の記述では当たり前過ぎて省略されているのだけど，「最大限の努力」とは「仕事をしないために交渉する努力」ではなく「技術で手間を解決する努力」を指すものだと思われる (勿論，場合によっては前者が大事になるケースも有るのだけれど) ． 「プログラマの三大美徳は "怠慢", "短気", "傲慢" である」というワー
口の悪い人間をエンジニアとして採用するべきか
旧帝大の情報系の研究室を可もなく不可もない業績で出て、今年の4月からまあまあ大手のIT企業で働いている。 来年あたりから採用面接で学生と話すことになるかもしれないんだけど、表題の件についてインターネットの人達に聞いてみたい。 研究室でも、あるいはTwitterでも優秀（ここでは、たとえばトップカンファレンスにほぼ毎年論文を採択される程度の能力を指す）で口が悪い人はそれなりにいる気がする。そういう人ともし面接で話すことになったら、どう評価すればいいんだろうか。技術的に色々知っていて、日夜最新のトレンドに追いつくどころか更に先を行くために勉強/開発/研究に取り組んでいるが、自分がよくないと思ったものに対して「それゴミでしょ」などとバッサリ否定するような人を。 たとえば研究室にいる優秀な後輩は（その人が認めている）優秀な人とは普通に会話しているが、自分のような冴えない人間には冷淡で、Twitte
KPTにGを足して、スクラムで最強のチームを作る!! - 株式会社クラフトマンソフトウェア
クラフトマンソフトウェアでは、ShouldBeeの開発をアジャイル開発方法論のひとつである「スクラム」を使って行っています。 また、レンタルCTOサービスにおいてもスクラムマスターとしてスクラムの導入のご協力をさせて頂いています。 今回は、スクラムで最強のチームを作る方法を書こうと思います。 > KPTをGKPTにKPTをGKPTに ShouldBee開発チームでは、スプリントの振り返りの際にPDCAを行なうためKPTを採用しています。スプリントが進むにつれ、振り返りの文化が自分達のチームに最適なものとなってきました。KPTが派生し、GKPTという概念が生まれました。 KPTは、(Keep, Problem, Try)ですが、これにGoodを足してGKPTです。 Goodはそのスプリントでよかった事や達成したことを書きます。Goodの中から今後も続けていくことをKeepに移します。 > ど
非エンジニアのマネージャがエンジニアチームと上手くやる方法 - Qiita
近頃の世の中の流れは恐ろしい。全業種ソフトウェア企業にならないと競争力が維持できない。 “寝たときは製造業、朝起きたらソフトウェア企業” by Werner Vogels（CTO, Amazon.com）at AWS re:Invent 2017 Key Note という恐ろしい話は管理職に落ちてくるので、「寝たときは製造業のマネージャ、朝起きたらソフトウェア企業のマネージャ」になれるのか？を考え始めるべきです。 元銀行員で非エンジニアで、いつのまにか開発ツールベンダーにどっぷりの私の経験からのTips を共有します。 エンジニアの方は、非エンジニアのマネージャにしれっとリンクを送ってあげてください（笑） 結論： 目標もバスの走らせ方もバスに乗せた優秀な人たちに任せて、バスの整備をする人になる。 マネージャが「何をつくるか？」の決定権を持てるのは彼/彼女が優秀なエンジニアの場合だけです。非
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
起業家の勉強会にて『エンジニアは自身の趣味で開発請け負って金を稼げるので会社として払う給与は低くて良い』と主張する人が現れた
The competitive edge of DevSecOps - Highlight
