水谷達兵

1996年生まれ / 商社→IT / 札幌出身,東京在住 / 仕事や生活の中での学びを…

水谷達兵

1996年生まれ / 商社→IT / 札幌出身,東京在住 / 仕事や生活の中での学びを綴るnote.

記事一覧

システム開発における設計の目的について

システム開発は下記の流れでフェーズ分けされ、リリースまで進行されることが多い。 ①企画 ②要件定義 ③基本設計 ④詳細設計 ⑤実装 ⑥単体テスト ⑦結合テスト ⑧システ…

水谷達兵
2週間前

要件定義で必要な「アクター」について

新機能を開発する際に必ず必要な「アクター」という概念について。 端的に言えば、下記のようなことを考える必要があります。 ①誰が使うか? ②誰が望んでいるか? ③誰が…

水谷達兵
5か月前
4

資料を読み上げるだけの会議は要らない

システム開発に携わっていると企画段階や要件定義段階でのミーティングや会議がとても多いです。 それぞれのメンバーの貴重な時間を使っているため、資料を読み上げるだけ…

水谷達兵
8か月前

プロジェクト進行で気を付けるべき民間企業と官公庁の違い

PL(プロジェクトリーダー)としていくつか案件を任せてもらうようになってきたころ、初めて官公庁関連の案件を担当しました。 そこで、民間企業とは違う官公庁ならではの…

水谷達兵
9か月前
2

複数部署とのプロジェクト進行で学んだこと

一つのプロジェクトで規模が大きくなると、複数の部署やチームが関わることはよくあります。 このとき気をつけるべきポイントとして「用語一覧」を作成すべき、ということ…

水谷達兵
9か月前
1

個別対応(カスタマイズ)が良くない理由

"ユーザー目線"を考慮して顧客ごと個別に改修やカスタマイズの対応をすることは一見、素晴らしいことのように思います。 ただし、良くないこともあることを学びました。 …

水谷達兵
9か月前

プロジェクトの遅れや案件過多は単純にヒトを増やせばいいわけではない

プロジェクトを成功させるためには、工数管理が大切です。 工数管理にはいくつか方法がありますが、よく使われる人月計算を例に取ります。 1日8時間、1ヶ月20日として計算…

水谷達兵
9か月前
3

バグ(障害)報告で大事にしていること

過去に経験したテストの現場 私が過去に経験したプロダクト開発のリリースされるまでの大まかな流れは下記の流れです。 ① 企画  ② 要件定義   ③ 基本設計  ④ …

水谷達兵
1年前
1

要件定義で画面イメージを作らないとどうなる?

要件定義書について要件定義書の核となるのが、実現したい要件のリストです。 このリストは最も仕様に直結するもので、多くの人が想像するモノだと思います。 このリストに…

水谷達兵
1年前
1

クリティカルパスを使ってサボろう

クリティカルパスでプロジェクト管理まず、クリティカルパス(最長経路)とは、プロジェクトの各工程を洗い出し、開始から終了まで「前の工程が終わらないと次の工程が始ま…

水谷達兵
1年前
3

QCDの観点でマネジメント!

QCDって?・Quality(品質) ・Cost(コスト) ・Delivery(納期) 上記3つの頭文字を取って「QCD」と言います。 この3つはすべて関連していて、依存関係にあります。 ど…

水谷達兵
1年前
4

要件定義の前にまずやること

システム開発は主に以下の流れで進めていきます。 1.要件定義 2.基本設計 3.詳細設計 4.開発 5.テスト 6.リリース 上記のうち、「1.要件定義」を行う前に、まずやるべき重…

水谷達兵
1年前

斬新なUIデザインをしない

UIデザイン時に基本的なことが、意外とできていなかったので備忘録…。 落とし穴 アプリやWEBの開発時に、画面表示に手を加えるとき、正しくUI(ユーザーインターフェー…

水谷達兵
1年前
15

はじめから完成形の資料は作らない

自分のために備忘として記録。 企画書や説明資料などを作成するときは、初めから100%の完成形を作ろうとしてはいけない。 理由としては下記のようなものがある ・そもそ…

水谷達兵
1年前
1

属人化とテレワークについて考えてみた

属人化は楽だと思うチームで仕事をしていると、それぞれがそれぞれの案件を担当していたり、業務内容が異なるケースはよくあることだと思います。 実際に自分の現場でもそ…

水谷達兵
1年前
1

ヒントは過去にある

当たり前のことができていなかったので、備忘録として記録… サイトやアプリでシステム障害が起こり、利用者から問い合わせが入る。 内容を把握し、システム保守に調査依…

水谷達兵
2年前
2
システム開発における設計の目的について

システム開発における設計の目的について

システム開発は下記の流れでフェーズ分けされ、リリースまで進行されることが多い。
①企画
②要件定義
③基本設計
④詳細設計
⑤実装
⑥単体テスト
⑦結合テスト
⑧システムテスト
⑨リリース

このうち③と④では何をするのか?成果物は何か?を調べてみた。
基本設計
システム全体の概要・機能一覧・操作画面・操作方法など、主にシステムを使用するユーザーから見える部分の設計を行う。
詳細設計
基本設計を基

もっとみる
要件定義で必要な「アクター」について

要件定義で必要な「アクター」について

新機能を開発する際に必ず必要な「アクター」という概念について。
端的に言えば、下記のようなことを考える必要があります。
①誰が使うか?
②誰が望んでいるか?
③誰が問合せを受け付けるか?

例えば①については、使う人は1人なのか、複数人なのか、によっても発行するアカウントのロール(役割)を変える必要があります。
更には、異なる端末でのログインがある場合一方はアクセスを許可し、もう一方はアクセスを遮

もっとみる
資料を読み上げるだけの会議は要らない

資料を読み上げるだけの会議は要らない

システム開発に携わっていると企画段階や要件定義段階でのミーティングや会議がとても多いです。

それぞれのメンバーの貴重な時間を使っているため、資料を読み上げるだけの会議は時間を浪費してしまいます。
事前に資料を共有しておけば各自のタイミングで見ておけるし、わざわざ集まって行う必要は全くありません。

ただし、各フェーズの"レビュー"や発生した"障害の報告"等はその場面での適切な方法での会議は必要で

もっとみる
プロジェクト進行で気を付けるべき民間企業と官公庁の違い

プロジェクト進行で気を付けるべき民間企業と官公庁の違い

PL(プロジェクトリーダー)としていくつか案件を任せてもらうようになってきたころ、初めて官公庁関連の案件を担当しました。

そこで、民間企業とは違う官公庁ならではの気を付けるべきポイントを学びました。
それはスケジュール管理です。
もちろん大前提として、民間企業案件でもスケジュール管理は当然します。
では、何が違うのかというと、予期せぬ指摘をもらって修正したり、必要な手順があったりという点です。そ

もっとみる
複数部署とのプロジェクト進行で学んだこと

複数部署とのプロジェクト進行で学んだこと

一つのプロジェクトで規模が大きくなると、複数の部署やチームが関わることはよくあります。
このとき気をつけるべきポイントとして「用語一覧」を作成すべき、ということを学びました。

フェーズとしてはプロジェクトの要件定義フェーズで要件定義書の一部として作成するケースが多いです。
ここで用語の意味を一つ一つ定義しておくことで複数の部署が共通の言葉で、共通の認識を持つことができます。
このときプロジェクト

もっとみる
個別対応(カスタマイズ)が良くない理由

個別対応(カスタマイズ)が良くない理由

"ユーザー目線"を考慮して顧客ごと個別に改修やカスタマイズの対応をすることは一見、素晴らしいことのように思います。

ただし、良くないこともあることを学びました。

そう思ったことが大きく2点あります。

1.仕様が複雑化し把握しきれなくなる
サービスとしての基本の仕様から逸脱して、このお客様はこう、このお客様はこう…といったように細かな仕様の違いがばらまかれてサービスオーナーでさえ把握しきれなく

もっとみる
プロジェクトの遅れや案件過多は単純にヒトを増やせばいいわけではない

プロジェクトの遅れや案件過多は単純にヒトを増やせばいいわけではない

プロジェクトを成功させるためには、工数管理が大切です。
工数管理にはいくつか方法がありますが、よく使われる人月計算を例に取ります。
1日8時間、1ヶ月20日として計算し、1人月=20人日と表現します。

例えば、あるタスクが1人月足りない場合、1ヶ月間作業者を増員すればことは解決しそうに感じます。

これは正解なようで不正解です。

その「タスク」がどんな内容かにもよりますが、マニュアルや手順書が

もっとみる
バグ(障害)報告で大事にしていること

バグ(障害)報告で大事にしていること

過去に経験したテストの現場

私が過去に経験したプロダクト開発のリリースされるまでの大まかな流れは下記の流れです。
① 企画 
② 要件定義  
③ 基本設計 
④ 詳細設計
⑤ 製造 
⑥ 単体テスト(④の確認)
⑦ 結合テスト(③の確認)
⑧ シナリオテスト(②の確認)
⑨ リリース
このプロジェクトでは、テスト工程を別会社(私が所属していたテストチーム)へ外注していました。
そのため、設計工

もっとみる
要件定義で画面イメージを作らないとどうなる?

要件定義で画面イメージを作らないとどうなる?

要件定義書について要件定義書の核となるのが、実現したい要件のリストです。
このリストは最も仕様に直結するもので、多くの人が想像するモノだと思います。
このリストに記載すべきは、要求をもとにした要件の一覧とその背景です。
背景を一緒に記述することで、そのあとの工程で目指すべき目的がずれにくくなります。

画面イメージを作らないとどうなる?要件のリストを作っておしまいではなく、画面イメージも作る必要が

もっとみる
クリティカルパスを使ってサボろう

クリティカルパスを使ってサボろう

クリティカルパスでプロジェクト管理まず、クリティカルパス(最長経路)とは、プロジェクトの各工程を洗い出し、開始から終了まで「前の工程が終わらないと次の工程が始まらない」という依存関係に従って結んでいったときに、所要時間が最長となるような経路のことです。その長さがプロジェクトの期間を表しています。

クリティカルパスを使わなくたっていいクリティカルパスを用いなくともスケジュール管理をすることはできま

もっとみる
QCDの観点でマネジメント!

QCDの観点でマネジメント!


QCDって?・Quality(品質)
・Cost(コスト)
・Delivery(納期)
上記3つの頭文字を取って「QCD」と言います。
この3つはすべて関連していて、依存関係にあります。
どれもバランス良く達成することが大事です。
が、なかなか簡単にはいかず、どれを最も重要視するかを決めなくてはいけないことがしばしばあります。

全部優先したいじゃあ、3つ全部を優先したい!
至極まともな意見です

もっとみる
要件定義の前にまずやること

要件定義の前にまずやること

システム開発は主に以下の流れで進めていきます。
1.要件定義
2.基本設計
3.詳細設計
4.開発
5.テスト
6.リリース

上記のうち、「1.要件定義」を行う前に、まずやるべき重要なことがあります。
それはズバリ、業務フローの洗い出しです。

開発をする前に、現状の業務フローがどうなっているのかを整理します。
現状を理解しなくては新しいモノを開発しても開発目的が定められません。
業務フローの洗

もっとみる
斬新なUIデザインをしない

斬新なUIデザインをしない

UIデザイン時に基本的なことが、意外とできていなかったので備忘録…。

落とし穴

アプリやWEBの開発時に、画面表示に手を加えるとき、正しくUI(ユーザーインターフェース)をデザインする必要がある。
そこでよくある落とし穴として、なにか革新的で斬新なモノを生み出そうとして間違ったUIをデザインをしてしまうことがある。
その考えが上手くハマることもあるが、案外落とし穴だったりする。
今まで他のデバ

もっとみる
はじめから完成形の資料は作らない

はじめから完成形の資料は作らない

自分のために備忘として記録。

企画書や説明資料などを作成するときは、初めから100%の完成形を作ろうとしてはいけない。

理由としては下記のようなものがある
・そもそも自分が完成形だと思ったものが、相手にとっては未完成かもしれない
・レビュー後に修正が必要な場合、手直しの時間がかかってしまう
・中間報告ができない

理想は、30%でも形ができてきたら報告、50%時点で報告、80%時点で報告。など

もっとみる
属人化とテレワークについて考えてみた

属人化とテレワークについて考えてみた

属人化は楽だと思うチームで仕事をしていると、それぞれがそれぞれの案件を担当していたり、業務内容が異なるケースはよくあることだと思います。
実際に自分の現場でもそうです。
みんなそれぞれ役割があります。

ある日、アプリの開発を進めるにあたり、開発環境でテストを行うシーンがありました。
iOSの検証端末に検証用のアプリをインストールする際に、「p12証明書」「Provisioning Profile

もっとみる
ヒントは過去にある

ヒントは過去にある

当たり前のことができていなかったので、備忘録として記録…

サイトやアプリでシステム障害が起こり、利用者から問い合わせが入る。
内容を把握し、システム保守に調査依頼をする。
保守からの返答をもらう。

「過去に同様の事象があったらしく、その時は別のサイト管理会社に対応をしてもらったようです。今回もそちらに振ってください。」

そう返答をもらいました。
で、別のサイト管理会社に対応してもらい、無事解

もっとみる