「直接会って話したほうがはやい」は速いだけ｜araya
全部主観であり自分の抱えてる感想 およそ3年に及ぶパンデミックによるリモートワークを経験した結果「直接会って話したほうがはやい」といってメンバーの出社を求める組織は徐々に増えていると感じる。 出社だけではなく、例えば不動産仲介業者とのやり取りも、メールで質問した内容に対して電話で答えが返ってくるというように、事あるごとに口頭での同期的なコミュニケーションを取りたがる人はいる。 「話したほうがはやい」という人は大抵伝える時の細かいニュアンスや表情から読み取れるテンションが直接会ったほうが伝わるしお互いレスポンスを待たなくて速くて楽だと言う。 それは全く否定しない。間違いないと思う。そもそもタイプミスや誤変換を気にしながらキーボードを打つよりも発話したほうがコミュニケーションは速いに決まってる。レイテンシーが発生するのは声を届ける媒体だけだ。 だけどそれは速い、もしくは楽なだけだ。わざわざ言わ
コンサルだけど同業ツイッタラーにクソムカついた愚痴
フォロワー2.6万人いて某コンサル会社所属のインフルエンサー?なツイッタラーがいる。 コンサルなんて狭い世界なので見る人が見ればどこのファームか大体察しがつく、というか同じ会社だろうしそりゃわかる。その人は恐らくシニアマネージャー(プロジェクトをいくつか回す、ほぼ現場の最高責任者)。 言ってることがおもろいし、趣味も合うし、とにかく"ロック"を志向していて旧態依然のダサいことを糾弾してるのとか痛快だったし、こんな人と一緒に仕事できたら楽しいだろうななんて思いながら黙って結構長くフォローしてた。 仕事がしんどくなった頃に重なってか、なんとなく言ってることが激務自慢、若手の現状とか視界に入ってない感じにちょくちょく違和感を感じるようになったけど、そこまで鼻につくわけでもなくフォローしたままだった。 ある時、彼がLINEか何かの画像を無言でTwitterに上げていた内容を見て呆気にとられた。 『
「技術的革新について話すだけのヤツはクソだ、黙って手を動かせ」とLinux生みの親のリーナス・トーバルズが語る
Linuxカーネルを開発したリーナス・トーバルズ氏が、Linux Foundationが開催したOpen Source Leadership Summit 2017(OSLS 2017)で行われた対談で、近年のテクノロジー業界についてや、自身の仕事の考え方を語りました。 Talk of tech innovation is bullsh*t. Shut up and get the work done – says Linus Torvalds • The Register http://www.theregister.co.uk/2017/02/15/think_different_shut_up_and_work_harder_says_linus_torvalds/ OSLS 2017でリーナス・トーバルズ氏は、Linux Foundationで取締役を務めるジム・ゼムリン氏と対談を
通勤手当は存在自体が不公平である、あるいはワークアウトで会社を作るということ：プロジェクトマジック：オルタナティブ・ブログ
★会社を変革するツール ワークアウトという意思決定ツールをご存知だろうか？僕は随分前に「GE式ワークアウト」という本を読んで、自分の会社でもやってみたいと思っていた。 簡単にどんなものかを説明しよう。 ・有志が1日集まって「会社を良くするための提案」を作る ・1日の最後に組織の最終意思決定者（例えば事業部長や社長）に対して提案プレゼンを行う ・提案に対して、意思決定者はその場で「Yes/No」を意思表明しなければならない 本では、有名なGEの「業界No1かNo2のビジネス以外は撤退する」というルールをやめるべき、という提案があり、ルールが実際に廃止された事例などが載っていた。（No1かNo2に見せかけるために、業界を無理やり小さく定義して、ビジネスの成長を阻害していたため） そこまでダイナミックでなくとも、ちょっとした無駄業務の廃止提案など、社員が発案して会社を良くするための仕掛けとして優
相手を説得するときにデザイナーがやってはいけない８つのこと
Paul BoagはUXデザイナーでデジタルトランスフォーメーションのエキスパート。非営利団体がWeb、ソーシャルメディア、モバイルを利用する支援をしている。 私たちは仕事をするために、クライアントとステークホルダーを納得させる必要があります。彼らがいないと、私たちは必要なことをするための承認を得ることができません。しかし、私たちのほとんどは説得するのが驚くほど下手です。よって問題は、私たちがどのように説得に失敗するのか、それについてどのように対処するべきかです。 私は、６月末のオンラインワークショップの準備にあたり、クライアントやステークホルダーとどのように協力して仕事するのかについて、多くのことを考えました。これは、同僚やクライアントから同意を得る方法について４つのパートから説明するものです。 私がこのようなワークショップを開くのは、ほとんどすべての作業において、やる価値があると他人を
「ノーアジェンダ・どうしましょうか会議」の傾向と対策 - UNIX的なアレ
wadap.hatenablog.com 先日、こんなエントリーを書きました。割とエンジニアやデザイナーの方は経験したことがある会議ではないでしょうか。このワードに反応されていたので、少し掘り下げてみたいと思います。 「ノーアジェンダ・どうしましょうか会議」とは もうこの名前に全てが詰まってはいるので、経験したことがある人はすぐにわかるとおもうのですが、以下の点が揃っているとまさにその会議かと思います。 アジェンダが用意されていない とりあえず関係がありそうな人を呼ぶ 会議が始まり次第「どうしましょうか」的な空気が流れる ダラダラ長い 丸投げ感満載 というところでしょうか。会議そのものに主催者側の専門性があるものでは起きづらいのですが、自身が理解できない or 経験の無い領域の話になるとわりとこういう会議になりがちなのかなと思います。 会議の傾向 そしてこの会議が始まり「どうしましょうか」
1ヶ月半休みなしでほぼ毎日終電まで仕事してたら過労でぶっ倒れた。そうなった経緯 - NaeNote
（最終更新日 2016-11-11：その後に書いた関連記事を記事末尾にまとめました） こんにちは、NAEです。 のっぴきならない事情により、2週間ほどは1日15時間くらいオフィスに詰めるような働き方をせざるを得ない状況が続きました。 うち半分は終電すら間に合わず、深夜にタクシーで帰っておりました。 結果として心身ともに影響が出始めました。誤解を恐れずに言うと、ぶっ倒れて休みをもらっています。 状態が落ち着いてきたので、 なぜ激務に陥ったのか その後の対応や経過などから得た学び を、振り返ってみます。 今回はそんなお話。 きっかけは片手間でヘルプに入った炎上プロジェクト はじめの1ヶ月間は稼働率170%。続く2週間は休みなしで終電まで仕事 休みがない。休日出勤でも間に合わない。こんな状態に陥った原因の数々 古くさい仕事のやり方による工数の無駄 プロジェクトの前提が崩れているのに放置し続ける誤
IT業界の問題がいつも話題になるけど本当の問題をみんな勘違いしていると思..
IT業界の問題がいつも話題になるけど本当の問題をみんな勘違いしていると思う。 度重なる顧客からの仕様変更。 プロジェクトスタート時の見積もりの甘さ。 品質の低さによるバグの頻発。 ゴールの見えない仕事と重圧により耐えられなくなったメンバーの病欠や離脱。 それらがまた品質の低さと遅延の原因になる。 デスマーチなんてよく言われてるけれどもね。 IT業界の人は言う。 これらの原因は無茶なことを要求する顧客のせいであり、技術的な知識がないから実現すべきことが簡単にできると思っている客先の業務担当者のせいであり、そんな無茶な客と契約してしまう営業や営業から降りてきた案件を大して精査せずに受け入れてしまうプロジェクトマネージャーのせいだと。 でもちょっと待ってほしい。 それらの問題は本当に相手側にあるのか。 もっとうまくやる方法はなかったのかと思っちゃうんだよね。 例えば契約締結後の仕様変更。ここで理
なぜプロジェクトは炎上するのか？炎上しやすい4つの傾向と、炎上を防ぐ3つの対策 - paiza開発日誌
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 某Mずほ銀行の案件のニュースが出たとき、弊社でも結構話題になりました。 あんなに巨大なプロジェクトをしずめるのは、もう本当に不可能なんじゃないかと思いますが、どんなに大きな炎上も、恐らくは小さな火種が集まって、やがて大きな炎となってしまった結果だと思いますし、最初の小さな火種の段階からぷちぷち消していけたらこんな結果にはならなかったはず……。 という話をしていたときに、paizaのエンジニアが「かつて炎上しているプロジェクトに自ら突入していくのが趣味だった」などと言い出しました。「そういう性癖なのかな」と思ったんですが、聞いてみると 「炎上しているプロジェクトに行くと『優秀な人たちはどんな振る舞いや働きをして炎上をしずめているのか』『何が原因で炎上したのか、どの時点で何をし
思考のスピードが速い人は｢型｣で考えている
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕
大規模システム開発案件のデスマーチは、どうしてこんなにつらいのか - あいむあらいぶ
かるび（@karub_imalive)です。 この春までSI業界にいたので、たびたび大型システム開発案件の大規模炎上を見てきました。そして、ここ最近はみずほ銀行のシステム統合案件が厳しいようです。 2012年頃からスタートし、一昨年くらいからヤバイんじゃないの？と言われていた案件がどうも最終局面な感じになってきているようですね。 規模的に見ても、大きすぎて後戻りできないっぽいので、カネと時間がいくらかかっても最後までやりきるしかなさそう。しかし、みずほ社内オトシマエとしてたくさんの悲しい人事異動が発令されることでしょう・・・。（まぁ、今回はソースがまとめサイトやマイナー雑誌の抄訳なので、詳細については続報を見守りたいところですが・・・) さて、プロジェクトの炎上にも色々ありますよね。大きい案件なら数千人規模から、小案件なら2～3人規模のプロジェクトまで、規模を選ばず、炎上するときは炎上する
プロジェクト・マネジメントの目的とは何か | タイム・コンサルタントの日誌から
中堅エンジニアが壁を破って成長するには、何を学ぶべきか。そういう問いに関連して、ここ何回か書いている。初級の仕事を一通りおえて、とりあえず一人前のことはできるようになっても、その先にしばしば壁がある。そこを乗りこえて面白い仕事をしていくためには、もう少しマクロにものを見て、人を動かせるようになっていく必要がある。 今年の1月に、静岡大学と浜松ソフト産業協会の共催によるプロジェクト・マネジメント講座に呼ばれて、初日の講師を務めさせていただいたときも、その話から始めた。集まった方はほぼ全員がIT技術者だった。IT分野は勉強会も盛んで、知識欲に燃えた熱心なエンジニアも少なくない。わたしはたずねた。 「この中で、現在プロマネの仕事をされている方はいらっしゃいますか？」 手を上げた方は全体の1/3もいなかった。ある意味、予想通りではある。プロマネの仕事をばりばりこなしている人は、こうした講座を聴きに
フリーランスなら読んどけ、これが撤退戦略だ。(1) – Re: 本当にあった怖い業務委託契約書、あるいはフリーランスはきちんと契約書を読まないとわりと死ぬ – (っ´∀｀)っ ゃー
ホーム › フリーランス › フリーランスなら読んどけ、これが撤退戦略だ。(1) – Re: 本当にあった怖い業務委託契約書、あるいはフリーランスはきちんと契約書を読まないとわりと死ぬ フリーランスなら読んどけ、これが撤退戦略だ。(1) – Re: 本当にあった怖い業務委託契約書、あるいはフリーランスはきちんと契約書を読まないとわりと死ぬ みなさんこんにちは。かつて火消しばかりやっていた @nullpopopo でございます。昨日twiterを見ていたらこんなツイを発見しまして。 https://twitter.com/nishi1010kawa/status/726385332434833408 ↑の絡みでたけさんがフリーランスあるあるなブログをまとめられていてかなり参考になった(というか、「あるあるあるある↓」と頷いた)のですが、フリーランスで仕事していると、たまに、極々たまーになんで
フリーランスなら読んどけ、これが撤退戦略だ。(2) – 負けないための撤退戦術 – (っ´∀｀)っ ゃー
前回、撤退戦略を取るに至るまでの経緯と契約書の重要性について書きました。今回は撤退戦略に舵を切った後の撤退戦術について書いてみたいと思います。そもそもプロジェクト撤退とは、戦いです。撤退戦なのです。撤退戦の勝利条件も含め、撤退戦術について詳しく紐解いてみましょう。 ■ 撤退戦略 (1) 契約締結前 編 前回から重ねて言いますが、撤退ありきで仕事することを勧めてるわけではありません。が・・・中には「おっ、こいつはヤバいぞ」という臭いがするプロジェクトやクライアント、時には共同作業者(社)がいるのも事実です。悲しいことですが。さて、こうした事態は非常に残念ですが、これが契約締結前で、かつ作業着手前であればラッキーです。何の義務もへったくれもなく撤退することが可能です。何ら悪びれることもありません、おめでとうございます。 もしよんどころのない事情で契約書締結前に作業着手してしまったら・・・こうな
「だから言ったのに」と言う人の言葉を無視してはいけない | サイボウズ式
マネジメント 新しいチームのあり方を探求 就活 就活生必見！サイボウズの疑問 ティール組織 会社の「あたりまえ」が変わる 多様性 100人100通りの個性 ワークスタイル 働き方、生き方、もっと自由に 青野慶久 サイボウズ社長の想いと覚悟 キャリア 人生の「積み上げ方」を見直す 複業 複数の「本業」をもつ働き方 人事制度 多様な働き方を支える仕組み マンガ サクッと手軽に読める！ サイボウズ式編集部より：著名ブロガーをサイボウズ外部から招いて、チームワークに関するコラムを執筆いただく「ブロガーズ・コラム」。はせおやさいさんが考える「チーム運営で意見を1つの視点ととらえることの大切さ」。 こんにちは。はせおやさいです。 「失敗は成功の母」と言いますが、失敗から学ぶことは思った以上に多いものですね。「失敗しないこと」よりも「失敗したとしてもそこから有益な知見を得られた」というほうに注目していく
[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita
ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。 （ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。） ただ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
新入社員に教え込んでいる13の具体的な仕事術を紹介するよ | Outward Matrix
誰がどう見てもそうとしか受け取れない文書術（公開版）
プロダクトマネージャーにたちはだかる壁を、どう乗り越えるか
