【DeNA／PayPay／マネーフォワード】波乱万丈伝から学ぶ！成長企業におけるデータマネジメントの勘所～大規模データ分析基盤の変遷～｜IT勉強会・イベントならTECH PLAY［テックプレイ］
イベント内容 データマネジメントの重要性がさけばれる中、その品質を担保する上でデータ分析基盤の構築は避けられません。 しかし、「導入してみたけれど運用工数がかかる」「データガバナンスや品質管理になかなか着手できない…」 「そもそも人が足りない！」など、様々な課題に直面している方も多いのではないでしょうか？ 本勉強会では、【DeNA社】【paypay社】【マネーフォワード社】のデータエンジニアが登壇！ 外部環境や組織体制の変化など、データ分析基盤を取り巻くその時々の課題をどのように紐解き、 具体策に落とし込んでいったのか等の経験を振り返り、データマネジメントの勘所をシェアしていきます！ 「やってしまった…」「あの時こうすれば良かった…」など、ここでしか聞けない波乱万丈伝が聞けるかも！？ タイムスケジュール 時間 内容
プロダクトマネージャの必要性 | F's Garage
とある創業社長のお悩みとして、 「いつも社員が考えた企画案を最後にひっくり返す役割になってしまう」 ということについて、胸が痛いという話をしていた。 こういう経験がある人は特にベンチャーでは少なくないだろう。親会社などからこれを食らうのは辛い話であるが、小さな組織でも、それなりにダメージはある。場合によっては、ワンマン社長の元で、好きなことができないと絶望してしまう人もいるだろう。 しかし、これについて、そのように見方を変えられるかが生き残りのカギである。 「社長にエスカレーションされるまで企画案の問題点に気が付かなかった企画、チーム、組織の問題」 と。 創業社長は、その会社で一番、そのビジネスについて考えている立場である。ちょっとやそっとで創業社長を上回るアイディアを出せると思ってる方が考えが甘い。ある意味、ひっくり返されて当たり前だと思うほうが話し早く進む。 ここでミニCEOと呼ばれる
組織としての「価値観」をシェアすること｜スズキアユミ（デザインメモ）
友人と出かけた際に、ひと休みのために入ったカフェでチームビルディングの話が白熱してだいぶ面白かったので、帰ってから改めて考えてみました。 組織の中での二極化 これ、あるあるなんだな…と思ったのが、組織である程度人数が増えた時に、仕事へのやる気の「ある人」と「ない人」で二極化が起きること。 ちょっと語弊が起きそうなので言い換えると、仕事へのやる気度が「高い人」と「低い人」。もっと言うと「上昇志向」派と「安定志向」派だ。 この双方は驚くほど、お互いに相容れない存在。歩み寄ろうとして話しても、互いに言語レベルで通じないので、下手すれば一騒動起きる。 経験をしたことがある人は、そもそも土台のような、根本が違うような感覚を持った人も多いはず。そう、そこから違うから、分かり合えるはずがないのだ。 だが、“組織”である限り、一緒に働く仲間である。どうにかしないと、分裂したままでは仕事にならない。 仕事の
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ
今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に３年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術
「ノーアジェンダ・どうしましょうか会議」の傾向と対策 - UNIX的なアレ
wadap.hatenablog.com 先日、こんなエントリーを書きました。割とエンジニアやデザイナーの方は経験したことがある会議ではないでしょうか。このワードに反応されていたので、少し掘り下げてみたいと思います。 「ノーアジェンダ・どうしましょうか会議」とは もうこの名前に全てが詰まってはいるので、経験したことがある人はすぐにわかるとおもうのですが、以下の点が揃っているとまさにその会議かと思います。 アジェンダが用意されていない とりあえず関係がありそうな人を呼ぶ 会議が始まり次第「どうしましょうか」的な空気が流れる ダラダラ長い 丸投げ感満載 というところでしょうか。会議そのものに主催者側の専門性があるものでは起きづらいのですが、自身が理解できない or 経験の無い領域の話になるとわりとこういう会議になりがちなのかなと思います。 会議の傾向 そしてこの会議が始まり「どうしましょうか」
社内横断の技術組織を終わらせました - nottegra’s blog
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
なぜプログラマはあなたの事が嫌いなのか - megamouthの葬列
営業やマネージャーにとって、現場にいるプログラマというのは扱いづらい存在である。 飲み会などで、普段の彼らを観察してみると。同じエンジニア同士で固まってボソボソとよくわからない話をして、控えめな声で笑っており、総じて温厚で、扱いやすそうな人々に見える。 ところが、仕事になると、彼らはなんやかんのと理由をつけて、スケジュールに文句を言い、プロジェクト途中のリクエストには素直に答えてくれず、あげくには遠回しな嫌味を言ってきたり、極端な場合には、その温厚な仮面を投げ捨てて、攻撃的な暴言さえ吐く事がある。 どうも彼らは我々の事が嫌いらしい、と感じている営業・マネジメント職の人もいるのではないだろうか？ 彼らの人格や価値観に問題がある可能性も否定しないが、このような感情的な齟齬は、多くの場合、あなた自身が彼らの「自尊心」を傷つけていることに気づいていないことが多い。 プログラマの自尊心 プログラミン
イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ
これからマネージャーになるエンジニアのあなたへ - yashiganiの英傑になるまで死ねない日記
こんにちは、新米ディレクターのid:yashigani_wです。 この記事ははてなディレクターアドベントカレンダー2日目の記事です。昨日はid:moretのそろそろ5年生なので右も左もわからない新卒のころの自分にアドバイスする - el cineでした。 私は8月にアプリケーションエンジニアからディレクターになりました。 はてなではディレクター職には担当するサービスの成長に責任を持つプロダクトオーナーとしての役割と、担当するチームの成果を最大化するマネージャーとしての役割が求められます。 マネージャーというと、多くのエンジニアはあまりなりたがらないとおもいますが、それはマネージャーに求められる責任を具体的にイメージできないことや未知の仕事に対する不安からではないでしょうか？ この記事は私の経験から、これからマネージャーになるエンジニアに向けてマネージャーがまず意識すべきことと、最初に陥るで
「できます＝やります」じゃない、非エンジニアに知ってほしいエンジニアのこと | HRナビ by リクルート
変化の激しいエンジニアの世界で、どうすれば成長し続けられるのか。そのヒントを、飲食店向け予約台帳アプリを手がける「トレタ」の増井雄一郎さんが解説します。今回のテーマは「エンジニアと非エンジニアのコミュニケーション」です。 エンジニアはクセのある人間ばかりで、会話が噛み合わない……。そう感じている非エンジニアの読者は少なくないかもしれません。しかし、そのクセには一定の傾向があり、「どんな価値観を重視しているか」は共通している部分があると、増井さんは言います。 そこで今回は、非エンジニアとエンジニアの距離を縮めることを目的に、エンジニア目線で「エンジニアが困る仕事の頼み方」や「エンジニア独特のコミュニケーション文化」について語ってもらいました。 「エンジニアの特徴を把握して『彼らにはそういう文化があるんだ』と認識してもらえると、普段からのコミュニケーションが取りやすくなるかと思います」と増井さ
Web業界の人はそろそろPDCAという言葉を捨てたほうがいいんじゃないか - 絶倫ファクトリー
PDCAは「小さな改善」を指すものではないし、そもそもWebサイト改善には向いてない。まずPDCAはP=計画ありきの「マネジメント」の話だし、Webはコントロールできない要素が多すぎて精度の高い計画立案が難しいからだ。 PDCAサイクルの出自は製造業の品質管理である。そしてPDCAという概念のキモは、「品質管理の話をしていると思ったらいつの間にかマネジメントの話をしていた。何を言っているのかry」である。例えば「C」は品質チェック作業はなく、品質のばらつき具合が事前の計画どおりだったかどうかを判断する。それはP=計画の検証そのものだ。製品の品質を管理するときに、単に品質チェックの「作業」を頑張ればいいのではない。品質の問題が生産工程全体のマネジメントの問題にスライドしていく。それがPDCAという概念の画期的な点だった。 だからPDCAというのは製造業だろうがWebだろうが、常にマネジメント
7年働いた時点での私の仕事の極意 - Kengo's blog
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債と向き合う