JVMツールの簡単インストーラー、sdkmanのことを紹介させてくれ

f:id:blackawa:20171003133129p:plain

SDKMAN! the Software Development Kit Manager

この完全に他のツールとかぶりそうな名前、かつアメコミみたいなアイコンのツールが、まー便利。 わりと前からあるから、みんな知ってるかもしれないし、そもそもこのツールについて人と話したことがあんまりない。けど、個人的に紹介したいからさせてもらう。

sdkmanとは

インストールすると、sdk install xxx みたいな感じでJVM系の各種ツールをインストールできるツール。

なんとJavaもインストールできる。

もうこれで良くない？

使い方

Installation - SDKMAN!を読んでくれ。 brewのインストールと同じでインストールスクリプトをbashで実行するだけ。ちょう簡単。 .bashrcとか.zshrcの末尾にちょっと勝手に追記されるから、それだけ確認しておいて。

試してみる

手元のMacはすでに環境構築済みなのでVagrantで建てたubuntuで試す。

vagrant init ubuntu/xenial64
vagrant up
vagrant ssh

# ここからubuntu
curl -s "https://get.sdkman.io" | bash
# unzipコマンドがないよって怒られる。実はunzipを入れても次はzipがないよって言われるので入れておく
sudo apt-get install unzip zip
curl -s "https://get.sdkman.io" | bash
# インストール成功して.bashrcと.zshrcの末尾にちょびっと追記される。
source "/home/ubuntu/.sdkman/bin/sdkman-init.sh"

# インストールできたか調べる
sdk version

# Javaをインストールしてみる
which java # -> 何も返ってこない
sdk install java 9.0.0-zulu
which java # -> /home/ubuntu/.sdkman/candidates/java/current/bin/java
java --version
# openjdk 9.0.0.15
# OpenJDK Runtime Environment (Zulu build 9.0.0.15+181)
# OpenJDK 64-Bit Server VM (Zulu build 9.0.0.15+181, mixed mode)

# Mavenもインストールしてみる
which mvn # -> 何も返ってこない
sdk install maven
which mvn # -> /home/ubuntu/.sdkman/candidates/maven/current/bin/mvn

# 動く
mvn archetype:generate # 当たり前だけどすごい

簡単すぎ。Javaインストールできるってすごい。

既存のツールが入っちゃってる人へ

消して。

brewで入れたなら brew uninstall xxx しよう。 Windowsならバイナリを消して環境変数PATHに入れた設定とかを消せばいいんじゃないかな。

Macならbrewとかportとかあるから、こういうのは特にWindows勢にとってめちゃめちゃ強力なツールになると思うな。

Overtone始めたらClojureのシーケンス操作の哲学にマッチしすぎててスゲー！ってなった話

とうとうライブができるプログラマーになることにしたので、Overtoneを始めた。

目標

  • (SHOULD)音作りを雰囲気だけかじる(ここは今回重要でない)
  • ドラムで軽やかなリズムを奏でる
  • ドラムに合わせてメロディが流れるようにする
  • だんだん音を足していく
  • (SHOULD)フィルターをかける

これくらいできればなんかそれっぽい感じになるでしょ。

始め方

github.com

を読んで頑張ろう。変化に耐えられる心を持てってwikiに書いてあったから、変化に耐えられない日記はポインタと化します。

使い方メモ

definst

楽器(というか音色)を定義できるっぽい。デフォルトでもいろいろあるけど。

ctl

今鳴っている音に対して変更をかけられる。なんかライブっぽくてかっこいい。 フィルターをだんだんかけていく、みたいなのもこれを使えるのかな。

(definst quux [freq 440] (* 0.3 (saw freq)))
(quux)
(ctl quux :freq 660)
;; => 1オクターブ上がる
(stop)

sample

サンプリング音源を鳴らす。 freesoundっていう無料音源サイト？からダウンロードすることもできるみたい。 コマンド叩いたらブラウザが開いて、ログインを求められた。面白い。

(def water-drops (freesound 50623))
(water-drops)
;; => 水音が鳴る
(stop)

この音を加工したりもできるんだろうな。

play-chord

コードを鳴らす。

(defn play-chord [a-chord]
  (doseq [note a-chord] (saw2 note)))
(play-chord (chord :C4 :major))

すごい。 chordはdoseqできるみたいだから、多分 chord 関数はシーケンス生成してるんだな。 実装見たら実際そうだった。すごい。こんなところでClojure likeなシーケンス操作が出てくるなんて！

ってことは、chordはシーケンスだから複数のコードを合成する、みたいなこともできるのか。 たとえばCmM7を鳴らしたい時は、

(let [minor7 (chord :C4 :m7)
      major7 (chord :C4 :M7)]
  (-> (concat minor7 major7)
       distinct
       play-chord))
;; =>  不穏な音

play-chordされる前の Set シーケンスの中身を見てみたら合ってそう。 こんなに簡単に複雑なコードを鳴らせるなら、ジャズが捗りますな(雑な偏見)。

metronome

ビートを定義する。

(defonce metro (metronome 120))

(metro) すると今のビートが取れるようになる。これを渡して、at関数で任意のタイミングでビートが鳴らせるようになる。

(defn chord-progression-beat [m beat-num]
   (at (m (+ 0 beat-num)) (play-chord (chord :C4 :major)))
   (at (m (+ 4 beat-num)) (play-chord (chord :G3 :major)))
   (at (m (+ 8 beat-num)) (play-chord (chord :A3 :minor)))
   (at (m (+ 14 beat-num)) (play-chord (chord :F3 :major)))
   (apply-at (m (+ 16 beat-num)) chord-progression-beat m (+ 16 beat-num) []))

けっこう冗長だから、もっとシンプルに書けそうだな。

とはいえ、これを実行すると延々けっこうきれいなコード進行が鳴り続ける。プログラミングで実現してるなんて。すごい。 しかもこれはシーケンスを解釈してるだけ。なんてこった！シーケンスすげぇな。

これの実行中は、関数を再定義すると apply-at された時に定義が書き換えられて新しいコード進行が始まる。

さらに別の、たとえばドラムトラックを書いて評価すれば、それがメトロノームに合わせて演奏される。

metro-npm

metronomeの内容を書き換える。つまりテンポを変えられる。

そういえば小節の概念がないな。 多分、ループを作った時のapply-atするタイミング次第で変拍子でもなんでもいいんだろうな。

わからないこと

sc-ugenっていうオブジェクトを足し算したり掛け算したりするサンプルコードの意味がわからない。 SuperCollider Unit Generatorのことらしいから、SuperColliderをちょっとさわってみないといけないのかな。

あとは、そもそもオシレーターってなんだっけ？？SAWって波の形だよね？みたいなレベルで音楽用語がわからない。 DAWさわっててもギター弾いてても曲書いてても、わからないことだらけだぁ。

https://github.com/overtone/overtone/blob/master/docs/ugens.mdを見てる限りは、サンプルコードに出てきて宣言元を辿れないやつはこのsc-ugenオブジェクトだったから、ugensのページに対応するものがありそう。

Clojureを書く時についつい忘れがちなキーバインドまとめ

最近2ヶ月ぶりくらいにClojureを書き始めたら、手癖で覚えてるキーバインドもありつつ、なんかここらへん押せばいいって手が勝手に動くけどちょっと違うらしくて動かない、ってやつもあり。

毎回思い出すのつらいからまとめることにした。

キー 起こること
<C-c><M-j> REPL起動
<C-c><C-q> REPL停止
<C-c><M-n> 今カーソルが開いているnamespaceに、REPLを移動させる
<M-.> 宣言に飛ぶか聞かれる
<M-,> <M-.>で飛んだ元に戻る
<M-s> 今カーソルがある位置から見て直上のカッコを消す

archetypeをMaven Central Repositoryに登録する

f:id:blackawa:20170929020542p:plain

作ったarchetypeをMaven Central Repositoryに登録した。 Railsくらいとはいかなくても、せっかくSpringはモジュールが揃ってるんだから、プロジェクト作成した瞬間に機能の雛形が手に入る世界を作りたい。

やったこと

  • JIRAチケットを切る。
  • 鍵生成する。
  • Maven Central Repositoryに登録する。

チケットを切る

Maven Central Repositoryにリリースするには、まずSonatypeのOSS Repositoryに登録してそこでリリース資材を作るとMaven Central Repositoryに同期されるっぽい。

ので、まずSonatype OSS Repositoryに登録する。ために、チケットを起票する。

http://central.sonatype.org/pages/ossrh-guide.htmlにあるとおりにする。ここで手順書いてもいつまで正しいかわからんし。 書くべき項目がいくつかあるのでそれを守る。 チケット種別に気をつけて。

ちなみに今回起票したのはこのチケット。ご参考までに。 [OSSRH-34598] spring-bootstrapping-archetype - Sonatype JIRA

返事が来るのを待つ

自分のドメイン blackawa.jp をgroupIdに指定したら、「ほんとにそのドメイン持ってる？別にgithub.ioドメインとか使っていいんだよ」ってコメントがついて、「もってるよ。なんか証明書類必要なら教えて」って言ったら承認された。

承認されるとSonatype OSS Repositoryにjarをアップロードできるようになったよ、ってコメントがつくので、そしたらアップロードできる。

GnuPG鍵を生成して登録する

アップロードするためには、鍵を作って鍵サーバーに登録し、jarに署名しないといけない。 Working with PGP Signaturesで言われたとおりにする。正直よくわからん。

Maven Centralのstagingにデプロイする

~/.m2/settings.xmlを以下のような内容にして mvn clean deploy する。 これがちょっとわかんなくてハマった。

ossrhの方のid/passwordはチケット起票した時にログインしたJIRAと同じやつってどこにも書いてなかった気がするけど雰囲気で入れてみたらそうだった。 英語斜め読みしかできないから多分見逃した。

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
  https://maven.apache.org/xsd/settings-1.0.0.xsd">
  <servers>
    <server>
      <id>ossrh</id>
      <username>blackawa</username>
      <password>*****</password>
    </server>
    <server>
      <id>gpg.passphrase</id>
      <passphrase>*****</passphrase>
    </server>
  </servers>
</settings>

deployできたらhttps://oss.sonatype.org/#nexus-search;quick~spring-bootstrapping-archetypeで検索にヒットするようになる。 そしたらJIRAチケットにコメントがついて、maven central repositoryには10分後くらいに、search.maven.org には2時間後くらいに反映されるよ、と教えてもらえる。

ハマりどころ

鍵情報がないのもログインできないのも全部401 Unauthorizedしか言われないのがちょっとしんどかったけど、分かれば大したことなかった。 pom.xmlけっこうちゃんと書かないといけない。けどそれはちゃんと具体的に怒られるから良かった。

参考

https://maven.apache.org/guides/mini/guide-central-repository-upload.html http://central.sonatype.org/pages/apache-maven.html http://central.sonatype.org/pages/working-with-pgp-signatures.html

自分用のスクラムツールを、自分のドメインにHTTPSで立てる

f:id:blackawa:20170927160905p:plain

自分用のタスク管理ツールがHTTPSで立ってるってカッコイイなと思って、実際やってみた。

実は1年に1回くらい思ってて、毎回挫折してた。今回初めて成功したことになる。嬉しい。

やったこと

https://taiga.io/)をblackawa.jpのサブドメインに立てて、HTTPS化する。 そのために、Certificate managerで証明書を発行する。 Route53 -> Elastic Load Balancer -> EC2の経路でアクセスさせる。 HTTPへのアクセスがあった時HTTPSにリダイレクトさせる。 taigaのユーザー登録機能を切る。

手順

EC2だけで動かす

taigaが公開してるドキュメントに、インストール用のスクリプトを使う手順があるのでそれをチラ見する。 ubuntu用に書かれてるので、EC2のt2-microでubuntuを立てて手順に従うと、数分でtaigaが起動する。 具体的には、nginx -> circus(gunicorn) -> django の構成のWebアプリケーションが、circusctlで起動する。

EC2の(Elasticじゃない)IPとURLで80番ポートにアクセスすると画面が見れる。

今回はELBを立てるので、Elastic IPの取得は不要。(僕は一度取得してしまったので後から消した。)

Route53でサブドメインを切ってEC2とつなぐ

ネットワークよくわからないけど、Hosted Zoneの子要素としてRecord Setというのがあって、こいつを足すことでサブドメインにアクセスが来た時に違うIPに通信を流すことができるぽい。 work.blackawa.jp にアクセスされた時用の「Aレコード」を切る。宛先はエイリアスなしで、一旦EC2のIP。

たしか反映されるのに数分タイムラグがあった気がする。

nslookup work.blackawa.jp

と打って、「いやそんなん知らんわ」と言われなくなったらOK。 逆にnslookupして名前解決できてなさそうならRecordSetの設定内容を見直す。

ブラウザからアクセスすると画面が見れるはず。

証明書を取る

次はELBを立てたいので、証明書を取得する。最初 let's encrypt を使ってみようかと思ってたけどAWS先生がやってくれると聞いてそっちにした。 ここがけっこうハマった。

証明書を取るには、 1. 証明してほしいドメインを指定して申請する 1. 確認メールを受信する 1. メールを開いて「Approve」ボタンを押す

という手順を踏む必要がある。この「証明してほしいドメインを指定して」ってのと、「メールを受け取る」っていうのにハマった。

メールは admin@blackawa.jp に飛んでくる

お名前.comならメール転送サービスが使えるからそれを設定しておく。 あと、Route53にお名前.comのメールサーバーに向けたMXレコードを追加する必要がある。これがないと転送が効かない。

反映されるのにちょっとかかる。自分で admin@blackawa.jp にメールを投げてみて届くようになればOK。

サブドメインを「別名」に指定する

証明書を申請する時、ドメイン名を指定できる。 ここに work.blackawa.jp と入れると、メールが admin@work.blackawa.jp に飛んでくるが、お名前.com的にはそんなサブドメインは知らないので当然転送サービスで転送できない。 だからといってドメインを「blackawa.jp」にすると、それで手に入れた証明書を使っても「証明されてるドメインとURLのドメインが違うからこれ危険やで」とブラウザに怒られる。 そこで、ドメインは「blackawa.jp」にしつつ、別名で「work.blackawa.jp」を指定する。 するとメールは admin@blackawa.jp に届き、かつサブドメインで使っても怒られない。

ただ、今にして思うとサブドメインにワイルドカードとか使えたのかな？とか思う。たとえばblog.blackawa.jpを増やす時証明書を申請し直すのめんどくさそう。

ELBを立てる

ここも結構ハマった。

こいつはHTTPSかHTTP、もしくはその両方を受け取ってくれる。 どこにどのプロトコルで転送するかは、ELBの子要素である「ターゲット」が知っているのでELBは使用するターゲットを指定するだけ。

...なように見える。正直よくわからん。

ターゲットはHTTPでEC2に通信を転送させる

最初、「HTTPS化だしここもHTTPSにしとけばええやろ」と思ってHTTPSにしたら502 Bad Gatewayが出て困った。nginxのログにも出ないし。 仕組みを想像したらここはHTTPのままで良いのでは？と気づいて直したら動いた。

Route53をELBに向ける

ここは簡単。新しいAレコードを追加すればOK。

ここまでやると、HTTPSでサブドメインにアクセスして画面表示ができるはず。できなければ通信がどこまでたどりつけたか調べながら頑張れ。

  • nslookup が結果を返すならRoute53が名前解決してくれてる
  • Bad GatewayならELBとEC2でリクエストとレスポンスがうまくできてない
  • EC2のURLにアクセスして表示できるなら、EC2インスタンスとアプリケーションはうまく動いてる
  • 証明書エラーならCertificate Managerに申請したドメインとサブドメインが一致してない可能性あり

くらいかな。

HTTPで通信されたらHTTPSにリダイレクトする

Redirect HTTP Traffic to HTTPS Using ELBを読んで頑張る。 他にもQiitaにも日本語でこれと同じことが書いてあったりするから読んで頑張る。

まぁよくあるパターンで、ELB経由でHTTP通信が飛んで来る時はリクエストヘッダーに特定のキーが付与されてるからそれをチェックすると良いよ、ってやつ。

アカウント開設できないようにする

これはtaigaの話だけど、 Taiga: Setup FAQs and common bugsにあるとおり、taiga-backとtaiga-frontそれぞれの設定を書き換えることで無料アカウント登録の口を閉じられる。 これをやっておかないと知らない人がアカウント作れちゃうので。

ここまでやれば、https://work.blackawa.jp みたいなことができる。嬉しい。

今後の展開

自前で建てたアプリなのにHTTPSで、ブラウザのURLバーが緑色に輝くのは、正直QOL上がる。みんなやろう。

今後はブログを子URLにするのと、監視基盤入れてみたいな。 あと、次にドメインを買う時はお名前.comじゃなくてAWSで買おう。

塩漬けだったblackawa.jpにS3とRoute53で自己紹介ページを置く

f:id:blackawa:20170927160431p:plain

しばらく前に買って放置していた blackawa.jp を、とうとう使い始めることにした。 というのも自分用にスクラム管理ツールを立てたくなったからで、今回の話はオマケではある。

やったこと

これまで「このドメインはお名前.comによって管理されています」としか出なかったblackawa.jpにアクセスした時、blackawa | Programmerが閲覧できる。

そのために、ドメインのDNSサーバーをRoute53に指定し、S3に向ける。

前提条件

  • ドメイン blackawa.jp はお名前.comで購入済み。

手順

S3を立てる

S3に新しいBucketを立てる。ドメイン名と同じ名前のBucketを作り、Web Hostingを有効にすると良いらしい。 indexページとerrorページを尋ねられるので、index.htmlとかにしておけばいいと思う。

で、index.htmlを置く。僕はこれの公開範囲をいじらないとS3のURLから見られるようにならなかったので、なんか設定が足りなかったのかも。

ここでは、S3のURLからindex.htmlが見られるようになればOK。 S3のURLはなんか命名ルールがあるから調べて。

Route53を立てる

AWSコンソールでRoute53にアクセスして、新しいHosted Zoneを立てる。立てるとDNSサーバーのURLが4つ発行される。 Route53ではIPアドレスを指定できる他にもELBとかS3にエイリアスを張れて、今回は当然S3へのエイリアスを張る。

お名前.com側で、blackawa.jpにアクセスした時にRoute53で名前解決するように指定する

今度はonamae.comにアクセスし、使うDNSをRoute53のDNSサーバーに書き換える。 更新したらしばらく

nslookup blackawa.jp

を叩き続ける。表示が変わったら実際に切り替わってるはず。 ブラウザからblackawa.jpにアクセスしてみて思ったとおりの画面が出てればOK。

お疲れ様でした。

ハマりどころ

ブラウザにアクセスしても出ないことがあった。 けど、 - blackawa.jpは名前解決されているか？ - S3のHTMLは誰でも見られるか？

を確認すればどこが悪いかわかるのでそこまでハマらなかった。

参考資料

忘れた。

今後の展開

はてなブログか自前で立てたブログサーバーも blackawa.jp 配下に配置したい。 はてなブログのデザインがあんまり好きになれないから、勉強がてら立ててもいいかなって思ってる。

解くべき問題を探すには、優れた質問を探すのだ | アート・オブ・プロジェクトマネジメント

前章で、スケジュールについての理解は深まりました。 次はこのプロジェクトでどのような問題をどうやって解決するのか決めなければいけません。つまり計画フェーズです。本章では「計画」を、いわゆる要件定義と設計をセットにしたものとして扱っているようです。 どうやって計画を立てれば良いのでしょうか？

自分の受託開発での仕事の流れを思い返すと、作成する要求定義ドキュメントの定義について顧客との間で取り決めが交わされていました。でもあのドキュメントの定義ってどんな基準で作られたのでしょうか。雛形があるとしたらそれはどんなロジックで決められたものなのでしょうか。

ソフトウェア計画の因数分解

ソフトウェア計画は、大きく2つの項目にわけられる、と本著は言っています。それは、

  • 何を行う必要があるのか？(要求の洗い出し)
  • どうやってそれを行うのか？(設計)

の2つです。 そしてこれら2つの作業の内容は、組織のスタイルとプロジェクトの規模によって変化します。 組織のスタイルについては、要求事項・設計内容・技術的チャレンジ・予算への決定権の持ち主が誰かによって必要な作業内容や合意を取るべき人が変わることを言います。 また規模については、1人プロジェクトなら本当に大切なことだけをドキュメントにまとめておけば十分かもしれません。一方、『人月の神話』のブルックス先生が論じたような新しいPCの開発なら、すべてをドキュメント化するくらいの勢いでないと1人1人が何をすべきか全くわからなくなってしまいそうです。

上記のことを踏まえたうえで、本著では計画フェーズの成果物として以下のドキュメントを作成することを提供してくれています。勿論各プロジェクトによって変更すればいいのですが。

  • 市場要求ドキュメント
  • ビジョンのドキュメント
  • 仕様書
  • WBS

市場要求ドキュメントはビジネス機会についての文書、ビジョンはプロジェクトがなにを達成すべきなのかや大きなレベルでの要求などが定義された文書、仕様書はビジョンを実現するためにもう少し細かい部分について、各部分がなにを実現すべきなのか定義したドキュメント、そして最後にWBSは、仕様を満たすための作業の予定をチームメンバー全員が決められるようにするためのドキュメントです。

計画の3つの視点

上記でまとめたものには、ビジネスとしての観点とエンジニアリングとしての観点が両方入っています。本著はこれら2つの視点を、大抵のプロジェクトにおいて相反するものであると述べていますが、同時にこれらの視点が競合することは計画フェーズの失敗のもっとも基本的なシグナルであるとも述べています。計画フェーズでチームは、すべての視点に立つメンバーが貢献できるような計画を立てるべきなのです。

ではチームがどのような状態であれば、正しい計画を立てられているといえるのでしょうか？ Scott氏は、それぞれの視点についてのある質問に答えられるかどうかを試金石とできると述べます。

ビジネス視点でみた計画

エンジニアから見て営業さんやビジネスサイドは、時たま特定の顧客の要望を丸投げする人に見えたりすることもあるかもしれません。しかしビジネスサイドの彼らが自分たちの組織の損益計算書を増益で終わらせる努力をしてくれるから、みんながお給料をもらえていることには、チーム全員が自覚的であるべきです。

チームがビジネス視点で計画を立てられているかを測るためには、以下のような質問が有効です(本の中にはもっとたくさんの質問が載っています)。

  • 顧客のニーズはなにか？
  • コストと、それに対して見込める利益はどれくらいか？
  • いかにして競合他社を出し抜くのか？

技術視点でみた計画

技術的に優れている結果顧客のニーズを満たす商品であれば最高ですが、単に技術的に優れただけの商品では売れません。エンジニアリングに携わるメンバーは、自分の仕事への審美眼を持つことは素敵なのですが、それだけに傾倒してはいけません。 顧客のニーズを満たすものを、最高の方法で実現するための計画になっているかは、以下のような質問で確かめられます。

  • このコンポーネントはどのようなインターフェースを持つのか？
  • このシステムはどれくらいのセキュリティレベル、可用性やパフォーマンスを担保するのか？
  • ある仕組みを実現するためには、どのような技術的な選択肢が考えられるのか？

顧客視点でみた計画

Scott氏は、この視点がソフトウェア計画で最も重要であり、最もないがしろにされがちであると言います。 プロジェクトマネージャは顧客視点での計画立案に長けたメンバーを採用し適切な権限を与えるべきです。彼らは以下のような質問に答えてくれるでしょう。

  • 実際のところ、我々の顧客はどのような作業を行っているのか？
  • どんな不満を感じているのか？
  • ユーザーになんと話せば、このプロジェクトの真価を分かってもらえるのか？

プロジェクトマネージャは3つの視点を操る者

プロジェクトマネージャは、ソフトウェア計画を構成する3つの視点を知ったうえで、それを適切にコントロールしなければいけません。 プロジェクトマネージャは、チームメンバーに各視点の共通点と相違点を理解してもらうことで、我々が時に「カネにならないが技術的に優れたアイデア」や「ビジネス的に最高だが技術的には実現不可能なアイデア」が出てき得るという事実を共有することができます。

また、3つの視点の政治的なパワーにも気を配る必要があります。 人数比は当然大切ですがそれだけではなく、各メンバーの声の大きさにも気を配り、 ある視点だけが強力になりすぎることを抑制しなければいけません。

優れた計画のためには、優れた疑問を探すこと

ソフトウェア計画の3つの視点についての話でもそうだったように、優れたプロジェクト計画には優れた質問が不可欠です。 計画を立てるときには、3つの視点からの質問を自分たちのプロジェクトに合わせてピックアップして回答していくとよいでしょう。しかし実際に疑問として使用するときにはもっと広い視点での疑問が必要です。 本著に書いてある疑問のごく一部を例として挙げておきます。

  • 議論の時に想定される顧客層は誰なのか？
  • 我々は解決したい問題に対して十分な技術力や知識を持っているのか？
  • 競合他社はこの問題に対して何を行っているのか？彼らの戦略はなにか？

勿論、良いソフトウェア計画手法があるならば、一方で悪い手法もあります。たとえば「このパージョンは前バージョンで省いた機能を入れるだけのものだ」など。 どんなに時間がなくてもこのようなパターンにハマってはいけません。

実際の計画の進め方

計画は少数のエキスパートで行うべきです。人数が増えるほど創造性と生産性が下がってしまいます。選出されなかったメンバーは自尊心が傷つくでしょうが、だからといって議論のメンバーを増やすよりは個別に彼らを癒やした方が良いです。

計画フェーズの成果物しての各種ドキュメントは、互いに相関しあいながらブラッシュアップされていきます。 しかし、抽象度に開きのある2つのドキュメントの修正はコストがかかるので、抽象度近いもの同士でフィードバックを行うべきです。

計画の手段として顧客調査を行う場合がありますが、様々な方法があるので適切なものを選択してください。

計画作業の成果として書き出される要求は、叙述的なシナリオになるはずです。ユースケース駆動開発に関する書籍がこのフェーズを助けてくれるでしょう。