メモ：自由にソフトウェアを作る課題で気をつけて欲しいこと

next49 @next49

学校の課題で「自由にソフトウェアを開発すること」というのが出たならば、プログラムに覚えありの学生を除き「自分が非常によく知っている事柄、かつ、面倒なことや時間のかかることがあり困っていること」を少しでも良くするためのソフトウェアを開発するべき。

next49 @next49

達者なコーディング能力や卓越したデザイン力を持たない凡人にとって、先達や既存のソフトウェアと戦える点は「自分が欲しいと思っているソフトウェアに関して詳細な点まで列挙できる」という点しかない。ソフトウェアの使い勝手は細かい点によって大きく変わることが多い。

next49 @next49

（承前） その細かい点を具体的に思い浮かべられるかどうか、気づくかどうかがとても重要。そのような細かい点を思い浮かべるには、「自分が非常によく知っている事柄、かつ、面倒なことや時間のかかることがあり困っていること」が題材として最適。

next49 @next49

自分があまり知らないけど、流行っているもの。自分は困っていないけど他人が困っているものは、自由作成ソフトウェアの題材としてはいけない。ソフトウェアの使い勝手を決める細かい点への想像力が追いつかず、中途半端なソフトウェアしか作ることができないため。

next49 @next49

次に、プログラミング経験が少ない学生は、ソフトウェアの用途、可能ならばソフトウェアへの要求（要件）をはっきりとさせてから、使用するプログラミング言語やツール（ライブラリー）を決めたほうが良い。理由は、言語やライブラリの勉強の途中で用途を見失って、道具に振り回されてしまうから。

next49 @next49

コーディングも要求分析（要件分析）、機能定義が終わってから行った方が良い。理由は同じく道具に振り回されるから。言語やライブラリーの使い方を学びながら開発するため、「作るべきもの」がいつの間にか「道具ができること」へと変質させられてしまう。要求と機能は地図とコンパスの役割を果たす。

next49 @next49

アジャイル開発（インクリメンタル開発）は、道具に熟練した人が行うこと。道具の使い方すらおぼつかない人は、アジャイル開発をしない方が良い。特に発注者＝開発者の場合は、プロトタイプを見せるまでもなく、欲しいソフトウェアについて理解しているわけなので、要求分析と機能定義をきっちりやる

next49 @next49

一方で、コーディングはステップバイステップで行う。簡単そうで小さい機能からコーディングすべき。学校の課題の場合は、言語やライブラリの使い方を開発しながら覚えることが多いわけなので、いきなり複雑で難度高いところに取りかかってはいけない。ドラクエ的にスライムから大魔王へが鉄則。

next49 @next49

課題で小さなソフトウェアを作るような学生にとって、要求と機能の違いは理解できないかもしれない。利用者の目線で「これを満たしていなければ私が欲しいものとは言えない」という条件が要求。開発者の視点で「要求を満たすためにシステムが提供しなければならない働き」が機能。

next49 @next49

要求がWhatの羅列。機能がHowの羅列。WhatとHowを分ける理由は、1つのWhatに対して複数のHowがあり得るから。 詳しくは http://d.hatena.ne.jp/next49/20100309/p2 に書いた。

next49 @next49

自由にソフトウェアを作る課題において、学生がやってしまいがちなのが、「自分が作れるものから逆算して要求をでっち上げる」ということ。たいてい、そういうことやる学生はプログラミングが苦手なので、とってもつまらない役にたちそうもないものが出来上がる。それは良くない。

next49 @next49

すべての学生に高い完成度のソフトウェアを作ってもらいたければ、作るソフトウェアに関してある程度の制限をして要求の自由度を下げる。自由に作って欲しいというのは、「作る必要性」から自分の頭で考えてほしいということ。そのソフトウェアを生み出す物語を自分の頭から生み出してほしい。

G座Ｙ一先生の親友@空想上 @syakekan

研究一般にいえる RT @next49 自由にソフトウェアを作る課題において、学生がやってしまいがちなのが、「自分が作れるものから逆算して要求をでっち上げる」ということ。たいてい、そういうことやる学生はプログラミングが苦手なので、とってもつまらない役にたちそうもないものが出来上が

坂東α @bando_alpha

苦手ならそっちの方向に進まないだろうからいいじゃねえか RT @next49 自由にソフトウェアを作る課題において、学生がやってしまいがちなのが、「自分が作れるものから逆算して要求をでっち上げる」ということ。たいてい、そういうことやる学生はプログラミングが苦手なので、とってもつま

next49 @next49

はい、一方でベテランはHowから隣接分野のWhatを選んで新たな研究テーマにチャレンジ。で新たなHowを手に入れるということをのこぎり型に繰り返し、研究生活を続けていたりします。一概に悪いことでもないわけです。 @syakekan 研究一般にいえる

next49 @next49

まあ、そうなんですが。今は苦手でも、未来では大好きになっているかもしれないので。 @bando_alpha 苦手ならそっちの方向に進まないだろうからいいじゃねえか

坂東α @bando_alpha

その時頑張るんじゃないですかね。そこで無理にチャレンジさせて出来なくて単位を落とすほうが向こうも迷惑で、それならシラバスで「詰まらなければ単位はやらない」と警告したほうが親切 RT @next49: まあ、そうなんですが。今は苦手でも、未来では大好きになっているかもしれないので。

シミヅ（鎌田） @shimiz_mckendiz

これ普遍的知見だわ。ゲームでもボドゲでも何でも当てはまるQT @togetter_jp .@next49 さんの「メモ：自由にソフトウェアを作る課題で気をつけて欲しいこと」が500PV超えましたよー。内容が気になるよね！。 http://togetter.com/li/65305

S.A.M. @SAM_tak

ソフト作りで何が一番難しいかってプログラミングそのものじゃなくて「何を作るか（仕様の決定）」だよね〜 RT .@next49 さんの「メモ：自由にソフトウェアを作る課題で気をつけて欲しいこと」をお気に入.. http://togetter.com/li/65305

イネーガァ @xo_answer

@next49 何に困っているかどうすればいいかわかっていれば ソフト開発以前に他の方法でも解決できているはず。 そして汎用性のあることならば誰かがやっているはずで それが無いというのは敷居が高いということ。

next49 @next49

そうですね。あと、何をソフトウェアで支援して、何は支援しないかを決めることも難しいですよね。 @SAM_tak: ソフト作りで何が一番難しいかってプログラミングそのものじゃなくて「何を作るか（仕様の決定）」だよね〜

next49 @next49

そうですね。とりあえずソフトウェア作れば良いというわけではないですね @xo_answer: 何に困っているかどうすればいいかわかっていればソフト開発以前に他の方法でも解決できているはず。そして汎用性のあることならば誰かがやっているはずでそれが無いというのは敷居が高いということ。

next49 @next49

計算機科学系の学生ならば、卒業するまでにアルゴリズムとプログラミング言語、データとコード、データと表現の違いをはっきりと認識しておいた方が就職してからハッピーだと思う。1つのプログラミング言語しか触っておらず、長いプログラムを書いたことのない学生は、混同しがち。

カワタカトレーナー（馬名っぽい） @kawataka7cdb

エクセルで競馬予想結果の集計用マクロを作った時は確かにこの発想だった.@next49 さんの「メモ：自由にソフトウェアを作る課題で気をつけて欲しいこと」をお気に入りにしました。 http://togetter.com/li/65305

next49 @next49

既にアナログに存在する道具ややり方を置き換えるソフトウェアを作る場合には、その道具が必要とされる本来の目的からトップダウンで、ソフトウェアに必要とされる要求を考えること。なぜならば、現在の道具の使われ方は、その素材や構築方法に制限を受けた結果かもしれないため。