水谷達兵

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

水谷達兵

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

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

システム開発は下記の流れでフェーズ分けされ、リリースまで進行されることが多い。 ①企画 ②要件定義 ③基本設計 ④詳細設計 ⑤実装 ⑥単体テスト ⑦結合テスト ⑧システムテスト ⑨リリース このうち③と④では何をするのか？成果物は何か？を調べてみた。 基本設計 システム全体の概要・機能一覧・操作画面・操作方法など、主にシステムを使用するユーザーから見える部分の設計を行う。 詳細設計 基本設計を基に、システムの内部構造・処理方法・データの流れなど、ユーザーからは見えない細部ま

水谷達兵

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

      新機能を開発する際に必ず必要な「アクター」という概念について。 端的に言えば、下記のようなことを考える必要があります。 ①誰が使うか？ ②誰が望んでいるか？ ③誰が問合せを受け付けるか？ 例えば①については、使う人は1人なのか、複数人なのか、によっても発行するアカウントのロール（役割）を変える必要があります。 更には、異なる端末でのログインがある場合一方はアクセスを許可し、もう一方はアクセスを遮断するなども扱う情報によっては必要です。 ②について、利用者目線で使いやすいも

      水谷達兵

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

        システム開発に携わっていると企画段階や要件定義段階でのミーティングや会議がとても多いです。 それぞれのメンバーの貴重な時間を使っているため、資料を読み上げるだけの会議は時間を浪費してしまいます。 事前に資料を共有しておけば各自のタイミングで見ておけるし、わざわざ集まって行う必要は全くありません。 ただし、各フェーズの"レビュー"や発生した"障害の報告"等はその場面での適切な方法での会議は必要です。 誰に対して、何のために？を明確に設定する必要はありますが。 例えば要件定

        水谷達兵

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

          PL（プロジェクトリーダー）としていくつか案件を任せてもらうようになってきたころ、初めて官公庁関連の案件を担当しました。 そこで、民間企業とは違う官公庁ならではの気を付けるべきポイントを学びました。 それはスケジュール管理です。 もちろん大前提として、民間企業案件でもスケジュール管理は当然します。 では、何が違うのかというと、予期せぬ指摘をもらって修正したり、必要な手順があったりという点です。そういったことの対応分のバッファを考慮する必要があります。 どちらが良い・悪いと

          水谷達兵

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

        水谷達兵

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

          一つのプロジェクトで規模が大きくなると、複数の部署やチームが関わることはよくあります。 このとき気をつけるべきポイントとして「用語一覧」を作成すべき、ということを学びました。 フェーズとしてはプロジェクトの要件定義フェーズで要件定義書の一部として作成するケースが多いです。 ここで用語の意味を一つ一つ定義しておくことで複数の部署が共通の言葉で、共通の認識を持つことができます。 このときプロジェクトで新しく定義する用語の他に、すでに使われている用語も用語一覧に記載しておくと良い

          水谷達兵

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

          水谷達兵

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

          "ユーザー目線"を考慮して顧客ごと個別に改修やカスタマイズの対応をすることは一見、素晴らしいことのように思います。 ただし、良くないこともあることを学びました。 そう思ったことが大きく2点あります。 1.仕様が複雑化し把握しきれなくなる サービスとしての基本の仕様から逸脱して、このお客様はこう、このお客様はこう…といったように細かな仕様の違いがばらまかれてサービスオーナーでさえ把握しきれなくなります。 運用方法にも差が生まれて、業務引継ぎがあった際に漏れが発生する可能性

          水谷達兵

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

          水谷達兵

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

          プロジェクトを成功させるためには、工数管理が大切です。 工数管理にはいくつか方法がありますが、よく使われる人月計算を例に取ります。 1日8時間、1ヶ月20日として計算し、1人月＝20人日と表現します。 例えば、あるタスクが1人月足りない場合、1ヶ月間作業者を増員すればことは解決しそうに感じます。 これは正解なようで不正解です。 その「タスク」がどんな内容かにもよりますが、マニュアルや手順書が完備されている簡単なテスト作業の場合は、1ヶ月間の作業者増員で解決するケースが多

          水谷達兵

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

          水谷達兵

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

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

          水谷達兵

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

          水谷達兵

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

          要件定義書について要件定義書の核となるのが、実現したい要件のリストです。 このリストは最も仕様に直結するもので、多くの人が想像するモノだと思います。 このリストに記載すべきは、要求をもとにした要件の一覧とその背景です。 背景を一緒に記述することで、そのあとの工程で目指すべき目的がずれにくくなります。 画面イメージを作らないとどうなる？要件のリストを作っておしまいではなく、画面イメージも作る必要があります。 この画面イメージを作らないと、文字だけのやり取りとなってしまいます。

          水谷達兵

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

          水谷達兵

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

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

          水谷達兵

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

          水谷達兵

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

          QCDって？・Quality（品質） ・Cost（コスト） ・Delivery（納期） 上記3つの頭文字を取って「QCD」と言います。 この3つはすべて関連していて、依存関係にあります。 どれもバランス良く達成することが大事です。 が、なかなか簡単にはいかず、どれを最も重要視するかを決めなくてはいけないことがしばしばあります。 全部優先したいじゃあ、3つ全部を優先したい！ 至極まともな意見です。 しかし、これは何も考えていないのと同じです。 3つ全部大事なのは大前提で、そ

          水谷達兵

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

          水谷達兵

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

          システム開発は主に以下の流れで進めていきます。 1.要件定義 2.基本設計 3.詳細設計 4.開発 5.テスト 6.リリース 上記のうち、「1.要件定義」を行う前に、まずやるべき重要なことがあります。 それはズバリ、業務フローの洗い出しです。 開発をする前に、現状の業務フローがどうなっているのかを整理します。 現状を理解しなくては新しいモノを開発しても開発目的が定められません。 業務フローの洗い出しができたら、それを資料化し、誰でもわかるように残しておきます。 資料化でき

          水谷達兵

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

          水谷達兵

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

          UIデザイン時に基本的なことが、意外とできていなかったので備忘録…。 落とし穴 アプリやWEBの開発時に、画面表示に手を加えるとき、正しくUI（ユーザーインターフェース）をデザインする必要がある。 そこでよくある落とし穴として、なにか革新的で斬新なモノを生み出そうとして間違ったUIをデザインをしてしまうことがある。 その考えが上手くハマることもあるが、案外落とし穴だったりする。 今まで他のデバイスやアプリでなれていた操作感で利用しようとすると、今までの操作感が通じずに思い

          水谷達兵

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

          水谷達兵

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

          自分のために備忘として記録。 企画書や説明資料などを作成するときは、初めから100％の完成形を作ろうとしてはいけない。 理由としては下記のようなものがある ・そもそも自分が完成形だと思ったものが、相手にとっては未完成かもしれない ・レビュー後に修正が必要な場合、手直しの時間がかかってしまう ・中間報告ができない 理想は、30％でも形ができてきたら報告、50％時点で報告、80％時点で報告。などのように都度報告することで大きな修正による手戻りもなく進めることができる。 かつ

          水谷達兵

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

          水谷達兵

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

          属人化は楽だと思うチームで仕事をしていると、それぞれがそれぞれの案件を担当していたり、業務内容が異なるケースはよくあることだと思います。 実際に自分の現場でもそうです。 みんなそれぞれ役割があります。 ある日、アプリの開発を進めるにあたり、開発環境でテストを行うシーンがありました。 iOSの検証端末に検証用のアプリをインストールする際に、「p12証明書」「Provisioning Profile」なるものを発行する必要がありました。 検証端末の情報などの情報ファイルですが、

          水谷達兵

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

          水谷達兵

          ヒントは過去にある

          当たり前のことができていなかったので、備忘録として記録… サイトやアプリでシステム障害が起こり、利用者から問い合わせが入る。 内容を把握し、システム保守に調査依頼をする。 保守からの返答をもらう。 「過去に同様の事象があったらしく、その時は別のサイト管理会社に対応をしてもらったようです。今回もそちらに振ってください。」 そう返答をもらいました。 で、別のサイト管理会社に対応してもらい、無事解決。 ここで、私が、保守へ依頼する前に過去に同様の事象がなかったか確認すべきで

          水谷達兵

          ヒントは過去にある

          水谷達兵