katapedia
  • README
  • doc
    • Ansible
    • Assert
    • Astah
    • Autohotkey
    • CI
    • C_Cpp
    • CentOS6x系でhttp認証に失敗する
    • Chef
    • Clipboard
    • コーディング
    • Configure
    • Console2_NYAOS
    • Debian系RedHat系の違い
    • DesignDoc目次サンプル
    • Docker
    • Doxygenコメント規約
    • Eclipse
    • Excel
    • FAQ
    • Footer
    • Git
    • GitBucket
    • GitBucketとJenkins連携
    • GitBucketとRocketChat連携
    • GitHub
    • GitLab
    • Gitで大量のファイルの中から必要ファイルのみをaddする方法
    • GitのGUI比較
    • Gitのリポジトリがでかくなったときの削減の昔のやり方
    • Gitワークフロー
    • Go
    • Googletest
    • Gradle
    • Grafana
    • Groovy
    • Haroopad
    • Haskell
    • Htmlpdfに直リンクする(ダウンロードしない)方法
    • IT業界
    • Java
    • Javascript
    • Javascriptrライブラリ・フレームワーク一覧
    • Jenkins
    • JetBrains_IDE
    • Linux
    • Linux Command
    • Linux Distribution
    • Makefile
    • Maven
    • MicrosoftProject
    • NoSQL
    • Omniauthによるアカウント統合
    • Outlook
    • PHP
    • Prometheus_Loki
    • Python
    • RDB
    • Redmine
    • RedmineDドライブへの保存
    • Redmineアップデート
    • Redmineプラグイン
    • Redmineメール通知
    • Redmine文字化け
    • Ruby
    • Rust
    • R言語
    • SVN
    • Sidebar
    • Solaris
    • Staticまとめ
    • Terraform
    • Thinkpad
    • Tmux
    • ToDoリスト
    • UML
    • Vagrant
    • Vim/Neovim
    • VirtualBox
    • Visio
    • Webアプリケーション
    • Webサーバ
    • Webブラウザ
    • Webブラウジング
    • Webページ備忘録
    • Windows
    • Word
    • Zabbix
    • Zsh
    • C#
    • dotfiles
    • html_css
    • Lua
    • sonarqube
    • terminal
    • tweetまとめ
    • xrdp
    • お預り証サンプル
    • その他Webサービス
    • その他ツール
    • よく使う英語
    • アジェンダサンプル
    • アジャイル宣言
    • アンチパターン
    • インシデント
    • エディタ・IDE
    • エンジニアリングスキル
    • オンプレミスサーバ管理
    • オープンソースライセンス
    • キックオフミーティング
    • コミットメッセージでよく使う英語
    • サーバデータ移行
    • サーバ環境構築
    • シェルスクリプト
    • セキュリティ
    • ソフトウェア開発
    • チャットツール
    • チーム構築
    • ツール調査履歴
    • テスト
    • デザイン
    • デザインパターン
    • ドキュメント
    • ネットワーク
    • ノート
    • バージョン番号
    • ビジネスモデル
    • プラクティス一覧
    • プラグイン調査
    • プログラマがやってはいけない97のこと
    • プログラミングテクニック
    • プログラム
    • プログラムエラー集
    • プロジェクトマネージメント
    • プロダクトマネージメント
    • ヘルプ文
    • ライフハック
    • リソース設計
    • リバースエンジニアリングツール
    • リリースノート
    • リリースノートサンプル1
    • リンク
    • レビュー
    • 人月の神話
    • 人間のあれこれ
    • 仕事のあれこれ
    • 会議
    • 作業報告項目サンプル
    • 例外処理
    • 勉強
    • 名言・教訓
    • 品質管理
    • 教育
    • 数学
    • 文書レビュー観点
    • 朝会
    • 未来技術
    • 林檎の木のものを持ってきた
    • 正規表現
    • 物理
    • 知識データベース
    • 紛らわしい・似たような用語
    • 経営
    • 経済
    • 自作template_class_でundefined_reference_to
    • 要求分析・要件定義
    • 見積もり
    • 設計
    • 評価
    • 認証
    • 議事録サンプル
    • 運用・保守
    • 開発インフラ
    • 開発環境
    • 開発計画
    • 関数名でよく使われる英単語
    • 関数命名規約
    • 関数型言語
    • 雑多メモ
    • 面接
Powered by GitBook
On this page
  • 仕事
  • コスト
  • 進め方
  • プロジェクト
  • コミュニケーション
  • 失敗
  • マネジメント
  • 評価
  • 働き方
  • 要求分析
  • 成長
  • 大企業病
  • 新人教育
  • 能力
  • 行動
  • やる気
  • チャレンジ
  • 学習
  • 35歳定年説
  • エンジニアリング
  • IT業界
  • 勉強
  • SIer
  • 炎上
  • 転職
  • 社会
  • 教育
  1. doc

tweetまとめ

PreviousterminalNextxrdp

Last updated 6 years ago

仕事

コスト

考えることが仕事の人にコスト削減を迫り 安易なコピペ業務設計が 返ってくるという展開をたまに見ます。 なぜなら現状維持したままコストを減らせとなると 新しい試みを削るしかなくなるからです。 コストがかかった原因を考えず 安直にコスト削減を目的とすると 創意工夫が失われます。— Pleiades (@baito_mo_yamuna)

【私見】 「質」の本質は「数」なんですよ。 駄作でもなんでも、とにかく作ってしまえば自分の欠点が見え、次はここを直そうという向上につながる。— 謎水さん (@nazomizusouti)

進め方

背景なしに、要望だけを提示する人には、以下を明確に伝えるようにしている。 - 自分は単なる作業者ではない。そのように扱われるとモチベーションが下がる - 背景を説明してもらえると、要望に対するマシな提案や納期が提案しやすくなり、互いに良いことがある可能性が高い— Yoshinari Takaoka (@mumumu)

フリーランスの仕事においてずっとふんわり感じていたことが最近確信に変わった。仕事ができる人はレスポンスが早い。仕事が早い、ではなく、連絡が早い。相手を不安にさせない。人脈多いとか技術が最先端とかセンスとかより少なくとも私が一緒に仕事をしたい人はその点で信用できる人だと確信しした。— りさ◆Webデザイナー (@rrisa_wp)

何度も似たようなことを書きますが、「あの人は仕事ができる」という評価を受けるための要因の7割くらいは「すぐできることをすぐやる」っていう機能だと思います。— たられば (@tarareba722)

プロジェクト

若い頃「プロジェクトX」という番組があって、 実在した企業プロジェクトを題材にそれが最後に窮地から大逆転するまでをドラマチックに描く番組で 「俺もこういうプロジェクトをやってみたい」と興奮したものだけど、 今なら分かる 大逆転が必要な位窮地におちいる時点でそのプロジェクトすごくダメ— アイザック (@Isaacsaso)

コミュニケーション

新人に発破をかけるつもりで「君たちは負債です!」って言っちゃう企業。発破じゃなくて冷や水かけてるだけだぞ。モチベーションアップを狙ってるんだろうが、信頼関係が全然できてないのにそんなこと言ったら逆効果だぞ。— MR.Goat@個人事業主 (@Morigori_Kazu)

「批判は人を成長させる」と本気で思ってる人が多くて驚く。少なくとも信頼関係のない誰ともわからないに人に批判されて成長することはないし、身近な人であってもほんとにピンチの時に叩かれたら簡単に心は折れる。批判がプラスになることがあるとすれば、本人に余裕がある時だけじゃないですかね。— えとみほ (@etomiho)

礼儀の定義が変わってきてる気がした 礼儀1.0 相手を重んじる。自分の時間を犠牲にし、時間を相手のために使う。直接会う。スーツなど服装をわきまえる。 礼儀2.0 相手の時間を奪わないようにする(電話しない、リモートで済むものはリモート)— GOROman (@GOROman)

失敗

マネジメント

評価

働き方

要求分析

成長

大企業病

新人教育

能力

行動

やる気

チャレンジ

学習

35歳定年説

エンジニアリング

IT業界

勉強

SIer

炎上

転職

社会

教育

「コミュニケーション=問題解決」という人々と 「コミュニケーション=ポリティカルパワー、利害調整、人心掌握、コントロール」という人々がいる。 後者の人々が、社内ツールの導入の意思決定をするので、社内SNSとかの訳が分からんものが導入されて過疎る。そこにSlackとかがゲリラ戦を— ところてん (@tokoroten)

「航空業界が失敗から学ぶ仕組みを構築している」話、もうちょっと詳しく書くと航空事故はどの国でも独立した事故調査委を置かねばならず、刑事・民事係争に利用されないという免責のもとで、必ず真実に迫り事故を再発させないというただその一点のみのために全ての努力が注ぎ込まれるようになっている— TJO (@TJO_datasci)

自分がミスったなんて報告、「僕ぁ人に詰られるとゾクゾクするんですよ」とかいう性癖でも持ってなきゃ言い難いのが常なのに、それをさらに言い難い雰囲気にしてしまうとか論外じゃないのと思うけど、なんでかやる人結構いるんだよな。— ケルビン@斜壊人 (@legendkelbin)

進捗管理も同じドツボに嵌ってるケースが多い気が。「遅れてます」に対して「具体的なキャッチアッププランは?」と詰め寄るから、段々と遅延が隠匿されるようになって炎上するケースをちょくちょく見かける。 — ケルビン@斜壊人 (@legendkelbin)

マネジメント 1. 部下に好きにやらせる 2. スゲー成果が上ってくるまで待つ 3. 「お前スゲー」って褒める 4. 「こいつ凄いから給与上げてやってくれ」って言う 5. 1 に戻る— Chaos Engineering (@yoshiori)

後こう「作業指示」だけして「作業目的」や「作業理由」を説明しないヤツ。断言してもいいけど、下についた新人は3年以内に「向いてないかも」とか「辞めたい」って言い出すからな。覚悟しとくといいよ。— ケルビン@斜壊人 (@legendkelbin)

「1人1人が自分自身を鼓舞できる環境を作る」のがマネジメントだと思っていたけど、「自分の発言が皆を鼓舞して士気を高める」と思っているマネジメント側の人が結構居る事が分かってきた。— ばんくし (@vaaaaanquish)

「マネジメントにおいて大事なのは、能力と余力と協力を作ること」 ⇒私のクライアントさん(部長クラス)のこのメッセージが、いつも心にズキューンと来る。— 沢渡あまね🍭職場の問題かるた(CV:戸松遥/絵:白井匠) (@amane_sawatari)

最近チーム作る役回りやってたんだが、コミュニケーション最適化するうえで一番大事なの平時のコミュニケーション量だったわ。練習でできないことが本番でできるわけがないのと同じで平時に問題ないことを理由と共に伝える訓練してないと問題発生時にコミュニケーションエラーが事態悪化の要因になる。— ズイショ (@zuiji_zuisho)

固定化したパフォーマンス指標で計測されてることを知ると、その人本来のパフォーマンスが歪められる話。 その指標だけを最大化しようとし、自主性、イノベーション、リスクテイクしなくなる。医者が手術成功率上げるため、難しい患者を避けるなど。 評価プロセスの透明化は弊害もあるなあ。 — Mahiro Watanabe / THE GUILD (@mr_dataman)

ニューエリートでいうこれ、すでに周りだと右側が当たり前という感じになってる。 — けんすう (@kensuu)

時間が無いのではなく、仕事が多すぎるのだ。仕事が多すぎるとは、取捨選択をできていないのだ(鋭利なブーメラン)— Takuto Wada (@t_wada)

改善とは自分の作業が「安全になること」「簡単になること」である。チェックリストに項目を足したり複眼チェックを増やしたりしても安全でも簡単でもない— Ryutaro YOSHIBA (@ryuzee)

資料から松下幸之助の言葉「額に汗することを称えるのもいいが、額に汗のない涼しい姿も称えるべきであろう。怠けろというのではない。楽をするくふうをしろというのである。楽々と働いて、なおすばらしい成果があげられる働き方を、おたがいにもっとくふうしたいというのである。」 — Taisuke 'Jeff' Inoue (@jeffi7)

生産性で大事な順 a. 穴を掘る場所 >>>>>> b. ドリルの向き >>>> c. 掘削効率 多くの人のマインドシェア c. 掘削効率 >>>>>> b. ドリルの向き >>>> a. 穴を掘る場所— Yamotty👨‍👩‍👦‍👦 | 10X, inc. (@yamotty3)

どっかのコンサル「ホームセンターでドリルを買う人はドリルが欲しいのではありません。穴がほしいのです」 俺「うるせー、俺は穴をあける自由と可能性が欲しいんだ!」— tomo makabe (@mkbtm)

そういえば、昨日誰かが「負荷がかかる状況が成長する」みたいなの書いてたけど自分は全くそんな事思ってなくて、とにかく継続して何かをやり続けられる環境のほうが成長すると思う。負荷かけて成長すると思ってる人の下で自分は働きたくない。— V (@voluntas)

企業の老化のサインだと思うもの - 過剰品質を目指す。例えば「何でも一番」とかやると際限なくなる - 手続きの単調増加。ルール作る側はそれが楽 - 局所最適。評価基準を誤るとなりやすい - 一万円の決済のために十万円分の工数かけて会議する類の無駄 推敲してないので不足、重複あると思います— sat (@satoru_takeuchi)

「日本の会社には価値のない仕事、意味のない仕事、お金を生まない仕事があまりにも多過ぎる」 ローランベルガー 遠藤功氏 ここまで断言されると辛い。 さらに 仕事は肥大化する 仕事は個別化する 仕事は陳腐化する だから継続的な仕事の断捨離が必要。 — Katsura (@kazekaoru5gatu)

「君たちは1円も稼いでないので将来に投資してもらってることに感謝して頑張ろう」って新卒に言ってるのをよく聞くけど、まわりを見渡してもそもそも自分の仕事のROIがどれくらいなのかわからず働いてる人がほとんどなので似たりよったりだなって思う季節がやってまいりました。— TAKAKING22@Rain Maker (@TAKAKING22)

私の職場にも5年で5人ほど辞めさせてるのがいる。突き詰めると教育がクソ過ぎるということに行き着く。 ・礼儀がなってないとかで質問に答えない ・クイズ形式 ・後出しジャンケン ・やって見せない ・揚げ足をとる ・重箱の隅をつつく この最強に卑怯な「見えないパワハラ」でみんな病んでしまった。— ガシ (っ'-')転職活動中 (@gashi_lksdsw)

過去の失敗を指摘して「だからオマエは(今後も)ダメだ」と指摘すると、効果的に相手のやる気と向上心を根こそぎにできるのでオススメ。— Yukihiro Matsumoto (@yukihiro_matz)

行動をすると、意識が高いとか、そのやり方じゃダメだとか揶揄されたり批判されるんだけど、行動すればするほど周りの環境がよくなり、批判する人が見えなくなる、と知ってから、行動するときのよく知らない人からの短期的な批判は気にならなくなってしまった。— けんすう (@kensuu)

なんで後者のほうがいいかっていうと、アウトプットを元に議論したほうがはるかに質のよい議論ができるからなんですよね。 — けんすう (@kensuu)

やる気を出す唯一の方法は「無理やりにでもやり始める事」だ。やる気が湧いてくるのをダラダラ待っていてもやる気は湧いてこない。脳科学的にも心理学的にも証明されている。ゴチャゴチャ言わずとりあえずやれ。やってりゃあその気になってくる。やる気に行動を支配されるな。行動でやる気を支配しろ。— Testosterone (@badassceo)

プログラミングの才能なんて僕にだって無いよ。好きか嫌いか、やりたいかやりたくないか。そして、結局の所、やるかやらないか、それが全て。— songmu (@songmu)

「考える前に手を動かせ」 というアドバイスを受けた経験のある人も多いと思いますが、あれはたぶん言葉足らずで、 「考えるための材料が不足だし考え方の訓練も足りてないので、まずは手を動かして材料を集めて欲しいし、それらを基にして考える訓練を積んでね」 という意味だと思うとよいです。— Kentaro Fukuchi (@kentarofukuchi)

だから、成長しようと思っているなら、年齢、性別関係とか出身大学、学部関係なく、今がスタート地点で全く問題ない。 むしろ、それより、今に満足している、俺出来るんじゃ?と思っている方が、大海を知らなさすぎで、怖い。 井の中の蛙大海を知らず。— 寺田佳央@クラウド・デベロッパー・アドボケイト (@yoshioterada)

文書をひねり出すとウンウン悩んでいると滅入ってくるし何も進まないのに、いざ書き出すと時間はかかるもののスルスルと進みだす。「まず始めてみればいいんだ」と毎回悟るけど次回は忘れている— sat (@satoru_takeuchi)

この世には2種類の人間がいる。口だけの人間と行動する人間だ。行動する人間は自分の事で忙しいから他人に口出してる暇なんてない。よって、批判や悪口を言う奴らの大半は口だけの人間だ。口だけ達者で行動しない連中に何言われようと関係ねえ。眼中に入れる必要すらない。ほっときゃいい。— Testosterone (@badassceo)

「基礎をマスターするまで次に進んではならない」式の教育法に付き合っていると、何も出来ないまま人生が終わるので、中途半端な理解でもとにかくアウトプット目指して突き進んだほうが吉じゃ。— ニャンニャニャにゃんにゃ (@NekoAntarctica)

何の才能もないならスピードを磨け。思い立ってから行動に移すまでのスピードを徹底的に上げろ。早ければ早い程良い。早く始めればそれだけ競争相手に差がつくし失敗してしまっても軌道修正ができる。スピード感のある奴は好まれるから良い人脈や仕事が集まって来る。スピードはそれだけで武器になる。— Testosterone (@badassceo)

岡本太郎の「情熱があって何かを始める人なんて少なくて、普通は何気なく始めたことに無意識のうちにのめり込んで、そこから情熱が生まれる」という言葉が好き— songmu (@songmu)

既にあるとか、出来が良くないとからとか、そういう「やらない理由」というのはすぐに見つかるので、その一歩を踏み出せない人は多い。 そういう人ほど、他人の作ったものにケチをつけるのが上手いのだけども、実際に「完成させた人」とは天と地ほどに差がある— ねこめし@Azure (@necomeshi)

手を動かせ,物を作れ,批評家になるな,ポジションを取った後に批評しろ,声明を出せ,それは手を動かして物を作るためのプロパガンダだ.— ドクター落合陽一 (@ochyai)

意識だけ高くなると実力に見合ったことをするのが億劫になるので打席に立つ回数が減るからです. — ドクター落合陽一 (@ochyai)

とっておきのライフハックを教えよう。後に映画化作戦だ。「後に映画化される」と思い込んで生きるだけ!皆が憧れる主人公でありたいしダサい真似はしたくないしハッピーエンドがいいしとか考えてると監督気分で自分の人生を客観的かつ冷静に見れるし、どんな苦境もなんかなんとかなる気がしてきます。— Testosterone (@badassceo)

気持ちはすごいよくわかるんだけど「したうちに入らない」って本当に禁句だよなぁ。それを言いはじめると「完璧にできないのなら最初からやるな」になり、最初から完璧にできるわけがないのでやらなくなる、やらないのでもっとイライラするという最悪のループが待っている— ひよこ大佐 (@hiyoko_taisa)

キンコン西野さんが言ってた 『踏み出す勇気は要らない。必要なのは「情報」だ。』 って言葉がピッタリな感じですね🤔 かく言う僕も、メリットデメリット合わせてたくさんの情報を知って、取るべきリスクを把握してからフリーになりましたから|ω・)و — こじWebエンジニア (@koji_aibaka)

一生懸命やった事がある人は他人の一生懸命を笑ったりしない。勝負に挑んだ事がある奴は敗者を笑ったりしない。笑われようと何言われようと「あの人は一生懸命やった事ないんだなぁ」「勝負した事ないんだなぁ」と同情してやるぐらいで丁度良い。人生なんて一生懸命になって勝負しまくってナンボじゃ。— Testosterone (@badassceo)

そのような、問題を通して考えるプロセスをまったく踏んでいないとしたら、その勉強法は見直した方がいいです。問題をにらんで解法を思いつくのではなく、いろいろ試しているうちにわかってくるのです。手を動かすのが大事です。さもないと単なるパターンマッチで問題を解くことになりかねません。— 結城浩 (@hyuki)

たとえ、世界中の人が《わかった、簡単だよ》と言ったとしても 自分がわかっていなかったら《いや、自分はわかっていない》と言う勇気。それが大切なんだ。 ー数学ガール ゲーデルの不完全性定理 126頁 この姿勢こそが学習者だよね。そしてこういう学習者を受けとめるのが教育者だよね。— 流 (@RyuGotoo)

世界がどんどん残酷になっていって、過去10年のスピードの倍くらいの感じで進化してる。そして新しいものを高速に学べない人とか適切な行動をすぐに起こせない人とかが仕事がなくなっていってる。 僕みたいな凡人はとにかく必死に勉強して行動をするしかないという感覚で、とにかくヒリヒリしてる、、— けんすう (@kensuu)

なるほど 「成功した人たちが凄い理由」の図解に納得の声 「上辺だけ見てはいけない」「他人の努力は見えにくい」 - ねとらぼ から — ねとらぼ (@itm_nlab)

前の職場で上司からも後輩からもそのスキルどこで覚えたんですか?とか何でそんな細かい事まで知ってるのって言われて、最初は茶化して「俺オタクだから」って言ってたけど、ある時から「読んでる専門書の冊数が違うからだよ」ってマジレスするようにしたらそこから会話がなくなったw — LiNK_Spd@矢板HC・乗鞍HC・ツールド日光 (@link_speed)

おれももう50過ぎたし言ってもいいと思うけど、年とったから技術的についていけなくなる人って、大抵25歳ぐらいの時点でもうついていけてない。そもそも最初からついていけてなくて、若いうちは周りのフォローでなんとかなってるだけ。— Atsuo Ishimoto (@atsuoishimoto)

プログラマの仕事 「うーんなんだこのバグ」 →コード読む →わからん →わかってきた! →やっぱりわからん →またコード読む 一週間後にしてほんの数行のコードで解決することが判明 コードなんもわからん人 「ほーん一週間で数行しかコード書いてないの?wwちゃんと仕事しろww」 →そして戦争へ— 堕天使ヴァネロピ (@Vane11ope)

なんでも最善を目指して過剰品質になるのはいかん— sat (@satoru_takeuchi)

人間は繰り返しが苦手です。すぐに飽きてしまい、ミスをおかします。でも、問題を解きほぐすのは得意です。これに対して、コンピュータは繰り返しが得意ですが、自分で問題を解きほぐすことはできません。 出典:プログラマの数学 これだけ端的に人間とコンピュータを比べられた表現をはじめて見た。— はりねずみ (@hedgehog_math)

FacebookのOSSに参加するときに最初に読めって書いてあるから、コーディング規約か何かかなと思ったら、行動規範だこれ (意訳) ・仲良く忍耐強く ・新人さんにも優しく ・深慮して ・敬意を払って ・言葉を選んで ・相手の立場で話を聞こう ・みんな違ってみんな良い— なかざん@やりがいを感じた上で働きたくねぇー! (@Nkzn)

「プログラマは勉強しないってホントですか?」 「ああ、あれを勉強だと思ってた人はみんな消えたからね」— tokoya (@tokoya)

1990年代、大手SIerでは、売上を伸ばす為に、社員にプログラム禁止令が出たんです。社員は管理だけしろと。それで、10年、20年たって、「これは不味い!」と内製する様になったんですが、一旦失われた技術は取り戻せない様ですね。 — 猫好きDB屋 (@neko3daisuki)

日本式設計手順 1 顧客の意見を幅広く集める。 2 エンジニアの意見を聞く。 3 上長、役員の意見を聞く。 4 全員の意見を少しずつ取り入れた製品を作る。 — 中村 俊介(くも)@ (@kumonabc)

まったくその通りすぎる。グーグルがグーグルでいられるのは受託ビジネスじゃないから。受託ビジネスはクライアントの無茶振りに「ノー」と言えなければブラック労働を避けられない。ノーと言うには強いブランド力が必要。それはマーケの賜物である。 — えとみほ (@etomiho)

「終わらなくても一生懸命、頑張ってる姿を見せる」って言葉を使うリーダー層がいたら、プロジェクトを即抜けた方がいいって、3年前の僕が言ってた。 — むぎ (@MUGI1208)

アジャイルだと技術力必要になりますよね?と聞かれることがあるんだけど、それウォーターフォールでも必要です...— Ryutaro YOSHIBA (@ryuzee)

ITの現場ってさ、「システムの稼働に向けて」「ユーザの満足を得るため」じゃなくて 「自分の作業と責任を如何に減らすか」で動いてる人が大半だから、色々と面倒な事ばかりになるよね。— アキラ◆フリーのSE屋さん (@akira_heart458)

人月商売の大手ITベンダーはシステム開発を工業化しようとして、製造業の工場モデルの導入を試みた。自分たちは設計や品質管理、工程管理(≒プロマネ)に特化し、実際に手を動かすプログラマーを工場の作業員と同じ扱いにした。それで本当に工業化できたかと言うと、見事大失敗だった。 — 木村岳史(東葛人) (@toukatsujin)

たかし君は、残業しても仕事の終わる見込みが立たなかったので、上司に相談したところ、解決策が出ないだけでなく次の条件を言い渡されました。 ①納期は延ばせない ②増員はできない ③機能は減らせない たかし君が取った行動のうち、もっとも適切だと思われるものに〇をつけなさい。— むぎ (@MUGI1208)

テスラが宇宙を飛んでロケットが逆噴射で着陸して米軍の無人機が空母に着艦して日米巨大ロボバトルが開催されて仮想通貨500億がサイバーテロにあうような時代なのに、いつまでpdfをプリントアウトして捺印してスキャン取ってメールさせるつもりなのかジャパン(パスワードは追って連絡致します)— TOM (@tom_kinoco)

「開発チームがやることがなくなっちゃったらどうするんですか(怒り気味)?」という反応をよくいただくんですが、稼働が空いても特に直近の問題はないでしょ。空いたら問題だっていうプレッシャーかけるから、タスクをダラダラやったり、やる必要のないタスクを実施したりするんですよ。— HARADA Kiro (@haradakiro)

— むぎ (@MUGI1208)

今の会社が給料低すぎるからもっと給料上げろと不満を言う人達は「今の会社が給料低すぎるから他の会社に転職する」で問題解決するはずで、それができないということは結局今の給料が相応だということ。いつまでも人のせいにしていても何も良くならない。まあ今まで人のせいにしてきたから(以下省略)— 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006)

これはエンジニアがどんどん辞めちゃう会社の管理職の人に言いたいんですけど、辞めるって決めてからの交渉は殆ど無意味です。辞めることがリスキーなのなんて幼稚園児でも分かってるし、それを計算に入れても辞めるって決めてるんですから。日々待遇について考えてください。— beepcap@HTTPSの強制には反対 (@beepcap)

もはや、そこが理想でない会社だと気がついたら、もう辞めるしかないですね!転職しましょう! 変わらない会社にいて、変わらないことにストレス感じるより、読んで感銘を受けて変わっていく会社で働いた方が良いのではないでしょうか。 雇用する側を働く側は選んでいく権利があるので。 — あやにー (@ayanie_jp)

娘が学校行きたがってないってツイートがバズって、多くの人から「学校行かないと協調性を覚えないぞ」ってリプライあったんだけど、実際、不登校児やフリースクールの子とも接してて思うけど、そういう子のほうが協調性結構高いんだよね。学校で学ぶのは単なる服従性だったり無思考性かもしれないね。— 森哲平 (@moriteppei)

昔は村で一番口笛が上手ければ、それを誇りに生きていけた。クラスで一番ラクガキが上手ければ、それを拠り所にしてがんばれた。世界の頂点にいる天才たちの仕事が、スマホから否応なしに流れてくる時代にあって、自分のショボさに耐えながら努力を積み上げていける人間は多くはない。— 荻野謙太郎(マンガ編集者) (@gouranga_)

「マサチューセッツ工科大学でこう言われたという。 「今の時代、すべての科学技術は5年で陳腐化してしまう。だから私たちが教えるのは、すぐに役立つ技術や最先端の科学ではなく、『学び続ける姿勢』そのものなのです」」 — 山形方人(nihonGO) (@yamagatm3)

2018年8月1日
2018年8月1日
https://t.co/YRKAa820R7
2018年7月25日
2017年5月11日
2016年1月20日
2018年7月21日
2018年7月2日
2018年6月11日
2018年4月13日
2017年10月5日
2018年7月1日
2018年4月20日
https://t.co/Owm96e2NbH
2018年4月20日
2018年6月27日
2018年6月17日
2018年5月23日
2018年4月27日
2018年4月6日
https://t.co/LwtnDg9TfT
2018年6月12日
pic.twitter.com/bcu7QvYPU7
2018年4月22日
2018年6月7日
2017年10月13日
https://t.co/CiwSmqEXKk
2017年8月24日
2017年8月22日
2018年5月31日
2018年5月24日
2018年5月17日
pic.twitter.com/DGWbEHelo1
2017年8月2日
2018年5月16日
2018年4月13日
2018年1月13日
2018年7月29日
https://t.co/T0mxL5uwMV
2018年7月9日
2018年5月12日
2018年6月19日
2018年6月8日
2018年5月17日
2018年5月16日
2018年5月15日
2018年5月6日
2018年4月12日
2018年3月5日
2017年11月26日
2017年9月26日
https://t.co/6u3PVBPQAY
2017年4月23日
2016年12月4日
2018年6月21日
https://t.co/Pz81ycojXQ
2018年5月17日
2017年8月31日
2018年2月26日
2018年2月20日
2018年2月11日
https://t.co/qjPMxmLfCs
@itm_nlab
pic.twitter.com/xo18zHA1Wv
2018年5月13日
https://t.co/fHG4JH9vLL
2017年8月2日
2018実は最初から使い物になってないんだけれども、それをようやく悟るのが35歳 https://t.co/uyXLvf3FMx— 山本ユースケ (@yusuke) 2018年2月28日
2018年5月27日
2018年5月17日
2018年1月22日
https://t.co/dMtat3itrz
2018年1月3日
2017年7月21日
https://t.co/DKSryiUikx
2018年7月1日
https://t.co/rLCoz1fJ6Y
2018年6月30日
https://t.co/MfArzlu4zK
2018年6月30日
https://t.co/BOOhtv1Rui
2018年5月24日
2018年5月21日
2018年4月13日
https://t.co/0KqZXlBawl
2018年3月15日
#IT系応用問題
2018年2月15日
2018年2月7日
2017年9月15日
#今までの炎上パターンに名前つけてみました
pic.twitter.com/MyabfDSR9l
2018年4月4日
2018年7月17日
2018年5月29日
https://t.co/KgdNksOOg7
2018年5月19日
2018年5月27日
2017年11月13日
https://t.co/GFPARSFx3S
2017年7月8日