サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
「相談があるのだけど……」と知人友人から持ち掛けられて、親切心から「アドバイス」をしてあげた。 でも、全く相手に響かず、「なんで言うとおりにやらないの」と、逆に相手を責めてしまい、何の解決にもならなかった。 そんな経験のある人はいないでしょうか。 私は死ぬほどあります。 そんな失敗から、徐々に私は「人からの相談」について、考えを改めざるを得ませんでした。 実際、「アドバイスの欲しい人」は本当に少ないのです。 多くの人が求めているのは、「黙って話を聞いてくれる人」であって、あれこれと改善案を考えてくれる人ではありません。 しかも、もっと悪いことに親切心からの「改善策」「アドバイス」はむしろ、「なんでこんなこともやってないの？」という批判だと受け止める相談者も少なくありません。 「◯◯してください」や「◯◯すべきです」といった直接表現はまず、誤解されて伝わるのです。 そして、非難されている、と
この記事の目的 最近「良いドキュメントが作れているな」と思う機会が増えてきたので、その知見をアウトプットしたくなった。 想定読者 今所属してる組織(会社/プロジェクトなど)のドキュメントがイマイチで悩んでいる人 そもそもドキュメントが無い組織に所属していてつらい思いをしている人 「ドキュメントを作れ」という漠然としたタスクを振られて困っている人 想定読者ではない人 メンテなブルなドキュメンテーションのエコシステムが完成している組織で更によいやり方を模索している人 私もまだ模索中なので、いいやり方があれば教えてほしいです👀 顧客提出などの「納品が必要」なドキュメントの管理方法を模索している人 この記事では「社内の情報共有」にスコープを切って話をしています 書いている人のスペック(参考) 歴５年くらいのなんちゃってフルスタックエンジニア 普段は Node.js /React.js or R
こんにちは、ホスティング事業部の @dojineko です。 今日は2022年02月22日、スーパー猫の日です 🐾 そんな今回は、2022年01月に社内で共有した、Slackを活用した日常のコミュニケーションでストレスを与えやすいパターンの例とその改善手法の提案を、 テックブログの記事として編集したものを共有したいと思います。 今昔ペパボのテキストコミュニケーションGMO ペパボではコロナ禍以前より、テキストでのコミュニケーションを主体とした業務に取り組んでいます。 普段からほとんどのコミュニケーションはSlackによるテキストチャットで行われ、 それぞれが組織やサービスにある課題やそれらを改善する提案をしたり、業務に関わる内容を文字にしたりしながらコミュニケーションしています。 テキストでのコミュニケーションは、「考えていること」「思っていること」を文字として具体化できることや、 後
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。DXをめちゃくちゃ改善した話を募集していま
イーロン・マスクが YouTube チャネルでスペース X のテキサス工場スターベースの中を歩き回りながらロケット製造や電気自動車について説明しているのを観た。ツイートしたこの件。 これがめちゃくちゃに示唆に富んでいて面白かった。この日のイーロン・マスクは饒舌で楽しそうなので、かなり魅入ってしまった。きっと彼はカンファレンスや会議室の中でインタビューを受けるよりも、工場でみんながロケット作ったり作業している場で語った方が情熱を込めていろいろ説明してくれるんだと思う。 この中で製造工程の話があって、これはロケット製造などの特定分野だけでなく、IT やその他の分野にでも当てはまる普遍的な知見だと思ったので意訳してみた。ざっとビデオを観て印象に残った部分だけを意訳した。あくまで大枠で言ってることをまとめただけなので、もし詳細に興味があればぜひビデオを観てイーロン・マスクの話を直接聞いて確認してく
Warning: Undefined array key 0 in /home/wwnstyle/wirelesswire.jp/public_html/wp-content/themes/wirelesswire_v3/functions.php online 17 Tweet 「もっと派手に、若々しく」とか「うーん、違うんだよなあ」と、ぼんやりした指示しか出してくれない上司と、「ここは赤で」「明日までに見積書を書け」みたいにガツガツ仕事を進めてしまう上司、どっちがいいか、という問題について最近考えたことがあった。 ガツガツ上司の場合、部下はストレスは感じるがやりやすい。上司が欲しがるものが明確化されているので、「赤にしろ」と言われれば赤にすればいいし、「見積書を書け」と言われれば書けばいいからだ。 それに引き換え、ぼんやり上司の下にいると、部下は苦労する。 なにしろ何をして欲しいの
ソフトウェアの開発プロジェクトにはさまざまな経歴や役職を持つ人が関与するので、我が強い人や性格に難がある人が問題になることもしばしば発生します。ソフトウェア業界のよもやま話を語るブロガーのニール・グリーン氏が、ソフトウェア開発プロジェクトの中で問題になりがちな人をタイプごとにまとめつつ、それぞれのタイプの特徴と管理職向けの解決策を解説しました。 How to Deal with Difficult People on Software Projects https://www.howtodeal.dev/ 上記のサイトにアクセスしたのが以下。上から「プロダクトマネージャー」「デザイナー」「プロジェクトマネージャー」「開発マネージャー」「開発者」「品質保証(QA)」の6カテゴリに分かれていて、それぞれの役職の中によくいる「問題のある人」のタイプが動物のアイコンで示されています。例えば、「プロ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに仕事の品質を高める上で、知見のある方にレビューをしてもらうプロセスは欠かせません。 ただこのレビュー、やり方や意見の伝え方によっては、期待した効果が得られなかったり、ネガティブな効果を生み出しかねません。そうした結果、レビューという行為自体が開催されにくくなることは、チームにとって非常にマイナスです。 全員のレビューへの期待を整えておくために、レビューの心構えや望ましい運営方法などを、レビューに関わる全ての人が共通認識化しておくことは、非常に重要だと考えています。 今回、このレビューを効果的に進めるポイントをまとめた、とても良
ごらり @gorizukai 部下から「議事録ってなんで作成する必要あるんですか？」と聞かれたことがあるので、今後聞かれたときのために議事録についてまとめてみました。議事録って慣れるまでは大変ですけど、文章の書き方が学べたり、社内人脈ができたりするので入社したての頃は特に進んで議事録作成することを勧めたい。 pic.twitter.com/xV0REtbeVD 2020-11-03 20:56:44gorilla｜モノづくり企業の図解屋 @gori_career 図解でキャリアや資産運用に役立つ知識をお届け｜元ヘッドハンターが製造メーカーで新規事業を立ち上げ｜経営企画｜age32｜元陸上U20日本代表｜3児の父｜図解したものをブログにまとめています｜図解やコーチングの相談はDMから https://t.co/SrwOVhuF5d
社内ではこういうおすすめをしてますね(文字数多いのでスクショで...) pic.twitter.com/uzqCh6zubs— 柴崎優季 (@shiba_yu36) 2020年7月7日 こういうツイートして、そういえば社内でメンターを初めて経験する人にオススメしている書籍たちを外部に公開してないなと思ったので紹介してみます。 メンタリングのスキルを学習する時のキーワードは「コーチング」と考えていて、以下の書籍を推薦しています。上から順におすすめ順になっています。この推薦は網羅的にコーチングを学べると言うより、初めての人でもとっつきやすく読みやすいものであることを意識して選んでいます。また、メンタリングを始めるだけなら、書籍の全部分を読む必要はなく、どこまで読んでおくと良いかも書いています。エンジニアリング組織論への招待 ザ・コーチ コーチングの基本 新1分間マネジャーエンジニアリング組
チームのマネージャーが、自らの責務をジョブディスクリプションとして明文化することは難しい。職務内容や権限を、断片的にしか書けないかもしれない。もしそうなるなら、実務も断片的になっている可能性がある。 チームマネジメント（組織マネジメント）という活動は、個々のマネージャーの経験や関心によって、断片的になりやすいように感じている。断片的とは、マネジメント活動が、責務の一部の領域に偏ってしまっていたり、問題を検知してはじめてその領域がマネジメント範囲であることを知る、といった様子を指している。 このような状態になる背景は、マネージャーにとって、マネジメントが、日々の実務を通して蓄積された経験に基づく活動になっているからではないか。マネージャーは孤独だ。ひとりでその責務を担う。エンジニアとは違い、チームで協働するわけではない。だから、形式知として言語化されず、個人の経験として暗黙知にとどまる。その
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 私自身これまで複数の開発案件でプロジェクトマネジメントをしてきました（開発もするプレイングマネージャー的な感じで） ※マネジメント規模は数人～60人規模まで様々（システム開発・ソーシャルゲーム開発が主） これまでプロジェクト炎上案件の立て直しを何件も実施してきました（立て直しは一番やりたくない…） 今回は「なぜ炎上するのか・どうしたら炎上しないのか」に焦点を当てて、炎上案件について共通点や回避策など実際の実例を交えて複数回に分けて纏めておこうと思います（※現職がゲーム開発なので、ゲーム開発を例にして記述します） みなさんの周りに何も解決
製品開発におけるマネジメントの全体感最初に結論エンジニアがマネジメント始める際には、↑のようにざっくり簡単にでいいので開発チームのマネジメントの全体像を掴んだうえで、自分がマネジメントするべき範囲を明確にして動くことをオススメしてみます。 以降、もう少し詳しく説明します。 なんで書こうと思ったかエンジニアにとってマネジメントとはなにか。突出した技術力を持った人というのがエンジニアでは花形なイメージが一般的にはあるでしょうし、マネジメントはエンジニア全員にとって必須科目ではありませんが、一定の経験、年齢、スキルになったら考えることだと思います。 しかし、エンジニアにとってマネジメントという言葉はとても曖昧。必須科目でない分、特定技術に関するものよりもずっとドキュメントや教材がすくなく、なにをやればいいかけっこうわかりにくい。 最近だとVP of Engineeringみたいなポジションがメジ
マネジメントの技術全体に興味があるので、その要素にはどういうものがあるかを知っておくために「マネジメント入門」を読んだ。 マネジメント入門---グローバル経営のための理論と実践 作者:スティーブン P. ロビンス,デービッド A. ディチェンゾ,メアリー・コールターダイヤモンド社Amazon この本は、マネジメントにはどういう話題があり、それぞれにはどのような研究や考えがあるかについて、ざっくり概要を教えてくれる本だった。マネジメントの機能を、計画する、組織する、リーダーシップを発揮する、コントロールするの四つに分類して話を進めている。目次は以下のとおり。 イントロダクション: マネジャーとマネジメント・マネジメント環境・マネジメント全般に関わる課題 計画する: 意思決定の基礎・計画策定の基本 組織する: 組織の構造と設計・人材を管理する・変革とイノベーションのマネジメント リーダーシップ
フロントエンドチームの取りまとめをすることになったので、元々サーバサイドエンジニアである自分とみんなが考えていることとズレが無いようにしたくて始めた。あと実際にサービスを開発してるメンバーと会社が考えていることの期待値合わせという意味もある。なお、会社のエンジニア全員とやってるわけではなく自分のチームでやってるだけである。また、対象は業務委託の人も含んでいる。業務委託の人を含めてよいか？という話はあるが、自分は評価者ではないということと、これによって契約が左右されることはほぼないということは念を押してる。 始める前によんだもの この辺 d.hatena.ne.jp ofsilvers.hatenablog.com ヤフーの1on1―――部下を成長させるコミュニケーションの技法 作者:本間浩輔出版社/メーカー: ダイヤモンド社発売日: 2017/03/25メディア: 単行本（ソフトカバー）
SPI Japan 2017というカンファレンスで発表をしました。 グロースフェーズの痛みの中で、いかに開発・運用チームを立て直したかという内容になります。 発表スライド 「Rebuild Team - 急成長プロダクトのDev&Opsで生じる悪循環とその解決策」 ここ最近の発表の集大成です。 急成長フェーズを体験した人は多くないはずなので、有用な知見ではないかと自負しています。 参加した感想 運営が非常に丁寧でした。選考通過時にはレビュアーから「こういう点が素晴らしい」とコメントいただき、また当日には司会者からフォローをいただき、非常に話しやすい場作りがなされていました。 一方で内容面については全体的に違和感を覚えました。もやもやです。 内容 思ったこと 補足事項 「改善施策が現場に受け入れられない」という意見が多かった 改善施策は現場の人が現場のために生み出すものではないか。 現場にメ
Inc.：長年にわたり、Googleは数え切れないほどの研究に取り組み、膨大なデータを集め、何百万ドルもをつぎ込んで自社の従業員をより良く理解しようと努めてきました。Googleの最も興味深い取り組みの1つであるプロジェクト・アリストテレス（Project Aristotle）は、社内で最高の業績をあげているチームに焦点を当て、チームの生産性を高める秘訣を探ろうというものでした。 なかでも、生産性の高いチームと低いチームの違いは何なのか？ を解明することに主眼が置かれました。 この調査をはじめる前、Googleの経営陣は、ほかの多くの組織と同じように、最高のチームをつくるということは、最高の人材を集めることであると信じていました。それは理にかなった考えです。最高のエンジニアに、MBA、博士を集めれば、最高のチームのでき上がり。そうですよね？ しかし、Googleの人事分析マネージャ、Jul
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? @eaglesakura です。 皆さん、進捗どうですか？ お仕事の規模が大きくなれば、参加人数が増えていくでしょう。 参加人数が増えれば、様々な宗教観の人がプロジェクトに参加するでしょう。 お一人様プロジェクトを中心にやっていた人もいれば、大規模案件のソルジャーとしてキャリアを積み上げてきた人もいます。彼らのスキルレベルもまちまちです。 私が参加している（そしてプログラマーに対して強い権限のある立場である）プロジェクトでは、次のようなルールをベースに適用しています。 これはなるべくプログラマーの負担をかけずに管理側（プロジェクトマネー
「お前は向いていないんじゃない、やってないだけだ」 この一文を読んでほんの少しでもなにかを感じた人は是非とも↓の本を今すぐに読むべきだ。 エラスティックリーダーシップ ―自己組織化チームの育て方 作者: Roy Osherove,島田浩二出版社/メーカー: オライリージャパン発売日: 2017/05/13メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る本著はみんなが考え、感じているリーダーシップという曖昧模糊な概念に対して具体性をもたらせてくれる。 それは「チームリーダーの役割は優れた人材が育つのを助けること」と定義付けていることだ。 このシンプルである意味で本質をついている定義付けが本著を名書たらしめているとぼくは思う。 この本の構成は1部〜4部(おおよそ本書の半分ほどを占めている)までが著者によるリーダーシップとはなにか？3つのフェーズの分類とそのときに期待さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
