誰も教えてくれないSIの本質、SIerの世界観
本記事について 国内の IT 業界について、ネット上では「SIer」VS「Web系」の構図がしばしば見られる。本記事は前者、SIer の世界観をひとりの当事者として雑多にまとめたものである。記事としては読み物、特にポエムの類。 対象読者 以下を想定する。 ITエンジニアまたはその卵で、 SIerを知らないWeb系の人 SIerに入社した新人や中途入職者 SIerにてSEまたはマネージャーして働いている者 SIerにてSEではないが裏方で働いている者（開発、研究、調査、教育、管理など） 学習や就労の初歩として参考にしてもいいし、議論やキャリアのダシに使っても良いだろう。 筆者について 吉良野すた: https://stakiran.github.io/stakiran/ 国内の大手 SIer に勤めるサラリーマン。現場には出ておらず、裏方で支えてメシを食べている。SI にも IT にもさほど
要件定義の目的とゴールとは - TRACERY Lab.（トレラボ）
TRACERYプロダクトマネージャーのharuです。 「要件定義とは何を目的としたプロセスなのか？なにが出来たら完了なのか？」 はじめて要件定義する人は、ここで詰まってしまうことが多いようです。 要件定義は、設計や実装に比べて、具体的な作業がイメージしにくいプロセスです。 そのような背景もあってか、2023年4月のBPStudy#188〜要件定義を学ぼう。ChatGPTを添えてに私が登壇した時の以下のスライドには、945個のはてなブックマークをいただきました*1。 speakerdeck.com 945というブックマーク数は、要件定義というものを具体的にイメージしにくいと感じている人が世の中に多いことの現れかもしれません。 そこで「要件定義とはそもそも何か」について、何回かの記事に渡って説明します。 この記事では要件定義の目的とゴールについて説明します。 プロジェクトの数だけ存在する開発プ
「1億台の常時接続」を実現せよ！ Nintendo Switchのプッシュ通知システム全面刷新の裏側 (1/3)
アマゾン ウェブ サービス ジャパンは、2024年6月20日と21日、国内最大の年次イベントである「AWS Summit Japan」をハイブリッドで開催。150を超えるセッションが展開された。 本記事では、ニンテンドーシステムズによるセッション「Nintendo Switch向けプッシュ通知システムのリプレイス事例」をレポートする。登壇したのは、同社 システム開発部の林愛美氏と坂東聖博氏だ。 2017年のNintendo Switchの発売とあわせてリリースされた「プッシュ通知システム」。同社は、長期運用を見据えて、よりクラウドネイティブなシステムへのリプレイスを決定するが、大量のTCP接続を維持するための様々な課題が立ちふさがった。 本セッションでは、AWS FargateやNetwork Load Balancer（NLB）といったAWSのマネージドサービスを用いた、“最大1億台”級
ミノ駆動さんに「なぜ負債解消にDDD？」と聞いたら、ソフトウェア開発の本質に気づかされた
ミノ駆動さんに「なぜ負債解消にDDD？」と聞いたら、ソフトウェア開発の本質に気づかされた 2024年1月15日 株式会社スタメン ミノ駆動（仙塲大也） 電子機器メーカーや大手精密機器メーカー、クラウドワークスを経て、2021年4月にREADYFORに入社。アーキテクチャの変更容易性や機能性を促進する設計構造を目指し、リファクタリングやドメインモデリングを主軸としたシステム設計に従事する。現在は、組織改善のためのエンゲージメントプラットフォーム「TUNAG」を擁するスタメンに在籍。ITエンジニア本大賞2023技術書部門大賞を受賞した『良いコード/悪いコードで学ぶ設計入門』著者としても知られる。 X（@MinoDriven） note Qiita 株式会社スタメン・テックブログでの執筆記事 ドメイン駆動設計（以下、DDD）に注目が集まりだしてしばらく経ちますが、いまだに捉えづらさを感じている人
実践：はじめてのWebAPI設計 - Qiita
はじめに この記事はAPIの基本的な実装方法を丁寧に解説します。基礎を学びたい方、今更聞けないような知識の振り返りを求める方の役に立つことを願っています。もう十分理解できている！という方は、目次から実装にとんでみてください。 具体的にはHTTPと呼ばれる通信方法を利用した、シンプルな本の貸し出しシステムの土台を考えます。要件の各ステップで、設計の基本原則やベストプラクティスについても触れながら、より実践的な知見を共有できればいいなと思います。 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 基本用語 Webに関する基礎知識の解説記事はQiitaに豊富にあったので、要点を抑えつつリンクをまとめました。 WebAPI Web
実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
サブスクリプション課金システム開発ケーススタディ - inSmartBank
世はまさに大サブスクリプション時代。この潮流の中で弊社スマートバンクもまた、去る2023年7月12日にB/43プラスというサブスクリプションサービスをリリースしました。 サブスクリプションといえばユーザーに提供されるコンテンツや機能といった直接的な価値に焦点が当たりがちですが、その土台にはサブスクリプションビジネスを成立させるための課金システムがあります。本記事では筆者が行った課金関連の開発を振り返ってみて重要だったポイントや工夫点を伝えてみたいと思います。 すでに世に多くのサブスクリプションサービスがある中で、課金システムの実装はコモディティ化した単純な作業に思えるかもしれません。しかしながら自社サービスにてゼロから実現するとなると、想像よりも多くの思考と意思決定が必要とされる、エンジニアリング観点ではとても奥深い題材といえます。いち開発プロジェクトのケーススタディ、あるいはいちプログラ
【入門】要件定義
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、(駆け出しですが)要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像 一般的なシステム開発のプロジェクトは下記のフェーズで進んでいきます。 ※ コンサルの領域だと要件定義の前に企画構想とい
【テンプレ付】chatgptを使ってツールの要件定義をしたら工数が40時間→4時間になった - みんなのシステム企画
「chatgptを使って要件定義の工数を削減したい」 「そもそもchatgptを使って質の高い要件定義ができるのだろうか」 とお悩みなのではないだろうか。 結論、chatgptで質の高い要件定義を短時間で実現することは可能だ。 実際に私もchatgptを使って下記のような要件定義書を完成させた。 通常この要件定義書を０から自力で作ろうと思うと４０時間はかかるが、chatgptを使う事によって４時間で完成させることができた。 しかし、ただプロンプトをなんとな投げ掛ければ良いというわけではない。 目的を達成するために綿密に設計をしたプロンプトを投げかける必要がある。 また、要件定義の中でも ・chatgptに丸投げして良いところ ・自分で手直しをした方が良いところ を精査することも大切だ そこで今回は上記のような要件定義書を4時間で完成させるために、私がchatgptへ投げかけたプロンプトを全
わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
【翻訳】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分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
設計書・仕様書のレビュー方法を定めたJIS規格登場 チェック体制を標準化しやすく
経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。 「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。 レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている
AWS、何から勉強したらいい？に対する俺の答え - Qiita
このツイートがわりと好評だったので解説。 「AWS、何から勉強したらいい？」に対する俺が考えた回答がこれ。 pic.twitter.com/ouuP3P27Bu — 伊藤 祐策(パソコンの大先生) (@ito_yusaku) 2018年4月17日 これは誰向け？ メンテナー以上の領域を目指す人向け。 オペレータ ... システムの運用、監視、障害調査＆対応をする人 メンテナー ... システムの拡張、改善をする人 アーキテクト ... システムを１から設計、構築する人 解説 各科目の選定基準 必修科目 ... AWSを本番運用するにあたって絶対に避けては通れないサービス。 重要科目 ... 間違った設計をすると、あとから取り返しがつかないサービス。 選択科目 ... 学習量を削るために仕方なく必修から外したが、Webサービスを構築するにあたりほぼ必須となるサービス。 必修科目で押さえておく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
1,000行で作るオペレーティングシステム
実践Terraform＠tmknom on Twitter: "すげーリポジトリ見つけた。Webサービスのシステム設計が学べる。日本語もある。システム設計ってどうやって学ぶのが効率いいんだろうって思ってたけど、コイツを出発点にするのはアリな気がする。 https://t.co/1YMBP9UMHo"