エンジニア組織のキャリア戦略とスタンスとして大事にすべきこと
こんにちは、株式会社エウレカでCTOをしている kaneshin です。 この記事は CTOA Advent Calendar 2020 の21日目の記事です。エンジニア組織におけるキャリア設計について、今までの私の経験を踏まえて考察してきたスキルの礎の部分について、いろいろな方にお話しする機会が増えたこともあり、今年の締め括りとしてエンジニア組織のキャリア戦略について一本書こうと思い、本記事を書いています。 はじめに株式会社エウレカは、恋活・婚活マッチングアプリ「Pairs」の運用とオンライン結婚相談所「Pairsエンゲージ」の展開をしています。私は2012年にエンジニアとして入社し、当時ローンチしたばかりのPairsチームへの配属となりました。（Pairsは以下「ペアーズ」と表記します） 入社当時は出会い系と同じ括りとして認識されていたペアーズですが、今ではこのようなクリエイティブを世
BacklogのSREを担当しているmuziです。 今回の記事では、ヌーラボにおけるSREの活動事例として、Backlogの課題検索機能のリプレイスプロジェクトについてご紹介します。 このプロジェクトでは、SREと開発者がチームを組んで、要件定義からリリースまで行いました。その結果、Backlogを構成するサーバ同士が疎結合になり、将来的なマイクロサービス化に向けた足がかりを作ることができました。 歴史の長いプロダクトにありがちな技術的負債への取り組みの一例として、みなさんの参考になれば幸いです。 リプレイスプロジェクトの背景 Backlogの課題検索機能 最初に、このリプレイスプロジェクトの背景として、Backlogの課題検索機能についてご紹介します。 課題検索機能とは、Backlogの「課題」ページで利用できる検索機能のことです。件名や詳細に対するキーワード検索に加えて、プレミアムプラ
はじめに 本書『Observability Engineering』は、複雑化の一途をたどる現代のソフトウェアシステムに立ち向かうための、強力な武器となる一冊であり本稿はその読書感想文です。Observability Engineering を今から知りたい方はもちろん、Observability Engineering の基礎を改めて学びたい方もぜひお読みください。この記事もかなりの長さになるので普通に書籍を読んだほうがいいかもです learning.oreilly.com 「Observability:可観測性」という言葉は、近年ソフトウェアエンジニアリングの世界で大きな注目を集めています。しかし、その概念の本質を理解し、実践に移すことは容易ではありません。 本書は、そのオブザーバビリティについて、その基本的な考え方から、具体的な実装方法、そして組織への適用まで、幅広くかつ深く解説して
production code の設計についてはよく議論される一方、ユニットテストをどう書くべきかについてはあまり議論されることが少なく。とにかくカバレッジが高ければヨシみたいな感じで軽く扱われていることが多い気がする。 その結果、テストを書くときやとりわけテストを追加するときに "良くない" 方法でテストを追加/拡張してしまい、メンテナンスしにくく壊れやすい・(未来の自分でも)読んでも何を検証しているのか分からない、テストが落ちても不安だけを煽り何が問題なのか分からない、技術的負債が誕生してしまう。 詳しいことは本 ( XUnit Test Patterns など? 詳しい人は僕に紹介してください)を読んだりチームメンバーと議論するのが良いと思うが、この記事を読んでテストの書き方に対する意識を啓発できたらなと思っている。 理想を述べるのは簡単だけど現実は大変、頑張ろう introduct
他人の10倍仕事ができる人に10倍の給与を支払うべきなのか問題
サブタイトル：「個人差」あるいは「知」と向き合う - 成果と継続、そしてチームについて語りたい記事だった。 この記事では、チームにおける成果と継続の価値について私が考えたことを述べようとしていたのですが、その問題提起の部分の話がかなり膨らんでしまったので問題提起部分だけを分けて書きました。 一応、どういう事を考えているかの概要もこの記事の末尾に書いておきます。 2024/7/7 10倍、という部分の構造について掘り下げた記事をかきました！ 2023/4/18:補足を追記しました。 2023/4/29 とうとう、続きをかきました！ 2023/4/30 結論"じみたもの"も書きました。↓ 問題提起："成果主義"は解か？ まず手始めに「他人の10倍仕事ができる人に10倍の給与を支払うべきなのか問題」について考えたいと思います。 様々な人が、プログラマ、あるいはソフトウェアエンジニアの個人の能力に
システム開発本部のデータサイエンスユニットに所属している19新卒の豊原です。 巷で結構耳にするMLOpsですが、結構苦労していらっしゃる組織も多いと考えます。 今回の記事では、マイクロアドで挑戦するMLOpsについての概要と、その挑戦について解説します。 機械学習システムが抱える根本的な問題 私たちの思うMLOpsとは CEという概念 レコメンドシステムが抱える根本的な性質 マイクロアドが作るシステムの現状 MLOpsで実現すること 技術的詳細 Airflowを用いて学習を同時並行で回す MLflowを用いて学習結果を保存する 機械学習エンジニア絶賛採用中 機械学習システムを構築する上で、他の通常のシステムと決定的に違うことがあります。 それはシステムの劣化の早さ*1と問題調査という点にあります。 機械学習システムが抱える根本的な問題 機械学習システムが抱える根本的な性質として、データを基
この記事は NTTコムウェア AdventCalendar 2023 5日目の記事です。 自己紹介&動機 高鶴と申します。NTTコムウェア コーポレート革新本部で、プログラム設計～コーディング～ユニットテストにかかわる技術の社内標準化をやっております。 プログラムの静的な解析で早期にバグを発見・修正することで、後工程でのバグ対処コスト削減（ウォーターフォール開発の場合）や、技術的負債の早期解消（アジャイル開発の場合）を目指す、というのが私のチームの仕事の大きな一部となっています。 静的な解析で早期にバグを発見するツールには、オープンソースでも商用でも様々なものがあります。しかし、ソフトウェアの品質をより抜本的に良くしていこうと思うと、「プログラミング言語を何とかする」というところを考えたくなってきます。 Rustであれば、そのような期待に応えてくれるのではないかと期待し、調査・検証を始めま
はじめに こんにちは、Classiの佐々木（@sasata299）です。前回の投稿からだいぶ間が空いてしまい、季節はすっかり秋になってしまいました。 この期間、Classiでは外部の攻撃者による不正アクセス（4月）があり、また、サービスの高負荷によるアクセス障害（4月・5月）が続くなど、利用者の方々には多大なるご心配とご迷惑をおかけしました。この9月までClassiのCTOとしてサービスとお客様に向き合ってきた立場として、改めてお詫びを申し上げます。 本記事では、この2つの問題について改めて振り返りると共に、当時の状況と今我々がどのように対策を進めているのかについてお伝えします。 （※当社のCTOの変更については、後日改めて記事を出す予定です） 外部の攻撃者による不正アクセスが発覚（4月） 「Classi」は、学校現場の多様なシーンで活用されるクラウドサービスです。スマートフォン・タブレッ
ソフトウェア開発に関わる人々の新たなきっかけを生み出す場となることを目指す「Qiita Conference」。ここで「働きやすく、成長し続けられるエンジニア組織を目指して 」をテーマに株式会社カオナビの松下氏が登壇。ここからは、CTOに就任して行った取り組みと、CTO室の設立について話します。前回はこちらから。 CTOに就任して行った3つの組織的な取り組み 松下雅和氏：ここからはCTOとして組織全体の話をしようと思います。当時「ニューノーマル時代のカオナビへ」ということで、オフィスの移転を行っています。カオナビでは、働き方を選択するのは企業ではなく、社員がするべきだと考えています。 出社は義務ではなく、自由に出社しても自宅でもいい。出社するなら居心地のいい環境を提供するのが企業の義務だと考えているので、すごくいい環境のオフィスを提供してもらった記憶があります。 働き方では、ハイブリッド勤
理想のUIをめざして！Webでハーフモーダルを作って磨き上げた話 - Tabelog Tech Blog
こんにちは！飲食店システム開発部オーダーチームの開発エンジニアを担当している堀口です。 食べログオーダーは、レストランでの飲食体験をより快適にするためのモバイルオーダーシステムです。飲食店に来店したお客様が自身のスマートフォンを使用してQRコードを読み取り、Web上でメニューをカートに追加し注文することができます。メニュー選択や注文操作はWebでありながら、ハーフモーダルを使用したネイティブアプリのような注文体験ができます。 この記事では、モバイルオーダーシステムのUI改善に焦点を当てます。ハーフモーダルの採用がどのようにして決定されたのか、その開発プロセス、そして実際に達成された改善点について詳しく掘り下げていきます。Reactを使用したフロントエンド開発で遭遇した課題と、それらをどのように解決したかの具体例を紹介します。 目次 なぜ「ハーフモーダル」を採用したか ハーフモーダルの導入と
「“開発者体験”で世界をエンパワメントする1日。」と題し、チームや組織の課題に日々取り組む方々に向けて開催された「Developer eXperience Day CTO/VPoE Conference 2021」。ここで、READYFOR株式会社の仙塲氏が「『Userクラス』で考える技術的負債解消の観点」をテーマに登壇。次にUserクラスの問題と、その解決方法を紹介します。前回の記事はこちらから。 Userクラスが抱える問題 ここでやっとUserクラスが抱える問題。Userクラスを今のモデリング観点と照らし合わせてみると、個人顧客と法人顧客の関心事の異なる問題を、たった1つのUserクラスで取り扱ってしまっています。つまり、複数の問題解決のために、Userクラスが流用されている構造です。特定の問題解決を意図した構造になっていないんです。 このユーザーというのは、個人でも法人でもどうとでも
はじめに みなさん 1on1ミーティング していますか？ ※また、様々な1on1があると思いますが、ここでは組織上の上司（もしくはメンターとなる人）と部下（もしくはメンティー）が行うものにフォーカスして話していきます。 組織のマネジメントにおいて1on1が大切である、という事は言われて久しいですね。 おそらく、1on1の導入されていない企業においても、「1on1？ なにそれ？」ということは減ってきているのではないでしょうか？ とは言え、この1on1ミーティングについての課題感もよく聞くところで、 1on1する側、される側ともに何を話していいのかわからない なんだかやっているが変化を感じない しっかりと本音で話せていない気がする なんだかマンネリ化してきている これでいいのかわからない とにかく困っている など、様々な疑問を持ちながら行っていることも多いのではないでしょうか。 自分も定期的に
はじめに POLプロダクト Advent Calendar 2020の8日目のバトンを受け取りましたので、技術的負債の優先度について考えてみます。 技術的負債の認識とその対策が非常に重要であることは、エンジニア以外の方々にとっても、認識されつつあると思います。 技術的負債と呼ばれるものは非常に多岐に渡り、どのような会社においても大量に存在するでしょう。 私自身もエンジニアとして大量の技術的負債を作ってきた自覚があり、またどなたかの技術的負債に向き合ってきた経験があります。 しかしながら、ではどの負債から返すべきなのかということは、私の中にも確固たるロジックがありませんでした。 今回はこの問題を掘り下げるべく、ある文献レビュー論文を追いかけ、その中で紹介されていたわかりやすい方法を紹介します。 技術負債とはなにか？ 技術的負債はWard Cunninghamさんが1992年に国際カンファレン
はじめまして。エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでエンジニアをしている@kaa_a_zuです。 早速ですが、質問です。みなさんは、所属している組織のコードを誇りに思い、この先数十年間に渡って使い続けることができると確信していますか？ 私は、この質問をされた場合、顔を背ける自信があります。今回は、私と同じようにこの質問に対して "YES" と答えることが出来なかった人たち、そして 「リファクタリングをしたい」と思っているエンジニアが在籍する組織の偉い人たち に読んでもらいたい内容を書こうと思います。 テーマは、技術的負債の返済方法と技術的負債をためない方法についてです。（かなり長いので、HOWだけ知りたい方は4章から読んでいただけたらと思います。） 1. 一般的な技術的負債とは 2. なぜ技術的負債が発生するのか 3. 技術的負債がもたらす問題点 3-1
仕事でバックエンド開発するときに考えていること: 実践編 - CARTA TECH BLOG
はじめに こんにちは、fluctでエンジニアをやっているyanyanです。 この記事は、仕事でバックエンド開発をするときに考えていること の続きです。 前回のスライドでは、私がバックエンド開発をするときに大事にしている考え方や思想の話をしました。今回は、じゃあそうした思想の下で実際にどういうものを私が作ったかという話をしようと思います。なので、この記事を読む前にスライドの方を読むことをおすすめします。 speakerdeck.com 何を作ったの？ すごいざっくりいうと、顧客向けWebサービスのバックエンド部分を0からつくりました。 0からと言っても、インフラ部分に関してはすでにあるECSサービスにタスクを追加するだけという形を取りましたが、アプリケーション開発というスコープでいうと技術選定からやり始めました。 どんなサービスなのか fluctが広告配信をしたり、運用支援をしている媒体社が
ロックインとはなにか？すべてが悪いのか？「開発におけるロックインのリスク評価と考え方」 #AWSDevDay | DevelopersIO
ロックインとはなにか？すべてが悪いのか？「開発におけるロックインのリスク評価と考え方」 #AWSDevDay とかく悪の象徴として語られがちな「ロックイン」ですが、それが本当に悪いものなのか？そもそもロックインとはなにか？それのリスクをどう考えればよいのか？真正面から解説された素晴らしいセッションでした。 「いや、そこまでAWSどっぷり使ってもうたら、他に移行するの大変やん？」 あなたがユーザー側クラウド導入推進担当として、あるいはクラウドベンダーの担当として上司やお客様から冒頭の質問を投げかけられた時、どのように答えますか？ 自分もクラウドベンダーの一員としてお客様と対峙する時、基本的には「AWSにあるものは基本的に全て使いましょう。それが結局は一番オトクです」と答えているんですが、それがすべて本当なのか？AWSのなかでもマネージドサービス複数あるけど、使えば使うほどええってわけでもない
Engineering Manager になってから身に沁みた12のアイデアと言葉 part2 - これはただの日記
2019/12 にこんな記事を書きました。 kths.hatenablog.com あれから一年たち、日々積み上げた新しいアイデアをみなさんとも共有したいと思います。 システム操作性スコア 私が勤めるスタディストでは、一部のサービスがマイクロサービスとして稼働しています。また、それ以外にも稼働している別プロダクトがあったりと、徐々に組織の管理対象となるサービスの数が増えつつあります。また、今後もその数は増加していくことが予想できます。 2020/12/26に発売されたばかりの書籍『モノリスからマイクロサービスへ』では、マイクロサービスが引き起こす可能性のある痛みの一例として、孤児サービスという言葉が登場します。これは文字通り、所有権や責任を負う人がいなくなってしまったサービスのことで、孤児サービスに対するトラブルシューティングは困難になることが予想されます。単に一部機能の停止で済めばマシで
和田卓人(t_wada)さんをお呼びして「質とスピード」の社内講演をしていただきました！ - stmn tech blog
こんにちは、スタメンCTOの松谷(@uuushiro) です。 7/25に、 和田卓人さん (以下、t_wadaさん)をお呼びし、「質とスピード」の社内講演会を開催しました！ t_wadaさんにご依頼したきっかけ スタメンが提供する「エンゲージメントプラットフォーム TUNAG(ツナグ)」はスタメンの創業事業で、サービス提供から約7年が過ぎました。この約7年間、プロダクト成長に注力してきた中で、内部品質や開発効率などに関する課題が後手に回っていました。 TUNAGが成長軌道に乗ってきた今、今後もエンジニア組織をスケールさせながら、継続的にプロダクトの価値を素早く世の中に届けていくために、開発者体験(DevEx)に関する明確な戦略が不可欠だと考えており、この課題に集中して取り組むために、今年の4月からCTO室にDevEx(Developer eXperience)チームを立ち上げ、2023年
こんにちは。Gaudiyでソフトウェアエンジニア兼スクラムマスターをしている Namiki ( @ruwatana ) です。 「チームが向き合う不確実性が大きいと手戻りが増えて価値提供のリードタイムが遅くなる」 「チーム内の心理的安全性の低さや認知負荷の高さによってエンゲージメントが低下して従業員がオンボード・定着しにくい」 ... などなど、昨今のチーム開発はこうした課題で溢れかえっていることかと思います。 結局のところ、我々は具体的にどんなプラクティスを行うことで、こうした課題を解決できていくのでしょうか？ 本稿では、筆者と筆者が4ヶ月ほど前に配属することになったチームがこうした問題に対して執ったアプローチおよびその効果をより具体的に示すことができればと考えています。 プロダクトチーム開発を行う皆様に何かしらの参考になれば幸いです。 1. チーム構成と特性 2. 特性が生み出しうるリ
月間10万人が読んでいるCoral Insightsのニュースレターにご登録いただくと、Coral Capitalメンバーによる国内外のスタートアップ業界の最新動向に関するブログや、特別イベントの情報等について、定期的にお送りさせていただきます。ぜひ、ご登録ください！ Coral Capitalで投資を決めるときの基準の1つに、チームに優秀なエンジニアがいるかどうかということがあります。最近はシード投資に加えて、シリーズA・Bで出資することも増えましたが、その場合には開発チームや開発体制、技術スタックや設計方針などについて詳しくお聞きすることがあります。それはメンバーが優秀で事業ドメインやビジョンが優れていても、十分な開発スピードが保てなければ事業成長のボトルネックになり得ると考えているからです。逆に開発速度が圧倒的に速いことはmoatになると、個人的には考えています。 これは自明な考えの
「CA BASE NEXT」は、20代のエンジニア・クリエイターが中心となって創り上げるサイバーエージェントの技術カンファレンス。山中氏は、"新しい未来のテレビ"を目指すABEMAの課題とそのアプローチ法について発表しました。前半は、ABEMAが抱える負債とインジェストアーキテクチャ「SUPERBIRD」について。 開局5周年を迎える「ABEMA」が抱える課題 山中勇成氏：「『新しい未来のテレビ』を目指すABEMA配信システムの再設計」というタイトルでお話しいたします。まず自己紹介ですが、山中勇成と申します。ハンドルネームで「みゆっき」という名前でも活動しています。 2017年に株式会社サイバーエージェントに新卒入社をして、今は「ABEMA」のコンテンツ配信チームで、主にバックエンドのエンジニアをしています。また、未踏スーパークリエータにも認定されています。「Twitter」と「GitHu
『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』ができるまで #voyagebook - t-wadaのブログ
昨日（2020年8月7日）、書籍『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』（ハッシュタグ #voyagebook）が出版されました。この本は私（@t_wada）がVOYAGE GROUPに在籍する主要なソフトウェアエンジニアにインタビューし、その内容をラムダノートの編集者鹿野さん（@golden_lucky）が本としてまとめたものです。2020年代のウェブにおけるビジネスとソフトウェア開発の在り方を濃縮した1冊に仕上がっています。 書名：Engineers in VOYAGE 事業をエンジニアリングする技術者たち 著者：株式会社VOYAGE GROUP 監修、和田卓人 編 （A5判、224ページ、ISBN：978-4-908686-09-2、本体価格1,800（＋税）円、電子版のみ1,000（＋税）円） 発行：2020年8月7日 メインタイトルが『
Machine Learning Casual Talkは、機械学習を用いたシステムを実運用している話を中心に、実践的な機械学習に関して気軽に話せる会です。実際に運用していく上での工夫や、知見を共有します。第12回目のテーマは「機械学習プロジェクトに関する「ベストプラクティスとアンチパターン」。機械学習ではデータを扱いますが、そのデータマネジメントがしっかりしていないと破綻してしまうという点について、ゆずたそ氏がお話します。前半は使えないデータとは何かについて。 自己紹介 ゆずたそ氏（以下、ゆずたそ）：では、発表を始めたいと思います。「データマネジメントなきMLは、破綻する。〜こんなデータじゃ機械学習できねぇよ問題の処方箋〜」という話をしたいと思います。 はじめに、まず自己紹介です。「yuzutas0」というアカウントをやっています。機械学習の専門家ではないのですが、機械学習を使った施策に
State of DevOps Report 2021を日本語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー - TC3株式会社｜GIG INNOVATED.
State of DevOps Report 2021を日本語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー はじめに State of DevOps ReportはDevOpsの成熟度についてアンケート形式で調査しているレポート資料です。毎年アップデートされているので、直近の動向などを理解し、かつ課題解決の活路を見出すのに良いレポートです。2021版が先日リリースされていました(もとのレポートはこちら)。 デジタルトランスフォーメーションの文脈の中で、ソフトウェア開発がますます増えてきていますが、単に一発作っておしまいではなく、継続的に進化させることが求められます。継続的にサービスを進化させていくことがビジネス力の根源となるということをアンケート調査から証明したのが、このレポートで、調査内容については、『LeanとDevOpsの科学』をご一読いただく
形状認識処理のディレクターを務めている寺田です。昨年10月よりDTダイナミクス（ミスミグループ出資の戦略的IT子会社）のお世話になっています。 私が入社した時点では meviy の形状認識はすべて C++ で書かれていましたが、そこに Rust を導入したというお話です。 Rust で何作ったの？ ゴチャゴチャと御託を並べる前に、まずは Rust で何を作ったのかを簡単に紹介しましょう。 大きく分けて下記の3領域に Rust を導入しました。 溶接リモデル機能 平板展開機能 自動テストツール ここでは先頭の「溶接リモデル」について簡単に紹介します。 この機能の内部実装を C++ から Rust に置き換えて、またロジックも大きく変更することによって、溜まっていた不具合を大幅に解消しました。 溶接リモデルとは 溶接リモデル 上図の左がリモデル前、右がリモデル後です。 板金製品は、平らな板金材
Tebiki株式会社では「現場向け動画教育プラットフォーム tebiki 」を開発しています。そして、このプロダクトの価値を最速で大きくしていくために、スクラムを導入しています。 スクラムによりtebikiの開発チームはより速いプロダクトのフィードバックサイクルを回せるようになりました。その一方で「スクラムチームはどのように技術的負債の解消に取り組んでいけばいいのか？」という課題に直面しました。 この記事では「スクラムと技術的負債の解消の両立」という課題に対してTebiki社が導入した「20%ルール」についてご紹介します。 Tebiki社における20%ルールとはTebiki社の20%ルールは エンジニアが開発に充てられる時間の20%をスプリントゴール以外のことに使うこと。 というものです。 つまり、エンジニアのリソースは以下のように使われます。 スプリント … 80%スプリント以外の開発業
リファクタリングには価値がある、とプログラマは確信していることだろう。しかし、その価値が何であるか？を上手く説明できるかというと難しいのではないだろうか。本稿ではリファクタリングの価値をテーマに筆者の説を提示していく。 品質特性の側面から 補足 品質特性の相互作用 リファクタリングの価値 障害対応 機能追加 システムの製品寿命 まとめ 品質特性の側面から ソフトウェアの品質特性としてISO/IEC 9126が一般的に用いられている。大きく6つの特性と細分化された副特性からなり、ISO/IEC 9126 - Wikipedia から引用すると 機能性（functionality） - 機能とその特性に影響する特性群 信頼性（reliability） - ある状況がある時間続いたときにソフトウェアがどの程度機能するかに影響する特性群 使用性（usability） - 利用するのにかかる手間、個
こんにちは！ dely株式会社サーバーサイドチームの安尾です。 本記事はdely Advent Calendar 2019の5日目の記事になります。 qiita.com adventar.org 昨日は辻さんが「Jupyterもいいけど、SageMath使って可能性もっと伸ばそう！」という記事を書きました。 tech.dely.jp 本日は「スピード優先の開発で溜まった技術的負債の返済計画（サーバーサイド編） 」というタイトルで、今delyのサーバーサイドチームの技術的負債についての考え方から、負債返済のために具体的に行なっていることをご紹介したいと思います。 技術的負債とは 抽象的な言葉なので、組織や人によって微妙に定義が異なるのではないかと思いますが、僕たちのチームでは「未来の開発スピードを下げる原因となるプログラムやアーキテクチャのこと」を総称して技術的負債と呼ぶようにしています。
実践 自然言語処理
自然言語処理（Natural Language Processing：NLP）の本格的な実践書。過去10年間で起きたブレークスルーにより、NLPは小売、医療、金融、法律など、さまざまな分野での利用が増えてきました。急速に利用が拡大する中で、産業界でNLPを使ったシステムを構築するのに必要な知識を学べる講座や書籍は不足していました。本書を読むことで、NLPの要素技術やSNS、Eコマース、医療、金融といった具体的なビジネスへの適用方法に加えて、NLPシステムを開発するためのベストプラクティスを詳しく学べます。 賞賛の声 序文 訳者まえがき まえがき 第I部 基礎 1章 自然言語処理入門 1.1 実世界での自然言語処理 1.1.1 NLPのタスク 1.2 言語とは何か 1.2.1 言語の構成要素 1.2.2 自然言語処理の難しさ 1.3 機械学習、ディープラーニング、そして自然言語処理の概要 1
「HTMLの前提についてはざっと知った、ステップアップできるHTMLの勉強がしたい」「人に勧められるHTMLにまつわる書籍はあるだろうか」「令和でHTMLを学ぶならこの1冊、というものがほしい」―――そうした人々のニーズを叶えてくれる書籍が販売された。 その名も「HTML解体新書」だ。 本ブログ記事は、レビュアーとして関わり本書を読んだ＠okuto_oyamaによる感想と、HTMLのこれからについて考えていることをまとめたものである。 本の内容については、著者によるブログ記事にまとまってあるのでそちらを参考にしてもらいたい。 creators.bengo4.com まだまだHTMLについて知らないことがあった 私がHTMLについて始めて触れたのは、とあるブログサービスのHTML編集機能からだ。その頃は HTMLの仕様というものを知る由もなく、どういったタグを使うと画面上にどのように表示され
皆さんこんにちは、虎の穴ラボのH.Kです。 オライリー書評シリーズは、今回で第7弾になります。 (前回の書評はこちら) toranoana-lab.hatenablog.com その他のオライリー書評はこちらになります。 今回の記事では、2019年9月のオライリー定期購読で届いた、『レガシーコードからの脱却』を読んだので感想を書きたいと思います。 読んだ動機 とらのあなの通販サイトは2018年6月にリニューアルされました。 リリースから1年半以上経過し、当時からは新機能も多数加わったこともあり、徐々に改修時に「技術的負債」を実感することが多くなりました。 開発メンバーも増えていく中で、いかに開発効率をあげることができるか、という課題もあったため、本書を読み、今後の開発に活かしていこうと考えました。 目次 目次は以下のような構成になっています。 目次 第Ⅰ部 レガシーコード危機 1章 何かが
保存版: Railsアプリケーションのセキュリティベストプラクティス（翻訳）｜TechRacho by BPS株式会社
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Security Best Practices for Your Rails Application | AppSignal Blog 原文公開日: 2022/10/05 原著者: Paweł Dąbrowski サイト: AppSignal Blog 参考: 週刊Railsウォッチ20221011 Railsのセキュリティベストプラクティス 日本語タイトルは内容に即したものにしました。原文の章インデントは訳文で一部を変更しています。 以下のRailsセキュリティガイドも合わせてお読みください。 参考: Rails セキュリティガイド - Railsガイド Webアプリケーションを構築するときは、パフォーマンスや使い勝手を重視するのはもちろんですが、セキュリティにも注目する必要があります。ハッキング手法は、技術の進化と変わらない
1 年を通して理解した CTO としての職務｜めもりー
はじめにみなさん，こんにちは。めもりーです。株式会社トラーナで執行役員 CTO になってから 1 年が経過しようとしているので，来年の所作も踏まえて，そろそろ記事にしようかなと思っています。 1年間 CTO としてどうだったか正直，CTO という職務が何をするべきか，常々悩んでいます。 上記の記事のように私の中では CTO の職務というのは "技術資産を常にフル活用できる状態にすること（意訳）" だと定義しました。 もちろん，会社によっては CTO は「技術のプロフェッショナルでテックリードの上に起つ存在である」であったり「ボードメンバーの一人として，経営に携わり技術的な意思決定をする」であったり「課題を洗い出し，技術的にどのように解決できるかのリードをする」といったり，十人十色だと思っています。 その中で，私自身の答えとしては，上記の技術資産の活用であると導きだしているものです。 CTO
アーキテクチャ変更を決断するときCTOは何を考えているか？ 技術的意思決定を経営陣に説明する実践的Tips - Fast DOCTOR Technologies TECH BLOG
記事を書く背景 ばんくしさんの「エンジニアとビジネスの距離感の難しさ」というブログを読みました。 経営とエンジニアリングをつなぐ立場であるCTOとしては永遠のテーマだと思います。 申し遅れましたが、私はファストドクター株式会社CTOの宮田 芳郎です。昨年、ファストドクターの開発組織は、大きな技術的意思決定を経営陣とともに実施できました。具体的には次の2点です。 アプリのFlutter化（意思決定は2022年5月） 新規のバックエンド開発時の言語をRubyからTypeScriptへ切り替え（意思決定は2022年6月末） いずれも一度の経営会議で、上記の方針について経営陣との合意を取っています。 5秒でわかる記事の結論 経営陣への提案資料は下記の5点をポイントとして記述すると良い 実施の意義（≒ 解決したい課題） 必要リソース（人・モノ・金 + 時間） 実現コンセプト リスク 手続きの妥当性
……と思っていたら5ヶ月かかりました． 【基盤開発チーム ブログリレー3日目】 「ほんとうにすぐ終わると思ったのかね」 こんにちは，エムスリーエンジニアリングGの榎田です．趣味は数学とテレビゲームです．最近はタクティクスオウガ リボーンを遊んでいます．システィーナをバーサーカーで運用しているのが弊ユニオンの個人的なイチオシポイントです． 閑話休題，ソフトウェア開発において「技術的負債」はつきものです．我々は無限の開発時間が取れるわけでも，神授の智慧を持っているわけでもないので，作ったものは何かしらの要因で負債を抱え，抱えた負債は（多くの場合，知らず知らずのうちに）増えます．負債だらけになってしまったソフトウェアの保守管理は大変ですし，負債になりにくいソフトウェアを作るのも難しいです．ではどうして負債を抱えてしまうのか．負債を返すことの何が大変なのか．負債リスクを予見するのはなぜ難しいのか．
バランスシートで考える技術的負債
はじめに エンジニアリングの課題としてよく話題になるのが技術的負債という言葉です。プロダクトを開発していった結果、その一部に満足のいかない部分が生まれ、それによって開発効率が落ちてしまうようなものを技術的負債と呼んでいると思います。つまり作り出した物が負債となってしまったという解釈が多いのではないかと思うのですが、私は作り出していないために生まれる技術的負債もあるのではないかと思っています。 この記事では、技術的負債を言葉の由来でもある会計的な視点から見てみることで、技術的負債の本質を解き明かし、どのように計画的な技術的負債の運用を行うかについて考察します。なお、私に会計的な専門知識はないのと、簡単化のために、あくまで会計風の表現で技術的負債を表してみたものと思ってください。 バランスシートで考えるプロダクト開発 技術的負債について触れる前に、まず、プロダクト開発を会計的に表現するとどうな
zx + Datadog + GitHub Actions でフロントエンドのコードベースの健全性を可視化する
フロントエンドのダッシュボードを作ってみたらいい感じだったので紹介です。 作ったもの zx と Datadog、GitHub Actions を使って以下画像のように、フロントエンドのコードベースの各指標を可視化するダッシュボードを作りました。 値はデモ用に書き換えています 現在、計測している指標はこちらです。 Vue SFCファイルにしめるTypeScriptの割合 Vue SFCファイルにしめるComposition APIの割合 strict: trueにした場合のType Errorの数（tsc & vue-tsc） Jestの各種カバレッジ 各指標は毎朝9時に更新していて、時系列での推移も確認できます。 なぜ作った？ 技術的負債解消等コードベースのリファクタリングの活動は、機能追加に比べ進捗を把握しにくい、成果が伝わりにくいという問題があり、それを解消したいと考えたからです。 こ
ラクスのPHPエンジニア12人によるPHPカンファレンス2020参加レポート - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに 株式会社ラクス 配配メール開発課のPHPエンジニア Jazumaです。 2020年12月12日(土)にPHPカンファレンスが開催されました。 phpcon.php.gr.jp 例年では「大田区産業プラザ PiO」で開催予定でしたが、今年は新型コロナウイルスの影響でオンライン開催となりました。個人的にはオンライン開催である分、地方のエンジニアでも気軽に参加することができたのは良かったのではないかと思います。 ラクスはPHPカンファレンスにスポンサーとして参加させていただいている他、社内からLT枠で2名が登壇しました。 今回はPHPカンファレンスに参加した社内のPHPエンジニアがイベントをレポートしましたので、ご紹介したいと思います。 各セッションのスライドについては以下にまとめましたので、ご活用いただければ幸いです。 No タイトル 1 SPAのAPI開発の「やりづらさ」をDDDと
エンジニア→プロダクトマネージャー→...その先は? 〜スマニューたいろーさん×クラシル奥原さんが語る、最先端のキャリア論 - Findy Engineer Lab
2020年11月26日（木）ファインディが主催するエンジニア向けイベント「【エンジニア職種徹底分析〜PdM入門編〜】スマニューたいろーさん×クラシル奥原さんが語る、エンジニアからのキャリアチェンジ」がオンライン上にて開催されました。 先日、”プロダクトマネージャーカンファレンス2020”も開催され、職種としてのキャリアが認知されつつあるプロダクトマネージャー（以下、PdM）。しかし、ビジネス側からPdMになるケースが一般的で、「エンジニアからPdM」というキャリアを選ぶ方はまだそれほど多くはないのが現状です。本イベントではスマートニュース株式会社のたいろーさん、dely株式会社（クラシル）の奥原拓也さんをお呼びして、PdMというキャリアについて語っていただきました。具体的な業務内容から裏話まで展開されたトーク内容をお届けします。 登壇者プロフィール エンジニア出身だから活きる、PdMという
Scrum@Scaleの基本と実装 - Chatworkの実践に学ぶ「スケールするスクラム」の導入戦略｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Scrum@Scaleの基本と実装 - Chatworkの実践に学ぶ「スケールするスクラム」の導入戦略 スクラムのスケーリング手法であるScrum@Scale（スクラムアットスケール）の基本的な概念、そして企業内での実践例を粕谷大輔（daiksy）さんが解説します。実践例では、Scrum@Scaleにおいて「だれが」「なにをやるのか」を、1週間のタイムスケジュールとともに解説します。 2001年にアジャイルソフトウェア開発宣言 が発表されてから20年。日本のソフトウェア開発の現場でもアジャイルはずいぶん一般的に扱われるようになってきました。そのうちの手法の１つであるスクラムについても、導入事例を多く見聞きします。 スクラムは原則的に少人数のチームに適用されることを前提としている手法ですが、さまざまな現場で扱われるようになるにつれ、規模の大きなチームへと拡張されるニーズも高まってきました。現
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SREの活動事例紹介 〜 Backlogのマイクロサービス化に向けた課題検索機能のリプレイス
もう一度読むObservability Engineering - じゃあ、おうちで学べる
Tests as Documentation - たにしきんぐダム
新卒がMLOpsに挑戦していく話 - MicroAd Developers Blog
プログラミング言語Rustになぜ注目するのか - Qiita
Classiで発生した2つの問題を繰り返さないために我々が取り組んでいること - Classi開発者ブログ
エンジニア組織のロール再定義、横断で動くためのCTO室設立… 組織改善にはボトムアップとトップダウンのどちらも大切
モデリングの仕方がUserクラスの負債化をまねく 分割設計で爆死しないための2つの考え方
2022年ももう終わりなので1on1について改めて学んでみた - Qiita
技術的負債の優先順位について論文を読んでみた
借りたものはきっちり返す。技術的負債への向き合い方 - Gaudiy Tech Blog
不確実性や心理的安全性に向き合い自己組織化するチームを作る実践プラクティス
スタートアップには「開発速度プレミアム」もある | Coral Capital
「ABEMA」が抱える大きな負債 ぼくがかんがえたさいきょうの配信システム「SUPERBIRD」
こんなデータじゃ機械学習できねぇよ MLにおけるデータマネジメントの重要性
meviy に Rust が入りました - DTダイナミクス テックブログ
20%ルールでスクラムと技術的負債の解消を両立する
リファクタリングの価値の考察 - プログラマーの脳みそ
スピード優先の開発で溜まった技術的負債の返済計画（サーバーサイド編） - dely Tech Blog
「HTML解体新書」HTMLのこれからと向き合うための本 - クラウドワークス エンジニアブログ
『レガシーコードからの脱却』を読んだ感想 - 虎の穴開発室ブログ
「小さいアプリケーションの作り直しだし，すぐ終わるだろ〜」 - エムスリーテックブログ