"要件定義/仕様設計"投稿一覧

橋瑞樹

エンジニア

設計をしたいというより、要件が定まっていない案件などはよくあります。
その場合は納期に応じて対応可能な範囲での開発要件を、作業者側で交渉しなければいけないという状況が発生します。
これを設計と呼ぶのであれば、そのような案件は多く存在します。
いわゆる大規模案件での設計業務を想像するのであれば、おっしゃるとおり数を踏んでステップアップするしかないかと。

市村聡士

エンジニア

副業案件は短い時間で頂いている時給以上の価値を提供しないといけないので、すでに持っているスキルを活かすことが多いです。
そのため設計経験の少ないエンジニアに副業で設計を任せる企業は少ないと思います。

1→10フェーズでこれから機能拡張やスケールする必要があるSaaSを開発している企業に転職すると、いやでも設計をしなければいけません。

設計の経験... 続きを見る

藤野博行

エンジニア

探せばあると思いますよ

以下蛇足（Bing先生）
＞＞＞
実際に案件に携わることは、設計スキルを磨く上で非常に効果的な方法ですね！副業で設計段階から関われる案件も存在します。以下のような方法で探してみると良いかもしれません：

1. **フリーランスエージェントを活用する**  
  レバテックフリーランスやITプロパートナ... 続きを見る

Tomotaka

エンジニア

フレームワーク、ライブラリ、その他自作の関数、型などで利用者側で型の一部を拡張させたい場合や使うまで型が断定できない処理に使うことが多いと思います。

※以下、fetch処理をラップして呼び出し時に<T>という型引数を受け取る関数を想定しています。

身近な例ですとfetch処理に外部APIから渡される想定の型をつけておくなどがあると思います。<... 続きを見る

櫻井隆太郎

エンジニア

ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング
https://amzn.asia/d/66xCVaS

仕様書の書き方からはずれてしまうかもし...

セーヤン

エンジニア

こちらはとても学びになりました。

システム設計の面接試験
アレックス・シュウ

Shinichi Kogiso

デザイナー

仕様設計を学ぶには以下の本がおすすめです。初めての方には「はじめよう！システム設計 ～要件定義のその後に」は特にオススメです。

----
はじめよう！システム設計 ～要件定義のその後に
続きを見る

Shinichi Kogiso

デザイナー

JavaScriptは、ウェブページを動的でインタラクティブにするためのプログラミング言語です。JavaやJavaScriptは名前が似ていますが、全く異なる言語であり、用途や動作も異なります。

TypeScriptはJavaScriptに型システムを追加してコードのエラーを早期に検出しやすくするためのJavaScriptのスーパーセットです。

これらの... 続きを見る

Shoichi Namba

エンジニア

JavaScriptというのはブラウザ上で動作するプログラム言語です。Javaとは無関係です。
ただJavaScriptはブラウザ上でそのまま動く必要があるため負荷のかかるビルドなどはできません。そのため、型をつけるためにTypeScriptというものが生まれました。これは事前にJavaScriptにトランスパイルすることで、開発時は型ありの開発ができるようにしたものです。
<... 続きを見る

yide wu

エンジニア

I am a seasoned Web developer with 6 years of experience and a track record of building 9 successful applications.  I have developed expertise in building dynamic user interfaces that deliver a smooth... 続きを見る

北山 淳也

エンジニア

PHP 6 は当初、内部エンジンで扱うエンコードをすべてUTF-16に変更するという意思決定が実施され
実際に開発も進行しましたが、2010年頃にそのプロジェクトは失敗になりPHP6は欠番とすることが決定されました。
その後、内部エンジンをZend Engine 3に切り替えたPHP7がリリースされました。

バージョン番号を+1ずつ進めなければならないとい... 続きを見る

北野勝久

エンジニア

Copilot / Copilot for Business がありますが、企業内での導入という観点だと、 Copilot for Business を利用しないと適切なルールを構築することは難しいのではないかな、と思っています。
ですので Copilot for Business 導入にあたって、参考となりそうな観点を書いてみます・・・と思ったんですが、最近、とても便利な整理をしてくだ... 続きを見る

北野勝久

エンジニア

こんにちは。株式会社スタディストで執行役員VPoEとして開発組織にまつわる様々な業務を行っている北野と申します。

・what,why,howの職種別の立て付け
・業務の割り振り方
・または職種ごとの3点のsyncを高めること

私たちの会社では各チームにこの分担のグラデーションを委ねていますが、それと同時に自分自身の役割を必要以上に制限... 続きを見る

Katsunari Takeda

プロジェクトマネジメント

各職種（PM、エンジニア、デザイナー）の役割の理想形。とても深遠なテーマですね。

絵に書いた餅感は否めませんが、私が考えるプロダクト開発組織の理想像は
・職種関わらず、全メンバーが顧客心理の解像度が高い
・職種関わらず、全メンバーで事業のビジョンが共有されている
・共有された顧客インサイト、ビジョン＋各分掌からの専門的な知見で開発が進んでいく 続きを見る

萩原 北斗

エンジニア

ATDD の取り組み自体は良い考え方だと思います。
スクラム開発の文脈では PO（PdMと同等と定義します） が受け入れ基準となる Acceptance Criteria（ここでは受け入れテストと同義とします） を定義することが謳われていますし、その原理主義的に言えば Shun さんのお考えも不自然ではないと思いました。

一方で、気を払ったほうが良い点としては、実経... 続きを見る

Takuo Doi

エンジニア

ケースバイケースですという前置きの上で。

ウォーターフォール型の開発をしないという前提において、多くの場合、

画面設計 (画面仕様書)
ビジネス上の重要な部分のドメインモデル

あたりは作るとよいかなと思っています。ただ、設計と言ってもエンジニアに指示をするためというよりは、クアイアントと合意を得るために作成しています。 続きを見る