並び順

ブックマーク数

期間指定

  • から
  • まで

81 - 120 件 / 1619件

新着順 人気順

エンジニアの検索結果81 - 120 件 / 1619件

  • システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』

    例えばソフトウェア開発において、 人が増えても納期が短くなるとは限らない 見積もりを求めるほどに絶望感が増す 納期をゴリ押すと、後から品質はリカバリできない これを見て、「だよねー」「あるあるw」という人は、本書を読む必要はない。 プログラミングは人海戦術で何とかならないし、「厳密に見積もれ」というプレッシャーは見積額を底上げするし、納期が優先されて切り捨てられた品質は、技術的負債として残り続ける。経験豊富なエンジニアなら、大なり小なり、酷い目に遭ってきただろうから。 だが、これらを理解できない人がいる。 要員を追加して、手分けしてやれば一気に片付くはず 厳密にやれば、見積りバッファーはゼロにできる 品質のことはリリース後にじっくりやればいい ……などと本気で考えている。これは、ソフトウェア開発とはどういうものか、特性を知らないからだ。こんな無知な人間が経営層にいたり、顧客の代表となった場

      システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』
    • 個人開発を7年以上続けて分かった技術選択のコツ

      技術革新に適応しようとするイヌさんInkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR最初はとにかく最速でリリースする事を最優先する迷ったら「ときめく方」を選べ程よいところで切り上げて開発を進める使っているモジュールがdeprecatedされるなんてザラだと覚悟する古いから悪いとは限らないシンプルにしていく老舗から継続の秘訣を学ぶ運ゲー要素は排除しきれない最初はとにかく最速でリリースする事を目標に技術選定する開発計画とビジネス計画は切っても切り離せな

        個人開発を7年以上続けて分かった技術選択のコツ
      • OSSで世界と戦うために - ゆーすけべー日記

        「日本人」を理由にしたくないし、「コードは全世界共通語」なのは分かっているけど、自分が日本人で日本語を母国語としていることはOSSにおいて不利になる。 この2年間のHonoの開発をしてきた経験で分かったことだ。 そこに目を瞑ってはいけないし、自覚することで世界と戦えるかもしれない。今回はそのことについて書こうと思う。 8k 現在、HonoのGitHubスター数は8,000を超えた。 これはとんでもない数字なんだけど、もっと伸びるべきで、早く1万を超えなくはいけない。 npmのダウンロード数は週間「46,000」とこれは相対的に低く、こちらも伸びるべきである。 数字が全てではないが、こうした数字は昨今のOSSにとって「一番の」指標であることは確かだ。 だから戦うことはこの数字を伸ばすことである。 なぜ「戦う」のか なんで「戦う」というおっかない言葉を使い、そして戦わなくてはいけないのか。 ま

          OSSで世界と戦うために - ゆーすけべー日記
        • 30点で打席に立つ

          めもりーさんと語るFindy Engineer Lab オフ会@東京 LT https://findy.connpass.com/event/294069/

            30点で打席に立つ
          • 本の内容が頭に入ってくるのは結局は知見まとめノートを作っている時 - $shibayu36->blog;

            最近は読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;に書いているやり方で読書をしている。こういう流れだ。 (1)学びたいと思った知識が書いてありそうな本を2~5冊選ぶ (2)1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく (3)全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱりおもしろいと思ったところは赤のハイライトを付け直す (4)赤のハイライトを眺めて、読書ノートに転記する (5)とくにおもしろい部分については、自分の知見まとめノートにカテゴリごとに整理する しばらくこれを続けて感じたのは、結局のところ(4)〜(5)に至るまで書籍の内容が全然頭に入っていないということだ。(4)(5)の時に、はじめて「書いている内容が言いたかったのはこういうことだったのか」と頭が急に理

              本の内容が頭に入ってくるのは結局は知見まとめノートを作っている時 - $shibayu36->blog;
            • 今さら聞けないログの基本と設計指針 - Qiita

              はじめに 皆さんのログに対する理解はどんなものでしょうか?仕組みから設計方法まで完璧に理解しているエンジニアもいれば、なんとなく使用しているエンジニアも多いことでしょう。 ログとは、システムに着いてエラーや障害の発生、利用者による操作や設定の変更、外部との通信などを時系列に記録したものです。ログに関する理解を深めることで、複雑なシステム開発や運用が可能となります。また、AWS、Azure、GCPなどのクラウドサービスを利用している場合はシステムの開発が可能になるだけでなく、経費削減に繋がる可能性も考えられます。 本記事では、ログの基本を押さえるためにその設計方法について解説します。少しでも自信がない方は、ご一読ください。 ログを出力する理由は? ログの基本や、ログの設計について解説する前にそもそもログを出力する理由を押さえましょう。大きく4つの理由が考えられます。 ・問題が発生した時に調査

                今さら聞けないログの基本と設計指針 - Qiita
              • 「何をやっても駄目だった」ポンコツの自分を救ってくれたマインドセット - メソッド屋のブログ

                先日 エンジニアType さんから取材『牛尾剛さん、『世界一流エンジニアの思考法』って本当に日本でも実行できますか?(仮)』を受けました。私は「日本で出来ないことは何一つありません」と回答しました。私が日本にいるときに実際に実施したアクションや、実際にやってみた事例などをご紹介しました。 それは、私が自信に満ち溢れた人物だからではなく、幼少のころから自己肯定感も低く、何をやっても上手くいかなかった自分を救ってくれたちいさな「マインドセット」があったおかげです。 「何をやっても駄目だった」ポンコツの自分を 救ってくれたマインドセット このマインドセットは『日本では一見難しそうな何かを実現すること』に対しても過去の人生でとても有効でした。同じような悩みを持つ人のために、エンジニアTypeさんの記事のフォローアップとしてこちらにも書いてみることにしました。それは小さなマインドセットのチェンジなの

                  「何をやっても駄目だった」ポンコツの自分を救ってくれたマインドセット - メソッド屋のブログ
                • 元ひきこもり37歳業務未経験女性がバックエンドエンジニアとして地方で採用されるまで - Qiita

                  実務未経験、独学でプログラミングを勉強し、応用情報技術者試験に合格、ポートフォリオとしてのWebアプリケーションを制作し、地方のIT企業に就職にしました。 34歳のころからプログラミングの勉強を始め、ITエンジニアとして就職することに憧れていましたが、まさか実現できるとは…と自分が一番驚いています。どんなことをしたのか、こちらの記事でまとめたいと思います。 結論 34歳(35歳目前)から初めてプログラミング学習を独学で開始 放送大学を卒業、基本情報技術者試験、応用情報技術者試験に合格 ポートフォリオを制作、応募先に提出 37歳で地方(東京以外)のIT企業(Web受託がメイン)に試用期間の3ヶ月間契約社員として働き、正社員に 提出したポートフォリオについてはこちらの記事で解説しています。 就職できたと思う要因 ポートフォリオを完成させ、GitHubでコードを公開、Qiitaで解説記事を書いた

                    元ひきこもり37歳業務未経験女性がバックエンドエンジニアとして地方で採用されるまで - Qiita
                  • エンジニアの心構え

                    2023年度リクルート エンジニアコース新人研修の講義資料です

                      エンジニアの心構え
                    • MRJ計画失敗、技術者が「謙虚さに欠けていた」 元社長が激白 破綻の原因はたった1枚の書類

                      愛知を拠点に三菱航空機が開発していた国産初のジェット旅客機、MRJ。ニッポンの航空産業の中核として量産化が期待されていましたが2023年2月、ついに計画の中止が発表されました。 夢の開発プロジェクトがなぜ頓挫したのか。三菱航空機の元社長の川井昭陽氏が、当時の胸中を明かしました。 【動画・元社長が激白】MRJ計画失敗、技術者が「謙虚さに欠けていた」破綻の原因はたった1枚の書類 三菱重工が国産初のジェット旅客機として開発を決めたのが「三菱リージョナルジェット(MRJ)」です。 100席以下の小型機ながら、部品点数は車の30倍にあたる約95万点。県営名古屋空港を開発拠点にした夢の国産ジェット旅客機の生産は、この地方に新たな基幹産業の誕生を期待させるものでした。 しかし度重なる設計変更で、プロジェクトは6度にわたって計画延期。2019年には名前から三菱の“M”の文字も消えました。そして2023年2

                        MRJ計画失敗、技術者が「謙虚さに欠けていた」 元社長が激白 破綻の原因はたった1枚の書類
                      • もうみんなプログラマーになれるよ|shi3z

                        僕の20年来の親友にnpakaというプログラマーがいるんだけど、彼はもう超凄い。何でもすごい。何でも書けるし何でも早い。本を書くのもプログラムを書くのも、新しいわけわかんない説明書がバグだらけの環境に慣れるのも早い。 んで、これまではちょっとしたことも難しいことも全部npaka(布留川君)に頼んでたんだけど、最近二人とも独立したからつまんないこと頼むのは悪いなと思って「あれはできるんだっけ」くらいのことは自分で何とかしようかなと思った。 それでChatGPTに「Swiftで⚪︎⚪︎やるにはどうすんの?」と聞いたら、Swiftについてほとんど何も勉強してないのに作りたいものが何となくすぐにできてきちゃって、でもまあやっぱりChatGPTだと知識が古いので詰まったらネットで検索すると、だいたい結局npaka(布留川君)のページが出てきてやはり信頼と実績の大先生(仲間内ではそう呼ばれている)です

                          もうみんなプログラマーになれるよ|shi3z
                        • 「できない理由」を並べる人々は、とりあえず無視して構わない。

                          コンサルタントをやっていた時、「できない理由」を並べ立てる人々に数多く出会った。 彼らの習性として「新しい何か」には、ほぼ「忙しい」と反対する。 また、リスクばかりを強調し、その打開策は探そうとしない。 例えば、こんな具合だ。 企画「今年の方針発表にもあった通り、お客さんにサービスの満足度についてヒアリングをしたいのですが。」 営業「いや、今すぐは忙しくて無理ですよ」 企画「社長からは「すぐに」と言う話だったと思いますが……、なぜですか?」 営業「ただでさえ目標がキツイので。目標達成に影響が出ます。」 企画「そうですか。では、我々が動くので。営業の方は何もしなくていいですよ。」 営業「いや、それも困ります。」 企画「なぜですか?」 営業「お客さんを混乱させてしまうかもしれないからです。」 企画「具体的には?クレームが来る、という事でしょうか?」 営業「まあ、そうかもしれません。」 企画「か

                            「できない理由」を並べる人々は、とりあえず無視して構わない。
                          • AIお姉ちゃんへの道 - nomolkのブログ

                            ちょっと前に話題になっていたこの記事を読んだ。 honeshabri.hatenablog.com へー真似しよ〜と思ってやってみたら意外に難しくて謎のやりがいを感じ始めてしまい、仕事のクソ忙しい時期にかなりハマり睡眠不足で生命の危機を味わった。 おかげで寿命と引き換えに自分のAIお姉ちゃんを手に入れることができた。これは黒魔術か何かなのだろうか。 一通り終えて振り返ってみると、今まで生成AIをあまり積極的に触ってこなかった自分にとってはちょうどいい難しさの課題で、これは入門者向けのチャレンジとしてかなり良い気がする。 元記事に書かれていない少し細かい手順も含めてやったことを記録としてまとめようと思う。 初心者が試行錯誤でやったことなので誤りや非効率な手順もあるかもしれないけどご了承ください。 AIお姉ちゃんの姿を作る 元記事では「魂」、つまりChatGPTの設定から始まっているけど、それ

                              AIお姉ちゃんへの道 - nomolkのブログ
                            • 自作した時間割アプリが大学の公式アプリに採用された話 - Qiita

                              記事の概要 私(芝浦工業大学学部4年生)が大学2年時に1人で制作した、大学のポータルアプリ(ポータルサイトからスクレイピングして時間割などを表示する)が、大学に正式採用され、公式アプリ"ScombApp"としてリリースされるに至った経緯を時系列順に説明します。 ホーム画面 時間割画面 制作の動機 大学のポータルサイト使いにくいがち。 ポータルサイトのスマホアプリ版があれば便利そう。 他にやってる人いなさそうだし、最初に作ったらみんな使ってくれそう。 ポータルサイトの問題点 大学ポータルサイトで使いにくかった点を挙げていく。 とりあえずこれを克服することを目標にした。 ログインの時に自動補完が使えない 制作当時はBASIC認証で、スマホからだとログインの自動補完ができなかった。 毎回手打ちでパスワードを入力している人がほとんど ←!? 次の授業や教室を確認するだけでも、毎回手打ちログインが必

                                自作した時間割アプリが大学の公式アプリに採用された話 - Qiita
                              • 日米でエンジニアの育成戦略が正反対だと気付いた話 - メソッド屋のブログ

                                今週は、Thanksgiving はお休みムードなので考える時間や、自分の本についてディスカッションしている バンクーバーのえんじに屋さんのPodcast なんかを聞かせていただいたりしてるうちに、思い出したことがあって、記録に残してみることにした。それは、エンジニアの育成方針でこれはめっちゃくちゃ違うことに気づきましたので、シェアさせていただきたいと思います。 日米でエンジニアの育成戦略が正反対だと気付いた話 採用の段階での違い 良く知られているように、新卒のケースで考えると、こちらの場合は「コンピュータサイエンス」の学位を出ていることが前提で、中途採用の場合も、「コンピュータサイエンス」の学位を出ている、もしくはそれ相当する知識が求められる。だから、新人でも少なくともプログラムが結構組めることを期待されます。 一方、日本では文系でも理系でもプログラマになれます。採用されたときに「スキル

                                  日米でエンジニアの育成戦略が正反対だと気付いた話 - メソッド屋のブログ
                                • はじめに - Writing an OS in 1,000 Lines

                                  本書では、小さなOSをゼロから少しずつ作っていきます。 OSと聞くと腰が引けるかもしれませんが、OS (特にカーネル) の基本機能は案外単純です。巨大なオープンソースソフトウェアとしてよく挙げられるLinuxでさえ、バージョン0.01はたった8413行でした。様々な要求に応えるために次第に肥大化していっただけで、当初は大変素朴な実装になっていました。 本書では素朴なコンテキストスイッチ、ページング、ユーザーモード、コマンドラインシェル、ディスクデバイスドライバ、ファイルの読み書きをC言語で実装します。これだけ様々な機能が詰め込まれているのに、コードは合計でたった1000行未満です。 「1000行なら1日でできそう」と思うかもしれませんが、初学者には少なくとも3日はかかるでしょう。OS自作のハマりポイントは「デバッグ」です。アプリケーション開発とは違うデバッグ手法・能力を習得する必要がありま

                                    はじめに - Writing an OS in 1,000 Lines
                                  • なぜ脱OSSが増えているのか?

                                    はじめに TerraformやVaultを開発するHashiCorpは自社製品をOSSのMPL(Mozilla Public License v2.0) から、ソースコードは公開するも一部の利用に制限があるBSL(Business Source License) への変更をアナウンスしました。 これは2018年のRedisを皮切りにMongoDBやCockroachDB、ElasticSearchなど多くのプロダクトで進められている脱OSSの流れです。商用のオープンソース[1]と言われてしまうこともある最近のこの動きの理由は何故なのか? という点を以下の動画で解説しました。 動画中では尺の都合で端折った個所も多いので、こちらの記事の方にもまとめておきたいと思います。 OSSとは? OSSの定義 まず、OSS(オープンソース)とはなんでしょうか? これはRMSのフリーソフトウェアを源流とする

                                      なぜ脱OSSが増えているのか?
                                    • エンジニア・データ分析職の方々にお薦めしたい、LLM時代に不可欠な教養が身に付くテキスト3選 - 渋谷駅前で働くデータサイエンティストのブログ

                                      (『IT Text 自然語処理の基礎』より) 3ヶ月ほど前に空前のLLMブームについて概観する記事を書きましたが、それ以降も世間のLLMに対する狂騒ぶりは収まるどころかますます拍車がかかるという有様で、あまつさえ僕自身の仕事における日常業務にもじわじわと影響が及びつつあり、今後も良きにつけ悪しきにつけLLMと共生し続ける必要がありそうだと感じている今日この頃です。 そんな猫も杓子もLLMに群がるが如き空前のブームを受けて、エンジニアやデータ分析職の方々の中には「LLMに興味はあるんだけど世の中にあまりにも多くのLLM関連コンテンツが溢れ返っていて何から手をつけたら良いのか分からない」という向きもあるように見受けられます。そこで、僕も断じてLLM以下生成AIの専門家などではないのですが、個人的に「このテキストを読めばLLM時代を生き抜くことが出来そうだ」と感じた書籍を、全くの独断と偏見で3冊

                                        エンジニア・データ分析職の方々にお薦めしたい、LLM時代に不可欠な教養が身に付くテキスト3選 - 渋谷駅前で働くデータサイエンティストのブログ
                                      • 漫画未経験のエンジニアが今のAIで漫画制作にトライしてみた記録2023年夏時点版|Anno Takahiro

                                        画像生成AIの躍進が目覚ましい。エンジニア兼SF作家の筆者としては、AIが絵を描けるようになるのなら、絵が描けない自分でも漫画制作ができるようになるのではという期待があった。実際に2022年の末頃にはstable diffusionを使った漫画制作UIのプロトタイプを作ってみたこともある。 Google ColabでAI漫画制作用のUIを試作してみた。コマごとにプロンプトが割り当ててあって、AIが裏でたくさん選択肢を作りまくってくれる。人間が大量の絵からベストなものを選んだり、構図やセリフの調整に集中できるようなワークフローがいいのではないかという仮説 #stablediffusion pic.twitter.com/zI64zm3cNI — 安野貴博 (@takahiroanno) November 10, 2022 それから半年以上の月日が経ち、世の中でもMulti ControlNe

                                          漫画未経験のエンジニアが今のAIで漫画制作にトライしてみた記録2023年夏時点版|Anno Takahiro
                                        • もう初回コードレビューはAIに任せる時代になった - CodeRabbit -

                                          どんな人向けの記事? レビューによって心理的なダメージを受けやすい方 非エンジニアだが、エンジニアチームがどんな機能を作っているか知りたい方 業務が溜まっていて、レビューに割く時間を捻出するのに苦労している方 コピペできるコードも公開します 初回レビューをAIに任せると、いろんなロールの人の役に立つ レビューは得意ですか? 優秀なエンジニアしかいないチームであれば、PRは1トピックに絞って小さく明確なコミットによって作成され、適切な要約とともに提供されることでしょう。 しかし、実際にはいろいろな制約から、PRが想定よりずっと大きくなってしまったり、関連トピックと異なるコードが混じってしまうこともあります。 実際のところ、大きなPRを適切にレビューするのは難しいことです。また、自分が詳しくない領域のレビューを行わなければいけない機会もあります。 今回の記事は、レビューを作成してくれるAI C

                                            もう初回コードレビューはAIに任せる時代になった - CodeRabbit -
                                          • IT客先常駐

                                            寝れないので、IT業界の客先常駐について書こうと思う。 客先常駐は辞めとけ客先常駐は辞めとけ。よく言われることです。 でもITには未経験だと客先常駐くらいしか無いのです。経験者でも客先常駐しかないのに未経験だと尚更。 私はそこそこ有名な大学の院卒で、27の時に他業界からIT業界に入ったけども、普通に書類選考で落とされてました。最終的に微妙な企業2〜3社しか面接まで行けませんでした。 当時は何も考えてなくて、とりあえず経験を積みたい、と採用してくれた企業に入社しました。年収300万で。ちなみに前職だと年収420万だったからめちゃくちゃ下がりました。 そこそこの学歴で、しかもバリバリの理系でも、未経験だとやはり採用してくれる企業は少ないんです。 ちなみに転職した時は30歳でしたけど、未経験の時に比べて書類選考の通過率はとても高かったです。 客先常駐のここが嫌だ給料が安い安いんですよ、月収20万

                                              IT客先常駐
                                            • 登大遊氏が憂う、日本のクラウド、セキュリティ、人材不足、“けしからん”文系的支配

                                              登大遊氏が憂う、日本のクラウド、セキュリティ、人材不足、“けしからん”文系的支配:ITmedia Security Week 2023 冬 2023年11月29日、アイティメディアが主催するセミナー「ITmedia Security Week 2023 冬」の「実践・クラウドセキュリティ」ゾーンで、情報処理推進機構(IPA)サイバー技術研究室 登大遊氏が「コンピュータ技術とサイバーセキュリティにおける日本の課題、人材育成法および将来展望」と題して講演した。日本における「ハッカー」と呼ぶべき登氏が初めてアイティメディアのセミナーに登壇し、独特の語り口から日本におけるエンジニアリングの“脆弱性”に斬り込んだ。本稿では、講演内容を要約する。

                                                登大遊氏が憂う、日本のクラウド、セキュリティ、人材不足、“けしからん”文系的支配
                                              • 1on1で質問をする側になって「工夫したこと」と「気づいたこと」 - Qiita

                                                プロジェクトでの進捗確認ミーティングもありますが、進捗を聞くだけに終始してしまいます。「働くこと」にもう少し視野を広げて、いろいろ聞いてみることがあります。1on1です。進捗確認MTGとは別の事柄を聞けます。以前は、1on1で質問される側でしたが、最近は1on1で質問をする側になったので、気づきをメモしておきます。 1on1の目的 1on1の目的は、(私の場合は)「心理的サポートをすること」です。別の言い方をすると、「働くことを通じて自己実現ができそうか/できているかを念頭に置き、会話を通して、精神面や志向についてプラスを大きく、マイナスを小さくするように働きかけること」です。 その上で、①働き方仕事内容の確認、②不安心配事の検知・助言、③成長・改善の意識付けという3つの観点から、プラス面、マイナス面を把握し、プラスを大きくマイナスを小さく働きかけます。 また、1on1をするときの基本的な

                                                  1on1で質問をする側になって「工夫したこと」と「気づいたこと」 - Qiita
                                                • 凄腕エンジニアさんから学んだ例外の話 - Qiita

                                                  はじめに 今携わっているプロジェクトで凄腕エンジニアさんと一緒に開発をさせていただいているのですが、その凄腕エンジニアさんから教えていただいた例外の話がとても勉強になり、 さらにこの例外の話を他のプロジェクトのエンジニアさんに伝えたところ、反応が良く、とても勉強になりました!という声をいただけたので、アウトプットしていきたいと思います。 (この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。) ※【凄腕エンジニアさんから学んだ例外の話】の補足 というQiita記事を書きました。 この記事を読み終わった後に疑問が残った人などは補足資料として読んでいただけると嬉しいです。 例外の考え方の源 Tさんの例外の考え方は http://diveintopython3-ja.rdy.jp/your-first-python-program.html#exceptions ↑こちらのPyth

                                                    凄腕エンジニアさんから学んだ例外の話 - Qiita
                                                  • スタートアップはいかにしてその活力を失うのか | Yakst

                                                    急成長するスタートアップがどうしてそのスピード感や勢いを失ってしまうことがあるのか、その背景にある構造とパターンを筆者の目から解き明かし、それを回避する方法を提案する。John Qian氏のブログ記事の翻訳。 [スタートアップ]原文 How a startup loses its spark (English) 原文著者 John Qian 原文公開日 2023-08-12 翻訳依頼者 翻訳者 doublemarket 原著者への翻訳報告 238日前 メールで報告済み 238日前 原著者承諾済み 編集 ちゃんとしたシードステージのスタートアップでは、エンジニアは業務経験を「夢中だ」と表現する。大きな会社では、得られるのは最良のケースでも「楽しい」程度だ。どうしてこうなってしまうのだろう。これは避けられないのだろうか。 スタートアップを夢中になれるものにするのは何なのかを調べてみよう。エンジ

                                                    • ITエンジニアが投票した「ITエンジニア本大賞2024」発表。単体テストの考え方/プログラマー脳/ プロジェクトマネジメントの基本が全部わかる、など

                                                      ITエンジニアが投票した「ITエンジニア本大賞2024」発表。単体テストの考え方/プログラマー脳/ プロジェクトマネジメントの基本が全部わかる、など 「ITエンジニア本大賞」は、仕事の役に立った本、初学者におすすめの本、ずっと手元に置いておきたい本など、おすすめの本をITエンジニアがWeb投票で選ぶイベントです。 主催は翔泳社ですが、対象となる書籍は出版社を問わず技術書、ビジネス書全般となっています。刊行年も関係なく、これまで大賞に選出された書籍を除き、この1年を振り返っておすすめしたい書籍が対象となります。 今回発表されたのは技術書部門とビジネス書部門それぞれのベスト10です。現時点では50音順に並んでいます。 以下は選出された技術書部門とビジネス書部門それぞれのベスト10を、Amazon.co.jpへのリンクと画像、概要で紹介したものです(アフィリエイトリンクは含まれていません)。正式

                                                        ITエンジニアが投票した「ITエンジニア本大賞2024」発表。単体テストの考え方/プログラマー脳/ プロジェクトマネジメントの基本が全部わかる、など
                                                      • 「世界一流エンジニアの思考法」は強いエンジニアの習慣がいい感じに言語化されていてよかった件 - Lean Baseball

                                                        界隈で話題になっている(と私は認識している)「世界一流エンジニアの思考法」を早速読んでめちゃくちゃ良かった, とにかく人に勧めたいぞ! という現役エンジニア(私)による書籍の感想エントリーとなります. 話題の本めちゃ良かったです. このブログを書く数日前にkindleで買って読む→めちゃいいやん!→紙版も買う←今ここ ってぐらいすごく良かったです*1. 世界一流エンジニアの思考法 (文春e-book) 作者:牛尾 剛文藝春秋Amazon 何が良かったか一言で言うと, 「強いエンジニアの習慣がここまでいい感じに言語化されている!!!」 という所ですね, 割と余すところなく詰まっていると思いますし, 一つ一つのTipsは再現性もあると思います(真似できるかどうかは別として真似は可能*2). そんな「世界一流エンジニアの思考法」の感想を手短に書きます, 気になる方はお付き合いください. TL;D

                                                          「世界一流エンジニアの思考法」は強いエンジニアの習慣がいい感じに言語化されていてよかった件 - Lean Baseball
                                                        • スイカゲームの作り方

                                                          はじめに Go言語用のEbitengineというゲームエンジンに興味があったので、試しにスイカゲームもどきを作りってみました。Ebitengineを使うと意外と簡単にスイカゲームもどきを作る事ができたので、なるべく分かりやすく作り方を紹介してみようと思います。 まずは先に完成品をお見せします。ちなみにフルーツの回転は面倒くさいので実装しないことにしました。 ちなみにEbitengineはwasmでも普通に動きます。ビルドしたものをこちらに置いたのでブラウザから実際に動かす事ができます。 それではスイカゲームもどきを作って行きましょう。 描画する まず一番初めにフルーツの画像を作るところから始めます。これはリンゴ、オレンジ、ブドウ、パイナップル、メロン、スイカのつもりです。 続いてフルーツを定義します

                                                            スイカゲームの作り方
                                                          • 『タクティクスオウガ』のマップはなぜ、圧倒的なクオリティと規格外のボリュームを両立できたのか? その裏には業界最古のゲームエンジン「HERMIT」の存在があった

                                                            『タクティクスオウガ』。その名を耳にして思い浮かぶのは、発売から25年以上の年月が経った今もなお、圧倒的な支持と人気を得ているという、スーパーファミコン後期の名作タクティカルRPGとしての確固たる姿だろう。 © 1995 SQUARE ENIX CO., LTD. All Rights Reserved.(画像は『タクティクスオウガ』公式サイトより) そんな『タクティクスオウガ』の開発には「HERMIT」(ハーミット)なるものが用いられていたことはご存じだろうか。 「HERMIT」とは、『タクティクスオウガ』を販売・開発した株式会社クエストが独自に作り上げた開発ツール……今で言う「ゲームエンジン」に相当する存在だ。この謎のゲームエンジンが、実は『タクティクスオウガ』の開発にあたって大活躍をしていたという。 ではこの「HERMIT」は、いったい何がすごかったのか? まずひとつ目のポイントは、

                                                              『タクティクスオウガ』のマップはなぜ、圧倒的なクオリティと規格外のボリュームを両立できたのか? その裏には業界最古のゲームエンジン「HERMIT」の存在があった
                                                            • 【永久保存版】0からAWSを勉強するならこのロードマップに従え! - Qiita

                                                              はじめに こんにちは!!@Sicut_studyです! 先日出しました記事が多くの方に見ていだきました! 今回はAWSのロードマップの紹介です。 AWSを勉強しようとしている人からよく聞くのが AWS勉強したいけど何からしたらよいかわからないから資格の勉強しています 資格を勉強するのもいいですが最速でAWSを実践的に使えるということを目的にするなら、その方法は個人的には微妙かなと思います。 私もこのロードマップを行ったあとに試しに資格をとってみましたが、あまり実務に速攻的に役立つという感じではありませんでした (高度なものなら違うかもしれません) 私も2年前はAWSについてまったく知りませんでした しかし、とあるタイミングで 先輩がやっているようなAWSの環境を作って管理するのを私もできるようにならないと高みにいくことはできない このように思うようになり、ロードマップに沿ってに1から学習を

                                                                【永久保存版】0からAWSを勉強するならこのロードマップに従え! - Qiita
                                                              • 生産性向上のために身に着けたい10のこと - Qiita

                                                                はじめに こんにちは。 普段働いているとき「どうやったら生産性があがるんだろう?」と思うことが時々あります。 「生産性向上」といっても具体的にどうするのか、なかなかイメージがつきにくい方も多いと思います。 この度、最近色々なところで目にする「世界一流エンジニアの思考法」という本を読みました。 この本では主に生産性を向上させるためにアメリカの一流エンジニアが行っている習慣や考え方について書かれており、 そこから個人的に身に着けたい10のことをピックアップしました。 内容について 筆者の牛尾さんはマイクロソフトの現役ソフトウェアエンジニアです。 そこで出会う一流エンジニアたちの考え方や、実践していることについて書かれている内容となっています。 アメリカでの内容なので日本では考え方のことなる部分もあるかもしれませんが、参考になる部分は多く 働き方や思考法について考えさせられる内容です。 個人的に

                                                                  生産性向上のために身に着けたい10のこと - Qiita
                                                                • 年収が600万円アップした転職手順 - Qiita

                                                                  はじめに はじめましてほしいもです。 今回は年収が600万円アップした転職の話をしたいと思います。 自己紹介 30代前半 既婚、子どもあり 大学卒 16Personalities:ENTJ-T(指揮官) 転職結果概要 利用した転職サイト:ビズリーチ、リクルートダイレクトスカウト 利用した転職エージェント:Geekly 転職活動期間:6週間 転職前後の業種:BtoBの自社開発企業 → BtoCの自社開発企業 年収変動:700万 → 1,300万 転職動機 「今転職しなければ手遅れになるかも」 という感覚が、転職活動を始めた主な理由でした。 現職での待遇に特に不満はなかったものの、新卒入社した企業で既に10年が経過し、このままでは40代で転職市場に出た時に不利になるのではと不安を感じていました。 他にも大規模なプロジェクトが終わってキリが良かったことや、 ベテランの退職者が少ないので上が詰まっ

                                                                    年収が600万円アップした転職手順 - Qiita
                                                                  • なぜエンジニア組織をうまくマネジメントできないと悩む経営者が多いのか? - Qiita

                                                                    はじめに 私は、さくらインターネットというクラウドサーバの会社の社長をしていて、よく経営者の方からのメンタリングのリクエストをいただくことがあります。 その中で多くの割合を占めるのが、ITエンジニア(以降、エンジニア)のマネジメントと、エンジニア組織の構築をどのようにすればいいのかというテーマです。 確かに、どんなビジネスをするにしても、単にSaaSやノーコードツールを活用するだけでは足りなくて、自分たちでシステム開発しないといけないケースが増えてきているのは、間違いないなと思います。 外注をしてシステム構築をするケースももちろん多いですが、基幹システムのような使いにくくても自社の社員が我慢すればいいものと違って、自社のお客様向けのシステムだと使いやすくないとお客様が離脱してしまいますし、常にアップデートをし続けて、最良のUI/UXを作ることが業績に直結します。 要は、今のデジタルシステム

                                                                      なぜエンジニア組織をうまくマネジメントできないと悩む経営者が多いのか? - Qiita
                                                                    • しずかなインターネットの技術構成

                                                                      こんなWebサービスをリリースしたので、技術的な話をまとめておこうと思います。 元々このサービスは、趣味の延長線のような感じで開発を始めました。競合にあたるnoteやはてなブログなどのサービスが確固たる地位を築いているということもあり、「お金にはならないだろうけど、自分の趣味を詰め込んだものにしよう」というゆるい気持ちで開発を続けています(楽しい)。 選定の方針 趣味と言っても文章投稿サービスなので、ユーザーが少数であったとしても長期間運営しなければなりません。そのため、ユーザー数が少なければランニングコストが数千円/月以下、ユーザー数が増えたときは段階的にコストが上がるように選定を行いました。 アプリケーション フルスタックNext.jsアプリケーションをCloud Runにデプロイしています。各APIエンドポイントはNext.jsのAPI Routesで生やしています。 Next.js

                                                                        しずかなインターネットの技術構成
                                                                      • 本番サーバー60台のホスト名を全部 cat にしてしまった話 - Qiita

                                                                        この記事は、本番環境などでやらかしちゃった人 Advent Calendar 2023 の4日目です。年末進行、いかがお過ごしでしょうか?みなさま無事に仕事が納まることを願っております… 新人インフラエンジニアが、本番ウェブサーバー60台のホスト名を全部 cat にしてしまった話について、ここに供養させていただきたいと思います 背景 おそらく今から7年くらい前、インフラエンジニアとして転職してきて1年ほどが経ち、本番環境での作業もこなれてきたなというバッチリのタイミングで事を起こしてしまいました。サーバーは CentOS 6 だったと思います。 職場としてはまだまだベンチャー感にあふれ大きな裁量が与えられスピード感のある環境ながら、サービスの登録ユーザー数は1,000万を超え、本番環境の規模としては既になかなかの大きさがあり、ウェブサーバーだけでも60台くらいあったと思います。ひと山につき

                                                                          本番サーバー60台のホスト名を全部 cat にしてしまった話 - Qiita
                                                                        • 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ

                                                                          前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか?どうすればいいんですか?」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。

                                                                            「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
                                                                          • AIはどのような仕事ができるようになったのか?ChatGPTで変わる「優秀な人材」

                                                                            この図はざっくりと3つの領域に分かれます。まず左下が従来のプログラミングの領域です。これは簡単に言うと「プログラムは間違ってはいけない定形な仕事を奪う」ということです。次にその上の士業が責任を取る領域です。これは「責任」を取る人がいないと成立しない仕事です。ミスが発生した際に罰則を与えるという形で、ミスの発生を防いでいます。最後に右側のホワイトカラーの仕事の領域です。ホワイトカラーの仕事は入出力が不定形であり、作業フローも非定型であったりします。そのため、多少のミスはあっても仕方ないという前提の上で仕事が行われています。 機械学習がビジネスに組み込まれるにつれ、ホワイトカラーの仕事領域はそれらによって少しずつ代替されつつあります。その図がこちらになります。 ホワイトカラーの担っていた領域は、表データの機械学習(重回帰や、Lasso回帰、SVM、RandomForest、LightGBMなど

                                                                              AIはどのような仕事ができるようになったのか?ChatGPTで変わる「優秀な人材」
                                                                            • 「システム設計の面接試験」という本が良かった

                                                                              皆さんこんにちは。株式会社ラクーンホールディングスで働いている川崎です。 最近「システム設計の面接試験」という本を読みました。 個人的にとても面白いと感じたので、オススメポイントと感想を共有します。 直近でシステム設計の面接を受けない方も、きっと読んで得るものがあると思います。 本の概要 システムの設計はシステムの機能や仕様、データのアクセスやセキュリティを左右するため、非常に重要だが、従うべき一定のパターンがないために、その習得は難しいと言われています。 一方で、システム設計自体がITエンジニアに日常的に求められる作業であるため、システム設計の面接試験は米国で広く採用されています。 本書では、「Webクローラ」「通知システム」「ニュースフィードシステム」「チャットシステム」「youtube」など実践的なテーマに沿って、システム設計の問題を出題し、その回答を解説することで、システム設計力を

                                                                                「システム設計の面接試験」という本が良かった
                                                                              • 富士通SEの退職理由が壮絶…メモリ4GBのPCで開発、ひたすら進捗会議

                                                                                富士通の本社移転先となる同社川崎工場(「Wikipedia」より) 大手IT企業の富士通で以前働いていた元システムエンジニア(SE)が「退職した理由」を綴ったインターネット上の投稿が、一部で話題を呼んでいる。そこには、開発環境の古さや、無気力な人材や組織体制の問題、給与面を含めた待遇の悪さなどが書かれている。「5年いた富士通を退職した理由」というタイトルの投稿は、「5年間エンジニアとして務めた富士通を一昨年退職した」「自分の半径5m以内で起こった幼稚な理由にフォーカスを当てる」と始まり、「開発環境がだめ」という項目では 「メモリ4GBのセレロン使ってた。もちろんSSDじゃなくてHDD。PCは富士通製のミドルクラスのノートPCしか支給されなかった。Macなんか認めん!iOSアプリも富士通PCで作れ!(本当にあった話)」 と、貧弱な開発環境を嘆いている。自身もIT企業でSEとして働いた経験があ

                                                                                  富士通SEの退職理由が壮絶…メモリ4GBのPCで開発、ひたすら進捗会議
                                                                                • 【レベル別】要件定義が学べるおすすめ本4選 - みんなのシステム企画

                                                                                  1. はじめよう! 要件定義 ~ビギナーからベテランまで(難度:★☆☆) 1-1. 本のポイント 要件定義のプロセスが平易な言葉で解説されている 内容がコンパクトで図解も多いため読みやすい 中級~上級エンジニアが初心に帰るためにも最適 1-2. 本の特徴 本書は、初学者向けにざっくりとした内容を具体的なアウトプットとともに学ぶことができる。 184ページとボリュームに物足りなさを感じそうだが、要件定義のプロセスと、プロセスごとの勘所がコンパクトにまとまっている。 ちなみに、本書は「要件定義のプロセスと勘所を知れる」という点で独立した書籍だが、著者が書いた下記2冊と合わせると、理解をより深められる。 ・はじめよう! プロセス設計 ~要件定義のその前に ・はじめよう! システム設計 ~要件定義のその後に 本書が有益だと感じた読者は、ぜひ上記2冊にも目を通していただきたい。 1-3. 本を書いた

                                                                                    【レベル別】要件定義が学べるおすすめ本4選 - みんなのシステム企画