江崎グリコの公式サイトより ほぼすべてのチルド食品（冷蔵食品）が、社内のシステム更新作業に伴う障害により出荷停止となっている江崎グリコ。4月初めに障害が発生し、出荷再開時期がいまだに未定という異例の事態を受け、同社は今月8日、システム障害によって2024年12月期の営業利益が60億円、売上高が200億円下押しされる見通しだと発表した。業績に多大な悪影響が生じるため、グリコがシステム更新プロジェクトの主幹ベンダであるデロイト トーマツ コンサルティングに損害賠償を求めて法的手段を取る可能性も取り沙汰されている。今後の展開について業界関係者や専門家の見解を交えて追ってみたい。 グリコは業務システムについて、独SAPのクラウド型ERP「SAP　S／4HANA」を使って構築した新システムへ切り替えるプロジェクトを推進してきた。旧システムからの切替を行っていた4月3日、障害が発生し、一部業務が停止。

新規でRailsプロジェクトを始める時の個人的な環境構築についてまとめる。前提とする条件等は下記。 規模: ~中規模 開発者数: 個人 利用シーン: PoC作成・スタートアップ立ち上げ・並の業務アプリ開発等 基本戦略 利用シーン的に「思い立ったらすぐアプリの開発ができる」という感じの運用がしたい。極力セットアップで悩みたくないから必要なミドルウェアなどは全部Dockerでインストールできるようにして立ち上げれば終わり、の環境を作る。その環境の中で色々とコマンドを叩いたり、rails newやrails gなどでRailsアプリを作成していく。 この辺のRailsの初期セットアップの手間を出来るだけ省きたいのでtemplateとなるリポジトリを作成し、そこからcloneしてくるだけでOKにする。 フロントエンドはReactなどを使わずをRails標準のerbとHotwireを軸に開発する。開

本記事では、1日目におこなわれた『龍が如く7 光と闇の行方』（以下、『龍が如く7』）のデバッグに関するセッション“「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム”をリポート。 セッションには、セガのQAエンジニア・阪上直樹氏と、ビルドエンジニアの粉川貴至氏が登壇した。 バグをハグしたくなる自動システム！ まずは阪上氏が開発者たちへ向けて、「バグは好きですか？」という質問からセッションがスタート。最初に龍が如くスタジオの各タイトルで、バグを発見した数の推移が公開された。ゲームの規模が大きくなるにつれ、バグも増加傾向にあるという。 そして全自動バグ取りシステムを運用した『龍が如く7』では、なんと25000ものバグが発見されたという。こう見るとネガティブな印象を受けるかもしれないが、バグ発見数が多ければ多いほど、ゲームクオリティがアップするということだ。 バグとい

2024年1月時点のAWSベストプラクティスに従って作成しました 好評でしたら続編も検討します 1. 環境ごとにアカウントを分離する 本番、検証、開発ごとにアカウントを分割しましょう ✕良くない例 ◎良い例 最初にアカウント分割しておかないと、後で分割するのはとても大変です アカウントを分割することで「検証と思って作業したら、実は本番だった」のような事故を減らすことができます コストがアカウント単位で集計されるため、環境ごとのコストを簡単に算出することができます AWS Organizationsを使用することで、各環境に応じた権限設定が簡単にでき、ガバナンスを強化することができます AWSアカウントはAWS Control TowerのAccount Factoryを使用することで、クレジットカード情報を都度入力することなく簡単にアカウントの払い出しが可能です また、AWS Contro

オランダのゲーム開発会社で、2D、3D、サウンド、UIなどゲーム制作に使える170種類以上のフリー素材を提供しています。 各素材は商用・非商用に関わらず自由に使えます。詳しくは、各素材の利用規約をご確認ください。 Kenney『Kenney』利用規約CraftPix

個人開発エンジニア集まれ！~個人開発LT会~ #3 ( https://individual-development.connpass.com/event/303818/ ) で発表した内容です。

参考記事: https://www.bannerbear.com/blog/why-you-should-do-50-coding-and-50-marketing-as-a-solo-tech-founder/ ポストック: https://postock.app/

アプリ開発者の収入調査 Vision Movileよりアプリ開発者を対象にしたレポート「Developer Economics – State of the Developer Nation 2015Q1」が発表されました。調査によるとトータルで無収入だった人は全体の17％、100ドル（約12,100円）以下の人は18％と全体の3割ほどが1万2千円以下であると報告されています。（2015年当時の円相場で算出しています）。1万ドル（121万円）以上は全体の24％いることから、1/4の人は大金を手にしていることになります。 またiOSやAndroidと比較すると、月間100ドル以下の割合はiOSが全体の37%、Androidが55%とAndroidが18ポイント多い結果となり、利益に結びつきにくい結果となりました。調査結果の時期が古いためご参考までにご覧ください。 アプリ開発者の事例 実際、ア

こんにちは、吉岡(@yoshiokatsuneo)です。 paizaでは、S・A・B・C・Dと5つのランクにわかれたプログラミングスキルチェック問題を公開しています。 スキルチェック問題を解いてこのランクを獲得することで、paizaでは、最初の書類選考なしで求人応募ができるようになっています。 paizaは、ユーザーのプログラミングスキルをより正確に評価できる方法を探し続けており、今回、「エンジニア戦闘力」「レーティング」という数字でスキルを可視化する方法を実験的に取り入れることになりましたので、どのようなものかご説明していきます。 ※記事公開時（2019/09/10）はβ版として「エンジニア戦闘力」という数値も用いていましたが、2019/11/21公開の正式版では「レーティング」に統一されました。 スキルランクの課題について 従来のスキルランクはわかりやすいのですが、場合によっては以下の

はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる

はじめに 個人サービスを公開するまでに必ずやるべきことがあるのですが、思い出すのに時間が掛かってしまったり、「事前にやっておくべきだった...」と毎回思います。ここら辺の情報は調べてもまとまっている記事がなかったので私なりにチェックリストとしてまとめてみました。難しいことは一切なく（経験者には当たり前なことかも？）、比較的簡単に出来るものを書かせて頂きますので気軽に読んでいただけると嬉しいです。 前提 僕は個人サービスを公開する上で集客に重きを置いています。後述するやるべきことは集客をベースとした内容であり、サービスを利用する上で必ず必要ではないということをご理解ください。また、WEBの要素が強めなので、モバイルアプリ等の開発者は参考にならないことが多いと思いますのでご了承ください。参考までに僕が個人開発しているサービスです。Gmailのようなツール寄りのサービスではなく、キュレーションサ

この記事では個人開発者として起業し、1年間サービス開発、運営をしてみたかずうぉんばっとが実際に経験した落とし穴を9つ、こうすれば穴を回避できたんじゃないかなというアイデアと共にご紹介します。 これから個人開発者、エンジニアからの起業を考えている方の参考になれば幸いです。 日程調整のニッテについて 先に簡単に自分が開発しているサービスについて、ご紹介させてください。 日程調整のニッテという使いやす〜い日程調整ツールです。ぜひ一度お試しください！ 新規事業開発には落とし穴がいっぱい では本題です。まずは以下の図ををご覧ください。 新規事業開発の流れはざっくり3つのフェーズ+メンタルケアに分かれます。 課題発見: 解くべき課題を見つける 課題解決: 課題を解決するようなサービスを作る 集客: ユーザーを集めて収益化する メンタルケア: 全てのフェーズで精神状態を保つためのケア 一見シンプルな流れ

よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を

2021年11月10日と11日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2021」がオンラインで開催されました。そこで竹下秀則氏が、大規模クライアントアプリ開発チームの生産性を改善した仕組み化について紹介しました。まずはチームの成長と課題について。 LINEのクライアントアプリ開発チームの効率化事例 竹下秀則氏：みなさん、こんにちは。今日は「大規模クライアントアプリ開発チームの生産性を改善した仕組み化の数々」というタイトルでお話しします。LINE福岡開発1室所属のエンジニアリングマネージャー、竹下と申します。よろしくお願いいたします。 さっそくですが、本日のアジェンダはこちらになります。まずは私がマネージャーとして所属している、今日お話しする改善の舞台となったチームについて紹介します。 次にそこで直面した課題の数々について赤

最近，仕事で使うことがあってたまたま気がついたのだが， PlantUML って JSON や YAML のデータを視覚化できるんだね。 やり方は簡単。たとえば { "firstName": "John", "lastName": "Smith", "isAlive": true, "age": 28, "address": { "streetAddress": "21 2nd Street", "city": "New York", "state": "NY", "postalCode": "10021-3100" }, "phoneNumbers": [ { "type": "home", "number": "212 555-1234" }, { "type": "office", "number": "646 555-4567" } ], "children": [], "spous

サーバ業務周りの管理、運用について役に立ちそうなナレッジをまとめました。 長期的に書いているため用語に統一性がなかったり、不足分など随時修正したいと思います。 1. サーバ設計 サーバスペックはどうするべき？ 使用するOSは？ CentOS開発終了について MWは何を使うべきか Webサーバ構築にはどちらを使うべき？Apache？Nginx？ サーバセキュリティで最低限押さえておきたいことは？ listenするポートは最小限にしましょう ファイアウォール設定で送受信IPアドレス、ポートの通信制御はしておきましょう 外部に出る際にはプロキシサーバを経由するようにする 随時パッチを当てるようにする linuxでのアンチウイルスソフトの検討 個人アカウントで変更系コマンドは実行させないようにする ログについて考えること ストレージ容量には気をつける データベースはどう決めたら良いか MySQLか

みなさんこんにちは。@ryuzeeです。 以前書いたスクラムマスターを雇う時に聞いてみるとよい38個の質問という記事に対して、自分も答えてみましたので、以下で紹介します。 なお、既に38個答えた勇者がいるのでこちらも併せて読んでみるとよいと思います。 「スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えた@katzchang/回答-スクラムマスターを雇う時に聞いてみるとよい38個の質問それでは、行ってみましょう。 スクラムマスターの役割についてアジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？スクラムマスターの関与の度合いはチームの力量や規律の有無、外部との関係性などによって変わります。 チームが自分で解決できない大きな問題をかかえていたり、チームとして機能していなかった