批判の文化が日本を技術後進国にしているかもしれないという話 - メソッド屋のブログ
先日、接触確認アプリがリリースされました。これは正直日本のソフトウェアの進歩に画期的なことだったと思います。私も衝撃を受けました。 www.mhlw.go.jp その後起こったことに関して正直は私の感想はこの通りです。 日本で起こっている地獄を見て、アプリ開発者は海外に流出してしまうわって思う。あの流れは最低最悪。みんな自分が気持ちよくなるためだけに、自分の国の未来を破壊してるんやで。— TsuyoshiUshio (@sandayuu) June 21, 2020 このような展開は、私が今住んでいるアメリカでは発生しない事案だと思います。じゃあ、日米でどういう違いがあって、日本人の自分が小さな一歩を踏み出して、日本がよりよい国になるようにできるとしたらどんなことだろうということを考えてみましたので、あまりソフトウェアの専門用語を使わない形で書いてみようと思います。 接触確認アプリが生まれ
今回はソフトウェアエンジニアじゃない人や学生にも、ソフトウェアエンジニアという職業には夢があるかもしれないと思ってもらうために書いています。そのため既に詳しい方からすると回りくどい説明も多いと思いますがご容赦下さい。 基本的に記事とかには技術的なことしか書かないスタンスでやってきましたが、今回の件はさすがに誰かに伝えておくべきだろうということで長々と垂れ流しました。 概要 GW中に趣味で開発したソフトウェアを無料で公開したところAqua Securityという海外企業（アメリカとイスラエルが本社）から買収の申し出を受け、最終的に譲渡したという話です。さらに譲渡するだけでなく、Aqua Securityの社員として雇われて自分のソフトウェア開発を続けることになっています。つまり趣味でやっていたことを仕事として続けるということになります。 少なくとも自分の知る限り一個人で開発していたソフトウェ
優秀さについて
Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 白のカピバラの逆極限 S.144-3 はじめに 「【転職エントリ】Googleに入社します｜Lillian｜note」という、医師から未経験で Google のソフトウェアエンジニアになった記事があります。 note.com 私は、この記事に出てくる「とある元 Google のソフトウェアエンジニア」で、面接の対策を立てました。 記事が出た当初から大反響で、私もそれなりの反応を見まして、いろいろと誤解されているなあ、と思う一方、アドバイザーはあくまでもアドバイザーだから、アドバイザーとして知りえた情報については、口をつぐむべきだと思っていました。 ただ、あまりにも誤解されており、悪影響が大きく、犠牲者も多くなってきたと思ったので、… 同僚からこれについてどう思うか、と聞かれた。元の文章が
新人の方によく展開させていただいている有益な情報をまとめておきます。今後も展開することがあるかもしれないため情報をまとめております。 あらたな、有益な情報がありましたら、随時追加してまいります。 有益な記事・論文・書籍等を執筆・紹介していただいた皆様に感謝申し上げます。 ちなみに、本記事に記載されている情報は、お困りごと・お悩みごとをお聞きしたとき・気づいたときに、そのお困りごとに対して参考になりそうなものだけを展開していました。この情報を一気に展開していたわけではございません。 コードリーディングについて [1]ソースコードを読むための技術 https://i.loveruby.net/ja/misc/readingcode.html [2]派生開発推進協議会 関西部会 スペックアウトチーム，「派生開発におけるスペックアウト手法の提案」，派生開発カンファレンス2015，2015 http
いちいち行かなくていい。高いわりに役に立たない。本を買ったりネットの解説動画を見ながら自分でやるんだ。 毎日勉強できるならカリキュラムはこう。大事なのは「わかんなかったら自分で調べる」ということ。これをひとつひとつ解説していくとあっという間に1年ぐらいのカリキュラムになって金がかかるようになる。ググれば全部出てくる。出てこなかったら調べ方が悪いのでググりかたを変えればおｋ。この記事にも初心者から見ると「なにその言葉。初耳」っていうのがあると思うけど、全部重要なキーワードなのでググって咀嚼して血肉としてほしい。ググればすぐ出てくる。 1日目: Linuxのインストール(Linuxの中でもUbuntuっていうのがおすすめ)とりあえずLinuxを自分のパソコンにインストールする。Linuxを触れるようになればいい。 PCがない場合は、中古のPCなんて3万ぐらいで買えるからそれ買ってきてインストー
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間
1. はじめに ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。 以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。 今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。 (エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います) 会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。 本稿では、そのような「新メンバー」を活躍しづらくしてしまうアンチパターンとその対策を紹介します。 2. 中途入社や部署異動で来た新メンバーが適応することの困難さを理解する 中途入社や部署異動で来た新メンバーが組織に適応することは、新卒社員のそれとは別の難しさがあり
Midjourney、Stable Diffusion、mimicなどの画像自動生成AIと著作権｜知的財産・IT・人工知能・ベンチャービジネスの法律相談なら【STORIA法律事務所】
ホーム ブログ 人工知能（ＡＩ）、ビッグデータ法務 Midjourney、Stable Diffusion、mimicなどの画像自動生成AIと著作権｜知… はじめに Midjourney、Stable Diffusion、mimicなど、コンテンツ（画像）自動生成AIに関する話題で持ちきりですね。それぞれのサービスの内容については今更言うまでもないのですがMidjourney、Stable Diffusionは「文章（呪文）を入力するとAIが自動で画像を生成してくれる画像自動生成AI」、mimicは「特定の描き手のイラストを学習させることで、描き手の個性が反映されたイラストを自動生成できるAIを作成できるサービス」です（サービスリリース後すぐ盛大に炎上してサービス停止しちゃいましたが）。 で、この手の画像自動生成AIのようなコンテンツ自動生成AIですが、著作権法的に問題になる論点は大体決ま
ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ
最高の夏を迎える中庭 前回の記事投稿からだいぶあいていますが、あいかわらずGAFAではない会社でソフトウェアエンジニアをしています。今回は最近の個人的な大仕事であった家を買った話を書きます。ちなみにこの記事にソフトウェアエンジニア要素はほぼないので釣りタイトルになります、ただプロダクト設計やプロジェクトマネージャー的な感覚は必要になって非常に面白かったです。 注意事項: この記事は素人の個人的な意見や感想です、また家に関して何が一番良いかは人それぞれなのでそういった議論もしません。 なぜ家を買ったのか？ 子供の小学校入学前であることコロナ禍であることで決断しました。元々、自分や妻のキャリアや子供のことなども含め賃貸で暮らしてきましたが、子供も大きくなり小学校入学前には持ち家を買いたいなと漠然と考えていました。大体2年前くらいから都内で4LDKの戸建てやマンションを探していて、実際に買う寸前
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
今年に読んでよかった「ニンゲンの不合理と付き合う」ための本まとめ (今年じゃないのもちょっとあり) - フジイユウジ::ドットネット
本をよく積みます。よく読むではなく、ともかく積んでいます。 俺たちの本積むスピードには誰も追いつけない（読んでない本、まだまだあるのにまた本を買ってしまう） pic.twitter.com/RxrHrRl8KX — フジイユウジ (@fujii_yuji) 2021年12月17日 毎週土曜の朝から積読を強制的に消化する会というのをオンラインでやってまして、「誰か来るだろうから起きて読まなくては……」と強制力が働くことで本を少しずつ読むことができています。参加者のみなさん本当にありがとう。 時期によって人が増えたり減ったりして、ここ最近は数人しかいない状態なので新規参加者を募集しております。誰でも参加できるので参加してみたい方は連絡くださいな。 というわけで、今日は読んでよかった本をまとめて紹介していきたいと思います(今年じゃないのもちょっとあり)。 まとめてみたらニンゲン的な原理や不合理と
私がよく参考にしているサイトまとめ
はじめに Twitter、Qiita、Zenn...といろんなところから情報収集するのはいいのですが、それぞれの有益な情報をそれぞれのサイトにお気に入りとして保存しているので、必要な情報を探すだけで一苦労です。 ここで一覧にしてまとめておくことにしました。 ただし、特定の言語に依存するような記事はあえて排除しています。 皆さんにとっても有益な情報があると、この記事を公開して良かったなと思います。 また、皆さんのオススメの記事がありましたら、コメントなどで教えてください。 コミュニケーション 質問 質問は恥ではないし役に立つ https://qiita.com/seki_uk/items/4001423b3cd3db0dada7 新卒からの質問をソシャゲっぽい仕組みにしたら捗った話 https://qiita.com/ysktsuna/items/fced3a9515c8f585ca50 会
プログラマーを30年間やってきた経験から学んだことまとめ
プログラマーにとって「どうすればより効率よくプログラムを組み上げられるのか」は常に頭を悩まし続ける問題の1つとなっていますが、その道のエキスパートであるエンジニアのジュリオ・ビアソンさんが30年間ソフトウェア開発に携わってきた経験から学んだことについてブログにまとめています。 Julio Biason .Net 4.0 - Things I Learnt The Hard Way (in 30 Years of Software Development) https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/ ビアソンさんは多数ある「学んだこと」を以下の3つに大きくわけてまとめています。 ◆ソフトウェア開発について ◆チーム・仕事について ◆個人的なことについて これからプログラマーになろうとしている、あるいは
概要 職業ソフトウェアエンジニアを目指す方々にオススメしたい書籍トップ10です 以下の観点から選定しました 10年後でも変わらない、流行にとらわれず長く役に立つ、ソフトウェアエンジニアリングにおいて普遍的な知識 特定のプログラミング言語やプラットフォームやツールに精通するのではなく、現代のソフトウェア開発の哲学・文化の全体像が把握できることを優先 200～300ページくらいで初心者でも読破できる 400～500ページくらいの本もあるが、それらは辞書的に使うのがいい あえて10冊に絞り込んだので、ここに含められなかった書籍も当然あります CI/CDやDevOpsに関する本も入れたかった… デザインパターンに関する本も入れたかった… DDDやClean Architectureなどシステム設計に関する本は意図的に入れていない 真・プログラミングスクールに通うくらいならこの本を読め10選を書きま
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
はじめに NFT って何ですか？ ブロックチェーン上に記録された一意なトークン識別子をその保有者のアドレスと紐付ける情報、およびそれを状態変数として保持するスマートコントラクトのこと。 以上。 え、それだけ？ はい。 「デジタル資産に唯一無二性を付与するインターネット以来の革命」なんじゃないの？ これを読んでください: speakerdeck.com なるほど。ところで、この記事は何？ いま話題の NFT について、NFT の標準仕様である EIP-721 の仕様書と、それを実装しているスマートコントラクトのソースコードから読み解けることを解説する。一般向けの解説とは異なる視点から光を当てることで、ソフトウェアエンジニアに「あ、NFT って単にそういうことだったのか」と理解してもらえるようにすることを狙っている。 また、NFT がソフトウェアとして具体的にどう実装されているかを知ることは、
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
本記事は、Simon Holdorf氏による「10 Extraordinary GitHub Repos for All Developers」（2021年4月4日公開）の和訳を、著者の許可を得て掲載しているものです。 こちらもどうぞ すべてのウェブ開発者へ。人気GitHubリポジトリ9選 面接のリソース、build your own X、優れたパブリックAPIのリストなど Photo by Vishnu R Nair on Unsplash はじめに GitHubは、あらゆる種類の技術、フレームワーク、ライブラリ、コレクションなどを共有するためのNo.1プラットフォームです。しかし、その巨大さゆえに、最も有用なリポジトリを探すのが難しいという問題もあります。そこで私は、すべてのソフトウェアエンジニアに大きな価値のある、素晴らしいリポジトリ10選を作ることにしました。すべてに多くのGitH
【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
2019夏、先輩が若手に贈る「お世話になった技術書60選」- 入門からガチまで – | DevelopersIO
「この本にはお世話になったなぁ〜」 「今でもたまに読み返してます」 「マジでめちゃめちゃ影響受けた」 「そう、こいつが俺のエンジニア人生を変えやがったんだ...」 ↑「こんな本を紹介してください！」と社内チャットで投げてみたら、すんごいことになったのでそのリストをシェアさせていただきます。 ※推薦理由はあくまで推薦者による個人的な意見や思い入れたっぷりなので、それを踏まえてお楽しみください。 目次 アプリケーション/プログラミング ドメイン駆動設計 Java言語で学ぶデザインパターン入門 Pro Git BINARY HACKS Effective Java リバースエンジニアリング―Pythonによるバイナリ解析技法 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 リーダブルコード メタプログラミングRuby 第2版 Head First デザインパターン テスト駆動開発 C
技術文書の書き方
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
シリコンバレーから失意の帰国をした十年選手のITエンジニア、生き残るため大学院で情報科学を学ぶ - Findy Engineer Lab - ファインディエンジニアラボ
はじめまして、白山文彦（@fushiroyama）と申します。 インフラエンジニアとして5年、ソフトウェアエンジニアとして7年ほど働いて、現在は多国籍企業でクラウド関連の仕事に従事しています。 今年に入ってから、会社員としてフルタイムで勤務しながら、大学院の博士前期課程（修士課程）で情報科学を学んでいます。 この記事では、ITエンジニアとして10年以上もご飯を食べていながら、どうして今になって大学院生という道を選んだのか。業務で身についたものと、大学でしか学べないものとの違いは何なのか。そして最後に、それをどのように今後のキャリアにつなげていこうと考えているのか。そのあたりの葛藤や心の動きをシェアできたらなと考えています。 社会人大学院について 理系技術者は米国で圧倒的に尊敬されている 米国のエンジニアと日本のエンジニアの違い 学位と職業に強い関連がある米国 年齢に関係なく学位を目指すのが
コンピュータサイエンスが気になるプログラマに勧める書籍リスト - Rubyist Magazine 第61号 巻頭言
コンピュータサイエンスが気になるプログラマに勧める書籍リスト Rubyist Magazine 第 61 号をお届けします。 （今回は内容に合わせて文体を変えております。ご了承ください。） さて、コンピュータサイエンス（以下「CS」）は知らないけど日々プログラミングしている、というプログラマの方はたくさんいらっしゃるかと思います。 そんな方でも、ふとCSを知ってる方がいいのかなとか、CSも知らないとまずいのかな……などと思い、改めて勉強してみたいけどとっつきが悪いとか、うっかり手にとったCSの教科書が何を言ってるかさっぱりで10秒で閉じた、という方もいらっしゃるかと思います。 それでもCSが気になるので、「本腰を入れて勉強をする前に、どういうことをやってるのか眺めてみたい」くらいの温度感の方向けに、CSに隣接するジャンルで、職業プログラマや趣味プログラマの人なら読めそうな書籍のリストを作っ
バッチ処理 プラクティス
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
日本のソフトウェア開発はなぜ世界から落伍したのか。中国人エンジニアの見方 - 中華IT最新事情
日本のソフトウェア開発はなぜ落伍したのか。中国のエンジニアの間でも話題になることが増えている。未来樹Aは、その理由をエンジニアの視点で解説をしている。委託開発が多い。システム開発の目的がイノベーションではなく、生産性の効率向上に留まっている。政府、地方自治体の案件が上位企業に集中するため、ベンチャーが育たないという理由を挙げている。 中国でも話題になっているCOCOAの件 日本でも話題になっているが、中国でも接触確認アプリ「COCOA」の件が、エンジニアの間で話題になっている。中国では、位置情報とQRコードを活用した健康コードが、2020年2月11日という早い段階で、アリババと杭州市によって開発され、1月ほどで他都市にも広まった。感染リスクが高いと判定されると赤になり、公共交通や店舗の利用ができなくなる。不便は強いられるが、それでも、生鮮ECやフードデリバリーが発達をしているため、生活はな
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
みずほ銀行システム障害に学ぶ
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（
御社のミッション、ビジョン、バリューを教えて下さい 御社では、日々の業務でどのようなソフトウェアを作っていますか？ 御社の主要な顧客のカテゴリーとマーケットを教えて下さい 御社の事業が、顧客にどのような価値を提供してどのように対価を集めているのか教えて下さい 御社の事業の立ち上げの経緯や意思決定や試行錯誤のプロセスについて、もしご存知でしたら、なるべく詳しく教えてください 御社の事業の今後の展望や計画について教えてください 御社の日々のソフトウェア開発で、ソフトウェアエンジニアとして、夢中になれる魅力や醍醐味を教えて下さい 御社の技術構成や開発プロセス、開発スタイルについて教えて下さい 会社のことは忘れてください あなたが最近、話を聞いたり自分で触って、驚いたり熱中したり感動したりしたソフトウェアがあったら教えて下さい あなたがこれまでの生涯でソフトウェアを開発していて一番愉快で面白くて最
どうやってテクノロジーを追いかけていますか？ジュニアソフトウェア開発者として応募したときにCI/CD、クラウドコンピューティング、Dockerとか大量のことを要求されました。もういっぱいいっぱいです。
回答 (2件中の1件目) 深呼吸しようか。そしてリストを３つ作れ。 1. 使い方を知っていて、最小限の調査で済むテクノロジー（例：「CI/CDパイプラインのセットアップの仕方を知っている」） 2. 企業のインフラで使われていることを知っているテクノロジー（例：「Dockerをいつ、何故使うかは知っている。だけどDockerfileは書いたことがない」） 3. 聞いたことはあるけど何者なのか見当がつかないテクノロジー（例：「Kubernetesというのは聞いたことがあるけど、何のために使うのか見当がつかない」） リスト (1) はコンフォートゾーンにあたる。履歴書のトップに書けて、これで...
ITエンジニアが投票した「ITエンジニア本大賞2022」ベスト10発表。「シェル・ワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など
ITエンジニアが投票した「ITエンジニア本大賞2022」ベスト10発表。「シェル・ワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など 「ITエンジニア本大賞」は、仕事の役に立った本、初学者におすすめの本、ずっと手元に置いておきたい本など、おすすめの本をITエンジニアがWeb投票で選ぶイベントです。 主催は翔泳社ですが、対象となる書籍は出版社を問わず技術書、ビジネス書全般となっています。刊行年も関係なく、これまで大賞に選出された書籍を除き、この1年を振り返っておすすめしたい書籍が対象となります。 今回発表されたのは技術書部門とビジネス書部門それぞれのベスト10です。現時点では50音順に並んでいます。 このなかから特に投票の多かった技術書3冊、ビジネス書3冊について、同社が2月17日と18日に開催する「Developers Summit 2021（デブサミ20
ソフトウェア開発の見積もり入門
見積もりとは？ Wikipediaによると見積もりとは、以下のようにあります。 見積（みつもり。見積り、見積もりとも書く）とは、金額・量・期間・行動を前もって概算すること。見積もること。あらましの計算をすること。また、その計算。目算。「所要時間を見積る」、「一日の来客者数をざっと見積もった」など、おおよその感覚で数字の見当をつける場合の口語体表現でも使われる。 Wikipedia このように見積もりとは、なにかを行う前に事前にその結果を予想しておくことを言います。 見積もりを使うケースは、ソフトウェア開発に限った話ではありませんが、製造業であるソフトウェア開発においては『見積もり』というタスクは様々なケースで登場します。 見積もりが苦手な人は多い ソフトウェア開発では、「この機能を開発するときにどのくらいで完成できますか？」といったケースが見積もりのシチュエーションとしては多いかと思います
保守性の高いソフトウェア開発のTips集
保守性の高いソフトウェアの開発に役立つ様々なTipsを書いた。 特定の言語にとらわれずあらゆる場面で役立つことを集めた。
GPT-4の回答を向上させる「プロンプト26の原則」、220以上の生成タスクが実行可能なマルチモーダルモデル「Unified-IO 2」など重要論文5本を解説（生成AIウィークリー） | テクノエッジ TechnoEdge
2014年から先端テクノロジーの研究を論文単位で記事にして紹介しているWebメディアのSeamless（シームレス）を運営し、執筆しています。 1週間分の生成AI関連論文の中から重要なものをピックアップし、解説をする連載です。2024年初っ端の第27回目は、「礼儀は不要」「モデルに質問させる」「良い解答には報酬」など、大規模言語モデルの返答が向上する「プロンプト26の原則」をはじめとする5つの論文をお届けします。 生成AI論文ピックアップ複数の自律AIエージェントが過去の経験を共有して未知のタスクを処理するモデル「Experiential Co-Learning」 画像から動く3Dシーンを生成する新モデル「DreamGaussian4D」 大規模言語モデルの返答が向上する「プロンプト26の原則」が公開。「礼儀は不要」「モデルに質問させる」「良い解答には報酬」など 220以上の生成タスクが実
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
NTT 東日本 - IPA 「シン・テレワークシステム」 - HTML5 版 Web クライアントの公開について
NTT 東日本 - IPA 「シン・テレワークシステム」 Beta 7 および HTML5 版 Web クライアントの公開について トップ | 中間報告 | 自治体テレワーク for LGWAN | HTML5 Web 版クライアント (Mac, Chromebook 対応) | バージョン履歴 | ダウンロード | ユーザー数グラフ 入門 - 今すぐ使ってみよう | クライアント検疫機能・MAC アドレス認証機能 | 二要素認証・ワンタイムパスワード (OTP) 機能 | マイナンバーカードを用いたユーザー認証機能 | 仮想マルチディスプレイ機能 行政情報システムでの利用 | 組織 LAN におけるポリシー規制サーバー設置 | 企業システムにおける VM・HDD クローン対応 | Wake on LAN リモート電源 ON 機能 | 画面撮影・キャプチャ防止のための電子透かし機能 FAQ
なぜ雑談が重要か - stmn tech blog
これはなに？ こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 コミュニケーションには会議体やテキストベースなど様々な手段があります。 その中で雑談がなぜ重要であるかについて、私の考えを記したものです。 大事な前提 〜目的と手段の関係〜 人々の活動には目的があります。そして目的を満たすための手段を追い求めています（ここでいう手段とはシステムであったり情報であったり、「目的の役に立つもの」と考えてください）。 目的と手段の関係性を次の図で表現します。目的と手段それぞれの円の重なりが大きいほど、目的に対して相応しい手段である、ということをここでは表します。 この図を使った例を出します。 今の時期、だんだん暑くなってきましたね。「暑さを解消したい」という目的に対して、「扇風機を点ける」「エアコンを点ける」「かき氷を食べる」「南極に送り込む」
情報処理技術者試験なんて何の役にも立ちません
情報処理技術者試験の資格を取っても実質的に得るものはありません。「実質的に」というのは、技術者としてのスキル向上に貢献するということであり、「報奨金が貰える」とか「履歴書に書ける」などの技術と無関係なものを含まないということです。 なぜ、情報処理技術者試験が役に立たないのかと言えば、出題内容が表面的な知識問題に極端に偏っており、本質的な理解を問うていないからです。たとえば、オブジェクト指向の三要素に「カプセル化」「継承」「ポリモルフィズム」がありますが、これらを御題目のように唱えていても何の意味もありません。しかし、情報処理技術者試験ではこれらの用語さえ覚えておけば、しっかり点になります。 オブジェクト指向におけるカプセル化を説明したものはどれか。 同じ性質をもつ複数のオブジェクトを抽象化して，整理すること 基底クラスの性質を派生クラスに受け継がせることクラス間に共通する性質を抽出し，基底
IPA のけしからん技術が再び壁を乗り越え、セキュアな LGWAN 地方自治体テレワークを迅速に実現
IPA のけしからん技術が再び壁を乗り越え、セキュアな LGWAN 地方自治体テレワークを迅速に実現 2020 年 11 月 3 日 (火) 独立行政法人情報処理推進機構 (IPA) 産業サイバーセキュリティセンター サイバー技術研究室 登 大遊 独立行政法人 情報処理推進機構 (IPA) 産業サイバーセキュリティセンター サイバー技術研究室は、このたび、できるだけ多くの日本全国の地方自治体 (市町村・県等) の方々が、LGWAN を通じて、迅速に画面転送型テレワークを利用できるようにすることを目的に、J-LIS (地方公共団体情報システム機構) と共同で、新たに「自治体テレワークシステム for LGWAN」を開発・構築いたしました。 本システムは、すでに 8 万ユーザー以上の実績と極めて高い安定性 を有する NTT 東日本 - IPA 「シン・テレワークシステム」をもとに、LGWAN
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
趣味で作ったソフトウェアが海外企業に買われるまでの話 - knqyf263's blog
新人の方によく展開している有益な情報 - Qiita
プログラミングスクールなんか行かなくていいからこれやれ
要件定義～システム設計ができる人材になれる記事 - Qiita
中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita
だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
ソフトウェアエンジニア、家を買う - hichihara note
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
プログラミングスクールに通うくらいならこの本を読め10選 - ニート向けソフトウェアエンジニアリング塾
ソフトウェアエンジニアなら3秒で理解できる NFT 入門 - Okapies' Archive
実践要件定義入門以前 - 勘と経験と読経
すべての開発者へ。すごいGitHubリポジトリ10選 - Qiita
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
カジュアル面談 逆質問テンプレ - yuiseki
ソフトウェアに関わる人が知っておくといいかもしれない法則10個