架空の営業管理システムを作ってもらう前提で、ChatGPTに要件定義をお願いしてみました。 実験として軽く試すレベルで始めてみたのですが、予想を超えるクオリティでしたので、一部始終を皆様にもご紹介します。 ChatGPTとのやりとり まず、ざっくりと必要な機能の洗い出しをお願いしてみました。 あっという間に必要な機能を網羅的にリストアップしてくれまた。私自身、SFA/CRMをいくつか触った経験がありますが、適切な内容だと思います。 中には、「データのインポート・エクスポート機能」のように、検討初期段階ではつい忘れそうな機能も含まれています。さらに頼んでもいないのにオススメの検討プロセスまで教えてくれました。気が利いてます。 機能ベースだと要件の妥当性が判断しにくく思ったので、画面ベースで要件定義してもらことにしました。 「図で教えて」とできないことをお願いしたところ、やんわり断りつつ、意図

はじめに こんにちは！AWS事業本部のおつまみです！ 本日(3/1)に AWS Certified SAP on AWS - Specialtyに合格し、晴れて12冠達成しました！ AWS資格の人気は高く、私と同じように12冠取得するぞ！と意気込んでいる方も多いと思います。 そこで今回は私が取得に使用した学習コンテンツやモチベーション維持方法をお伝えしようと思います。 同じように資格取得に励んでいる方の参考になれば嬉しいです。 想定読者 AWS12冠を目指されている方 資格取得のモチベーションを維持したいと思っている方 12冠取得を目指した理由 私が12冠取得を目指した理由です。 2023 AWS ALL Certifications Engineersになりたかった。 AWSサービス全体の知識の幅を広げたかった。 クラスメソッドに入社したら全冠取得するものだと思っていた。 最初はミーハー

例3 : RDS なしパターン 上のミニマム構成パターンとほぼ同じですが、提供する AWS 環境から RDS を除くことも可能です。データベース不要な静的なキャンペーンサイトなどを動かしたい場合に最適です。 よくある質問 シンプル構築パッケージに寄せられるご質問について、よくあるものをこちらに記載します。 Q.EC2 や RDS のスペックは指定可能ですか？ A. はい、指定可能です。 シンプル構築パッケージではお客様にヒアリングシートへの回答をお願いするのですが、ヒアリングシート内で希望するサーバースペックについても回答いただくことが可能となっています。 Q.利用したい OS や DB エンジンがないのですが、対応可能ですか？ A. 対応可能なケースもございますので、まずはご相談ください。 EC2 の OS や RDS の DB エンジンは今後対応の幅を広げていく予定ですので、現在対応し

手順書フォーマットは千差万別 みなさんは自己流または、組織やプロジェクトで定められた手順書のフォーマットはありますか? 私は自己流の手順書フォーマットがあります。 自己流の手順書フォーマットがあるといっても、かなり扱いがふわふわしているので、備忘やメモの意味合い強めでまとめていきます。 「もっとこうした方がいいよ!!」などフィードバックがあれば、ぜひお願いします! いきなりまとめ 手順書はExcelやスプレッドシートではなく、Markdownで書く 手順書はgitで管理する 5W1Hを意識して手順書を書く 基本的にはCLIを使った手順書にする 手順書はExcelやスプレッドシートではなく、Markdownで書く 手順書をExcelやスプレッドシートで書くメリット・デメリット 手順書をExcelやスプレッドシートで書いている方も多いと思いますが、私はMarkdownで書いています。 Exce

開発時にはみなさん Git や GitHub を使うと思いますが、使い方についてチームメンバー間で微妙に認識の違いがあると進捗を妨げてしまいます。それを防ぐためにガイドラインを定めてみました。 ちなみにこれは CX 事業本部の Tech Lead のお仕事紹介第 1 弾のポストです。 この記事の英語版も書きました。 前提 CX 事業本部ではクライアントからの開発案件や自社サービスの開発をしていますが、その際に有用な（と考えている）ガイドラインです。 様々な事情でチームメンバーが変更になる可能性があり、新規メンバーの立ち上がりを支援する意味合いも込めています。そのため、開発効率をなるべく落とさずに効果的なスキルトランスファーが実施できることを主眼としています。 ガイドライン 定めたガイドラインの全文を貼ります。 3 つのセクションに分かれています。 commit 時のガイドライン avoid

バタバタ・・・ばたんっ！ リビングから響く遠慮のない生活音に眠りから引き摺り起こされる。ベッドの脇に落ちたスマホを手で探りあて、人工的な眩しさを遮るように薄く瞼を開く。 「（・・・５時１５分か。）」 通学に一時間かかる長女は毎朝この時間に起きてはバスケの朝練に向かう。部活の愚痴を吐くものの、それなりに楽しんでやってるようだ。 光というにはあまりにも弱い外の明かりをたよりに、ベッドの横に視線をやる。五歳と七歳のチビは何も聞こえた様子もなく、布団を蹴り飛ばした格好のまま寝ている。のせられた小さな足をそっと下ろし、また蹴り飛ばされるであろう布団をかけた。 もうひと眠りしようか、、などと考えながら再びスマホを手に取りアプリを開いた。 「（あぁ・・・アップデート出てんなぁ。。）」 「・・・」 ガバッ！ もう一度眠りへ引きずり込もうとする布団の温もりを断ち切るため、必要以上の大きな動作で身を起こし、そ

中山（順）です 先日に東京リージョンで比較的規模の大きな障害が発生いたしました。 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 障害の影響は特定のAZに限られていたことは上記の公式メッセージで説明されているとおりです。 また、障害発生の早い段階で単一のAvailability Zoneで問題が発生していることがService Health Dashboardでアナウンスされていました。 しかし、Design for Failureの原則に基づいてリソースを複数のAvailability Zoneで冗長化してるケースでも何らかの影響を受けたというケースもあったようです。（以下、その一例です） 8月23日のAWSの大規模障害でMultiAZでも突然ALB（ELB）が特定条件で500エラーを返しはじめたという話 これは、

1人もしくは（すごく能力の高い人だけの）少人数での開発と、大人数での開発ではプログラミングに対して気にするべきポイントに差があるような気がしています。 ここでいう大人数の開発とは、「プログラミングがどれくらいできるのか、自分が把握していない人がコードを書く可能性がある環境」を想定しています。 ここに挙げているポイントは「規模感に関わらず常に気にすべきこと」も含まれていますが、大人数になると特に問題が大きくなりそうなものをピックアップしてみました。 また、レビューに対する工数をすごくたくさんかけられる環境など、開発現場によっては当てはまらないものもいくつか含まれていますが、本記事ではあまり気にせず思いついたものを羅列しています。 本記事では基本的に「レビューでつぶす」という解決方法はあまり考慮していません。粒度によりますが、本当に厳密なレビューフローがないと、どこかのタイミングで読みづらいコ

監視という一種マニアックな領域を真正面から解説した貴重な本です。監視で悩む人のみならずシステム開発に携わるすべての人にオススメ。 「全然わからない。俺たちは雰囲気で監視をやっている」 自分はAWS事業本部コンサルティング部所属ということもあって、いろんなお客様にAWSインフラのコンサルティングしてます。最初のインフラ構成設計時に監視の話をすることも非常に多いんですが、 「どうしましょう。CloudWatchでいけますかね？」 「MackerelとかDatadogとかもありますが、どうしましょ。マネージドとの違いは〜」 「とりあえず、ディスク使用率80%でしきい値設定しておきましょうか。みんなそうしてますよ」 とか言っていた昔の自分に見せつけたい本、それが今回紹介する「入門　監視」。 監視設計の原則がよくわかんない メトリクスのしきい値決めるところから監視を考えてしまいがち よく考えずに、い

「ほんまに運用できるの？」毎秒6000イベントをミリsec対応するウェブサービスを、マルチクラウドで構築した話を聞いてきた #devsumi 最近、結構な頻度で聞くようになってきた「マルチクラウド」という単語。 いろんなクラウドの良いとこ取りができるのでメリットしかなさそうだけれど、運用・保守面含めて、「そんな簡単じゃないやろ〜」と一歩引いた視点で自分はみていました。 恐らく、Developers Summit 2018において、マルチクラウドというテーマで話されていたのは、このセッションだけじゃないでしょうか。 結論から言うとすっごい面白かったです。マルチクラウドで構成組む時に必ず出てきそうな問題点の解説もあり、非常に貴重なノウハウが満載なセッションでした。 __ （祭） ∧ ∧ Y　 ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉     ﾏﾙﾁｸﾗｳﾄﾞﾀﾞ ﾜｯｼｮｲ |_|＿| し'´Ｊ 講

本記事は当初SVNとGitの比較として「ブランチを用いた開発フロー」のメリット・デメリットについて記載していましたが、 「SVNでもブランチを利用できること」「分散型という言葉に対する記載の誤り」についてご指摘をいただきました。 そのため、ブランチを利用した開発フローに対して感じたことを焦点に記事を修正しております。誤った情報を記載していたこと、SVNに対して誤ったイメージをもつ可能性のある記載をしていたことに対し、深くお詫び申し上げます。 Gitをまともに使い始めて約二ヶ月がたちました。 特に、「ブランチをきる」「修正する」「レビューする」「マージする」という、おそらくGitで想定されている開発フローに沿っての開発はクラスメソッドに入社してからが初めてです。 6月に入社する以前は、開発用のソースコード管理には主にSVNを利用し、1つのバージョンの流れに全ての修正をコミットしていくフローで