決して止まらないカイゼン体制を作りたい | 深津 貴之 (fladdict) | note
中長期のための大きなデザインも大事だけど、そのために日々の改修が犠牲になってはならない（その逆は言語道断）。そんなわけで、しばらくの間は、1〜2日で終わる小さな改修を、コンスタントにnoteチームに提案したいなぁと考えている。 もちろん、「リソースが許せば」だけれども。なぜならpiece of cakeにはまだデザイナーが1人しかいないことだ。そんなわけで、中長期でどういうチームを作るべきかウンウン唸っている。 並行して走るスロットが3-4つ欲しい理想を言えば、デザイン/開発リソースを3つのグループにわけたい。「大局リソース」、「開発リソース」、「カイゼンリソース」の3つだ。これらはそれぞれ独立しているのが望ましい。複数のレイヤーを1人のスタッフが兼任していると、どれかが忙しくなると、他の全てがストップしてしまうからだ。 大局リソース ガイドライン、コンポーネントなど、会社全体にストックさ
組織としての「価値観」をシェアすること｜スズキアユミ（デザインメモ）
友人と出かけた際に、ひと休みのために入ったカフェでチームビルディングの話が白熱してだいぶ面白かったので、帰ってから改めて考えてみました。 組織の中での二極化 これ、あるあるなんだな…と思ったのが、組織である程度人数が増えた時に、仕事へのやる気の「ある人」と「ない人」で二極化が起きること。 ちょっと語弊が起きそうなので言い換えると、仕事へのやる気度が「高い人」と「低い人」。もっと言うと「上昇志向」派と「安定志向」派だ。 この双方は驚くほど、お互いに相容れない存在。歩み寄ろうとして話しても、互いに言語レベルで通じないので、下手すれば一騒動起きる。 経験をしたことがある人は、そもそも土台のような、根本が違うような感覚を持った人も多いはず。そう、そこから違うから、分かり合えるはずがないのだ。 だが、“組織”である限り、一緒に働く仲間である。どうにかしないと、分裂したままでは仕事にならない。 仕事の
なぜ製品仕様を合議制で決めてはいけないのか。
プロダクトマネジメントにおいて「製品仕様を合議制（多数決）で決めてはいけない」というルールがあるが、それは何故なのか。そして、だとしたらどのように人の意見を取り入れるのが良いのか、を考えてみた。 なぜ製品仕様を合議制で決めてはいけないのか。合議に参加している人たちは、その問題の責任者ほど制約条件や問題の背景を深く理解をしていないから。合議制や多数決で物事を決めると、必ずその結果に満足している人たちの方が満足していない人たちよりも多くなる。これは素晴らしい手法だ。 しかし、製品開発の目的は社内の人を満足させることではない。正しい製品をつくることだ。製品にとっての正しさとは、「その製品を顧客（市場）が求めていること」であり、これを満たすためには様々な調査や知識が必要だ。 製品仕様のように、問題の複雑さが一定を超えると、知識を持っている人と持っていない人の意見に違いが出始める。世の中（「社内」と
社内横断の技術組織を終わらせました - nottegra’s blog
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
【黒から】発想とやり方次第でブラック起業予備軍がホワイト企業になって従業員が結婚ラッシュになった話【白へ】
青木文鷹 @FumiHawk 丁度去年の今頃、知人に「従業員の仕事効率上げたい、このままじゃ人数増やさにゃ仕事こなせなくなる」と泣きつかれたので、いくつかアイデア出したら結構うまく回ってるみたいで、勤労感謝の日なのでちょっとTWしてみる。（個人的には休み関係なく絶賛勤労中で、今日は新嘗祭なんだけどねｗ）（続 2016-11-23 12:14:15 青木文鷹 @FumiHawk 最終目標は「仕事の効率UP」と「業績向上」。サービス売る仕事なので基本デスクワークと企画と外回り。残業時間超過がちらほら。最初に「会議参加人数を5人迄」「会議の前振り＆挨拶無し」「会議時間90分以内」「会議資料作らない」「致命的欠陥指摘以外対案無き反対論不可」のルール決めた。（続 2016-11-23 12:15:46 青木文鷹 @FumiHawk このルールで会議の開催回数が半分以下、時間は1/4以下に。次に決めた
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
