takoyaki_umaaaa
edit{{{ comment
<dl>
<dt style="font-size:big;"></dt>
<dd style="font-size:small">
<ol>
<li></li>
<li></li>
<li></li>
</ol>
</dd>
</dl>
}}}
== Notebook
{{{ html
<dl>
<dt style="font-size:big;color:red;">アプリについての意見を聞くための準備ができていない</dt>
<dd style="font-size:small">
<ol>
<li>何を聞きたいのか。聞きたい事項を簡潔に。</li>
<li>なぜ聞きたいのか。経緯。</li>
<li>悩んでいる部分、詰まっている部分について具体的に。</li>
<li>どう対応しようと考えているか。</li>
</ol>
</dd>
</dl>
}}}
=== 区切り線
* 考えをまとめるためにエクセルで絵を描く → 画像形式にしないと Web (Wiki) 上に載せられない、というサイクルが非常に面倒。[[br]]
作成中のアプリ、やっぱり browser上でも動くようにしておきたい。ブラウザからReadme.htmlが作成できれば少しは役にたつだろうか。
* 本当ならサーバー上のhtml fileにリアルタイム更新ができれば一番よかったんだろうけど。とにかく保存が面倒。
* Wikiのような感覚で更新できるのが理想。最近のCloud Driveによる共有のような、"Shared linkを取得して相手に連絡" というのはあまりにも大げさに感じる。[[br]]もし友人から '''「いいかい？よく聞いてくれ！さっきCloud Drive上にExcelで資料を作ったんだ！今からそのURLを伝えるから少し中を確認してくれないか！」'''なんて連絡が入ったら、いったい何があったのかとか、彼をこんなにも焚きつけるものは何なのだろうとか、そんなことばかりが気になって資料の中身なんて頭に入ってこないことだろう。
* 資料を編集したらWeb上に表示されている資料もすぐに反映される形が理想。仕事でなら「レビュー済みかどうか」「前回正式版からの変更点一覧は」とか気にする必要があるだろうけど。
=== 区切り線
* "そのページに埋め込める" ということが非常に大事なんだと思う。設計書にしても、いくら丁寧に関連文書にリンクを貼ってもそれを辿る人は非常に稀だ。レビュー中なんて、関連文書にリンクがあっても「分かりにくい」「初めは概要から入るべきだ」なんて言われて、基本設計書に似たような図があるのに詳細設計書の冒頭にまで同じような図を入れたり。そして一部機能に修正が入ったら、その似たような図を描いている資料を全部修正して回るなんてホントに時間の無駄。同じようなことを何回も書いているだけでいいならそれでいいんだけど、こっちの実作業時間が削られるばかりだから。
* 「同じことを何度も書かない」なんてソースコード上でなら当たり前のようにやっているはずなんだけど。設計資料(の媒体)もオブジェクト指向で作れるように考えればいいのだろうか。
* 使いまわしができるという点でTiddlyWikiをしばらく使ってみたものの、資料がまとまらなかった。ずっと発散していく感じ。自由度が高いのはありがたいが、自分のように計画性がない人間が使う場合はもう少しガイドラインが欲しいと感じた。
=== 区切り線
* 最近の写真編集アプリの流れなのかは分からないが、既に決められたフレームに手持ちの写真をはめ込むだけでストーリー性のあるアルバムができるというもの、手軽に見た目の良い出力が得られるので受けが良く、良さそうだと感じた(出力結果はどれも似た感じになってしまうが)。
* 作成中のアプリも「手間をかけずに資料が作れる」ものを目指したいと考えているので、こういうアプリは参考にしたい。
* そういえば出力される資料はどれも似たようなものなのかもしれない。そのページで何を伝えたいかが明確になればほとんど使いまわしでなんとかなるのだろうか。
=== 区切り線
* ソースファイルの命名規則
* どれとどれの名前を同じにするか
* 何を基準に資料を作るか (説明したい内容を漏れなく説明できるか)
* DOM tree基準
* ソースファイル基準
* モジュール構成基準
* それぞれの図の関連図
* 目的，方針
* 要件一覧
* 実現方法
* 機能分割
* モジュール分割
* 責務とあるべき姿
* 管理する情報
* 変換する内容，情報の増減，そこで情報が変化しても問題ない理由
* 必要な手続き
* 発行会社の認定が必要とか
* 既存のプロセス以外に何か必要とか
* 工場の生産ラインプロセスに追加が必要になる……などとなるとソフトのインパクトが小でもプロジェクトのインパクトは大になる
* 基本設計