要件定義～システム設計ができる人材になれる記事 - Qiita
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間
ガラケーに「2020年問題」発生、設計仕様に潜んでいた不具合の真相とは
報告はいずれもKDDIと沖縄セルラー電話が2000年代後半に発売したソニー・エリクソン・モバイルコミュニケーションズ（現ソニーモバイルコミュニケーションズ）製の端末に集中しているもようだ。2006年に発売した「W43S」や2007年発売の「W53S」、2008年発売の「W64S」や同機種をベースにした「S002」のユーザーが、「時計が0時0分で止まった」といった症状をソーシャルメディアに投稿している。 いずれの機種も3G（第3世代移動通信システム）までにしか対応していない。このためKDDIが2022年3月末に3Gサービスを終了すると携帯電話としては使えなくなる。KDDIは「ユーザーの報告などで事態を把握した。メーカーに問い合わせ、原因の調査や対応の協議を始めた」（広報部）としている。現象が起こっている機種の特定も進めているという。
https://blog.animereview.jp/zero-trust-architecture/
シンジです。社内インフラを構築するとき、何を指標として設計しているか、何のために作るのか、誰が嬉しいのかを考えずに淡々と予算を投入している企業の多いこと多いこと。これから会社を作るならまだしも、既存企業は長年の蓄積があるわけです。物理機器や、買収合併の弊害、シャドーITに働き方改革推進の圧力。これらに個別的に対処することこそが無駄かつ自己満足なので、自社のインフラはどうなるべきだったのかを考えたい物です。 ITは企業にとってコアである 企業や組織運営において、ITを使うことで便利になったり、効率が良くなったりする程度の時代はとっくに終わっています。企業や組織からIT全てをとっぱらってしまうと、企業や組織が消え去る可能性が非常に高い、というか確実に死ぬであろう状態にまでITに依存しています。つまり現代においてはITはコアなのです。 情報システム部門はその重要性を理解していない 企業においての
『東京タワー』の建設フロー、PM視点でみてヤバすぎたので解説｜Shoko Suzuki
はじめに ： Who I amこんにちは、建設×ITのスタートアップ「シェルフィー株式会社」でプロダクトマネージャーをしているShoko（@shokosuzuki1991）です。本日noteデビューしました！👏 先日参加した『建設職人甲子園』というイベントで、東京タワー建設時のエピソードが紹介されてたのきっかけに、『東京タワーができるまで』を調べれば調べるほど、すごすぎる！ヤバすぎる！となったので、今回はそのあたりをPM的な切り口でまとめてみました。 （※なるべく事実に忠実に書いてますが、一部わかりやすくする表現を優先しているところもあります。予めご容赦ください🙏） 1.構想の大胆さがヤバい 東京タワーが完成したのは1958年です。当時は爆発的なテレビの普及が予想される中で「このまま各局独自の電波塔が増えると、東京中が電波塔だらけになって景観が悪化する」という問題を抱えていました。 そ
ギットハブ
ギットハブ ギットハブは、ソフト開発者が設計図を公開・共有できるサイトです。 ギットハブの歴史 ギットハブは2008年の設立で、スマートフォンの普及などとともに、無償公開し自由に改良できる「オープンソースソフトウエア」の開発や普及の基盤になってきました。開発者同士が情報をやりとりするソーシャル・ネットワーキング・サービス（ＳＮＳ）の機能も果たしています。 JSONについて 当ウェブサイトでは、個人情報を取得するために「.JSON」という聞いたこともない拡張子のファイルを利用することはありません。 セキュリティ証明書について 当ウェブサイトでは、サーバ証明書の切り替えに伴いルート証明書のインストールをユーザへ案内することはございません。 ギットハブ.comではなく、github.comをお探しの方はこちらへどうぞ。 ギットハブ.comではなく、ギットハブ.コムをお探しの方はこちらへどうぞ。
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
設計書の意味をもう一度考えてみろよ - masayang's diary
katzchangのつぶやきで、オブジェクト指向開発を理解した開発者に、設計書は不要という両記事を知る。書かれていることは特に目新しくない。前から言われていることだし別にオブジェクト指向に限った話でもなかろう。→The Source Code Is The Design 2009年2月23日に書いた記事より再掲: 今更ながら「設計ができる」人に問いかける その「設計書」なるもので、本当にコード書けるの？ 「書ける『はず』」ってのは「書ける」のとは違うよ。 だが、はてぶに寄せられた意見にはなんだかな〜と思わせるものも目立つ。 これは一緒に仕事したくない人だ。UMLも書きたくないのかな →UMLからコード起こせるの？ Really? この記事は酷い。この著者は10年間で何をしてきたのか？偏った開発経験しかしていない気の毒な開発者。 →ただしい開発現場で経験を積んできたようにしか見えないが...
2010年現在のアクセスレベルの限界 - プログラマーの脳みそ
前提条件を破った場合、どのような挙動をするのか？ - 都元ダイスケ IT-PRESSで言及をもらったので 現代は４つのアクセスレベルでの可視性制御の限界が囁かれていて、打破するためにいろいろ模索しているところ はてなブックマーク - Nagiseのブックマーク / 2009年12月24日 についてちょっと具体的な話をしておこう。 このブックマークコメントは可視性と公開APIと非公開(内部)APIと - 都元ダイスケ IT-PRESSに対してつけたものだった。このエントリは設計する際にJavaの4つのアクセスレベルをどう使い分けるかを書いた良エントリだと思う。 privateで困る例：自動テスト JUnitといった自動テストコードを書くことを考えてみよう。クラス内だけで再利用される冗長コードをprivateメソッドとして括り出した。このメソッドが単体独立で動作検証が可能なのであれば、そのI/
複数カラムレイアウトをどう活かすか (ユーザビリティ実践メモ)
本実践メモでも以前に取り上げたように、ここ数年、横幅900px以上を採用するサイトが増えてきています。 画面横幅を900px以上にするメリットとデメリット。右端が欠けることに注意 横幅の拡大によって、情報を掲載できるスペースは拡大し、実現できる表現の幅も広がります。 もちろんそれらは喜ばしいことですが、自由度が増すからこそ、効果的なスペースの使い方をきちんと考えることがますます重要になります。今回はカラムを複数に切ったレイアウトについて、スペースをどのように活かすべきかを考えてみたいと思います。 複数カラムの使用は、メッセージを分散させる カラムを複数に切って情報を提供することは、1つのページに複数の役割を与えることを意味します。 もちろん、ナビゲーションなどページにとって必要な機能もありますが、より多くのエリアを 定義することはそのページが持つメッセージをぶらしてしまう危険性があることを
Shibu's Diary: きれいなソースコードを書けるようになるためには
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 by chazmatazz 「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか？」という質問を受けたので、「はて？どうしているだろうか？」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。あ、Pythonに限定してますが、他の言語でも似たようなものはあると思いますので、脳内変換をお願いします。 事前の設計はしません 「こういう処理が必要」「こういう計算しなきゃね」みたいなロジックや「要件はこうかな？」ということは事前に考えたりするけど、クラス構造とかは基本的に考えないで手をつけます。そして、ある程度規模が大きくなって「あ、ちょっとこの関数大きすぎて理解しにくいなぁ」と
JavaFesta 札幌で Mind Map と UML の話をしました。：An Agile Way：オルタナティブ・ブログ
10/30 に札幌で開かれた JavaFesta2009 にて、 ソフトウェア開発に役立つビジュアル思考 ～マインドマップ/UMLを現場で有効活用しよう～ というお話をしてきました。Android の話の裏番組だったので人の入りを心配したのですが、札幌のみなさん結構熱心に聴いていただきました。 ソフトウェア開発の現場でマインドマップとUMLを使える場面と例をふんだんな絵と写真で紹介しました。両方の利点を活かした使い方の提案も。 いつものように、情報カードをスタッフに用意してもらってマインドマップ自己紹介（偏愛マップ風）をみなさんにやってもらったり、ユースケース図をみんなで描いてみたり、と和気藹々とした感じで進めることもできました。新さんはじめスタッフのみなさん、どうもありがとうございました。 ぼくの伝えたかったことは、ソフトウェア開発をもっと、協調的に、生産的に、創造的に、そして、楽しくし
Java製のデータモデリングソフトウェア·Ermodeller MOONGIFT
ErmodellerはJava製のオープンソース・ソフトウェア。最近はデータが主体になったシステム開発が多い。データは大抵がデータベースによるものだ。そうなるとデータの定義が固まればコントローラの仕組みも大抵決まってくる。データベースを適切に設計することが、システムの組みやすさやパフォーマンスに大きな影響を及ぼすのだ。 各種DBに対応したモデリングができる そうなるとデータモデリングソフトウェアに対する期待が大きくなる。その点、マルチプラットフォームで動作するJava製のモデリングツールは優位だろう。Ermodellerは多数のデータベースに対応したモデリングソフトウェアとして便利に使えそうだ。 Ermodellerが対応するのはMySQL/PostgreSQL/Oracle/PointBaseとなっている。モデリングは概念、論理、物理型の3つに対応している。データベースからのリバースエン
【連載】ゼロから始めるUMLモデリング講座 | エンタープライズ | マイコミジャーナル
Copyright (C) Mainichi Communications Inc. All rights reserved. 掲載記事の無断転載を禁じます
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RESTful Web アプリの設計レビューの話
Amazon.co.jp: ソースコードリーディングから学ぶ Javaの設計と実装: WINGSプロジェクト佐藤匡剛 (著), 山田祥寛 (読み手): 本