イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
Google re:Work - マネージャー
イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
「“全部自分の責任です”っていうリーダーを、俺は信用しない」TAKUROが語るリーダーの哲学｜新R25 - シゴトも人生も、もっと楽しもう。
GLAYを25年率いたリーダー論がここに。 「“全部自分の責任です”っていうリーダーを、俺は信用しない」TAKUROが語るリーダーの哲学 日本を代表するロックバンド・GLAY。 今年でデビュー25周年を迎え、10月2日には15枚目のアルバム『NO DEMOCRACY』のリリースを控えています。 そんなモンスターバンドを率いてきたギタリスト・TAKUROさんは、2005年に設立した事務所「loversoul」の代表取締役であり、その後自主レーベル「loversoul music ＆ associates」、現「LSG」も立ち上げています。 今回新R25では、常にリーダーという立場でバンドや会社を牽引してきたTAKUROさんに、「リーダーとは何か？」というテーマで取材を行いました。 TAKUROさんの考える「カリスマとは？」「責任の取り方とは？」「20代ですべきこととは？」。深いお話をたくさん
今の時代、「ふわっとした仕事を具体的なタスクに落とし込むスキル」だけで十分食えると思う
どうもしんざきです。とある業界の、社員100人ちょっとの企業で中間管理職をしています。 同業他社の管理職同士で飲むことがたまーにありまして、先日は何故か「どれくらい古いパソコン用語を知っているか勝負」という、冗談抜きでひとかけらの生産性もない話で盛り上がっていました。 平成も終わろうかというこの時代に、HYMEM.SYSの記述方法についての宗教議論とか、本当になんの役にも立たないのでやめて欲しいです。超楽しかった。 で、その時、もう一つ盛り上がっていた、というか愚痴の言い合いになっていたのが、「ちゃんとタスク切れる人不足」という話でした。 毎度毎度、人手が足りている、足りていないの話になるのは管理職飲み会あるあるです。飲み会の一つの焦点といっても良いかと思います。 業界にもよるのかも知れないんですが、実をいうと今、採用自体は割とスムーズにいっているという話を聞くことが多いんです。 それも、
メテオフォール型開発 - 実践ゲーム製作メモ帳2
今日は、日本の代表的なソフトウェア開発手法について紹介しよう。 その名も、メテオフォール型開発である*1。 第一節 通常のウォーターフォール型開発におけるプロジェクトはこのような形を取るが、 メテオフォール型開発ではこのような形が取られる。 そしてこうなる。 これはアジャイル型開発手法におけるサイクルであるが、 神の前では無力である。 神の一声は全てを崩壊させ、 民は一生懸命これを再建す。 これが、メテオフォール型開発*2である。 第二節 全てのスケジュールは天界の都合によって決まる。これを黙示録と呼ぶ。 ソフトウェア開発においてフィードバックは重要なファクターだが、 神にフィードバックは届かない。 ただし、祈りを捧げることはできる。この祈りはごくまれに届く。 神は様々な姿を取る。 外から現れることもあれば、 内に棲んでいることもある。 あるいは、まだ会っていない or 会うことすらできな
「大きなかぶ」に見る開発プロジェクトにおける教訓、あるいは猫は何故ネズミを呼んだのか: 不倒城
「大きなかぶ」というお話をご存知だろうか。 「大きなかぶ」は、ロシア民話を元に描かれた絵本である。主人公であるところの「おじいさん」は、畑にかぶの種をまく。その株はめったやたらに大きく育ち、喜んだおじいさんはかぶを抜こうとするのだがなかなか抜けない。 おじいさんはおばあさんに救援を頼むのだがそれでも抜けない。おばあさんは孫の少女に、少女は犬に、犬は猫に、猫はネズミに、それぞれ救援を頼んで皆で引っ張ることで、ようやく株は抜ける。「うんとこしょ、どっこいしょ、それでも株は抜けません」の繰り返しが印象的な童話である。 さて、実はこの「おおきなかぶ」というお話は驚く程示唆的であって、われわれはこの「株の引き抜き」をシステム開発案件に見立てた時、二つの教訓を得ることが出来る。 1.往々にして、「人手が足りないから」ということで救援を頼むと、現行人員よりもパワー不足の人員がアサインされる。あるいは、協
もしも童話「おおきなカブ」がITのデスマプロジェクトだったら
渋谷の雑居ビル。 ホワイトボード前に置かれたパイプ椅子にイヌ、ネコ、ネズミが一触即発の雰囲気で座っている。 扉が開き、慌てた様子の青年が入ってくる。 孫「お疲れ様です、すいませ――」 ネズミ「遅えよッ！！」 ネコ「！！」 イヌ「……ネズミさん、怒鳴るのはやめましょうって……」 ネズミ「……チッ」 孫「あの、本当、すいません。11時からって、皆さんにお約束してたのに……」 イヌ「ま、まぁ。とりあえず、ミーティングの報告をお願いします。もう２時間も押してるんで」 孫「は、はい！ すいません、ではこちらの資料を…… あっ」 イヌ「どうかしましたか？」 孫「印刷した資料が１部たりなくて。……じゃあ、はい！ 僕のは大丈夫なんで、業務委託の皆さんで、どうぞ！」 ネズミ「ッ……！」 イヌ・ネコ「……」 孫「はい、では皆さんお手元に資料ありますかね、お疲れ様です！」 ネズミ「……」 イヌ・ネコ「……お疲れ
日本人はなぜ｢論理思考が壊滅的に苦手｣なのか
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕
「職位が高い人間ほど、技術的な実務から遠ざかってしまう」のを解消しようとして、失敗した時の話。
どうも、しんざきです。 実を言うと先月・先々月と、プロジェクトが割と生死をさまようレベルで炎上しておりまして、夢のデスマ王国という風情だったんですが、お蔭様で今月はだいぶ落ち着いてきまして、若干人間的な生活が出来る状況になってきました。 デスマ程健康に悪いものはこの世に存在しないと思います。 失敗した時の話をします。 十年近く前の話ですが、システム開発の会社に勤めていたことがあります。 それ程有名な会社ではないのですが、一応独立系で、社員は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという、まあよくある「昔ながらのシステム開発会社」だったと思います。 私はその会社で、主に金融関連のプロジェクトを担当する部署に所属していました。 ぬるい案件もあれば地獄案件もあったのですが、まあそれはいずれ、ほとぼりが冷めた頃に書こうと思います。 某大きな銀
CIAのスパイマニュアルに学ぶ「会社をダメにする11の行動様式」
第二次世界大戦時のCIAの秘密資料。題してSimple Sabotage Field Manual。要は、敵国内のスパイが、組織の生産性を落とすためにどのような「サボり」ができるか、という「サボり方ガイド」である。2008年に公開された。（なお、正確に言うと、CIAの前身組織、Office of Strategic Servicesの作成文書である。） 以下、一部を抜粋した意訳です。本文は意訳の後に。 「注意深さ」を促す。スピーディーに物事を進めると先々問題が発生するので賢明な判断をすべき、と「道理をわきまえた人」の振りをする 可能な限り案件は委員会で検討。委員会はなるべく大きくすることとする。最低でも5人以上 何事も指揮命令系統を厳格に守る。意思決定を早めるための「抜け道」を決して許さない 会社内での組織的位置付けにこだわる。これからしようとすることが、本当にその組織の権限内なのか、より
マネージャーの視点から見える向こう側の景色｜Kazutaka Irie
「マネジメントなんてやりたくないよ」 そんなふうに言っていたのがほんの数年前のことだったのだけど、いつの間にかマネージャーの人たちをマネジメントするような立場になってしまった。 ちょうど人事考課のフィードバックをする時期になって、他のチームメンバーの人たちを優先した分、マネージャーやリーダーと呼ばれる立場の人たちは後回しになってしまっている。 「私のことは後でいいから他のメンバー達の評価を先に伝えてあげてください」 そんな言葉に甘えながら、遅くなってごめんねと言いながら、マネージャーの人たちのフィードバック面談を今更（更改された年俸やインセンティブ含め、既に人事考課の結果は本人まで開示されているので本当に遅い。ごめんなさい。）やっているわけだけれども、実際に話をしてみるとむしろ彼らの方がよほど悩んでいたり、早めのサポートが必要な状況だったんじゃないかと感じることが多い。 ここから始まる文章
制作会社がクライアントに切られてしまう一番の理由とは？ | ベイジの日報
昨年度の当社はほぼ100%が元請けだった。ここ数年、元請け比率は非常に高く、企業のWeb担当者の声を直接聞く機会に恵まれているともいえる。 その中でも新規で取引を始める顧客のほとんどは、サイトのお問い合わせフォームか電話から折衝が始まっている。その依頼の多くはサイトリニューアルである。ということはつまり、過去に既存のWebサイトを作った制作会社（代理店や開発会社）が存在しており、そのうえでネットで他の制作会社を検索し、私たちを見つけ、声をかけてきている。その背景には、今まで付き合ってきた制作会社に対する大きな不満があることが多い。 お会いした際には当然、今までの経緯の一環として、制作会社の何が不満だったのかを聴くことになる。きちんとカウントしたわけではないが、感覚値でいうと8割くらいは同じ理由である。それは「言ったことしかしてくれない」「自分たちから提案してくれない」である。ようするに制作
「明日からプロダクトマネージャー」と言われたら - dely engineering blog
こんにちは！ dely, Inc.でプロダクトマネージャー兼開発部ジェネラルマネージャーをしている奥原 (@okutaku0507) といいます。この記事はdely Advent Calendar 2018の2日目の投稿です。 先日は、弊社のAndroidエンジニアでマネージャーを勤めている梅森から「AWS CodeBuild+AWS SAM（Lambda）+Slackで最高なAndroid CI環境を作る」というタイトルで投稿がありました。梅森はDroidKaigi 2019にも登壇する予定です。 tech.dely.jp 弊社が運営しているレシピ動画サービスのkurashiruはよく知っているけど、開発チームは何しているのかわからないという方に、少しでも弊社の開発部のことを知っていただければ幸いです。もし、同職種や弊社に興味を持ってくれた方がいましたら、僕のtwitterのDMでも良い
デスマーチが起きる理由 - ３つの指標
デスマーチが起きる理由 - ３つの指標 著者： 青い鴉（ぶるくろ）さん @bluecrow2 これは結城浩さんの運用されていた YukiWiki に当時 Coffee 様 (青い鴉（ぶるくろ）さん）がかかれていた文章です。 ただ 2018 年 3 月 7 日に YukiWiki が運用停止したため消えてしまいました。その記事のバックアップです。 今は 404 ですが、もともとの記事の URL は http://www.hyuki.com/yukiwiki/wiki.cgi?%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1%A4%AC%B5%AF%A4%AD%A4%EB%CD%FD%CD%B3 になります。 昔、自分がとても感銘を受けた文章なので、このまま読めなくなるのはとてももったいないと思い、バックアップとして公開しています。 お願い もしオリジナルの図を保存されていた方いら
プロジェクトをリードする技術 - kakakakakku blog
今日，社内勉強会で話す機会があり，過去1年間を振り返りつつ「プロジェクトをリードする技術」というタイトルにした．今回は参加者がエンジニアだけじゃなく，ビジネスチームのメンバーもいたため，できる限り，技術的な用語を使わないようにした．質疑応答とディスカッションもあり，1時間非常にワクワクした時間だった． 関連する領域 僕がプロジェクトをリードするときに意識しているのは，スクラムなど特定のプラクティスに依存しすぎないことで，チームの特性によって，関連する様々な領域からプラクティスを集めている．ザッと挙げるだけでも，こんなにたくさんある． チームビルディング ファシリテーション マネージメント 3.0 アジャイル (スクラム / カンバン / XP) 組織論 育成 心理学 メンタリング プロジェクトマネジメント 資料 過去1年間に取り組んだことを全て詰め込んだ！プレイングマネージャーとして頑張っ
クリスマス・メッセージ：折れない心をもつために : タイム・コンサルタントの日誌から
Merry Christmas! ５年前から、大学でプロジェクト・マネジメントを教えるようになった。今年の前期は東大の大学院で、また後期は法政の学部3年生に教えてきた。それ以外にも、単発的に依頼されて話した事もある。個別のエピソードについては、すでに何度か書いたと思う。しかし全体として、何をどんな風に教えるべきか、いつも悩ましい。 悩む最大の理由は、大学生・院生が実務の経験をほとんど持たない事だ。共同で事に当たることがなければ、プロジェクト・マネジメントの必要性がピンと来ない。また、授業で例題を考えるにしても、ビジネスに関わるケースを採り上げづらい。だからいきおい、「たとえば、あなたが同期30人の集まるパーティの幹事になったとしよう」といった例になってしまう。 それでも、講義を数回聴いた学生は、しだいにその意義が分かる者が出てくる。アンケート用紙にも、「もっと早くからこういう話が聞きたかっ
個人開発で得たスピード仕事術
できる犬さんMarkdownエディタを一人で作りながらフリーランスをしています。今月(11月)の売上は18万円を超えました。順調に伸びていて嬉しい。毎日楽しいです。 個人開発はスピードが全てです。残業代もがんばった賞も出ないからです。一人何役もこなさないといけないので、作業のスイッチングコストが常につきまといます。設計してコードを書いてユーザサポートをしてマーケティングして・・。ましてや本業などがあると、プロジェクト単位で脳を切り替える必要もあります。 プロになってから約8年、常に本業と並行して何かしらの個人開発を続けて来ました。そして、このスイッチングコストをどうすれば最小限に抑えられるかという課題と向き合ってきました。自分で言うのも何ですがかなり速いと思います。例えば、先日ユーザさんから機能要望を受けたのですが、書き込みを見て２時間で対応してリリースしました。そしたらユーザさんが「速す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「誰のせいにもしない」文化が、組織の多様化と問題解決を進めていく──熊谷晋一郎×青野慶久 | サイボウズ式
プロジェクトの基本
https://github.com/yoshiori/manager-readme/blob/master/README.md
「Googleで最高のマネジャーになるための8つの習慣」 鍵を握るのはやはりソフトスキルだった
