情報処理推進機構（IPA）は9月30日、経済産業省が立ち上げた「レガシーシステムモダン化委員会」の説明資料を公開した。2023年10月に発生した全銀ネット障害や、24年4月に起きた江崎グリコのシステム障害を問題事例として挙げ、レガシーシステムが抱える課題などをまとめている。 公開したのは、9月12日に開催したレガシーシステムモダン化委員会の第1回会議の資料。同委員会は、産業界がレガシーシステムを脱却するために、その現状や課題を明らかにして対応策を検討するために立ち上げた。 資料では、レガシーシステムからの移行が進まない企業について「経営層の関与が薄く、改修して利用し続けた方が安全であると判断される割合が多い」と指摘。社内に設けた情報システム部門についても「これまでの付き合いのあるベンダー企業からの提案をそのまま受け入れてしまいがち」などの課題を挙げている。

はじめに こんにちは、Watanabe Jin(@Sicut_study)です。 今回は記事1本で初心者が必要な知識を全て学べるGitチュートリアルを紹介していきます。 世の中にはたくさんのGitに関する教材があります。しかし、真に良いと思える教材はありません。 もちろん私も4年前はGitという言葉を知らない状態から、書籍などで学習をしました。 しかし、書籍で知識を得たとしても実際にコマンドを使って実践的に学んだわけではなかったのでほとんど身になりませんでした。 私が思う世の中にあるGitの教材のイケてない点は2つです。 結局ほとんどの人が、教材ではなく実際に使ってみて使えるようになっているはずです。 書籍でやったことを全部ちゃんとできるようになった人はいないと考えています。 実際に利用するコマンドは限られている、たまに使うコマンドを紹介しとしても「この記事1本」で説明することができると思

こんにちは。レシピ事業部バックエンド基盤グループの石川です。 2014 年、このブログに『開発環境のデータをできるだけ本番に近づける』というタイトルの記事が投稿されました。 クックパッドでは、ユーザーさんが実際に体験している状況と近い状況を再現しながら開発することに価値があると考えています。技術的には、最初からレコードがたくさんあることによってパフォーマンス問題に気付きやすくなるなどの長所がありますし、サービス開発としても、実際のユーザーさんの体験を最速でなぞって素早くフィードバックループを回せるようになるという長所があります。 この慣習は 2014 年の記事から 10 年経った今でも続いています。一方でその実現手法については変化を続けてきました。現在のクックパッドでは状況に応じていくつかの手段を使い分けています。それらの手段については今まであまり公開されていなかったような気がするため、こ

技術的負債をうまくマネジメントすることは重要です。なぜなら、持続可能な長期的な利益の確保こそが競争戦略における目標であり、技術的負債への対応力はその目標に近づくための重要な組織能力だからです。EMとして組織の成果の最大化を目指す上で避けては通れない課題です。また技術的負債への対応は、単に技術的な課題ではなくそれらを包含するプロダクトの課題です。どうやって解決するかだけでなく、なぜ、いつ、どのくらいやるべきかを、事業責任者などのステークホルダーと合意して初めて対応を進めることができます。こうした課題に対しては、多職種をつなぐメンタルモデルの構築、方向付け、ファシリテーションといったソフトスキルが必要になってきます。EMはエンジニアリングの視点とそうしたスキルを併せ持つことが期待される存在で、技術的負債への対応においても重要な役割を担うと考えています。本記事では、技術的負債をマネジメントする方

こんにちは。 2024/7/1 からファインディに入社した斎藤です。 ファインディでは、Findy Team+ という、エンジニア組織の開発生産性を可視化し、開発チームやエンジニアリングメンバーのパフォーマンスを最大化するためのサービスの開発に携わっています。 今回は、私が入社初月からさくさくアウトプットできた理由についてご紹介します！ 入社初月からプルリク1日4件出せました ファインディでは1日あたり4件プルリクを作成するというのを1つの指標としています。 入社直後は慣れるまでは結構厳しい指標だなと思っていたのですが、この記事で紹介する様々な仕組みのサポートもあり気がついたら初月から達成できていました。 中途入社あるあるだと思いますが、入社直後になかなか成果が出せなくてプレッシャーを感じてしまうということがあります。 簡単なタスク中心ではありますが、初月から貢献しているという実感が持てた

はじめに こんにちは。データシステム部/推薦基盤ブロックの佐藤 (@rayuron) です。私たちはZOZOTOWNのパーソナライズを実現する推薦システムを開発・運用しています。推薦システムごとにKPIを策定していますが、データの欠損やリリース時の不具合によってKPIが意図しない値を取ることがあるため定常的に確認する必要があり、これをKPIのモニタリングと呼んでいます。 先日、推薦システムの実績をLookerでモニタリングするというテックブログで推薦システムのKPIをモニタリングする方法を紹介しましたが、運用していく中でいくつかの課題が見えてきました。本記事では、より効率的かつ効果的なKPIのモニタリングを実現するための取り組みについて詳しくご紹介します。 はじめに 改善の背景と課題 背景 課題 トレンドを考慮した異常検知が不可能 モニタリングの設定が面倒 アラート対応フローが不明確 サマ

こんにちは。LINEヤフー株式会社でデータベースエンジニアをしている、松浦、中園、大塚、曽根、笠井です。 データベースはLINEヤフーのさまざまなサービスを支える重要なソフトウエアですが、その安定的な運用やトラブルシューティングには、データベースに関する専門的な知識が必要です。 一方で、データベース部門に配属される新卒のエンジニアは、全員が学生時代にデータベースを専門的に勉強しているわけではありません。このような新卒エンジニアは、データベース部門へ配属後、OJTや実際のデータベースの運用業務に携わりながら、データベースに関する専門知識を深めていきます。 今回のブログ記事では、データベースエンジニアとしての専門性を高めるために、部門内で実施している専門書の輪読会、そして、MySQLを題材としたデータベースカーネルのモブプログラミング（以下、モブプロ）の取り組みについてご紹介します。 1. 輪

相手に話が通じず物事を前に進めにくいと感じることがある。特に、階層化された組織の違うレイヤーの相手や他部署の相手の場合にありがちかもしれない。 そういう時はついついヒートアップしてしまい相手のせいにしてハレーションを生むような話し方をしてしまいがち。"相手が理解してくれないのは相手の頭が悪くて理解できないから"みたいな態度は相手に伝わり、関係がこじれてより一層物事を前に進めにくくなってしまう。 こういう時に感情的になってうまく対処できないのは解決のための引き出しが少ないのが原因なので、思いつく対処法を雑に書きとめておく。 いったん自責思考に切り替える あまりに話が通じないと感じると自分の方が賢くて相手が悪いみたいなスタンスになりがちなのでまずはリセットする 相手に勝とうとするのではなく、目的を思い出して相手も自分も勝つにはどうすればよいかを考えるよう切り替える ほぼ相手に非があることももち

リクルートで売れる営業と売れない営業の差を見える化 西舘聖哉氏（以下、西舘）：このあとのパネルディスカッションでは、（営業とマーケティング部が）どう歩み寄っていくのかというお話ができればなと思っています。ではまずは、加藤さんのお話に入っていきたいと思いますので、お願いします。 加藤じゅういち氏（以下、加藤）：みなさん、こんにちは。加藤じゅういちと申します。私のバックボーンはリクルート、外資のディーラー、ベンチャーの役員、そのあと独立という大きな流れです。 リクルートには21年半おりました。もともと最初は営業ではなく、HR事業、求人広告の部門で制作ディレクターをしていました。営業の後工程で制作物を作るという、クライアント企業の広告を作る部門でした。 ここにいた時に、よく営業に同行してヒアリングやプレゼンをやっていたんですね。中島さんは営業からスタートということですが、私は営業からではなくて制

2024年9月18日開催「一休×AEON 事業会社のサービスを支える基盤開発トーク」の登壇資料です。 https://ikyu.connpass.com/event/327095/

1. 汚いコード、クソコードは意図して作ってる訳ではない 以下の記事に、とてもよいと感じた箇所がありました。 よほど悪意を持った人でない限りは、意図的に汚いコードを書こうという人もいません。単純に良い習慣が身についていないだけで、悪意はなくても汚いコードになってしまう、という事はよくあります。個人的には、ほとんどがごく単純に知識の問題であると感じています。 よくプログラマーの間で、現場でひどいコードがあると喚いたりすることがあります。 でも、前述の通り、別に悪意をもってそうしているわけではないし、その人の知識量や経験、そして、案件の忙しさなどによって結果的に汚いコードになることはあります。 コードそのものを批判するのはいいと思いますが、コーダーを責めるにはいろいろな背景を配慮する必要があるし、外野からSNSで晒して喚くものではないと感じます。 とはいえ、プログラマーを職業としてするからには

はじめに エンジニアのみなさま、日々の学習本当にお疲れ様です！ また本記事まで足を運んでいただき本当に感謝です。 約3分程度で読めるので最後まで読んでもらえると幸いです。 要件定義関連の記事の投稿をしました。時間あればぜひ読んでみてください。 今回は「非機能要件」の 可用性 性能・拡張性 運用・保守性 移行性 セキュリティ システム環境・エコロジー の6項目について理解を深めてアウトプットしようと思います。 非機能要件｜6項目について 1. 可用性 システムが継続して利用可能な状態を維持する能力を指します。『稼働率』 で表現されます。システムは定期メンテナンスや予期しない障害により、一時的に利用できなくなることがあります。可用性は、稼働している時間と停止から復旧までの時間の割合で決まります。たとえば、Amazonの「Amazon ECS」サービスは 『99.99%』 の稼働率を保証しており

# 参考資料 - https://gist.github.com/voluntas/9c1d9d51e86a853fed6889f743a12145 - https://amzn.to/4ewrbw7 - https://amzn.to/3XzYYh4 - https://www.ipa.go.…

概要 目次 Pythonでデータに重複があるか確認する方法 PyCon JPが不正をしていない理由の解説 本記事では、Pythonで重複したデータを集約する方法、及び、機密情報を隠して集計をするための手法について解説します。 本記事で紹介するコードは投票結果の集計やアイデアの集計などで有効に使うことができます。 内容に誤りがありましたらご指摘ください。 本記事は、今後の健全なコミュニティの発展に必要不可欠な情報であるため、健全な技術コミュニティの発展を目指す情報交換プラットフォーム、Qiita.comにて公開します。 Pythonでデータに重複があるか確認する方法 リスト形式の場合 Pythonでリストから重複があるか確認する3種類の方法を紹介します。 重複の有無をbool値で出力します。 外部ライブラリ、cythonを使わない場合、データの分布に関する事前情報がない場合はこれらの方法が有

はじめに 時間管理が上手くなりたいと日々思っているため、このテーマにしました。 自戒の念を込めて😅 タイムマネジメントの王に!!! おれはなるっ!!!(CV.田中真弓) ※掲載内容は個人の見解であり、所属する企業を代表するものではありません。 参考にした書籍 『エンジニアのための時間管理術』 Thomas A. Limoncelli　著 株式会社クイープ　訳 発行年月日：2006年10月 ページ数：272 ISBN：978-4-87311-307-4 タイムマネジメントについての考え方や手法を取り入れたいと思い読みました。 時間管理した先のゴールは？ 自分のための時間・家族との時間を最大化する。 前提 エンジニアはタイムマネジメントが難しい。 プロジェクトワークと割り込みが入り混じる職業。 外部からの割り込みは生産性を低下させる。 中断した作業に戻るには時間がかかり、エラーが紛れ込む可能

総当たりする所要時間を考えると、9桁以下や10桁でも文字の組み合わせに記号がないと、危険ですね。 尚、同ガイド「インターネットの安全・安心ハンドブック」には、第6章でパスワードに関することのみにフォーカスした章があり気になる方にはおススメです。 パスワードの使い回し禁止の人力は現実的? パスワード長く記号も使おうはわかったよと、そして次の節が「使い回しはだめよ」です。使い回しがだめなら単に最後の文字だけ変える、これもだめです。 それが、だめなのはわかるのですが、わかりますが長くて複雑かつ使い回さないものは覚えられないですよね、私は電話番号という数値のみの10～11桁をよく使うものなら覚えられ、それ以上は厳しいです。 覚えられないパスワードは保管して、適時利用することが推奨されます。次の節でその方法について説明します。 「ノートに書く」? 必要に応じてノートを開く、そこに複雑な文字列がある.

例えば要件定義の期待値は、上記の計算式に当てはめると (0.5 + 4×1 + 2) / 6 = 1.17時間になります。 類推見積もり 具体例 「Aという機能を持ったシステムを開発するのに、前回は3ヶ月かかった。今回のシステムも機能が似ているので、今回も3ヶ月程度で開発できるだろう。」 特徴 過去の類似プロジェクトのデータに基づいて見積もるため、迅速に概算を出すことができます。 （これ、実はみなさん日常で何気なくやっているのではないでしょうか？？） 注意点 今回のプロジェクトと過去のプロジェクトが完全に同じであるとは限らないため、誤差が生じる可能性があります。 ボトムアップ見積もり 具体例 システム開発プロジェクトの場合 要件定義：1週間 設計：2週間 プログラミング：4週間 テスト：2週間 総合計：9週間 特徴 プロジェクトを細分化して見積もるため、より詳細で正確な見積もりが可能です。

1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ

♪ピンポーン あなたは今、幸せですか？ APIの教えを身につければ必ず救われます。 ぜひ話を聞いていってください。 APIが好き Web API（以下「API」）って、それ単体で部品としていろんな人に使ってもらえたり、いろんなフレームワーク上で使われたりして、汎用性が高いのでとても好きです。 仕組みとしてはとてもシンプルですが、モバイル開発が普及した現在においてもかなり重要な役割を担っています。 対象読者と参考書籍 本記事の対象読者は、Web開発に関する基本的な知識がある方です。 「API(REST API)とは何か」や「HTTPってなに？」といった内容は含みません。 ただ、今回参考にさせていただいたオライリー・ジャパンの「The Web API」はそういった基本的な部分から応用まで幅広く記載されています。 古い書籍ですが、かなり役に立ちました。本当におすすめです。 今回は本書籍の１~３章

はじめに こんにちは、Watanabe JIn(@Sicut_study)です。 突然ですが、私には不思議に思うことがあります。 なぜ同じタイミングでエンジニアになったのに、気づいたらスキルに圧倒的な差がついてるのか？ もちろん努力量が違うというのもあるかもしれません。しかし、効率よく学習をするにはテクニックが存在します。 この記事では効率よく学習することをタイパのよい勉強法として紹介します。 「コスパのよい勉強法」に関してはネットに調べれば多くあります。それは本当に効率のよい勉強法はある程度やり方が決まっているからです。ここでは、考え方に加えてエンジニア向けにどのようにやるのかも説明します。 この記事を読むことで、短期間で大きな成果を出している人がどのような学習をしている秘訣を理解することができます。 モチベーション 短期間で成果を出す勉強法をしている人々は世界中に多くいます。 彼らは1