GitHub - cto-a/dxcriteria: DX Criteria: the Criteria for Two DXs (Digital Transformation and Developer eXperience)You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
「ノウハウを囲い込むベテラン社員問題」について。
入院患者向けの治療食を製造する会社で、仕事をしていた時の話。 病院給食といえば、味は薄い、献立も魅力がない、まずい、という先入観が定着している。 が、中身はしっかりしていて、国家資格である管理栄養士が献立を立て、また患者に対し栄養指導を行うことが法律で義務づけられている。 病状に応じて制限されるミネラルや栄養などを計算し、また必要なカロリーや栄養を充足させ、その上で1食あたりのコストを経営的な要求に収める必要もある。 その上でもちろん、患者さんを食事として楽しませる技術も要求される。 それはとても、高度な仕事だ。 だが、どれだけ栄養的に基準を満たし、コストの範囲内に収めても、パンに味噌汁を添えて出したら患者さんはやはり怒り出す。 そこには患者さんを楽しませる、「ノウハウ」が不可欠だ。 だから、どんな国家資格にも言えることだが、資格を取り立ての新卒がすぐに通用するような現場ではない。 多くの
マネジメントとエンジニアリングの両立が難しいのはなぜか？のたとえ話 - 文字っぽいの。
与太話です。 数ヶ月前、マネジメントをしながらメイン機能の開発をしていたら完全にタスクがオーバーフローして大変なことになったんですよ。 その時に「両立が難しいのは分かったが、なぜ両立が難しいんだろうか。」をひたすら考えていたら思いついた「たとえ話」です。 素潜り漁師と漁船で例えます。 エンジニアリングは素潜り漁 コードを書いているときは集中して潜りきらないといけない エンジニアが割り込みを嫌うのはこのため 途中で呼び止められたら潜水をやめて浮上しないといけない 割り込みが終わったらまた潜り始める 難しい機能を作る時ほど深く潜らないといけないというイメージ 深さと釣果には相関がないので深ければ大漁というわけではない ただ、深い漁場は素人の素潜り漁師が到達できないので、漁場が荒らされていなくて釣果が期待できる 浅めの場所を複数箇所どんどん潜って数を稼ぐタイプがいる フルスタックエンジニアみたい
良いテックリード、悪いテックリード - 小さなごちそう
本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v
今はコードがお偉いさんなんだからMOBは雁首揃えろって話 - アンカテ
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ Mob Programmingって初めて聞いたけど、とてもいい方法に思える。 コードを書く時に、今現在の仕様はわかっていたとしても、今後どうなるか、どういう方向に発展するのか気になって、ビジネス的にその分野に詳しい人の所に聞きに行ってから書きはじめることがあるし、性能的に大丈夫かDBに詳しい人の意見を聞いたり、何か迷った時に過去のプロジェクトで似たようなケースをどっちの方法で解決したか調べたりすることもある。 書き出すとすぐ終わる短いコードでも、書き出す前に、聞きにいったり議論したりする時間が随分かかっていることもある。この時間をかけないと、結局、後で変更になるので、先に聞きにいくのがベターなんだが、チーム全員集まってひとつのコードを書けば、そういう時間を省略できるような気はする。 だから、これが生産性が高いということは感覚的に
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
サービスか受託か。Webサービスを作るということ | F's Garage
先日、某SIコンサル社にいる方が、まだ転職を悩んでるという前提でのカジュアル面談に臨んだ。その人の転職理由というのは、僕が受託の会社から転職した時に言っていたこととそのままだったので、是非、本面接に進んで欲しいと思った。 その一方で、受託からWebサービスに来る人に、よく言うことして、 「受託からWebサービスに来ると、ファンタスティックな案件がなくなってつまらないかもしれないですよ」 と言う話をする。これはどういうことか？というと「技術的チャレンジ」を求めるならば、筋の良い受託の会社にいる方が楽しくて、Webサービスはコードを書いている瞬間から技術的なレガシーを産んでおり、先々に渡って最初の選択の影響を受けるので、あなたの技術力の定義が「話題の言語でコードを書けること」であるならば、Webサービスはあんまり勧めません、という話をする。 当時僕がいた会社は、技術の共通化がまだ進んでおらず自
ブラック企業の見分け方（IT企業編） | 株式会社アクシア
ブラック企業への風当たりはますます強くなるばかりですが、５月１０日に厚生労働省が長時間労働や賃金不払い等の労働関係法令に違反した企業のリストを公式ホームページにアップしました。 ブラック企業リスト、厚生労働省が334社を公表 今後は毎月更新 この情報については実はこれまでも全国の労働局のホームページには個別にアップされていたのですが、今回の件は全国ばらばらになっていた情報を厚生労働省が一つのリストにまとめてアップしたというニュースです。 全国で３３４件というのは随分と少ないんじゃないかとか、何で俺の勤めてる会社が入っていないんだとか、色々なご意見があるかと思いますが、電通のような話題性のあるニュースにまでならなくとも、ブラック企業はこうして会社名が公表されてしまうリスクがあるわけです。ちなみにこのリストの中にはあの電通の名前ももちろん入っています。 またこんな記事も出てました。 すぐに辞め
AWS事業部の採用方針について | DevelopersIO
主にクラスメソッドメンバーズにおけるサポートサービスとフートシリーズ（運用保守オプション）を担当するグループです。運用保守、システム監視、セキュリティ監視、継続的コンサルティングと、システム稼動後のお客様インフラを24時間365日体制で安定した状態に保つために日々お客様とやりとりしています。 このように、一つの部の中に担当業務が違う複数のグループがありますが、部全体のビジョンはただ一つ、「AWSに関する圧倒的な量のノウハウを用いて、AWSインフラを安く早く構築し、AWSのことをまるっとお任せしてもらうことで、お客様のビジネスに貢献する」です。そして同じビジョンを掲げたチームとして、採用方針もグループ毎に分けず、部として統一しています。 今回はAWS事業部の採用方針をご紹介します。 AWS事業部の採用方針 AWS事業部の採用方針は以下の3つです。 技術が好きな人を採る クラスメソッドはエンジ
タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話
何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、本格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に
SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から
スタートアップに向く人、向かない人（エンジニア編）｜えとみほ
先日、機械学習のエンジニアを募集する広告を出したところ、複数の人から「旦那に頼めばいいじゃん」と言われた（知り合い以外の方のために説明すると、私の夫は工学の博士号を取っているソフトウェアエンジニアである）。 確かにスキルマッチング的にはドンピシャではあるのだけど、夫とは実際に半年ほど働いてみて、すぐに一緒に働くのは無理だと断念した。少なくとも、今のスタートアップのフェーズでは、彼の能力や経験を生かしきれないと思ったからだ。 スタートアップに必要なのは「雑でもいいから速い人」先に少しだけ夫のバックグランドを話すと、彼は20代後半まで大学の研究室で働いており、その後私と出会ったVR系のベンチャー企業に転職し、30代前半でソーシャルゲームの会社に2回目の転職をした。職歴としては、そのソーシャルゲーム会社での経験が最も長いと思う。 ソーシャルゲームの会社では、ゲームの開発ではなく、不正なユーザーを
エンジニアの技術力評価は難しい? - 5年間運用してきた技術力評価制度の改善の歴史 ‒ / Regional SCRUM GATHERING Tokyo 2017
Jan 12, 2017 @ Regional SCRUM GATHERING Tokyo 2017
「人間より組織構造にフォーカスを」伊藤直也が解く、チームなのに“1人”になってしまう謎
チームなのに「1人」になってしまう構造 伊藤直也氏（以下、伊藤）：ちゃんと作っていくものやミッションと組織の構造をきちんと合わせていきましょうというのが、マネジメントの基本としてものすごく大事です。しかし、形を合わせただけでは、その通りに機能してくれないことがあります。 これはKaizen Platformにいたときにあったことですが。Kaizen Platformは内製組織らしく、さっきみたいにプロダクトマネジャーが真ん中にいて、エンジニアがいて……という構造になっていて、各ユニットごとにきちっと切ってありました。 しかし、よく見ると、各ユニットのなかではエンジニアが3人くらいずついますが、エンジニア同士があまり一緒に仕事をしていないんですよね。 そこで、エンジニアと1:1の面談をして「最近どう？」と聞くと、「う～ん、なんか最近1人で仕事している感じですね」とみんな言っていて、「あれ、な
日本のサラリーマンの褒められなさは異常｜NZ MoyaSystem
先日、筆者のこちらのツイートが突然反響を得始め、一晩で50リツイートを超えました。 ニュージーランドで働いていると、日本って褒められない社会だなって感じる。 きちんと仕事していても「ありがとう」「よくやった」って言われること少ない。 失敗すると「なにやってるんだ」「再発防止策を考えろ」って厳しく詰められる。 最近良く見た例のニュースと一緒だな。 — はっしー@NZプログラマ (@hassy_se) June 15, 2016 ニュージーランドに限らず、海外で働いた経験のある方からもかなり共感していただけて、多くの方が感じていることだとわかりました。日本で働いてて、ほめられる機会ってなかなか無いですよねー。 ほとんど褒められなかった社畜時代 筆者は現在、ニュージーランドでプログラマとして勤務していますが、以前は日本の某SIerでシステムエンジニアとして働いていました。 ひと月の残業時間がだい
強い組織をつくるための7つのヒント | ライフハッカー・ジャパン
『社長！ すべての利益を社員教育に使いなさい』（大西 雅之著、あさ出版）の著者は、日本最大規模のインドア型テニススクール「ノアインドアステージ」（以下ノア）の代表取締役。右肩上がりで成長を続けているといいますが、その秘密は社員教育に関する考え方にあるようです。 社員教育にはできるだけ時間や人を投資するというのが、わが社のスタンスです。（中略）ですから、「社長はすべての利益を社員教育に使いなさい」は、偽らざる本音であり、経営者として目指しているゴールです。（「はじめに」より） とはいえ、最初からそういった考えを持っていたわけではなく、以前はむしろ正反対の方向性だったのだとか。かつては成果主義にとらわれていたため、従業員の仕事を「成績」だけで評価し、「社員の幸せ」＝「給料」と割り切っていたというのです。その結果、幹部社員6人が示し合わせて退社するという事態に。 そこで、この"事件"をきっかけと
Slackでイラッとしない、コミュニケーションのコツ - 雲ようかん
社内コミュニケーションツールとしてサーバーワークスではSlackを使っています。 Slackは便利な一方でテキストでのコミュニケーションは注意が必要なため、以下のようなガイドラインがあります。 否定しない 叱責しない 2回で伝わらなければf2f これはこれで大事なのですけど、やっぱりちょいちょいイラッとすることってありますね。言葉の言い回しってテキストではより重要です。文章はニュアンスが伝わりづらいので誤解を招きやすく、それを見た相手が不愉快さを感じるとその後に少なからず影響する。それが積み重なるとコミュニケーションロスが発生する。悪い循環です。 Slack見てると、それが上手い人と下手な人っています。でもよく見るとちょっとした言い回しくらいしか違いがありません。3つほど紹介します。 1. 語尾をちょっと緩める 語尾を少し口語というか緩い感じにするだけで随分違います。 ＊＊＊してください。
Slackにハッシュタグ的な「ゆるく情報をまとめる方法」が欲しかった話 - コネヒト開発者ブログ
【後日談】 qiita.com ソースコードを公開しています〜、もしよろしければご一緒にどうぞ！ Slackの話をします ご無沙汰しております。 コネヒトでPHPを書いている金城 / @o0h_です。 突然ですが、皆様Slack大好きですか。 起床すると真っ先にSlackの赤い丸を消しに行く生活を送っていますか。 コネヒトではSlack大好き従業員・役員が多く、この中で日々色々なやりとりが繰り広げられています。 そんな風にSlackを使っていると、「もっとコレしたい」「アレできないの」が溢れてきます。 先日の島田の記事でも、その一例を紹介いたしました。 Slackの情報が「まとめにくい」問題 非常にフロー型の情報・交流に適したツールだな、と思うわけです。 パッと言える。スッと目に入る。 そうすると、「その場で思いついたアイディア」などを刹那的に投げつけていきたくなります。 ・・・が、その速
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう？（あるいはいったい何がないのだろう？）
開発組織マネジメントのコツ - Speaker Deck
