リモートワークの中で大事なこと - そーだいなるらくがき帳
リモートワーク、テレワークが本格的に始まって1ヶ月以上経った人も多いのでは無いでしょうか。 自分は2月から独立してほとんどをリモートワークで過ごしてきましたが、その中で大事だなと学んだ知見を共有していこうと思います。 作業環境は大事 そーだいなる環境 静音キーボードがオススメ ネットワークは本当に大事 会社は積極的に支援すべき 買ってよかったリスト フットレストがあると疲れが違う ペンタブがあるとテレカンが捗る 毛づくろいの会話が大事 雑談するトリガーを増やす 気軽に雑談出来る場所を増やす リモートワーク交流会の開催 オンラインだと繋がりが偏る 関係する線を増やす 進捗は全てを解决する 適切な問題設定が大切 まとめ 合わせて読んでほしい 作業環境は大事 まず一番大事なのは作業環境です。 どこまで投資するか難しい…って気持ちもわかります。 しかし緊急事態宣言は延長され、会社のリモートワークも
障害から学ぶクラウドの正しい歩き方について考える - そーだいなるらくがき帳
AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか？ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か？と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか？というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため
成果で評価していくということ - そーだいなるらくがき帳
最近、この話をすることが多いのでブログに個人的な意見をまとめる。 まず成果主義と結果主義は違う。 勘違いされてる人が多いけど成果主義は成果とそれまでの過程を踏まえて評価する。 結果主義はその言葉の通り、結果のみで評価する。 そのため売上を至上と置いてる営業の評価をする場合などは結果主義はわかりやすい。 個人的な意見では結果主義は嫌いではないし、スポーツなどは完全に結果主義だ。 それは置いといて、多くの会社は成果主義であるし、だからこそちゃんと成果で評価すべきだ。 その点について次のようにまとめる 成果を評価するということ 成果を評価するためには 目標を設定すること と 行動すること が必要だ。 行動した結果、成果が生まれ、そしてその成果が目標を達成したかを評価する。 結果主義であれば目標に対して、成果がどの程度達成したかの差分だけで評価する。 成果主義はその過程も評価するので達成した上で、
ソフトウェアエンジニアが当たり前にやるべき事 - そーだいなるらくがき帳
manabusakai さんの下記の記事を読んだ感想。 blog.manabusakai.com Twitterにも書いたけど僕は信頼されるエンジニアをずっと目指してきたし、そのために僕に必要なことがここには詰まっていた。 ほんとみんなに読んでほしい。 このエントリーの中の信頼を得ているエンジニアの姿を引用する。 有言実行である 仕事の納期をきっちり守る どんな仕事でもムラがない 困ったときに快く相談に乗ってくれる 皆がやりたがらないタスクを拾ってくれる チームの雰囲気を良い方向に導いてくれる etc... まさに。 ではソフトウェアエンジニアとしてこの他に当たり前にやるべき事って何があるだろう？ ソフトウェアエンジニアとしてやるべき事 僕らは技術で問題を解決することで価値を高めたり、対価を頂いている。 例えば使っているOSSにバグがあったらどうだろう？ これは自戒をかなり含むが不満をSN
プロセスの監視 ~ check-procsを読み解く - そーだいなるらくがき帳
この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の8日目です。 qiita.com soudai.hatenablog.com それでは8日目は check-procs です。 check-procsはプロセスを監視してくれるプラグインです。 github.com インストールと設定手順 至れり尽くせりなので公式ドキュメントに手順が書いてあるのじゃ！！ mackerel.io 使い方 至れり尽くせりなので公式ドキュメントに使い方が書いてあるのじゃ！！ mackerel.io オプション一覧 公式ドキュメントに無いので追加しました。 # check-procs -h Usage: check-procs [OPTIONS] Application Options: -w, --warning-over=N Trigger a warning if over a n
エンジニアの信頼を得るには良質なアウトプットが必要な話 - そーだいなるらくがき帳
先日、僕が大好きでリスペクトしてるソフトウェアエンジニアさんたちと意見交換会（呑み会）中にソフトウェアエンジニアの信用と信頼について話題になったのでメモ。 僕が「このソフトウェアエンジニアは信用できる」っていうのはどういう指標がありますか？って質問した時に出た意見としては コードに対して何らかの貢献をしている 新規プロダクトの開発など OSSのメンテナンスなど（パッチを送るなど） 自分の持つプロダクトに対する反応など が出てきた。 これらのような「良質なアウトプット」を定期的に行う頻度も大事だよねという感じ。 なるほど、確かにって思ったのだけど更にその中で良質なアウトプットとは何かという話題になった。 ソフトウェアエンジニアの属性 ソフトウェアエンジニアには得手不得手がある。 言語だったりレイヤーだったりで好き嫌いも含めて得手不得手がある。 更にもっと言えば「プロダクトの成長段階」でも得手
早くチームにマッチするために気をつけてる事 - そーだいなるらくがき帳
新入社員として1週間が過ぎた。 ブルックスの法則的に考えても私はまだチームにとって生産性をマイナスさせる存在でしかない。 ブルックスの法則 - Wikipedia だからいち早くチームにとって必要な存在になる必要があるし、そのために気をつけてる事をメモする。 これを見て「もっとコレした方がいいよ」ってアドバイス、逆に「それは不要だよ」ってアドバイスを期待してる。 チームやプロダクトを好きになる これはとても大切なことだ。 嫌いな人とは仲良くできないし、嫌いなプロダクトは育てれない。 もし、コレを読んでる人が職場のチームもプロダクトも嫌いなら転職した方がいい。 ただ好きの反対は無関心なので無関心の場合は条件付きでやっていけると思う。 この辺の話は主旨が変わるのでまた別の機会があれば話したい。 コミュニケーションについて 新しいチームに合流してまず一番大事なのはコミュニケーションコスト。 自分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
