過去の賢人に学ぶ、インフラ運用チームのマネジメント失敗事例 - Qiita
gumiアドベントカレンダー9日目です。 今回はちょっと技術的なことを離れて、チームマネジメントまわりのことを書いてみようと思います。 1.チーム背景 私の所属しているチームは、主にAWS環境の運用を行っています。 チームメンバーは、ほぼ私が1人で対応していた時期から、数人規模のチームを推移してきました。 「愚者は経験に学び、賢者は歴史に学ぶ」とはよく言ったもので、残念ながら私は完全に前者になってしまいました。 改めて自分の失敗を振り返ると、良書と呼ばれる本には、失敗内容に関連した内容が記載されています。 特に、【Team Geek】の内容は、以前読んだ筈なのに全く実践できていなかったなあと。。。 【参考】『Team Geek』を読んだメモ 今回は、私のチームマネジメント失敗事例やそこから学んだことを徒然なるままに書いてみようと思います。 2.失敗したこと 2-1.メンバーの増加タイミング
[ThinkIT] オープンソース時代の企業システム選択ポータル
2024/8/11 オープンソースのアプリケーション開発フレームワーク「Flutter 3.24」「Dart 3.5」リリース 2024/8/11 「KDE Frameworks 6.5.0」リリース 2024/8/9 「Samba 4.20.4」リリース 2024/8/5 新しいカーネルが採用された「Arch Linux 2024.8.1」リリース 2024/8/4 エレコムの無線LANルーターに複数の脆弱性、JPCERT/CCが注意喚起 2024/8/3 オープンソースのコンパイラ「GCC 14.2」リリース 2024/8/3 プログラミング言語「Rust 1.80」リリース 2024/8/1 「Xen 4.19」リリース 2024/7/31 機械学習フレームワーク「PyTorch 2.4」リリース 2024/7/31 バージョン管理システム「Git 2.46.0」リリース
業務系エンジニアはどうしていくべきか？ - 急がば回れ、選ぶなら近道
まず超個人的な見解です。あとWeb系の人は関係ないので、そういう人は読んでも無駄です。ここでいう業務系エンジニアというのは、主にSI屋で特定企業向けのシステムを構築しているエンジニアの人たちをさします。 まず、非常に難しい時代になったと思います。 端的に、ちゃんとしたSIをやることが難しくなりました。まず、技術的には面倒なことが増えた、というかできるオプションが制御できないくらいに増えているので、うまく制限をしないとコードや仕組みが劣化する一方になりました。エンジニアリングに自由を！というのは聞こえはいいのですが、チームプレーをするのに、いちいち約束事決めないと回らないようになっているような気がします。それも毎回。始めるたびに。 別段、いきなりチームメンバーの能力があがったり、さがったりするわけではないのですが、なぜか外すと酷いことになる振れ幅が増大したような気がします。ルール決めをいちい
夜遅くまで残業する技術者たちへ--身の安全を図るための10の自己防衛術 - builder by ZDNet Japan
あなたも「コンピュータの専門家」という言葉から連想されるステレオタイプなイメージをご存知のことだろう。極めて聡明であるものの、内向的で少し軟弱（他に言いようがない）というものだ。もちろん全員がそうであるというわけではない--しかし、IT分野に従事する人の多くは、護身術の訓練を受けたことがないということも事実だろう。われわれは、自らの身を守ることよりも、ネットワークを守ることに注力している。このため、自らの仕事に熱中するあまり、身の周りで起こっていることに気が付かないということもあり得るのだ。 われわれの仕事の性格上、サーバにパッチを当てるために、あるいは翌日の始業時間までに電子メールを復旧させるために、他の人々が帰宅した後も夜遅くまで仕事をしているということが多いはずだ。その結果、睡眠不足と極度の疲労に襲われ、周囲の状況に注意を払っていない状態で、午前2時に暗い駐車場を歩くこともあるかもし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
