日記駆動仕事術のススメ | DevelopersIO
「仕事日記を書くといいですよ」という話をする機会があったので、日々の仕事をスムーズにするシンプルな「日記駆動仕事術」について書いてみました。 日記書くといいですよ prismatix事業部の塩谷(@kwappa)です。 他部署の人と1on1する機会があり、その中で「日記書くといいですよ」という話をしました。 そういえば以前からことあるごとに「日記書きましょう」と言い続けていたのですが、ちゃんとコンテンツにしたことはなかったような気がします。 せっかくの機会なので、日記駆動の仕事術とその意義について書いてみます。 日記駆動仕事術 これはぼくの1月の日記（架空）です。Notionを使って、1か月に1ページ使うようにしています。やり方はシンプルなので、手に馴染んだツールで置き換えることも簡単だと思います。 タイムラインとしては、1/31(月)の業務を開始したところ、だと思ってください。 TODO
「仕事のコード」を残す際のチェックリスト｜Uchio Kondo
最初に注意: この文章は「はじめに」「総論」が長いです🙃 追記＠2021/08/11 17:46想像よりはるかに反響をいただいたので、せっかくだからと要点をMarkdownにしてGitHubに置いてみました。何かにご利用ください。 はじめに・「仕事のコード」、つまり、業務などで作ったコードが、なるべく負債にならず、なるべく俗人化しないようにするために留意すると良さそうなことを自分の経験などから列挙したものです。 ・ちなみに、「対象読者」に書いてありますが、そもそものモチベーションが「非エンジニアがノーコード系のサービスで作ったシステムが最近増えつつあるような...」というところでした。こういうのどう取り扱うといいんですかねとなった時、まずは運用できる形にしてもらいたい、という狙いがあります。結果的に、ジュニアなエンジニアが良いシステムを残す上でも使える知識かなと思います。 ・個別の項目に
PDCAサイクルが古い？OODAループと比較、PDCAとOODAの活用方法 | AndHA Blog
PDCAサイクルが古い？OODAループと比較、PDCAとOODAの活用方法 公開日 : 2021.07.06 最終更新日 : 2022.10.05 デザイン デザイナーのリュウイチです。 早速ですが皆さん… 最近どう？PDCA回してる？ 回してますかぁ。いいですねぇ。Hi-Hi。 より良い質の仕事をしていくのには欠かせませんよね。 仕事のデザイン制作ではもちろん、 趣味のミニ四駆でもPDCAを意識してやってみていて、これがまた面白いんですよ。 そんな事をやっていたら聞こえてきた。 “PDCAサイクルは古い” … 嘘だ！俺のミニ四駆はPDCAサイクルで少しずつ早くなったんだ！ じゃ〜PDCAに変わる新しいものってなんだよ！！ OODA(ウーダ)ループ…? と新しい言葉と出会いまして PDCAとは何かを振り返ってみて、 OODAループとはなんぞや？と それぞれの比較もまとめていこうと思います！
みずほ銀行システム障害に学ぶ
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（
入門 入門 監視 / reading-practical-monitoring
「入門 監視」を読んだので、自分たちのチームに当てはめて考えてみる
「無人化システム」を駆逐する組織マネジメントとエンジニアリング
弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい
毎朝15分以上のデイリースクラムをしてる - Mitsuyuki.Shiiba
15分以上のデイリースクラム 今一緒に仕事をしているチームでは、毎朝みんなで集まって話をしてる。みんな家から仕事してるからZoomで。 デイリースクラムみたいなものではあるのだけど、15分以内におさめる、ということはあまり考えていない。 だいたい15分は超えていて、長いときは30分ぐらいかかる。でも、それでいいと思っている。それだけ話すことがあるというだけ。 どうして？ 理由は、開発チームだけじゃなくて、プロデューサーも含めて全員で「現状を確認する」「同じ方を向く」「不安を共有する」ということをやっているから。実際のところ、開発チームだけの話だと5分もかからない。 プロデューサーはチームの外側で起こった色んなことをフィルタリングして開発チームに必要な情報を届けてくれる。とても助かる。お互いに情報を共有して、現状の認識合わせをする。そのうえで、今日何をやるべきかを再確認している。 そんな感じ
遅いデジタル投資は、コストだけがかかる｜深津 貴之 (fladdict)
仕事上、デジタル・トランスフォーメーションの相談が、ちょいちょい発生します。 DXの苦戦例というと運用体制や制度変更せずに、無理やり技術導入してる…がありがちですが、それ以前に「タイミングを逃した」導入ケースも多いイメージです。 共通課題すぎるので、よくするテクノロジー導入の例え話をnoteにまとめておくことに。 戦国時代の鉄砲導入を例えにした小話です。 最初に火縄銃を導入した人一番手は高コストかつ、ハイリスク・ハイリターン。そもそも一番最初は、この技術がアタリかも不明瞭。自分でリスクと手間をかけて、運用体制や使い方を確立しなければならない。 ただし技術導入に成功したときには、圧倒的に無敵なポジションを取れる。押し寄せる武田の騎馬隊を、コテンパンにできる！ 成功事例をみて即座に導入した人 一番コスパが良い賢いプレイヤー。ミドルコスト、ミドルリスク・ハイリターン。他人がコンセプト実証をしてく
ネットワークエンジニアとして
◆ ネットワークエンジニアのメモ：ブログ ⇒ iPhone、キャリア契約者数、成功する働き方 ◆ ネットワークエンジニアのランチ：ブログ ⇒ ランチ、ITニュース、Cisco、Network ◆ ネットワークエンジニア 役立つ物理ツール ⇒ 構築作業や保守作業で役立つ物理アイテム ◆ サーバ技術入門：サーバの基礎をはじめから ⇒ インフラエンジニアに役立つサーバ技術解説 ネットワークエンジニアとしての Network Studyでは、これからネットワーク エンジニアになりたいと考えている方や、CCIEレベルのネットワークエンジニア になりたいと考えている方に役立つよう基礎から上級レベルまでNW技術を解説。 Network Studyの内容は、国家資格であるネットワークスペシャリストの取得や CCNA/CCNP/CCIE取得に役立つ内容に仕上げているだけではなく仕事で役立つ ようにCisco
障害対応時にまずはissueを作ると良い - そーだいなるらくがき帳
先日のAmazon SQSの障害には色々と肝を冷やした人も多いのではないでしょうか。 classmethod.jp 今回のようなケースとは別に障害は大小あれど、みなさん日々戦っていることだと思います。 障害対応はエンジニアの花形であるものの、サービスに対する知識やソフトウェアの知識など経験と技術の両方が必要です。 そのため、どうしてもトラブルシューティングはエースエンジニアなどの一部の人に依存してしまう…などの問題が発生しがちです。 そこで今日は私の経験から障害対応のいろはを書いて行きたいと思います。 今回のスコープの外 実際に障害時の具体的な対応、例えば障害切り分けやRDBMSのボトルネックの探し方などの話はしません。 まずissueを作ると良い 本題です。 トラブルを認知したらまずはissueを作りましょう。 issueを作るときはtemplateが事前に設定されていると便利です。 g
なぜ「システムが無事に動いている」ことの価値は理解されないのか
最近はあまり技術的な仕事をしていないんですが、実は私は元々DBエンジニアです。 OがつくDBとか、PがつくDBとか、mがつくDBとかをいじくって、クエリを書いたり、テーブルの設計をしたり、パフォーマンスのボトルネックをあれこれ調べて解消したり、INDEXヒントを総とっかえして頑迷なオプティマイザをぶん殴ったりすることが主なお仕事でした。今でもたまーにそういうことをします。 同業の方であればお分かりかと思うんですが、DBのパフォーマンスは凄く唐突に、かつ多くの場合極端に落ちます。そして、DBのパフォーマンスが落ちると物凄く広範囲に影響が及びます。 アプリケーションサーバ、重くなります。クライアント、ろくに動かなくなります。お客様、切れます。カスタマーサポートにはわんさか電話がかかってきます。 ただ「遅くなる」だけでも十分に影響は甚大なのですが、それ以上のトラブルが発生するとまあエラいこっちゃ
エンジニア3人で支える月間10億PV
・2年で月間10億PVを支えるまで成長した ZenClerkの運用上の工夫を紹介 ・AWSのTipsとあるある話の共有
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードレビュー研修