ソフトウェア開発における学習性無力感 – 作業環境の改善 | POSTD
暗闇を呪うよりも、ろうそくに火を灯そう 過去24時間で、私の2つ記事、 Why Your Programmer Just Wants To Code（なぜ、あなたのプログラマはコーディングだけをしたがるのか） と A Wake-Up Call For Tech Managers（テックマネージャーへの警鐘） は、Mediumで96,000回以上読まれました。また、 Redditのコメント数も900を超えています 。 思っていたよりも、問題は深刻のようです。 そう、テック企業には悪いマネージャーもいます。そして、私はそうしたマネージャーに辛辣です。プログラマの無関心の責任は、直接的に彼らにあると思っています。 フラストレーションがたまり、何の権利もないと感じながら思考停止に陥っているプログラマを私は助けたい。 上記コメントの 圧倒的 大部分を投稿したのは、これを読んでいるプログラマの皆さんで
知識が無いからこそコードレビューで指摘をしよう - Qiita
初めに 私は他人にダメ出しできるほど優秀なプログラマーではありません。おわり。 先進めなくなるので続けます。チームで開発するようになって約３年。自分ダメダメだなーとは思いつつも、自身の成長を一番感じたのがコードレビューだったのでこんな記事を書くことにしました。 個人で開発している方や、各々が完ぺきなコードを書けるチームにいる方、１分１秒の時間が惜しいプロジェクトにいる方(そこまで行くとコードレビューちゃんとされているかわかりませんが)には向かない内容となります。また、捉え方によっては馬鹿が優秀な人の足を引っ張ることにも見えますので、自分の環境に合わないと思う方は参考にしないでください。 とおもったら、会社としてやってるところもあるんですね。 https://qiita.com/awakia/items/8344ba751426e386e0f5 他にも、かっちりしたレビュー記事はたくさんある
製品ロードマップの使用をやめて、GISTプランニングを試すべき理由 | POSTD
何年にも渡り、私は相応量の製品戦略、ロードマップ、プロジェクトガントチャートを作成しました。しかし、もうこれらの資料を作ることはありません。以下に説明する優れた代替策を見つけたからです。 まず、以前のやり方はこちらです。 注釈： 戦略 ロードマップ プロジェクトプラン 実行 アジャイル このプランニング方式だと膨大な仕事が必要です。株主全員の同意を得るだけでも大変だと言うのにROIはかなり低くなります。プランはあっという間に現実と一致しなくなり、期間が長いほど、乖離も大きくなります。私の作ったすてきなロードマップやプロジェクトガントチャートが公開する時点で既に古くなっていると気づいたのは、少し経ってからでした。このプランニングもウォーターフォールのひとつなので（有名な ウォーターフォール・モデル とは異なります）、即応性はほとんど期待できません。トップで変更があると、それが波及しボトムでの
コードレビューのレビューはマネージャーの仕事 | POSTD
経営に関する名著「 High Output Management （邦題：ハイアウトプット・マネジメント（＝高い成果を可能にするマネジメント））」の中でAndy Groveは、”トレーニング（訓練・教育）はマネージャーの仕事”であり、組織の成果を向上させるためにマネージャー（経営者・管理者）が実践できる最高のレバレッジ活動だと述べています。 多くの組織のマネージャーにとって、この言葉は現在においても参考にできる素晴らしいアドバイスでしょう。しかし、現代のソフトウェア開発チームのマネージャーに関して言うと、その中心となる考え方はシフトしています。 > エンジニアリングチームの成果向上にとっては、GitHubのプルリクエストなどで実行するコードレビューが、今では最大のレバレッジポイント（レバレッジの作用点）である。 品質管理以上の役割 従来、コードレビューのプロセスは品質管理のツールと見なされ
全然わからない。俺たちは雰囲気でマネージャーをやっている。 - アルパカログ
自分は今、コード書かずにマネジメントしかしてなくて、そんなポジションの人にそれほど価値ないでしょ、とか思ってしまうけれど、こういうポジションの人がいないチームの話とか聞くと、やっぱりいたほうがいいんじゃないか、と思うし、ほとぼりが冷めるとまた自分は無価値のように思えてしまう。 こんな心境の吐露を「エンジニアリングマネージャのキャリアについての悩み」で拝見して、私も何か発信しなければと思ったのがこの記事のきっかけである。筆者のdaiksyさんは、 エンジニアマネージャってなんか実績を示しづらいので、世の中の数多のマネージャ職に埋もれて、自分にスポットが当たりづらい、結果、キャリアに不安が拭えない、みたいなとこないです？ とも述べていて、これら2つのメッセージに込められた心の葛藤は、全てのエンジニアリングマネージャー(以下EM)が感じていることではないかと私は思う。少なくともEMの一人として私
日本にアジャイルが普及しづらい本当の理由〜不確実性に向き合うマネジメント論〜 - Qiita
はじめに こちらの記事は、技術評論社に寄稿させていただいた「エンジニアリング組織論への招待」をご紹介するための文章です。Qiitaにも再掲しておきます。 アジャイルって何だ？ 「ウォーターフォールよりもアジャイルのほうがいいのか？」そんな言葉をIT企業の経営者から聞くことがあります。2000年代の後半くらいから、日本国内においてもアジャイル型の開発プロセスが注目を浴びて、多くの企業が実践するようになりました。 ところが、世界各国に比べて日本のアジャイル型開発の普及率は依然として低く、理解度も進んでいません。流行っているからやってみようと始めた企業も流行りが変わると今度はリーンだとか、今度は○○だといったように新しい方式を導入してみては失敗するところも珍しくありません。 アジャイル開発の専門家ですと名乗る人の話を聞いてみても、それが何なのか、けむにまかれたような説明をされてしまい、いまいち納
「階層がないフラットな組織」より「階層があり、社員が自分の役割を越えて動き回る組織」のほうが強い説、を考える。｜面白法人カヤック 人事部
「階層がないフラットな組織」より「階層があり、社員が自分の役割を越えて動き回る組織」のほうが強い説、を考える。 まとめ・階層がない組織にも、非公式な階層はできている。 ・平時は組織の階層を活かして動き、有事は階層を気にせず自分の役割を超えて動くような社員を増やすのが良さそう。 ・「自分の役割を越えて動く」を社員に学習させる方法があるはず。そうしないと、結局組織が硬直化する。 ・「役割を超えて動く方法」を学習してもらうために、新入社員にしってもらうことをまとめてみた。階層がない組織にも、非公式な階層はできているカヤック社外人事部の神谷さんが行った勉強会の資料から抜粋してみよう。 フラット化の課題 ・ 階層は今も基本的構造のままであり、マネージャーに権威があり、公式的な階層が無い場合でも隠れた階層が存在すること、階層を受け入れ、それを調整しなければ組織における仕事が進まないことを指摘(Levi
ボロボロのチームを立て直したエンジニアリングマネージャーのお話 - もくもくプロダクトマネジメント( @Nunerm )
久津（@Nunerm）です。リクルートでPM/EMをやってます。 この記事はEngineering Manager vol.2 Advent Calendar 2018の15日目の記事です。 普段このブログではプロダクトマネージャーに関する記事を書いていますが、エンジニアリングマネージャーも担っているので、この記事ではEM人格で語ります。 さて、エンジニアリングマネジメントにまつわるエピソードには様々なものがあります。ゼロからチームを作り上げた話、初めてEMになって試行錯誤した話、新しいやり方を装着しようとして失敗した話などなど… 今回は私は「ボロボロのチームを立て直した話」を書きます。このシチュエーションと似た経験をされた方がどれくらいいるのかわからないですが、何かしらヒントを得ていただけたら幸いです。 ※なおこの話はリクルートの話ではありません。とある別の企業での話ですのあしからず。
美しいソフトウェアをなぜ、どうやって書くか - Qiita
最近、デザイナー（兼ほとんどエンジニア）の先輩と話していて確信したのが、ソフトウェアデザインはエンジニアが相手のデザインであるということです。デザイナーとエンジニアがやっていることに似通っていることがいろいろと挙がりました。 ソフトウェアも良さを「美しい」とか「きれい」とか表現すると思います。でも美しさ難しいです、人それぞれあると思います。僕の中で思っている美しさがなんなのかを吐き出してみます（実際この通りに書けてるか、これが本当に美しいのか、とか言われるとちょっとドキッとしそうなので自戒の念も込めて・・）。 なぜ美しいソフトウェアを書かねばならないのか ハッカーと画家（翻訳版）に出てくる一文（原文はSICPからの引用）です。 「プログラムは、人々がそれを読むために書かれるべきである。 たまたま、それが計算機で実行できるにすぎない。」 以下はハッカーと画家からの前後の引用です。 ソフトウェ
No Managers, Yes Agile. ～アジャイルなプロジェクト管理とは～
2012/12/22(土)の社内で開催した「プレゼン祭り」で発表した内容です。アジャイルに全く触れたことが無い人を対象にしたつもりが、「難しい」「内容が盛り沢山で覚え切れなかった」「寝ちゃった」などなどとあまり好評ではなかったのですが、自戒の念も込めて公開しておきます。 対象は「ウォーターフォール開発しか体験したことのない経験5〜6年程度の若者」です。 ※2022/04/11追記 Speaker Deckに移行しました。 https://speakerdeck.com/takigawa401/toriaesu30fen-tehitotoorifen-katutaqi-nihanareruasiyairuru-men
失敗プロジェクトの弔い方 - @ledsun blog
プロジェクトを燃やした経験から、どうすれば有効なふりかえりができるのか考えてみました。 要約 失敗プロジェクト参加者の信用を回復 失敗プロジェクトの撤退戦術を共有 失敗プロジェクトの回避方法を検討 背景 「社内の失敗プロジェクトを振り返って今後に活かそう」みたいな会があったので失敗のポイントを明確にすべく張り切って他のPMに質問しまくってたら「そんな傷口を抉るようなことするな」と怒られが発生したので人間界には主旨はなく気持ちだけがあると悟った回。— モーくん (@calfscalf) 2017年5月9日 を見て考えました。 外野から見たら、確かにまったくこう見えると思います。 なぜ、傷口を抉るようなことをするなと言いたい「気持ち」になるのでしょうか？ 失敗プロジェクトの当事者の立場 デスマると、渦中の人は如何にして心を折らずに終戦までもっていくかがんばっている。社内からは、あいつらのせいで
なぜプロジェクトは炎上するのか？vol.1～それはスカウターが故障してるから～ - Qiita
私自身これまで複数の開発案件でプロジェクトマネジメントをしてきました（開発もするプレイングマネージャー的な感じで） ※マネジメント規模は数人～60人規模まで様々（システム開発・ソーシャルゲーム開発が主） これまでプロジェクト炎上案件の立て直しを何件も実施してきました（立て直しは一番やりたくない…） 今回は「なぜ炎上するのか・どうしたら炎上しないのか」に焦点を当てて、炎上案件について共通点や回避策など実際の実例を交えて複数回に分けて纏めておこうと思います（※現職がゲーム開発なので、ゲーム開発を例にして記述します） みなさんの周りに何も解決できない「なんちゃってPM」はいませんか・・・？ ※スカウターの話は後半で出て来ます プロジェクトが炎上する理由 いきなりですが、プロジェクトが炎上する理由は プロジェクトマネジメントしている人間のマネジメントスキルが低いから です。 「そんなの当たり前だろ
経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 - Qiita
デリゲーションポーカーを作った プランニングポーカーみたいに権限委譲を促進するカードゲーム、「デリゲーションポーカー」をいきおいでつくった。さらにLINEスタンプも作った。 カードゲーム販売ページ LINEスタンプ販売ページ デリゲーションポーカーの元ネタはこちら参照 権限と責任の話 経営者マインドが足りない！の欺瞞 よくネットで炎上しがちなひとが「経営者マインドが従業員に足りない！」というようなアメリカ人には大和魂がない！的なそりゃそうだろとしか言いようのない言説を口にします。 この表現はさておき、このような言説を口にしてしまう背景には何があるでしょうか。このような人はきっと自分の会社の従業員にもっといろんなことを任せていきたいと思っているのでしょう。 ところが、そのような期待値をしっかりと部下に対して伝えることができていないため、メンバーも自分自身の成長のタネがどこにあるかわからずに、
「龍角散」復活 左遷された女性開発者が原動力に｜出世ナビ｜NIKKEI STYLE
1998年の発売以来、医療・介護の現場から家庭まで幅広く利用されている、龍角散の服薬補助ゼリー。薬を飲みやすくするために開発されたゼリー状のオブラートで、世界35カ国1地域で特許も取得している。福居篤子執行役員が生みの親。一連の開発で多くの賞を受賞する一方、左遷も経験している。逆風にへこたれず、それを力に変えた彼女の実力を見込んで役員へ引き上げたのは、現社長の藤井隆太氏。服薬補助ゼリーシリーズ開発の軌跡を通じ、一時は倒産の危機に瀕した老舗企業を、2人のリーダーはどう蘇らせたのか。証言を基に振り返った（次回「『独裁』は悪いですか 龍角散を再生した音大卒社長」参照）。 ◇ ◇ ◇ 臨床薬剤師としての病院勤務が原点「製薬会社はどうしてこんな飲みにくい薬を作るのだろう？」。龍角散執行役員の福居篤子氏は臨床薬剤師として病院に勤務していた頃、よくそんなことを思っていたという。 薬が嫌だ、飲みたくな
派生開発推進協議会（AFFORDD）
2021年 [06/17] 派生開発カンファレンス2021のプログラムページに講演中のQ&Aを公開しました。new!! [06/17] 派生開発カンファレンス2021開催報告を公開いたしました。new!! [06/08] 派生開発カンファレンス2021の講演動画をYoutubeのAFFORDDチャンネルに登録しました [06/08] 派生開発カンファレンス2021のプログラムページに講演資料を公開しました。 [05/18] 派生開発カンファレンス2021に意見交換会の実施を追加しました。 [04/12] 派生開発カンファレンス2021の参加受付を開始しました。 [03/04] 派生開発カンファレンス2021のスポンサー募集を掲載しました。 [01/17] 派生開発カンファレンス2021の発表募集を掲載しました。 [01/17] ET2020 AFFORDDセッション 開催報告を公開いたしま
エンジニア組織がない会社でエンジニア組織を立ち上げるためにやった3つのこと - Qiita
LITALICO CTOの岸田崇志(@takish)です。 2017年のアドベントカレンダーもついに最終日となりました。 入社して2年経ち、エンジニアも順調に人数が増え、新卒採用からの育成、そして新規事業ラインへのエンジニアラインがスケールアウトできるようになってきました。 特に前職ではインターネット事業の急激な成長を経験したので、エンジニア育成サイクルの礎を築いて置くことの重要性は身にしみて感じていたので、最初からそれを念頭に組織を組み立てています。 はじめに 筆者はエンジニア組織の立ち上げは3回目なので「デジャヴ？！」と感じる事も多々あり（笑）、既視感ありまくりの2年でした。 一方で既視感があるということは、どこも成長のフェーズにおいて同じ課題に直面するということでもあるという事でもあります。 そのため、そのような経験を基に過去失敗した轍をもう一度踏まないことを心がけました。 成長フェ
非エンジニアのマネージャがエンジニアチームと上手くやる方法 - Qiita
近頃の世の中の流れは恐ろしい。全業種ソフトウェア企業にならないと競争力が維持できない。 “寝たときは製造業、朝起きたらソフトウェア企業” by Werner Vogels（CTO, Amazon.com）at AWS re:Invent 2017 Key Note という恐ろしい話は管理職に落ちてくるので、「寝たときは製造業のマネージャ、朝起きたらソフトウェア企業のマネージャ」になれるのか？を考え始めるべきです。 元銀行員で非エンジニアで、いつのまにか開発ツールベンダーにどっぷりの私の経験からのTips を共有します。 エンジニアの方は、非エンジニアのマネージャにしれっとリンクを送ってあげてください（笑） 結論： 目標もバスの走らせ方もバスに乗せた優秀な人たちに任せて、バスの整備をする人になる。 マネージャが「何をつくるか？」の決定権を持てるのは彼/彼女が優秀なエンジニアの場合だけです。非
「君は今日から人工知能開発部門のリーダーだ！」と言われた時の処方箋 - Qiita
いわゆる人工知能技術が巷をにぎわす昨今、人工知能を研究する部署/団体を設立するのがトレンドになっています。もちろん、部署の設立にはそれをマネジメントする人間が必要です。「その時」は突然やってきます。 「わが社でも人工知能技術を研究しビジネスに役立てるべく、新しい部門を設立することになった」 「はい」 「ひいては、君にその部門のマネジメントを任せたい」 「！？」 「将来的には100人規模にし3億円規模のビジネスにしたいと思っている(※)。まずは中期計画を作成してくれ」 「そ、それは・・・」 「部門設立のプレスリリースは来月発行される。よろしく頼むよ(肩ﾎﾟﾝｯ」 (※: 好きな数字を入れてください) (from 疾風伝説 特攻の拓) 本文書は、実際こうした事態が起こった時に役立つチェックリストとして機能するようにしてあります。具体的には、以下の構成をとっています。 設立編: 何を「目指す」の
会議/ミーティングについて本気出して考えて見た結果 - Qiita
はじめに 「会議だけで一日終わっちゃったよ・・・」と言うワードを聞く頻度が増えました。 前々から、会議なんとかしたいなぁと思いつつも、どうやればいいのかな？ってのをいまいち理解できていなかった＆良い機会なので、ちょっと力入れて調べ/考えてみました。 結論 まず結論を述べておきます。たった2点です。 1.「適切な振り返り」を行うこと 適切な振り返りとは、「基準を明確にし、測定し、データに基づいた振り返りを行うこと」。 そして、この「適切な振り返り」は、会議だけに留まらせず、基本的な仕事のスタンスにさせていくこと。 2.日頃からチーム力を上げておくこと 人間心理として、会議に対する心理的負荷は大きい。心理的負荷を下げ、効果的な会議を行うには、日頃からチーム力を上げておくことが効果的である。 チーム力を上げるには、「心理的安全性（チームのメンバー一人ひとりがそのチームに対して、気兼ねなく発言でき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サイボウズのPC標準機はどれもメモリ32GB積んでるって、正直ムダじゃないですか？ | サイボウズ式
