アウトプットについて
なぜこのブログを作ったかということを書いておこうと思う。
正直、今までブログをいくつ作っていくつ消したかわからない。学生の頃は、長文を書くといえば小論文とか作文だった。だから、何かきちんとした話題があって、それをきちんと構成しないといけない、と思っていたのだと思う。そういった内なるプレッシャーが辛く、10代のころはブログを作っても、1つ2つ記事をアップしたところで二度と更新しなかったりした。そしてそのうち消して、また何かあったときに開設して、結局消して…ということを繰り返していた。
20代になって、Twitterに出会った。これはすごくハマった。slackも水があった。話題は今この瞬間のことを書けばいいし、なくてもTwitterにログインするだけで自然と言及できるような話題が目に入る。一つ一つの投稿は決して長くはないから構成も気にしなくていい、というハードルの低さも良かったのだと思う。 そうやって合うインターネットサービスを見つけた結果としてどうなったかというと、自分のことがよく分かるようになったと思う。自分が何に怒るのか、何を喜ぶのか、何を好きになるのか。自分の今考えていることや、これまでの行動がどういう考えに基づいているのか、言葉にできるようになった。言葉にできることで、何かを選択するときに、自分にこの後なにが起こるのかを見通せるようになった。だから、疲れる前に休む、なんてこともスムーズにできるようになったと思う。
でも、フロー情報というのは、簡単に一つ一つの投稿が完成する代わりに、達成感がないと思う。Twitterみたいなサービスを使う肝は、続けること、そして細かいことを蓄積することにあると思う。それはできたし、得るものもあった。けれど、それだけじゃ満足できないようになってきた。流れていくものじゃなく、ある程度の「重さ」のあるものをアウトプットしたいと思うになった。
色々考えたけれど、なにがやりたいか考えたときに、やっぱり文章を書きたい、ブログをやりたい、という結論になった。苦手としていたところをチャレンジするのはいい選択だと思ったし、自分自身がブログなどに書かれた文章に助けられてきたのもあって、身近だからだ。
また、そういう結論を出すときに役に立ったのが、小さな習慣という本を知って読んだことだと思う。
この本についてもまた書きたいと思うんだけれども、とにかくこの本の通りに習慣を実践するうちに、いろいろなことをハードルを上げずに始めて、続けることができるようになった。だから、ブログもまず始めて、ちょっとでもいいし大したことでもなくていいから書けばいい、と自然と思えるようになったのは大きい。
……ということを書いてみて、読み返してみて思うのは、すごく文章がかたい。 次回はもうちょっと改善しようと思います。
ユースケース駆動開発をしてみた
これは2年位前に実践したときの記録です。
はじめに
新たにそこそこの規模のサービスを開始することになったので、設計の足がかりにと思って読んだ。今までは既存のサービスを改修する案件ばかりだったので、新しく１つ作るというのは初めてだった。
全部は読んでいない。後半は特にspringの説明が多くなってきたので興味が湧かなかったのと、アーキテクトなどはある程度もう決まっていたので、読んでも参考になりそうにないと思ったから。
実際読んだのは以下の章。
実践した感想
ドメインモデリング
やっている時に気をつけたこと
最初に作る時は特に、完成させようとしない。クラス図やER図とは別のものとして考える
所感
今の現場には用語集や設計図、モデルの図などの資料がかなり少なく（メンテされている資料はほぼなかった）、ドメインの概念を口伝や実装の中で教わることが多かったので、入った時にはかなり苦労したという経緯があって、実際にドメインモデリングをする時には、今回の開発対象以外のドメインも含めたドメインモデルを作成したが、今後の資料としてかなり使えるものができたと思う。
この本では、一旦ドメインモデリングをした後、後の工程で議論された内容を反映しつつ完成させていくということになっている。実際にやってみたところ、開発対象のサービスのドメインモデルが洗練されていき、チーム内で、概念的な部分で理解が一致していくのを感じた。話しながら「こういう構造だったのか」と気づく部分も多かった。
このドメインモデルを作る前は、「わからないものを開発する」という、何か薄闇の中で話し合っているような感覚だったが、一通り完成した後のチームの雰囲気は明るかったように思う。
ちなみに、事前に一人でドメインモデル作ってみてましたが、チームで最終的に合意したものとはかなりズレました。
ユースケースモデリング
やっている時に気をつけたこと
- ユースケース図を描いて、ユースケースを整理する。
- ユースケースを書くときは叙述的に書く。システムとユーザーのやり取りとして書く。どちらのイベントも省略しない。
- ユースケースを書くときはモデリングしたオブジェクトの名前を使う。
- 画面の名前を明らかにする。
所感
ユースケース図とユースケース記述は両方作った方が良いと思った。ユースケース記述を書いている間に、自分が何を書いているのか、今のユースケースはどのユースケースとつながっているのかを見失う瞬間がくるので、図があるとかなり楽。
ユースケースの記述をする前に、ある程度画面の絵を描いたりしたこともあり、画面の想像はできていたつもりだったが、システムの動きでわからないところや、描いていなかったが、存在する画面があることに気づいたりして有益だった。とりあえず書いてしまってあとでみんなで見直すぐらいが良さそうに思った。
画面の名前書くときは絶対「」をつけてたが、めんどくさくてもそうした方がよかった。主語はシステムorユーザーで統一し、システムが主語の文を書いたら、次はユーザーが主語の文を書く、というのを律儀に守ったことで、文章量はともかく、書く作業で迷ったり困ったりすることがなく、比較的楽だったと思う。
代替ケースを出すうちに、仕様の調整が必要な部分が見えてきたりしたので、代替ケースは必須だなと思った。
