はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最強のスタッフ エンジニアは意外とマネジメントぽいこともするかもしれない #スタッフエンジニア - Qiita と「スタッフエンジニアの道」で思いつつ、でもマネジメントというものが好きになれない。そんな私だがタイトルで興味を持った「マネジメントは嫌いですけど」を読んだ。 マネジメントは嫌いですけど | 関谷 雅宏 |本 | 通販 | Amazon マネジメントを生涯やりたくないので、やらないで済むために、2025 年はマネジメントを理解したい。 感想 エッセイの趣が強い。それが面白みでもあるのだが、体系だってマネジメントを理解する本では

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? アドベントカレンダーも今年の仕事も終わった。こんなところにこっそり書くと照れられるか絶妙な面持ちをされるかしそうなのだがもう年末なのでこっそり書いておきたい。私はいわゆる中年だ。40 代女性。 なぜ俺たち中年はアウトプットできなくなったのか #ポエム - Qiita を読んだ。 あと 仕事する上で(外見を含む)年齢というバイアスから解き放たれればだいぶ楽に働けるようになる気がしている。 という 前職の人事担当者のつぶやき を最近読んだ。私も本当にそう思う。 私はというと 2022 年に人生初めて転職して、ようやく 3 年目、のペーペーを

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? しくじりエンジニア！私みたいになるな！ - Qiita 人間であれば誰しも「しくじったこと」が一度はあると思います。 あなたがエンジニアとして「しくじったこと」で思い浮かぶものは、どんな内容でしょう? を思い浮かべてのポエムです...。もちろん具体的な誰かの顔をイメージする記事ではないですが、社会人も 20 年そこそこになると「余計なこといっちゃったなー」とか、「うわあああ！ (頭の中で後悔)」とか、後になって胸にチクっとくる場面を、(割と)(これでも)(幾度となく) 経験しています。 Unsplash 本番サーバー60台のホスト名を全

海外エンジニアに、要件を伝えたい。できれば効果的に読んでもらいたい。しかし 69 ％の人はメールを、サラッとしか読まない 1 つのメールにかける時間は 10 秒以下 45 ％がスマホ等でメールを確認している ...らしい。【保存版】悩まず書ける！英語メールの書き方の５つのポイント | 英語で暮らしと仕事が楽しくなるビズメイツブログ Bizmates Blog 踏まえ書き記す。 基本フォーマット What How By When Hello team. After deploying [foo] there is an error like [bar]. Need workaround by [1st, Aug etc..]. ## Impact Need workaround. ## Status Now Customer is [hogehoge]. Regards, -- [Your

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 製品を提供する開発のお仕事は、期待を良い意味で裏切ったり、悪い意味で裏切ったりすることがあると思います。ユーザーから受けるフィードバックにはどちらかと言えば悪い意味で期待値がズレていたことが可視化されてきます。そのすべてを「伸びしろ」として受け止めておけば、受け止める側としては良いことづくめなのですが、一方のユーザーには「消化不良」が残ることになってしまいます。 そんなユーザーの期待値をどうコントロールするか、永遠の課題ながら、なんとなく思っていることを見える化してみようとして書きます。我流ですが… 例えば 人は、期待値という物差しで相

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あー、そういえばちょうど良い具合の勤怠管理システム欲しいな～！ そんな休日ありますよね！？ Azure でちょっとしたプロトタイプみたいな設計レシピ作ってくれと言われたので作り始めてみたメモ。 オーダー: 就労管理 Azure を使う Azure OpenAI も使う あとは自由 雑だがあとは自由なら自由にやってみようということでとりあえず。 Request 時刻を Excel に記録 Microsoft Forms からの Request を Excel に記録 アイディアを膨らませる ものが動くと楽しいですよね。 勤怠管理システムを

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング | ジャレッド・バーティ, ザッカリー・サラ・コ―ライセン, ジェン・ランボーン, デービッド・ヌーニェス, ハイディ・ウォーターハウス, 岩瀬 義昌 |本 | 通販 | Amazon 本書は経験に長けた執筆者たちがドキュメントを作成する方法をゼロから説明するフィールドガイドです。 架空のソフトウェア開発チームのストーリーを追いながら、ソフトウェア開発ライフサイクルの各ステップにおいて、ユーザーニーズの理解、開発者に役立つドキュメントの作成、公開、測

ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析 | Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani, 島田 浩二 |本 | 通販 | Amazon を読み直したのでその読書感想文です。 本書は、読者が自身のアーキテクチャ上の難題に対して効果的なトレードオフ分析を行い、より良い決定ができるようにするための書籍です。 本書では、サービスの粒度やデータの所有権、コードの再利用やワークフローの調整、可用性や信頼性の実現といった現代のソフトウェアアーキテクチャの難題と、それに対するさまざまなアプローチやパターンを紹介します。そして意思決定を難しくするトレードオフについて、モノリスを分解しマイクロサービスアーキテクチャに再構築する例を通して詳しく説明します。 『ソフトウェアアーキテクチャの基礎

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

前略、退職します。そんな実はいわゆる「退職エントリ」なのですが、会社の皆様へのお礼がてら。結論から書くと 「発信」することで自分の可能性と視野が広がるよ、発信は良いぞ、という話（ポエム）です。「自ら～」は有名な リクルート社 の言葉ですね（私はリクルート社のひとではありませんが）。純粋に好きで自分の感情にフィットするのです。 ↑退職を伝える社内Slack とてもとてもお世話になりました 自己紹介と経歴 2003年、新卒入社以来「ERPの開発」所属20年目。上海赴任経て2児の母をやっています。20年の構成成分は以下です。「発信活動」はそのうち10～20％くらい。およそ赤線の成分内にやっています。 だから、8割はインプットの人です。なので全くすごいことはありません。学びを結果に変えるアウトプット大全 という本では7割アウトプットすら奨められているようで。インプット・アウトプット半々くらいでよい

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「推測するな、計測せよ」って誰が言ったの？という話。 「推測するな、計測せよ」という言葉があり、いかにも、「憶測で物を言うな」という文脈での逃げワードとして使われがち。しかしいかにも日本語的に語呂が良すぎるので、日本語話者以外であるであろう誰かの意図を、日本語で良いカンジにリメイクしたものだと「推測」していた。 似たところに「マッカーサー元帥の部下であり、日本の産業界に統計学的手法をもたらし大きな影響を与えたというデミング博士」の webサービスの性能改善や大企業に伝わるQC活動の文脈でよく使われる「計測なくして改善なし」*1

グレース・ホッパー - Wikipedia Grace Hopper - Wikipedia “アメージング・グレース” , グレース・ブリュースター・マレー・ホッパー (Grace Brewster Murray "Amazing Grace" Hopper, 1906年12月9日 - 1992年1月1日) は、アメリカ海軍の軍人かつ計算機科学者。75歳で退役、最終階級は准将。プログラミング言語COBOLを開発した。 Image COBOLの母、「グレース・ホッパー」です。こんなCSSアート作品もあるようです。 See the Pen Single Div Grace Hopper by Tricia Katz (@triciaakatz) on CodePen. ともかく、リアルコンピューターおばあちゃんと言える位カッコイイのです。 名言 おばあちゃんの名言。 9 Grace Hopp

「暴言吐かないように気をつけます」 暴言暴言書いているので念のためBOSS（社では執行役員ともいう）のお名前はマスキングしています。弊社の開発部のトップリーダーに彼自身の「分報」を開設させる、という今年前半の社内コントリビューションを自慢するために書いています。 関連: Developers Summit 2022に登壇したので、その感想🍬 - Qiita 「弊社の執行役員に、#times_役員 なSlack分報を開設させるまでにやったこと全部書く」。BOSSは尊敬している。だからこそもっとBOSSと気楽に話したい、仲良くなりたい、BOSSの考えていることを知りたい、でも話しかけるのは緊張しちゃう、いつでも話していいよ？ムリ～～... そんな悩みをもつ方やチームの参考になれば嬉しいです。 結論: 地道なお互いの信用獲得。それは狩猟ではなく農耕 結論から。地道にお互いと全方位的な信用獲得を

複文は単文に分ける 区分ごとのロジックを別クラスに分ける 区分ごとのクラスを同じ「型」として扱う 区分ごとのクラスのインスタンスを生成する Javaの列挙型を使えばもっとかんたん 入門Javaのenum - Qiita 区分ごとの業務ロジックを区分オブジェクトで分析し整理する 状態の遷移ルールをわかりやすく記述する 第3章　業務ロジックをわかりやすく整理する データとロジック (計算式) を別のクラスに分けることがわかりにくさを生む 業務アプリケーションのコードの見通しが悪くなる原因 データクラスを使うと同じロジックがあちこちに重複する データクラスを使うと業務ロジックの見通しが悪くなる 共通機能ライブラリが失敗する理由 データクラスが広く使われているのは、手続き型プログラミングの実装単位として採用した結果 業務ロジックをわかりやすく整理する基本のアプローチ データとロジックを一体にして業

読書において読み飛ばしはアリか？ 新人さんにすすめる有益なツール達 2022春 - Qiita 新人さんにすすめる有益な技術書達 2022春 - Qiita 新人さんにすすめる (弊社の) 有益な記事達 2022春 - Qiita で新人さん向けまとめを作成した。 が、こんなに読めないよ、と感じる方もいると思う。 私は多読に挑戦していたら「どうやって読んでいるんですか」などとも聞かれるようになった。なんだかしっかり本を読んでいるように思われてしまうのも恥ずかしい。この記事では 「読書において読み飛ばしはアリか？」 をテーマに、読書術について書きます。タイトルの「さいきょうの」は私見をまじえている点でそう書きました悪しからず 先に結論: 「読書において読み飛ばしはアリ」 「本は必要だと思ったときに、手の届くところに置いてあればよい。本はうまく活用すれば、Google検索よりも質の高い情報に短

新人さんにすすめる有益な技術書達 2022春 - Qiita に記載しておきつつ自分はしっかり読めていなかったので読んだ本。開発者にも有益な「コンサル一年目が学ぶこと」について理解した点のまとめと、開発者として「コンサル」な人とお仕事をする上でどういうマインドを持ちたいかのメモです。 図解　コンサル一年目が学ぶこと | 大石哲之 | ビジネス・経済 | Kindleストア | Amazon https://d21.co.jp/book/detail/978-4-7993-1532-3 感想 ストイックだなあ... 言っていることはわかる。でもストイックだなあ... という感想である。 何故これらが大事なのか、のテクニカルな側面はもっと他の本で深掘りするのが良いのかもしれない。例えば会議の議事進行などは 「世界で一番やさしい会議の教科書」を読んだので、その要点 - Qiita がおすすめであ

「Visual Studio Code完全入門」 発刊1カ月で重版！ 『Visual Studio Code 完全入門』が3日間限定で全文無料公開中 - Book Watch/ニュース - 窓の杜 『Visual Studio Code完全入門』重版出来記念、全文無料公開キャンペーン - インプレスブックス Visual Studio Code完全入門 Webクリエイター&エンジニアの作業がはかどる新世代エディターの操り方 - インプレスブックス 5/21(Sat) 23:59まで無料公開中とのことで、斜め読みし、自分にとって発見だった部分のメモです。 筆者: リブロワークス – LibroWorks – 編集プロダクション・リブロワークスのWebサイト Visual Studio Code完全入門 Webクリエイター&エンジニアの作業がはかどる新世代エディターの操り方 | リブロワークス

はじめに 自分と似たような好み (宗派) の人の参考になればと思い書いています。自分の好みとは... 脱ExcelしたいMarkdownテンプレート目次 - Qiita Notion概要と、無料Markdownエディタとの比較 - Qiita ですが正直なところNotionは使いこなせているわけではなく、日々の打合せやネタ帳をただの *.txt でWindowsのお仕事自端末に保存して過ごす人生でした。 きっかけ Obsidianは最高のマークダウン『メモ』アプリである 最高とは。しかしそういえば自分の *.txt 、書くだけで見返すことができていない... 。 そこで WindowsデスクトップVersionを入れた Obsidian is a powerful knowledge base on top of a local folder of plain text Markdown

UNIXという考え方 | Ohmsha Amazon - UNIXという考え方―その設計思想と哲学 | Mike Gancarz, 桂, 芳尾 |本 | 通販 感想 「プリンシプル オブ プログラミング」 でも触れられている「UNIX哲学」そのものの本。哲学と、その背景にある「理由」を理解できる。最後に他のOSにもリスペクトがあるのが素敵。読み方としては一通り「プリンシプル オブ プログラミング」的な本を読んだあとそれでもUNIXを敬遠するなら、これを読んでみたら意外と考えが変わるかもしれない本であった。 素人さんお断りのUNIXというものが最も大切にしているのはなにか？である。 要点 イントロダクション UNIXの創造者たちは、ユーザーは初めからコンピュータを使えるとみなした。「ユーザーは自分が何をしているかを分かっている」前提。 第1章　UNIXの考え方：たくさんの登場人物たち 定理

ここ数日流行りの言説「～はブルーオーシャン」に乗じて過去のメモを放流しています。 保守開発はブルーオーシャン エンタープライズ製品、花形は設計、新機能リリースであって欲しい。一方、当然その裏には保守、サポート開発という甚だ地味なチームがいる。 保守開発の1日 お客様からの問合せを捌き 今月の不具合対応チケットを捌き それでも差し込みが入る。 トラブれば他部署との打合せが多くなるから 残りの時間で頑張って本でも読めたらそれは最高だがそんな日がなかなかない。 成長の法則には70:20:10というものがあるらしいが私の場合は20を仕事で学び80をコミュニケーションの難しさに悩み10を無理やり溢れさせてどうにか学習しているもんだなあなどと思う。 なんてことを少しは反省して以前、こういうことを書いた : 有害な頑張り コロナ禍で在宅勤務が増えた エンドユーザの自宅PCからPingだWireshark

考え方 質問は恥ではないし役に立つ。きょうびお金を払えば何でも教えてもらえてしまう時代... プログラミングで発生する「エラー」に立ち向かう秘伝書 のような書物が常にあるとは限らない そんなの自分で調べてよ！ そんなの早く質問してよ！ なんてつまらないすれ違いは勿体ないです。聞きづらい雰囲気があるとしたら先輩側の教え手としての技量不足。先輩も新人さんも効果的に質問しあえるようにするのが鉄則だとおもいます。まとめてみました。 効果的な質問をする時の鉄則 主語を書く。 質問の目的をはっきりさせる。 解決期限をはっきりさせる。 5W1Hを伝える。 自分で試したことがあれば伝える。 質問に関連する操作の内容、ログ、エラーメッセージ等の情報を全部伝える。 以下テンプレートに則る。 質問テンプレート 15分かけて考える。ただし以下を埋めるために15分かかってしまったらその時点で書けたところまでで相談す

話題の 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方 | 仙塲 大也 |本 | 通販 | Amazon の読書感想文です。 SNS時代ならではの本だと感じた まず驚いたのがこの本冒頭、#ミノ駆動本 とハッシュタグのガイドが書かれています。 本書のSNSでのハッシュタグは #ミノ駆動本 です。本書の感想などを投稿するとき、ぜひお使いください。 なるほどこうして体験を共有することを最初から想定しているのだな～、と (本筋と少々ズレたところで) 感服しました。ということでお祭りに参加するつもりで書き留めています。 リファクタリングを勧善懲悪で、ゲーミフィケーションした痛快な攻略本だと思った 「クソコード動画」やゲームがむしろアイディアの核にあり、技術的根拠詳細が語られている本と考えると、余計なるほどな、腹落ちするところ多数でした。誤解を恐れず書くならば、むしろ

システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション | Jeffery D. Smith, 田中 裕一 |本 | 通販 | Amazon エンジニアがDevOpsで解決する組織・自動化・コミュニケーション。早速お薦めしたく書いています。読書感想文です。 感想5点 良いぞ。周りに薦めたい 百聞一見。目次だけでも: https://www.oreilly.co.jp/books/9784873119847/#toc 特に自分にとって良かったのは以下 9章　せっかくのインシデントを無駄にする 10章　情報のため込み：ブレントだけが知っている だが、一番スゴイのは11章かもしれない 「文化を変えようと思うのであれば、文化がどのように共有されているかを理解すること」 コロナ以前は 議事録 会議 机横での雑談 飲み会 タバコなどなどあったが コロナ以降、リ

プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則 | 上田 勲 |本 | 通販 | Amazon 読書感想文です。 いい仕事いい先輩いいコードに、自分にとっていいタイミングで巡り合えれば、成長できます。しかし、これは運に左右されます。確率は高くありません。 そこで書籍を読んで勉強します。ただし、初学者向けの書籍では文法とイディオムは身に付きますがプログラミングスキルの改善には至りません。 そうかと言って、達人プログラマたちの名著を読んでも敷居が高く難しすぎて挫折したり、知識が素通りして結局得るものがなかったりします。 さらにさしあたりやらなければならない仕事があり、その仕事に直結する技術を身に付けなければなりません。しかも、その技術はどんどん更新されていきます この悩みを解決してもらうために書いたのが本書になります。 ソフトウェア業界で高名なよいコードを

というような記事に共感しつつ自分も苦手である。開発としてどう会議をサバイブしたら良いのか... 評判の良い以下をさらったので要点。 内容 表紙と絵柄は好みが分かれるかもしれない、が、ストーリー仕立てで以下。 初めてのダメ会議 確認するファシリテーションを始める 書くファシリテーションを始める 隠れないファシリテーションを始める Prepするファシリテーションを始める 確認するファシリテーションを始める 課題 決まったことが明確になっていない 結局何も決まってない 何か決まったけど、具体的に何をすればいいのかよく分からない ファシリテーションの入門 ファシリテート 用意にする・促進する ファシリテーション あるゴールを達成するための活動を、促進する、容易にするための技術 会議ファシリテーション 何かを決めることを促進する、容易にする技術 ファシリテーションのテクニック 決まったことの確認 や

ライト、ついてますか―問題発見の人間学 | ドナルド・C・ゴース, G.M.ワインバーグ, 木村 泉 |本 | 通販 | Amazon を読んだので、響いた要点と学びのメモ。 最初に感想 全体としてポエミーな書物。なので読書感想文が賛否両論になるのは理解はできる。 自分にとっては、ある程度開発経験を経てから効いてくるフレーズが多いと感じた。フレーズそのものは響くものも多いので、使っていきたいようなものもある。笑 気に入ったのは 「ユーモアのセンスのない人のために問題を解こうとするな。」 要点 「それは誰にとって問題なのか？」という問いについて考えてみよう。 この問いは １．一方では誰が依頼主か、つまり誰をしあわせにしなければならないかをはっきりさせようとしているもの。 ２．もう一方では適切な解答を見つけ出すのに役立つかも知れないヒントを得ようとしている。 問題は何なのか？とたずねる以前にあ