今日もプログラマになる勉強する人のところで話をしてきました。

で、また適当にいろいろ書いてました。

http://www.slideshare.net/nowokay/20140228-31742219

今日は特に、この図の内容についてまとめておきます。



※ このエントリは、主に今日の話を聞いた人を対象としています。前提や補足については省略しています。





利用者はユーザーインタフェースを経由する コンピュータの上にプログラムを載せたとしても、ユーザーはそれを直接さわるわけではありません。なんらかのユーザーインタフェースを介して、ユーザーはコンピュータ上のプログラムを使います。

そこで、プログラムを利用してもらうためには、ユーザーインタフェースについて勉強しておく必要があります。

これは、UI/UXという話題になります。

デザイナと分業されている分野でもあるので、深く知る必要はあまりないですが、基本的なことは踏まえておく必要があります。





ユーザーの要求を汲み取って作るものを決める そういったプログラムを作成するのですが、その前にユーザーが何を求めているかを知る必要があります。実際のユーザーや想像上のユーザーが何をするか観察したり聞き取りをしたりして要求を見出します。

この、要求の見出し方などの勉強も必要です。

SIerというのは、だいたいこのあたりの作業を行って、実際の作業を下請けに出したりします。





要求は直接プログラムに落とせないので作業に段階がある 要求を見出せたとしても、要求から直接プログラムに落とし込むことはできません。仕様を決めて、設計して、プログラムコードを書いて、テストをして、という手順に分解して作業をすすめます。

このそれぞれの作業について、さまざまな手法があります。少なくとも代表的な手法は勉強しておいたほうがいいでしょう。

また、これらの作業をどのように進めるか、というプロセスも大事です。

一番単純で基本になるのが、仕様を決めて、設計して、プログラムコードを書いて、テストをしたら完成のように、各手順を一回ずつ順番に行うのがウォーターフォールです。

ただ、プログラムというのはプログラムコードを書いて初めてわかることが多く、最初の仕様ですべてを決めておくことができません。そこで、最初に小さいウォーターフォールをまわして、その結果をもとに改めて仕様を決めて、と繰り返し作業を行いつつ作るものを大きくしていく、スパイラル形式のプロセスもあります。

また最近ではこれらの作業をフレキシブルに組み合わせたものもあります。





複数で開発するとコミュニケーションが必要 プログラムを作成する手順がわかったとしても、プログラムはひとりで作ることは少なく、また一人で作るとしても作業管理などが必要になります。

複数のプログラマが作ったソースコードを共有する必要もあります。

どんな作業をだれがいつ行うか、だれがどんなコードを書いたか、といった技術的な情報のコミュニケーションが必要になります。



