100人以上の資料を読んで見つけた伝わりやすい成果報告書の書き方 - CARTA TECH BLOG
TL;DR 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように はじめに 技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。 仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。 しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとって
IT系を腐す文化本当にやめてほしい
学生のころ、IT土方がどうとかで業界がだいぶまずい場所だと文系の大学生の自分は思い、とても興味のある分野だったけどやめた。 それから5年がたち、今の職業を続けていてもと感じて、ずっと抱えていた興味に素直になろうと思い半年独学し、SES系の会社に転職した。 DBすらよくわかっていない状態だったけど、めちゃくちゃ楽しくて毎日充実しているし、3年たったけどまだ楽しい。 会社で学んだことを活かして個人開発したらまたそれで収入が増えてスキルが上がり、それを会社で活かせば褒めてもらえてより難しい課題に挑め、また更にスキルアップしてより難しい個人開発に挑める。 だからこそ新卒の時入社で来て居たらなぁと思うし、最近では自分と同じようにもっと早く業界に入っていればという中途の人にも出会った。 「他人の言葉に流されるなんてその程度」 そういう意見もあるかもしれないけど、ネット上での世論が世の中に影響を与えるよ
はじめに こんにちは、WatanabeJin(@Sicut_study)です。 今回は私が初学者のときに最も苦労したDockerの技術を身につけるためのロードマップを紹介していきます。 Dockerが難しいのはなんといっても概念的なところだと思っています。新人時代の私は入社していきなり「Dockerで環境構築して」とだけ先輩に言われて何もわからない状態から自力でなんとか使えるところまで1ヶ月かけて学びました。(プログラミング経験なしでいきなりDockerは辛かった) その後、同じくプログラミング経験なしの方にDockerを指導した際に、この流れでやっていけば技術として身につくなと思ったのでまとめていきます。 概念が難しいDockerの学び方 私自身がものすごく1年目の時につまづいたDockerの勉強の仕方についてどのように身につけていったかを紹介します。… pic.twitter.com/
マネージャーに全てを決められたくない vs マネージャーには答えを持っていてほしい問題について - yo-log
Engineering Manager Advent Calendar 2023 7日目の記事です。 結論ファーストで書きます マネージャーは答えを持っていません。 大事なことなのでもう一度言います。 持っていません。 この問題ってそもそもなに？ 細かくみてみましょう。 マネージャーに全てを決められたくない マネージャーがHowまで決めてくるケースや、現場チームが決めたHowに対して口出ししてくるようなケースにおいて発生する事象です。 ものによってはWhyやWhatまで現場で考えたいんだ、というケースもあるかもしれません。 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023 - Speaker Deck こちらのスライドにあるような「私考える人」的な動きになっているマネー
IT業界でストレスなく働くには - Qiita
はじめに ITエンジニアのみなさんこんにちは。 今日はIT業界でストレスなく働くということについて考えます。 GPT先生にお題を頂いてそれぞれコメントしていきます。 状況への適応の困難さ IT業界で最も多く発生しているのはこの要因かと思います。 ITエンジニアはSESなどで時間いくらで切り売りしている時給労働者ですが、簡単にはできない技術を提供することで高い単価を頂く仕事になっています。 学生さんから社会人になった人には分かりにくいですが、一定の期間内に一定の成果を出すといった点がコンビニのバイトとは大きく異なります。 現実の状況や要求が個人の能力や資源を超えている場合、適応することが難しくなります。このような状況では、ストレスが生じやすくなります。 誰にでも簡単にはできない技術 はマニュアル化されておらず、自分で状況を判断して適切な結果を出していく仕事となりますが、それができないとすると
限界集落化するIT業界？ - Qiita
はじめに 日本は2021年時点で高齢化率(65歳以上の高齢者の比率)が28.9%の超高齢化社会のようです。 そして、わたし達の勤める会社も高齢化が緩やかに進んで いると思います。意外と認識するのが難しいのですが、すべての人は生きているだけで年を取りますので、会社の構成員の平均年齢は毎年自動で上がります。 会社の高齢化は、IT業界の人口分布を調べると確認できそうです。 出典 : - IT 人材需給に関する調査 － 調査報告書：みずほ情報総研株式会社 レポートは出てきましたが、分かるような分からないような感じですね。 仕事の役割が変わりそうな年代で再集計してグラフ化してみましょう。 みなさんが仕事をしている周りの人達の年齢層はどのようなものでしょうか？ このグラフに当てはまっているでしょうか？ もしもそうであるとしたら、限界集落化が進行している可能性があります。 限界集落化 限界集落とは、人口
本稿は Yorick Peterse 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 yorickpeterse.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Yorick Peterse 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 GitLab 社で働くのはどのようなものだったか 私は2015年10月に GitLab 社に入社し、6年あまり働いて2021年12月に退社しました。 前に GitLab 社を辞めて Inko に取り組んでいることは書きましたが、2015年から2021年までの間、GitLab 社で働いていたことがどのようなものであったのかについては触れませんでした。理由は2つあります。 燃え尽き症候群に苦しんでいて、(当時は) 自分の人生の最後の6
はじめに この度、転職とスキル向上を目的に個人サービス(Football League)をリリースしました。 ITに関する学習は約1年ほど、その内の半年でサービスの開発をしました！ まだまだ修正箇所はあるものの、ひとまず形にはなったのでサービスの使用技術や開発過程を共有したいと思います。 私自身、独学で学習してきたのでそういった方々にとって少しでも参考になれば幸いです。 ご報告 現在権利関係について、本サイトで利用している外部APIの提供者様にお問い合わせしているため、メンテナンス状態とさせて頂いております。 ・メンテナンス時間 2024/01/18 15:45〜未定 自己紹介 商業高校卒(サッカー部⚽️) 25歳 青森住み🍏 職業はトマト農家です🍅 どのようなサービスか 本サービスは、欧州5大リーグのサッカーの試合結果やチーム情報などを閲覧することができるWebサイトです。 ただ情報
はじめに いつも聞いているポッドキャスト番組で、エンジニア転職について生々しくリアルな話が聞けたので、紹介します。今の自分がやっている仕事が市場価値を上げられているのか？ と日々の業務を振り返るきっかけになりました。詳しく知りたい方は是非、聞いてみて下さい。 転職の前提 かいちさん（転職した人）の紹介 情報系の大学院卒 中堅のバックエンド・エンジニア(30代) 社会人7年目 主に使っている言語: python, PHP アジャイル開発ができることを転職の軸に据えた 転職して感じたこと ① 30代は中堅の仕事を求められる → リーダー的立場が求められる ② 若い時の業務経験が転職の際に活きてくる → 20代はとにかく挑戦する回数を増やそう ③ 転職はどのタイミングでやってくるかわからない → 常に職務経歴書を更新し続けよう 結論 重要なポイント ・チームで開発した経験があるか？ ・AWSなど
先日、個人開発していたzenncastというWebサービスをリリースしました。 Zennでトレンドになっている記事を、毎日AIが10分のラジオにして届けてくれるというサービスです。 ありがたいことに公開後はたくさんの方に試してもらえ、技術的な質問も多数いただきました。 このZennではzenncastの技術構成や仕組みを紹介します（プロンプトつき）。 作ったもの まずはエピソードを一つ選んで1分くらい聴いてみてください！ AIラジオの雰囲気が掴めると思います。 主な機能・特徴 毎朝10分のラジオを生成 Zennでトレンドになっている記事を要約して紹介 お便りを投稿すると、翌日のエピソードでAIパーソナリティが拾ってコメントしてくれる BGMをつけて爽やかな聴き心地 これらのステップは人の手を介さずすべて自動化されています。 Spotifyなどの各種プラットフォームへの配信はSpotify
エンジニアの奇行 嚢中の錐という言葉がある。有能な人物は自ずと傑出していくという意味だが、有能さとは例えば学歴の高さとは一致しない。 たとえMIT卒であろうとも大成するとは限らないし、ましてや入試の点数などで見れる人間の側面は限定的である。 企業などで採用する側からしてみたら当然ながら採用後の活躍を期待して雇用するのであり、入社をゴールとしてそれ以降働かなくなる人は望ましくないし、学歴や入試の点数によってそういう人かどうか判定する事はできない。 活躍という観点で言うと長いキャリアにおいてより重要となるのはキャリア開始時での能力の高さよりも、険しく長い道のりを自己メンテナンスしながら歩み続けられる根気の強さが重要とされている。その根気の源泉は執着だったり崇拝だったり妄信だったりトラウマだったり原体験だったり人によって様々だが、ここではひっくるめて「やる気」と簡略化して呼ぶことにする。 さて「
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
とあるプロジェクトでナノ秒からミリ秒への変換で四捨五入してきた人がいて、時刻を扱うときは保存精度未満は切り捨てるべきというのが常識になっていないなーと思ったので。 2023-10-01 を、何年か表示する時に、2024年に丸める人はいないだろう。 13:45 が何時か表示する時も、13時と表示するだろう。（口頭で何時？と聞かれたら14時と答えるかもしれないけれど） つまり、ある精度で表した時刻は、実際には次のような半開区間を示しているのである。 2023-01-01 00:00:00 <= 2023年 < 2024-01-01 00:00:00 13:45:00.000 <= 13:45 < 13:46:00.000 そして、そう決めたからには一貫して同じように、指定精度未満は切り捨てというルールを維持しなければならない。秒以下は四捨五入で、とかやってはいけないのだ。 一貫しないと何が問題
今年の頭にうちの会社にやってきたエンジニアの話。 彼は実装がめちゃくちゃ速く、コードもきれい。テストもちゃんと書く。 とてもできるエンジニアなのだが、一つだけ困っていることがある。 実装完了した機能をすぐに本番環境にデプロイできないと、とても不機嫌になるのだ。 うちの会社が開発しているのはtoBのシステムで、実装内容によっては営業やカスタマーサポートからお客さんにアナウンスがされてからでないとデプロイができないものがある。 急にUIが変わったり新機能が追加されるとお客さんが混乱するしカスタマーサポートに問い合わせが殺到するので、デプロイ前に調整が発生するのは致し方ないことなのだが、こうした背景を説明しても彼は納得してくれない。 「とにかく早くデプロイをさせろ」の一点張りで、彼が勝手にPRをリリースブランチにマージして、機能が出てしまったこともある。 それによってカスタマーサポートへの問い合
新人が1on1に来ない - Qiita
新人が1on1に来ない。その原因を考察する。 ここで出てくる新人の情報は以下である。 年齢: 30代前半 エンジニア歴: 5年 入社して半年 1on1を行うに至った経緯: 1年前、私と同じ時期に入社した同期Aが退職した。 詳細はよく分からないが、どうやらチームの先輩の1人と相性が悪いとの事だった。 尚、Aが退職したのは上記の理由だが、退職したいからこれを名目上の理由にしているのであって、原因は他にある可能性はあるが、この際それは考慮しない。 会社の人員構成: ほとんどがエンジニア歴10 ~ 20年のベテラン。平均年齢は30代後半。 Aは30代前半。 周囲の反応: Aが退職を告げた時、周囲はうろたえた。事前に相談は無かったし、特に問題はないように思われていた。 何より30過ぎた社会人は、問題があれば自分から話して来るという思い込みが、既存社員にあったもしれない。 年齢は関係あるか: ないと考
エンジニアが株式会社作ったログ
この記事を読んだ方から有益な情報をたくさんいただいたので追記している。 特定創業支援等事業の認定 法人設立ワンストップサービス gBizID 自分でやっていないものについては各項目で明記している。 なぜ作ったのか？ 自分の興味があった教育分野において、実際にやってみて自ら経験を積み、社会に役立つようなことがやりたいと思ったため。 あと、長くサラリーマンをやって、矛盾している組織が許せない性分だとわかったので、じゃあ自分で組織を作ってみようという単純な発想による。できるだけ矛盾していない組織を作ろうと目指しているが、やらずに文句だけ言うのはフェアでない、という意味合いもある。 フローチャート やることが多く、時系列がわかりづらかったのでフローチャートを書いてみた。 週一で動いた場合、 3 ヶ月ほどかかる。また、灰色の枠は実施していない。 経費について 登記前にかかった費用はすべて創立費、登記
12のソフトウェア・アーキテクチャの落とし穴とその避け方
これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す
IT 系に行くことはやめたほうがいいと思う
最近こんな感じの記事をいくつか見かけた https://xtech.nikkei.com/atcl/nxt/column/18/00001/08910/ IT 系の人が足りないとか言う話 また、子供になりたい職業のランキング上位に IT 系が上がったみたいな話もあった 個人的にはやめたほうがいいと思う IT 系エンジニアになりたいって思う人は基本自分が使ってるサービスとかに関わりたいと思ってるだろうけど そういうところ行けるのって IT 系でもごく一部 自分の好きなサービスの会社とまで絞り込むと採用される人数は限られてるし、人気があるから倍率も高い 難易度的には東大に入るよりも難しいんじゃない？と思うほど なので実際は IT 系を目指してもほとんどは底辺でブラックと言われる SIer とか SES などになる IT 系エンジニアって一応は専門職だし、必要な知識が多いし、なりたいと思ってすぐ
※かなり燃えてきたようなので、当初から内容修正してます。 先日、ビッグサイトで開催されている「Japan IT Week」に参加してきました。 この展示会、IT関連では一番大きな展示会、という事で、各メーカーさんともにかなり力を入れて参加している展示会だと思います。 ただ、その「力を入れている」が行き過ぎちゃって、かえって治安が悪くなっているなぁ〜なんて思ったので、今日はそのことについて書いてみたいと思います。 主催のRX Japanさん：過度な呼び込みをしている一部企業のせいで、展示会全体のイメージが下がってますよ。早めの対策を。 コンパニオンの皆さん：私も含め、皆様の絶え間ぬ努力を理解できない人間が多数いました。プロフェッショナルリズムを理解できなくてスイマセン。 参加者の皆さん：悪いのは過度な呼び込みをしている企業や個人です。現場の人に八つ当たりはしないでくださいね。 過度な呼び込み
30代からプログラミングを本格的に始めたエンジニアが生産性について思うこと - Sansan Tech Blog
最近キーボードで文字を打つのが面倒になってきている技術本部 Eight Engineering Unitの斉藤です。 キーボードは既に100年以上使われ続けているみたいですね。そろそろ新しい入力の方法ができてもよさそうです。 例えば、頭で考えていることが文字に起こせたら、AIに任せるよりももっと便利だと思います。 前置きはさておき、Sansanではちょっと前にエンジニアの生産性と生産量の最大 化が話題になっていました。このブログをご覧の方ならご存知の方も多いのではないでしょうか。 私はこれまで何度か転職をしていますが、どの職場でも例外なくこの話題が挙がりました。 チームとして、あるいは事業としてどう最大化するかが基本前提となるのですが、私が今回話したいのは個人としての生産性の最大化についてです。 私は個人の生産性を上げることもチームの生産性を上げるのと同じくらい非常に大事なことだと考えてい
自分の心理的安全性を、自分で高める - Link and Motivation Developers' Blog
エンジニアの梅原です。 少し前から「心理的安全性」というキーワードについて、疑問に思うところがあって色々と考えていて、 なんとなく考えがまとまったので、自戒も込めて文章として書き起こしてみました。 もともと社内向けに書いたものでしたが、思いのほか反響があったためこちらでも書いてみようと思います。 めちゃくちゃなこと言ってんな、って思う人もいるかもしれませんが、際に振ったときの思考実験だと思って読んでもらえると。 心理的安全性とは何か？ 一般的に「心理的安全性」とは、以下の定義で語られます。 "A shared belief held by members of a team that the team is safe for interpersonal risk taking." （このチーム内では、対人関係上のリスクをとったとしても安心できるという共通の思い） Edmondson (19
この記事を公開するかどうかかなり迷った。こんなことを全世界に公開しても自分の価値を下げて損するだけだけだし、世渡りが上手い人は不調な時に不調ですなんて公言しない。不調は隠してどうにかして、あとから「あの頃は実は辛かった」と言った方がずっと賢い。 でももう何をどうすればいいのかさっぱり分からないしとにかく吐き出したいんだ。 人生がかなり厳しい状況になっている。 いや、人によってはそのくらいなんだと思う程度かもしれないが、自分にとってはどうすればいいのか分からない状態なので、とりあえず聞いてほしい。 自己紹介 32歳フリーランスAndroidエンジニア 引きずるコロナ禍の影響 コロナ禍でリモートワークになってから仕事も生活も上手くいっていないという話は何度かこのブログにも書いてきました。 具体的にはリモートワークだとどうしても気が引き締まらないことやコミュニケーションの難しさなどからパフォーマ
ソフトウェアエンジニアとして働き始めて 20 年以上になります。 元々ソフトウェアでいろいろ作りたくて就いた職業なので、結構な数のプロダクトを開発してきました。 私がメインで開発したもので OSS として出ているものでは、 yrmcds: memcached クローンで、レプリケーション機能などを持つ usocksd: SOCKS4/5 サーバー & ライブラリ transocks: アプリのネットワーク通信を透過的に SOCKS サーバーにプロキシする透過プロキシ coil v2: Kubernetes の CNI ネットワークドライバ moco: MySQL を自動運用する Kubernetes オペレーター accurate: Kubernetes 上で namespace ベースのソフトマルチテナンシーを実現するためのソフトウェア などがあります。これらのソフトウェアの多くは、現役
D-Plus Tokyo #1 https://d-plus.connpass.com/event/315744/
Adobe Firefly で生成PdMむけの記事でこのような記事がある。 「プロダクトマネージャーこそ、戦略的に読書せよ！」── 最短で成果を出すための読書地図 (1/6)|ProductZine（プロダクトジン） これのエンジニア向けの記事がないかなと思っていたがなさそうだったので作ろうと思った。しかし客観的な視点でこれがおすすめというのは難しいので自分が参考になったと思った本を家の本棚を見ながらまずは100冊リストアップしてみた。 紹介する本は10年読まれていたり、近年発売のものであれば10年後にも読まれているだろうというものを選ぶようにしている。個別のプログラミング言語やフレームワークなどの本はバージョンアップに追随ができないことが多いので選んでいない。 入門本プリンシプル オブ プログラミングリーダブルコード定番中の定番。おそらくこの2冊はあちらこちらで紹介されている。とりあえず
YAMLは「便利なJSON」として使われることが多い一方、その複雑性から落とし穴も多く、しばしば批判の対象になります。 なぜYAMLはそこまで複雑なのでしょうか? その背景のひとつは、本来のYAMLがJSONとは大きく異なる目的意識で作られているからです。 本稿ではYAML specに従う形でYAMLのコンセプトを解説することを目指します。残念ながら、ここに書かれているYAMLの思想は実際には実用されているとは言い難いですし、これらの背景を理解しても「YAMLは複雑だ」という事実がひっくり返ることはないでしょう。それでも、YAMLの複雑さの源泉を体系的に理解し、YAMLとほどほどの距離感で付き合う助けにはなるのではないかと思います。 この記事ではこういう話をしますYAMLはJSONとは独立に、異なる目的で生まれた野心的な仕様であるアンカーやタグなどの強力な構文は、これらの目的を満たすために
X（元Twitter）を長年支えてきたエンジニアに、買収前後の中の様子はどうだったのか聞きました（CloseBox） | テクノエッジ TechnoEdge
イーロン・マスクによる買収以来、揺れ動いてきたTwitter（現在はXに改名）ですが、その内部がどのようになっていたのかはなかなか伺い知ることができません。筆者が個人的に参加しているポッドキャストbackspace.fmでは、TwitterのiOSアプリ開発に2010年から携わってきたソフトウェアエンジニアの丹羽善将（@niw）さんにその渦中の話を聞くことができました。 丹羽さんは、超有名テックブログのDaring Fireballで、世界で最も優れたiOS開発者の一人としてTwitter退社を惜しまれた人物です。 ▲Daring Fireballより 丹羽さんをゲストに迎えたエピソードは下のリンクからどうぞ。
引く手数多そうなエンジニアがムカつく
他に行く当てなんていくらでもありますよとでも言わんばかりの態度がムカつく。 はいはい正論ですよ、転職副業あたりまえ終身雇用絵空事。 でもさ、会社に来てるんなら会社に参加しなよ。 何のアイデアも「難しいですね」「技術的には可能ですが」「そもそも要ります？」 なんかさ、気概が感じられんのよ。 内心なんてわかりっこないけどさ。 会社の事業とか理念とか関係ない、どうせ転職するまでのつなぎ、私は何も困りません、みたいにさ、見えちゃうのよ。 泥臭くてもやらなきゃいけないときもあるじゃん。 実現したいときもあるじゃん。 何でそんな事なかれ主義なんだろう。 そんなに優秀で、ありとあらゆる技術を手足のように使いこなして、なんで志がないんだろう。 お金とか見返りとかキャリアとかポートフォリオとか。 自分、自分、自分、メリット、メリット、メリット。 ちょっともう、うんざりしちゃうよ。 ハッキリ言って。 これはN
はじめに エンジニアとして成長し、「つよつよエンジニア」と呼ばれて周囲から評価されるエンジニアになりたいという若手エンジニアや学生の方は多くいると思います。 私は今までで数百人以上のエンジニアと一緒に仕事をしており、その中にはベンチャーや上場企業でCTO/VPoT/テックリードといった役職についている「つよつよエンジニア」も多くいます。 (かくいう私も組織マネジメント力よりは技術力を評価されてCTOをしていますし、今もコードを書いています)。 「つよつよエンジニアになるためにはどのようなアクションをとればいいか」という視点で述べられていることは多くても「成果物にどのような特徴があるのか」という観点で述べられていることはあまり無い印象です。 成果物の特徴さえわかれば、まだ自身がそのレベルまで到達できていなくても、成果物のレベルを引き上げることができます。 （世阿弥の「風姿花伝」でも「真似る」
はじめに この連載では共通化とモジュール分割について扱います。この話題においてQiitaで有名な記事のひとつが@MinoDrivenさんの単一責任原則で無責任な多目的クラスを爆殺するでしょう。この記事を未読の方はまずこちらを読むことをお勧めします。本連載では、この記事に書かれているような基礎的な事項については既知であることを前提に、どのようにすれば単一責任原則にそったモジュールの分割を行うことが出来るのかをなるべく 「場合による」という言葉に逃げずに なるべく 網羅的・理論的に 解説します。 いいね、ストックをよろしくお願いします。 対象読者 設計に興味のあるエンジニア 基礎的な設計原則について学んだものの、実際の場面でどのように応用すればいいのかが掴めないエンジニア ミクロな設計についての知識を増やしたい人 ※この記事では、特定のメソッドをどのように作成するべきか、このクラスは複数の処理
重度のADHDでなくても、注意力が散漫、一つのことに集中できない、 興味の対象がすぐ目移りしてしまうタイプの人間は少なくないと思う。 特にIT系のエンジニアにはその傾向が多い気がする。 自分もその一人だ。 ふと隣のハイパフォーマーな同僚をみると、やるべき1つの仕事だけに数時間ずっと没頭して、ものすごい成果をあげている。 それを見て自分もタスクにとりかかるもやる気が起きず、つい趣味のコードを書いたり文献調査をして1時間を過ごしてしまう。 隣の彼の姿と自分を重ねると、自分はなんて生産性が低いんだと辟易としてしまう。 しかし、我々はそのフィールドで勝負をしてはいけない。 1つのことをずっとやり続ける集中力なんて持ち合わせていないし、多分一生手に入れることはない。 我々の武器は、様々なことに興味を持つことだ。 そして興味をもったことに対しては、「仕事として」ではなく「遊びとして」愛をもって取り組め
サーバーレスの次はなんなんだ
はじめに この記事は、同人誌サークル「めもおきば」から不定期刊行している技術解説本「めもおきばTecReport」に書いたものを公開用に再編集したものです。 ⇒ めもおきばTecReport 2023.12 この記事のほかにも「私もSecHack365に参加したい！」や、「2023年振り返りと2024年技術予想」としてこんなキーワードを取り上げているので、気になったらぽちっとしてください！ メガクラウドと特化型クラウド／ハイパーバイザーのSoC化／ライセンスとクラウドベンダー／イベント駆動型API／LLM時代のAIペアプロ力／生活必需品としてのGPU・NPU／Passkey／ウェブアクセシビリティ／リアルイベントの再開 サーバーレスの次はなんなんだ サーバーレスと呼ばれる技術ムーブメントが盛り上がり始めて8年近くが経ちました。各クラウドベンダーのFaaS（Function-as-a-Ser
ITスキルロードマップ roadmap.sh がすごい。AI and Data Scientist について対応する本をまとめた - Qiita
ITスキルロードマップ roadmap.sh がすごい。AI and Data Scientist について対応する本をまとめた機械学習データ分析キャリアデータサイエンスデータサイエンティスト Developer Roadmapsというサイトがすごいです。ITエンジニアの分野別にスキルアップのロードマップが示されています。 言語、基盤、アプリ、かなり網羅されています。 その中のAI and Data Scientist Roadmapについての推薦図書まとめです。 雑感 これだけ学んでいれば「こいつ知ってるな」感がありますね。ただ気になる点としては ビジネス、ドメイン知識や分析目的定義などのスキルについて言及がないのは残念。 いきなり数学から入るコースになってますが、一旦は飛ばしてコード写経してから戻ってきても良いと思います。ここで挫折すると勿体無いので。 計量経済学重視の観点はいいですね
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
技術選定の審美眼（2023年版） / Understanding the Spiral of Technologies 2023 edition
Tech BASE Okinawa 2023 2023/09/23(土) https://codebase.connpass.com/event/285901/ https://techbaseokinawa.com/
こんにちは！経営企画の仕事をしているudonです。1年半前の見習いQA以来、2度目の文章です。今回は10X社内の会議のルールを整理し、そして全社員の未来のカレンダー予定を一旦全部消す、通称「ビッグバン」の第一回を実施したのでその背景や内容について書きます。 (イメージ) 10Xでは社内におけるコミュニケーションを大きく「同期」「非同期」に分けています。同期は会議や突発的な電話など同じ場にいることが前提であるコミュニケーションを指し、Slackなど非同期は必ずしも同じ時間での往復を前提としない文章やドキュメントによるコミュニケーションを指します。入った当初は「ドウキ・・？ヒドウキ？？」とドキドキしてた私ですが、2年も経つと慣れてしまいました。慣れって怖いですね。 話が長いという皆様の期待を裏切ることなく、タイトルにもなっているビッグバン(会議の全削除)の話にいくまで5,000文字嵩んでしまっ
私個人の障害対応の経験と 一昨日参加したIncident Response Meetup vol.1での学びから 障害対応において大切だと感じていることをまとめる。 障害とは リリース後のシステムにおいてシステムの不具合やユーザーの操作ミスによってユーザー業務に影響が出ているもしくは出る恐れがあるもの。 障害対応の目的 システムを直すことではなく、ユーザー影響の回避・低減・早期回復をすること。 障害対応に対する心構え システムの信頼性の要である 障害への対応の仕方でユーザー影響が大きく変わる いつ発生するかわからないため特定の人が常に障害対応をするということは不可能である 素早く適切に行動するための備えが重要である 役割分担 障害対応では復旧対応、原因調査、ユーザーへの説明、社内調整などたくさんのことをやる必要がある。 またそれぞれの作業の難易度が高いことも多い。 一人の人間にできることは
科学的根拠に基づき、エンジニアこそ筋トレをやるべき理由を解説
はじめに こんにちは、生産プラットフォーム開発本部のstakmeです。 本稿では、スプレッドシートの作業に「手続き的なアプローチ」と「宣言的なアプローチ」という観点を持ち込み、ふたつを対比しながら紹介します。Google Sheetsの多彩な関数を駆使して、日常的な問題に効率的に対応するための具体的なテクニックやヒントを提供します。また注意点やリスクを指摘し、スプレッドシートをより強力に活用するための知識を提供します。 目次 はじめに 目次 背景・課題 本稿の目的 規則的な処理を繰り返すケース 手続き的に構築された例 宣言的に記述された例 SEQUENCE ARRAYFORMULA 関数の組み合わせ なぜ「宣言的」なのか データが徐々に増えるケース 手続き的に構築された例 宣言的に記述された例 別の見せ方でデータを表示したいケース 手続き的に構築された例 宣言的に記述された例 やりすぎのケ
NEW! 2024.04.12 スキル 未踏落合陽一登大遊プログラマー 登大遊、落合陽一など数々のスーパークリエータを輩出してきた、独立行政法人情報処理推進機構（IPA）の「未踏IT人材発掘・育成事業」（以下、未踏IT）。その立ち上げから現在までを知るのが、統括プロジェクトマネージャーの竹内郁雄さんだ。 2017年には、ビジネスや社会課題解決につながる人材を発掘する「未踏アドバンスト事業」にも統括プロジェクトマネージャーとして参画。国際的なデファクトスタンダードとなるソフトウェアを日本から生み出すべく、人材育成に心血を注いでいる。 前身の未踏ソフトウェア創造事業から数えて24年。のべ2000人を超える修了生を見てきた竹内さんだから言える、優れたエンジニアに共通して求められる素養を聞いた。 未踏事業統括プロジェクトマネージャー（PM） 一般社団法人未踏 代表理事 竹内郁雄さん 1946年、富
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【永久保存版】0からDockerを勉強するならこのロードマップに従え！ - Qiita
(翻訳) GitLab 社で働くのはどのようなものだったか - forest book
完全未経験が半年で個人サービスをリリースした話 - Qiita
30歳エンジニア転職で役に立たなかった経験と役に立った経験 - Qiita
AIラジオ『zenncast』の技術構成（プロンプトつき）
キャリアハックの奇行 - Software Transactional Memo
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
タイムスタンプの精度を落とすときは切り捨てろ - methaneのブログ
プログラミングにしか興味のないエンジニアに困っている
展示会で過剰な呼び込みをやめてもらえませんか？っていうお話。｜原田篤史_独立系水処理エンジニア
追い詰められている - みんからきりまで
メンテのいらないソフトウェア - 誰かの役に立てばいいブログ
若手のうちに知りたかった生産性の高め方
ソフトウェアエンジニアにおすすめしたい本を100冊選んでみた | gennei's blog
「YAMLの本来の使い方」を仕様から読み取ってみる | Wantedly Engineer Blog
つよつよエンジニアの成果物にある5つの特徴 - Qiita
どうしてあなたの共通化は間違っているのか：目次 - Qiita
注意力散漫なADHDエンジニアへ「散漫さを武器にしよう」
実践要件定義入門 - 勘と経験と読経
会議全部ふっとばして社員の集中力を10xした話(ビッグバン) - 10X Product Blog
障害対応で大切だと感じていることのまとめ - Qiita
ITエンジニアこそ筋トレをやるべき理由 徹底解説
宣言的でメンテナンスしやすいGoogle Sheetsという考え方 - ZOZO TECH BLOG
登大遊、落合陽一を生んだ、未踏の父・竹内郁雄に聞く「優れたエンジニア」に必要なこと - エンジニアtype | 転職type