迷い人

日々勉強。勉強の先に何か見つかるといいなぁ

ChatGPTさんに要件定義について教えてもらった

 

 

ChatGPTさんに要件定義について教えてもらったので、シェアします

まず何をする工程か質問しました。

 

 

具体的な活動内容について教えてもらいました。続いて5W1Hフレームをしていして質問してみます。

 

 

Where(どこで)の部分は深堀しづらいので、それ以外の部分について、詳しく質問してみます。まずはWho(誰が)の部分です。

 

要件定義は誰がするのか

要件定義の役割について質問しました。

 

 

システムアナリストとプロジェクトマネージャーは兼任していることが多いイメージ。

また、開発チームだけでなく、テストケースを作成する品質保証チームにまで言及しています。

 

要件定義は何をするのか

要件定義の中でも「ニーズの収集」について、現状把握、問題特定、業務要件というポイントを提示して、質問しました。

 

その結果がこちら。

 

 

こちらが指定したポイントで詳しく解説してくれています。こちらの考えに引っ張られるのはよくないので、ChatGPTさん自身の考えを改めて質問しました。

 

 

ニーズの収集の手法について、解説してしてくれています。解説をお願いする時に「プロセス」だったり「手法」だったりを指定してみるといいかもしれません。

 

要件定義はなぜやるべきなのか

要件定義を実施する目的について質問しました。

 

 

ビジネス戦略や市場動向についてまで言及されていて素晴らしい。ただ、8つもあるので最も重要な目的を質問しました。

 

 

完全に同意です。コンセンサス形成無しの要件定義に起因する後工程での大災害をいくつも見てきました。

 

要件定義はいつやるのか

要件定義はプロジェクト計画の次の工程ということなので、プロジェク計画の成果物のうち、要件定義でインプットになるものが何か質問しました。

 

 

PMBOK第6版の計画プロセスにおけるアウトプットが提示されています。

次に要件定義の成果物のうち、設計工程でのインプットになるものを質問してみました。

 

 

要件定義と設計の線引きが難しいと感じていたので、そのことについても質問してみました。

 

 

要件定義な「何を」を決める役割で、設計が「どのように」を決める役割というのは納得感のある説明です。

 

要件定義をどのようにやるか

要件定義のやり方について、要件の特定、整理、詳細化、文書化のやり方について質問しました。

 

 

めちゃくちゃ具体的です。最初から完璧を求めず、フィードバックを取り入れていこうというアドバイスも素敵です。

 

要件定義の目的で最も重要なことがステークホルダーとのコンセンサスということだったので、その方法について質問しました。

 

 

ChatGPTさんが自分で大事だと言っていることもあり、9つもヒントを出してくれました。どれも具体的かつ納得感があります。

 

最後にまとめ

最後にこれまでChatGPTさんに教えてもらったことをまとめてもらいました。

 

 

まとめもいい感じです。

 

参考:ChatGPTさんに質問したこと

ソフトウェア開発における要件定義工程とは、何をする工程でしょうか

 

ありがとうございます。とてもよくわかりました。要件定義工程の目的と活動について、5W1Hのフレームでもう一度説明してもらうことはできますか?

 

ありがとうございます。要件定義工程について改めて全体像がわかりました。もう少し詳細に教えてください。Who(誰が)の部分について、要件定義工程においては様々な人が関係することがわかりました。関係者ごとの要件定義工程における役割について教えてもらってもいいでしょうか。

 

ありがとうございます。よくわかりました。次にWhat(何を)の部分について詳しく教えてください。要件定義工程で活動について、「ニーズの収集」から「要件の確認と承認」と教えていただきました。この中で「ニーズの収集」についてもう少し詳細に教えていただけないでしょうか。現状把握、問題の特定、それを背景とした業務要件の提示などが含まれるのではないかと思うのですがいかがでしょうか。

 

こちらが指摘したポイントについての回答をありがとうございます。私が指摘したポイントはいったん忘れていただいてChatGPTさんが考える「ニーズの収集」について、改めて詳しく教えていただいてもいいでしょうか。

 

ありがとうございます。続いてWhy(なぜ)の部分について詳しく教えてください。後続の開発工程をスムーズに行うため、ステークホルダーの期待やニーズを正確に満たすためというのが目的だと理解しました。この他にも要件定義を実施する目的はあるでしょうか。できる限り詳細に教えてください。

 

幅広い観点で要件定義を実施する目的について教えていただき、ありがとうございます。この8つの中でChatGPTさんが考える最も重要な目的は何になるでしょうか。またその理由も教えてください。

 

ありがとうございます。次にWhen(いつ)の部分について詳しく教えてください。プロジェクト計画の後、設計の前が要件定義を実施することがわかりました。プロジェクト計画工程でのアウトプットを使って要件定義を実施することになると思うのですが、要件定義のインプットになるプロジェクト計画工程の成果物について教えてください。

 

とてもよくわかりました。ありがとうございます。次に要件定義工程のアウトプットが次工程の設計のインプットになると思います。要件定義工程の成果物がどのように設計工程で利用されるのか教えていただいてもいいでしょうか。

 

ありがとうございます。要件仕様書が設計工程でのアーキテクチャやモジュール、データベース設計に利用されることがわかりました。要件仕様書では、画面設計やデータベース設計の一部もやることがあると思うのですが、要件定義工程と設計工程のアウトプットについて、どのような考え方で線引きすれば良いでしょうか。

 

ありがとうございます。最後にHow(どのように)について詳しく教えてください。ニーズの収集については詳しく教えてもらったので、収集したニーズを元に要件を特定、整理、詳細化し、それを文書化させる方法について、詳しく教えてください。とても難しい作業だと感じています。

 

ありがとうございます。フィードバックによる見直しも重要であることが再認識できました。文書化したものを使って、ステークホルダーとの確認・承認のプロセスについて、進め方とヒントを詳しく教えてもらえないでしょうか。承認した文書について、後から意識違いがあり、修正することになるケースも多く、ステークホルダーに正確に文書を理解してもらい承認してもらうことがとても難しく感じています。

 

ありがとうございます。要件定義工程における活動や目的についてとてもよくわかりました。これまで様々な観点で説明いただいた内容をポイントをしぼってまとめていただけないでしょうか。全体として1000文字以内でまとめていただけるとありがたいです。

Laravelにおけるレイアウト(@section @yield @component)について

Laravelのレイアウトについて記事にしたいと思います。

 

Laravel入門(青本)のP85〜P95あたりまでのことです。青本の説明めちゃくちゃわかりにくい。。。

 

この記事の目標は青本よりはわかりやすく書くこと!

 

Laravelにおけるレイアウトの基本は@sectionと@yieldの二つで、簡単にいうと@yield部分に@sectionで記述した内容がはめ込まれて表示されます。

 

まずレイアウトの雛形を作る

viewフォルダの配下にlayoutsフォルダを新規作成し、ファイル名をtakoyakiapp.blade.phpにして、以下のコードを記述します。

 

<html>
  <head>
    <title>@yield('title')</title>
  </head>
  <body>
    <h1>@yield('title')</h1>
    <div class="header">
      @yield('header')
    </div>
    <div class="content">
      @yield('content')
    </div>
    <div class="footer">
      @yield('footer')
    </div>
  </body>
</html>

 

わかりやすく、header、content、footerに分けています。

@yield('文字列')で文字列に対応する@sectionがはめ込まれて表示されることになります。

 

では次に@section部分を作成します。

 

@section部分を作る

前回作成したtakoyaki_calculation.blade.phpを以下のように修正します。

 

@extends('layouts.takoyakiapp')

@section('title', 'たこ焼き')

@section('header')
    <p>最適温度</p>
@endsection

@section('content')
    {{$kekka}}
    <form action="/takoyaki_calc" method="post">
        {{ csrf_field() }}
        <input type="text" name="msg" value="{{$temperature}}">
        <input type="submit">
    </form>
    <a href="{{route('takoyaki_calc')}}">
        <button type="button">リセット</button>
    </a>
    @component('components.message')
        @slot('msg_title')
        なぜ温度が大事か
        @endslot

        @slot('msg_content')
        最適な温度であれば、外はカリ!、中はトロ!を実現できるから
        @endslot
    @endcomponent
@endsection

@section('footer')
    <p>copyright 2020 o-ya</p>
@endsection

 

@extends('layouts.takoyakiapp')で@sectionをはめ込むベースとなるレイアウトを指定します。今回は先ほど作成したlayoutsフォルダに作成したtakoyakiappです。

 

続いて@sectionを記述していきますが、書き方は大きく2つあります。

 

@section( セクション名, 値 )

単純にテキストや数値をセクションに表示させる時に使います。

 

今回は「@section('title', 'たこ焼き')」と記述しているので、ベースとなるtakoyakiappで「@yield('title')」の部分に「たこ焼き」という文字列がはめ込まれます。

 

@section( セクション名 ) 〜 @endsection

@sectionから@endsectionまでの内容がセクションの内容になります。

複数行に渡ってき記述したい場合やパラメータを使いたい場合はこちらを使いましょう。

 

@section('content')の内容は前回作成したビューと全く同じ内容を記述しています。

 

↓前回記事

oyaoya1123.hatenablog.com

 

 

最後に@componetsについて解説します。

 

@componentsの使い方

@yieldと@sectionの関係はベースとなるレイアウトを決めてそこに記述された@yieldに@sectionの内容をはめ込むものでした。

 

@componentsを使うと、外部から@sectionに組み込むことができるようになります。

 

今回は「@component('components.message')」という記述をしていますが、これはcomponetsフォルダにあるmessage.blade.phpの内容を組み込んでいますということです。

 

message.blade.phpは以下のように記述しています。

 

<div>
  <p>タイトル:{{$msg_title}}</p>
  <p>コンテンツ:{{$msg_content}}</p>
</div>

 

$msg_titleと$msg_contentというパラメータがあると思います。ここにはめ込む値をcomponetsの中のslotで定義します。

 

今回はmsg_tilteに「なぜ温度が大事か」を定義したので、画面の表示としては「タイトル:なぜ温度が大事か」となります。

 

コンテンツも同様です。

 

以上により以下のような画面となりました。

 

f:id:oyaoya1123:20200820232646p:plain

CSSを一切適用していないので見た目は悪いですが、タイトル、ヘッダー、コンテンツ、フッターと一応そろっています。

 

まとめ

@section、@yield、@componentについて解説しました。

 

  • @yieldに@sectionで記述した内容がはめ込まれる
  • extendsで@yieldで記述したベースレイアウトを読み込んでから@sectionを書く
  • @componentを使えば外部から組み込みもできる

 

以上になります。

Laravelでフォーム入力

フォームから「たこ焼きを焼くための最適な温度」を入力すると、「最適な温度!!」「温度高すぎ!」「温度低すぎ!」の何かを画面表示する機能を実装しました。

 

f:id:oyaoya1123:20200819213336p:plain

 

f:id:oyaoya1123:20200819213822p:plain

 

ちなみにリセットを押すとまた「たこ焼きを焼くために最適な温度は何度でしょう?」の画面に戻ります。

 

このWebアプリを作るためにいじったのはルートとコントローラとビューの3つです。

それぞれ簡単に解説します。

 

ルートの記述

web.phpに以下のように記述しました。

 

Route::get('/takoyaki_calc/', 'HelloController@takoyaki_calc')->name('takoyaki_calc');
Route::post('/takoyaki_calc/', 'HelloController@takoyaki_calc_post');

 

getの方は「http://localhost:8000/takoyaki_calc」に最初にアクセスした時にHelloControllerのtakoyaki_calcアクションを呼び出します。

 

またnameでtakoyaki_calcと宣言しているので、route('takoyaki_calc')で「http://localhost:8000/takoyaki_calc」を呼び出せるようになります。

 

postの方はgetで呼び出した画面に好きな温度を入力して、送信ボタンを押した時にHelloControllerのtakoyaki_calc_postアクションを呼び出します。

 

同じURLでもhttpメソッドが異なれば、ルートをそれぞれ記述して、アクションも別にできます。

 

コントローラの記述

続いてコントローラです。いつものように青本のHelloControllerをそのまま活用しています。

 

  public function takoyaki_calc()
  {
    $data =[ 'kekka' => 'たこ焼きを焼くための最適な温度は何度でしょう?', 'temperature' =>''];

    return view('hello.takoyaki_calculation', $data);
  }

  public function takoyaki_calc_post(Request $request)
  {
    $msg = $request->msg;

    if(ctype_digit($msg)) {
      $temperature = (int)$msg;
      if ($temperature > 250) {
        $data =[ 'kekka' => '温度高すぎ!', 'temperature' => $temperature];
      } elseif($temperature < 200) {
        $data =[ 'kekka' => '温度低すぎ!', 'temperature' => $temperature];
      } else {
        $data =[ 'kekka' => '最適温度!!!', 'temperature' => $temperature];
      }
    } else {
      $temperature = '';
      $data =[ 'kekka' => '整数を入力してね', 'temperature' => $temperature];
    }

    return view('hello.takoyaki_calculation', $data);
  }

 

takoyaki_calcアクションはview関数でtakoyaki_calculation.blade.php読み込んで、その内容を返しています。

 

その時パラメータとしてdataをビューに渡しています。

 

takoyaki_calc_postアクションはビューで入力された値を$request->msgで取り出して、まずctype_digit関数で整数かそうでないかの判断を行います。

 

整数であれば、数値によって$kekkaに文字列を入れて、再びビューに返します。

 

整数でなければ、$kekkaに「整数を入力してね」を入れて、再びビューに返します。

 

ビューには画面で入力した温度もtemperatureとして返すようにします。

 

ビューの記述

最後にビューの記述です。

<html>
    <head>
        <title>最適温度</title>
    </head>
    <body>
        {{$kekka}}
        <form action="/takoyaki_calc" method="post">
            {{ csrf_field() }}
            <input type="text" name="msg" value="{{$temperature}}">
            <input type="submit">
        </form>
        <a href="{{route('takoyaki_calc')}}">
            <button type="button">リセット</button>
        </a>
    </body>
</html>

 

最初にhttp://localhost:8000/takoyaki_calcにアクセスした時は、$kekkaに「たこ焼きを焼くための最適な温度は何度でしょう?」が格納されており、それが表示されます。

 

formでは、actionにルートのpostで記述した/takoyaki_calcを設定し、methodはpostにします。

 

これで送信ボタンを押すと、フォームに入力した値がHelloControllerのtakoyaki_calc_postアクションに渡されて、その結果が表示されるというわけです。

 

リセットボタンは画面を初期状態(httpメソッドがgetでフォーム画面が呼び出された状態)にするために配置しています。

 

まとめ

今回もルート→コントローラ→ビューの流れにそった基本的な処理を記述してみました。httpメソッド(getやpost)については過去解説しているので参考にしてください。

 

oyaoya1123.hatenablog.com

 

ルート→コントローラ→ビューの理解

Laravelの青本を進めてます。

 

ひとまずルート→コントローラ→ビューの理解を確認するために

 

http://localhost:8000/clcu/5

 

って入力すると画面に「25」が表示される簡単なWebアプリを作ってみました。

 

ルートの記述

Route::get('/calc/{num?}', 'HelloController@calc');

 

{num?}の部分が任意でパラメータを受け取れるようにしています。任意なので、http://localhost/calcuでもエラーとならずに動きます。

 

HelloController@calcの部分はHelloコントローラーのcalcアクションに記述してあることを実行するという意味です。

 

コントローラー名がHelloなのは、青本で作ったコントローラーを流用しているから。

 

コントローラの記述

  public function calc($num='zero')
  {
    if (is_numeric($num)){
      $data = [ 'kekka' => $num*$num];
    } else {
      $data = [ 'kekka' => '数値にしてね'];
    }

    return view('hello.calculation', $data);
    
  }

 

calcアクションの記述です。

 

$num='zero'の部分は、URLでパラメータが指定されなかった時は文字列のzeroを入力するようにしています。

 

is_numericでパラメータに数値が入っているか評価しています。

例えばhttp://localhost/calc/sevenだと、$numにはsevenという文字列が入るので、elseの命令が実行されることになります。

 

view関数で、viewフォルダの中のhelloフォルダに格納されているcalculation.blade.phpを読み込んで、その内容を返します。

 

ちなみにview関数の戻り値は正確にはResponseインスタンスなんですが、詳細は割愛。

 

ビューの記述

<html>
    <head>
        <title>計算</title>
    </head>
    <body>
        <p>計算結果</p>
        {{$kekka}}
    </body>
</html>

 

計算結果を画面に表示させます。

計算結果は{{$kekka}}の部分です。

 

まとめ

・ルートでWebブラウザに入力するURLからコントローラとアクションを特定

・URLの中のパラメータもアクションに渡す

・アクションは渡されたパラメータから計算処理を実施し、ビューに渡す

・ビューは結果を表示する

 

参考

ルート→コントローラ→ビューの流れについては別記事でも書いているので参考にしてください。

 

oyaoya1123.hatenablog.com

 

 

localhost、グローバルIPアドレス、プライベートIPアドレスについて

今更ながらLaravelの

 

http://localhost:8000

 

についてちゃんと理解しておこうと思って記事にしています。

 

以下のサイトでほぼ理解できるとは思うんですが自分の理解のために、自分の言葉で表現しようと思います。

 

codor.co.jp

 

qiita.com

 

localhost127.0.0.1について

Laravelのアプリケーションをローカルで開発していると良く、動作確認のためにブラウザに「http://localhost:8000」とか「http://127.0.0.1:8000」と打つ事が多いと思います。

 

どちらも(設定を変えていなければ)同じ結果になるという事で

 

localhost = 127.0.0.1

 

という理解で大体問題ないです。

 

localhostを理解するためにまず127.0.01というIPアドレスから理解する事がわかりやすいかなと思います。

 

IPアドレスにはグローバルIPアドレスとプライベートIPアドレスがある

結論からいうと127.0.01はプライベートIPアドレスの一つで、自分のPCの住所のようなものです。

 

外部ネットワークにつながるウェブサイトには全てにグローバルIPアドレスが設定されており、それらは重複しません。

 

一方でプライベートIPアドレスは内部ネットワークないで設定されるIPアドレスで内部ネットワークが異なれば、重複する事が許されています。

 

f:id:oyaoya1123:20200817121616p:plain

 

http://localhost:8000とは

Laravelにおいて、「 http://localhost:8000 」の意味は、Webブラウザから自分自身のPCにあるWebサーバにポート番号8000でアクセスすることです。


Laravelはサーバ機能を内蔵していて簡単にサーバーでアプリケーションを実行できるというわけです。うーん、便利。

 

f:id:oyaoya1123:20200817121900p:plain

 

なので、Webサーバを自分のPC以外のところに設置している場合は、localhostではアクセスできず、エラーとなります。

 

なぜ某プログラミングスクール卒業生は評判が悪いのか(1)

某プログラミングスクールの卒業生はなぜこんなにも評判が悪いのか。

 

評判が悪い根拠は私が面接させていただいた3社の社長さん全員の評判が悪かったから。数が少ないのはご愛敬。

 

どういうふうに悪かったかというと

 

・スクールで作った制作物をポートフォリオとして持ってくる。持ってきたもの作りについて全然説明できない。

・コンピューターサイエンスの基礎的な知識が足りない。

・課題を出すんだけど、わからなければ聞けば良いのに、わからないまま殆ど完成していない制作物を提出してくる

 

みたいな感じ。

 

 

評判が悪い理由をブレストで考えてみる。

 

・企業が(社長が)求めるスキルレベルに到達していないため。

・チーム開発で自分が作っていない機能について全然理解していないため。

・スクールカリキュラムを終えただけで、なぜそのように動作する等の理解が足りていないため。

・プログラミングスクールを卒業したら自分は即戦力に慣れると本気で信じてしまっているため。

・プログラミングスクールのカリキュラムがその人に取っては大変で、その大変なカリキュラムを卒業したのだから、ある程度できる人間なんだと勘違いしているため。

・スクール卒業生が非常に多く、良い人も悪い人も非常に多く、悪い人が目立っている

・スクールに申し込んでくる人は「即戦力になれる」という誇大広告を信じている人が多く、変な自信がついてしまっているため。

・会社に貢献したい、社会の役に立ちたいというようなモチベーションではなく、スキルを生かしたい、好きな仕事がしたい、お金儲けがしたいというモチベーションの人が多いため。

・プログラミングスクールで学ぶ人のほとんどが元々スキルレベル、コミュニケーションレベルが低い人が多いため。

MACでプログラミングをすることで、自分がすごい人になったと錯覚しやすくなるため

・社長に見る目がない(実は面接受けた人がすごい人だった)

・プログラミングスクールのカリキュラムレベル、品質が低いため、カリキュラム内容をこなしただけでは、世の中で必要とされるスキルレベルに到達できない。

・プログラミングスクールのカリキュラムがどんどんわかりやすくなっており、自分で考えなくても、ほぼ答えにたどり着けるため、考えるスキル、調べるスキルが身につかない。

・プログラミングスクールで数少ない自分で考える課題についても、少し調べれば課題の回答があふれており、それをコピペすれば動いてしまうので、スキルが身につかない(公式ドキュメントを調べながら苦労するという経験をすることがない)

・世の中で求められているスキルレベルがどんどん上がっており、スクールのカリキュラムが世の中を求めるレベルに到達していない

・プログラミングスクールのカリキュラムが終わらせることに重点をおいており、カリキュラムでつまった人に対してメンターが答えて教えてしまい、自分で調べたり、自分で理解したりするスキルが足りない。

・テクニカルスキルの他にコミュ力のようなヒューマンスキルも必要なんだけど、そういうスキルが低い人が多い。

 

とりあえずこんなところで。

 

もうちょっと時間置いて、他の要因も考えてみることにする。