状態遷移表を作る
つくる！
- イベントリスト作成
- 状態遷移図作成
- 状態遷移表作成
の順でつくります
イベントリスト作成
仕様書から、イベントとアクションを見つける。
- イベント：なんらかの処理とか日付とか。業務を行う上で起きるいろいろなこと
- アクション：イベントによって起こること
というざっくりした理解。イベントの表現が難しい
漠然と、契約管理のシステムを例にして考える
| イベント | アクション |
|---|---|
| 申込 | 契約を作る。契約が申込中状態になる |
| 契約予約処理 | 契約が契約予約状態になる。月額商品を翌月1日開始で作成する |
| 月初 | 契約が契約中状態になる。月額課金の開始 |
状態遷移図作成
状態を取り出す
- 申込中
- 契約予約
- 契約中
状態から状態に行く矢印をひいて、アクションを書く
- [なし] -申込-> [申込中]
- [申込中] -契約予約処理-> [契約予約]
- [契約予約] -翌月1日-> [契約中]
ここまでだと矢印が一方通行なので、たとえばキャンセルとかはあるのか？とか考える
- [申込中] -キャンセル-> [？]
ありそう
なしに戻るのか、キャンセル済という新しい状態があるのか迷う。とりあえず新しく作ってみる。
アクションがキャンセルとなしで同じなら、一緒にしてもいいかも。
- [申込中] -キャンセル-> [キャンセル済]
全部つなげて書いてみる
graph LR;
a>開始] --> none(なし);
none(なし) -->|申込| ordered(申込中);
ordered(申込中) -->|契約開始処理| reserved(契約予約)
reserved(契約予約) -->|翌月1日| engaged(契約中)
ordered(申込中)-->|キャンセル| canceled(キャンセル済)
状態遷移表作成
| イベント/契約の状態 | なし(s0) | 申込中(s1) | 契約予約(s2) | 契約中(s3) | キャンセル済(s4) |
|---|---|---|---|---|---|
| 申込 | 契約を作成/s1 | ||||
| 契約予約処理 | 月額課金商品を翌月1日開始で作成/s2 | ||||
| 翌月1日 | s3 | ||||
| キャンセル | s4 |
契約予約→契約中の遷移、月額課金は自動で始まるのでアクションではないかな…と思ったので、状態が変わることだけ書いた。
埋まってないところを考えて、全部埋める。
イベントが起こりえない場合はx
イベント起きるけど、なにもしない場合は/
を書く
| イベント/契約の状態 | なし(s0) | 申込中(s1) | 契約予約(s2) | 契約中(s3) | キャンセル済(s4) |
|---|---|---|---|---|---|
| 申込 | 契約を作成/s1 | x | x | x | x |
| 契約予約処理 | 月額課金商品を翌月1日開始で作成・s2 | ||||
| 翌月1日 | / | / | s3 | / | / |
| キャンセル | s4 | 月額課金商品を削除・s4 |
翌月1日はどの状態でも起こり得るのでなにも起きない場合は/を書く。
申込は契約を新しく作るので、契約なし以外の状態では起こりえないはず。
契約予約キャンセルがありそう。ある想定で書いてみる。
このあたり、書いてなかったらサービス仕様書に反映してもらおう
graph LR;
a>開始] --> none(なし);
none -->|申込| ordered(申込中);
ordered -->|契約開始処理| reserved(契約予約)
reserved -->|翌月1日| engaged(契約中)
ordered -->|キャンセル| canceled(キャンセル済)
reserved -->|キャンセル| canceled
図もこんなかんじに修正
| イベント/契約の状態 | なし(s0) | 申込中(s1) | 契約予約(s2) | 契約中(s3) | キャンセル済(s4) |
|---|---|---|---|---|---|
| 申込 | 契約を作成/s1 | x | x | x | x |
| 契約予約処理 | x | 月額課金商品を翌月1日開始で作成・s2 | x | x | x |
| 翌月1日 | / | / | s3 | / | / |
| キャンセル | x | s4 | 月額課金商品を削除・s4 | x | x |
全部うめたー。
埋めると、このパターンどうだろうって考えるのでヌケモレがなくなる。はず。
所感
今まで見よう見まねで適当に書いてたので、型のお勉強でした。
結構すぐ状態遷移表書いてて、イベントリストや状態遷移図の段階を丁寧にやってなかったけど、やっぱ図のほうが読みやすいなーと思った。全部埋めるという意味では表を使うのが良いけど、見てわかるのは図が強い。
イベントが起こりえないのとなにもしないをあんまり区別してなかったのでちゃんと分けて書くようにする。
契約で話始めたけどこれ申込は別ドメインのほうが良くない？って途中で思ったけど書き直すのが面倒になったのでそのまま行った
参考
状態遷移表による設計手法（3）：状態遷移表を使用した要求分析モデル (1/3) - MONOist http://monoist.atmarkit.co.jp/mn/articles/1207/11/news001.html
ごちそうさまでした
GW満喫中。
RICE on STAGE「ラブ米」～I'll give you rice～
に行ってきました。
www.nelke.co.jp
ラブ米は元々好きなアニメだったのですが、舞台を見てもっと好きになりました。we love rice.
アニメの方は、米人気の低下により廃校の危機に直面している穀立稲穂学園を救うため、ひのひかり、にこまる、あきたこまち、ひとめぼれ、ささにしきの5人が「ラブライス」を結成。新嘗祭でハーベストショーを披露し、米人気の上昇、米騒動を起こして廃校阻止を目指す話です。
5分アニメなので1時間で1クール見れます！二期作まであるので全部見るとしても2時間です！ラブ米を見てください🌾
アニメも良かったけど舞台のストーリーがすごく良かった。
（以下ストーリーのネタバレを含みます）
危険なやきそば未確認飛行物体から現れたのは穀物すべてを滅ぼそうとするスーパーフードのフリーカ。フリーカに洗農されてしまった古代米たち、裏切りの陸稲。穀物の危機を救うため立ち上がるラブライス。
やっぱり最後はひのひかりくんの「みんなまとめて炊いてやる！」でした。うるち米、陸稲、古代米、そしてフリーカ。あらゆる価値観・宗教観を認め合う、そんな雑穀MINDを手に入れた全穀物が一緒に炊かれてハッピーエンドです。
探している両親になかなか会えず、自分のルーツがわからないことで迷っていたあきたこまちさんは、ラブライスのみんなの想いに触れて「私はあきたこまち、みなさんのことが大好きなあきたこまちです！」と迷いを断ち切る。
スーパーフードであるが唯一必須アミノ酸リシンを持たないことで兄のキヌアのような宇宙食になれずコンプレックスを抱いていた敵のフリーカさんに、あきたこまちさんがかけた言葉は「私たちと一緒に炊き上がりましょう」。
あきたこまちさんもフリーカさんも、自分のあり方に迷って、ひとりで悩みを抱え込んでいた。その悩みを解決してくれたのは、米米フレンズのみんな。みんなと関わり、一緒に炊き上がること。
そしてそれが形になったのが「雑穀おいなり」。みんなを包むおあげは必須アミノ酸リシンを豊富に含む大豆からできています。ずっとひとりだったフリーカさんはみんなと一緒に炊かれることで、必須アミノ酸リシンを手に入れることができたのです。
ぶっとんだ世界観だしちりばめられた米ギャグや怒涛の展開にひたすら笑いっぱなしなんだけれども、それだけじゃなくみんな真剣にお米と向き合ってお米を愛してくれて、だから公演が終わった後も記憶に残る。
そしてお米だけじゃなく、いろんな味、いろんな特長を持った多種多様な穀物たちが同じ釜で炊き上がる。お米も麦も、みんなまとめて炊いてしまう包容力。やさしさ。ラブ米はすべての穀物に対する愛にあふれていました。
米ギャグで笑い、米米フレンズのみんなの穀物愛で幸せになり、そして見終わった後はおなかが空いてごはんが食べたくなる、そんなすばらしい作品でした。
ごちそうさまでした！！💛🍚
いま米に対する興味がうなぎのぼりです。
ちょうどお米を買うタイミングだったのであきたこまちさんを買いました。十六穀米にして炊いていなり寿司にして食べようと思います。
いやしかし今は大変な米飢饉です……千穐楽が終わってしまいましたがまだまだ米をおかわりしたい気持ちでいっぱいです……。米ったね…。
あきたこまちさんやひとめぼれくんとは違い、流通していないため気軽に食べることができない陸稲のネリカさんを推し米にしたので、自宅でひとり飢饉でした。稲稲……お米食べたい。
システムの奴隷にならないために
わたしはあまり仕事熱心なほうではないのですが、ありがたいことにそれなり楽しく仕事をさせてもらっています。なので基本的には「暇だし仕事するのもアリだな」と思えるくらいにはモチベーションを持ちつつ日々を送っています。
基本的には。
ただし嫌いな仕事もある
うちのSEのお仕事のひとつに運用作業というのがあります
主観ですがこれは最低の仕事です
なにするかというと、一言でまとめるとシステムが処理できないユースケースやエラーのデータを良いかんじに直してあげる作業のことです
いやそんなんシステムがちゃんとやれよ
っておもうよね
わたしは最初にそうおもいました
なぜシステムはちゃんとやってくれないのか
- システムの実装してない
- 設計がミスってて考慮されてないとか
こういう自業自得的なものがままある
- それ以前にサービス仕様がない
これは我々より前の問題
システムの奴隷
という気持ちになります ディストピアかな！？
物語ならワクワクするかもしれないですが当事者になってみると全然ワクワクしません、最悪です
地獄の二週間のおはなし
このチームに配属されて最初の二週間、わたしは運用チームに入り、日がな一日、ひたすら運用をしていました。
前のチームでは運用なんて毎朝ちょろっとメール見る程度のものだったので衝撃でした、データパッチの嵐です、最悪です
しかも業務知識がない状態での運用はさらに最悪です、どう改善していいかわからないままよくわからない手順に従って言われるがままに作業をするのです
この時のわたしはシステムです、人間APIです
いや自分なにしにこの職場選んだんだっけ？みたいな気持ちになります、毎日毎日誰でもできるような作業を粛々と手順通りやるだけの暮らし…………
なにがやばいって、一日を終えて成長したなとか学んだなとか思うことがひとつもないんですよ
2年目だよ、もうちょいなんかあるでしょ、わたしのキャリアと人生ってなんなんだ？ということをいつもより遅い帰りの電車（運用で残業したことがなかったので本当にメンタルがつらかった）でめちゃくちゃ考えて泣きました
その次の日、この仕事はもう無理だと周りに訴えてチームを変えてもらいました。あれ以来運用が大嫌いです。運用嫌いキャラとして生きてますがマジのガチで嫌いです
絶対に運用倒す
まとめると、運用が嫌いな一番の理由は自分が成長してる実感がないからです。
コード書いたら楽しいし成長できるのに、運用で楽しくもないし価値もない作業をやってる時間、自分にとってめっちゃ無駄じゃんって思うよね。
それならコード書いて解決する方を選びたい。
エンジニアなんだし。
運用を倒すという強い思いは"チーム全員"に必要
この思いをチーム全員で共有したい。同じ方向を見たい。
わたしたちはチームだから。
ひとりの力はとても弱い。
競い合い、助け合い、時には傷つけ合い、仲間と共に時を刻むことで人は成長する。
俺たち3人は力を合わせることで、その力を3倍どころか10倍にも100倍にもすることができたんだ
考えた上で感じろ
前回ブログに書いたようなことをずっと溜め込んでいたのですが、LTでみんなに向けて言ってみたら思いの外すっきりしたというか、わだかまっていたものが解けて力が抜けたような気がします。
一人でもやもやしていた時間もたしかに必要だったけど、もう少し短く済んだかもしれないということで。
溜め込みがちなようなので、とりあえずやってみる、に切り替えるのも必要だなーとことあるごとに思うのですが……なかなかね……。いつもことが済んでから思う。
仕方ないのでチームリーダーを志す（仮）
チームリーダーにはなりたくないのですが、現実問題いまのチームにはリーダーが必要らしいので、エラスティックリーダーシップ読んでいます。社内チャットでわめき立てているときにおすすめしてもらいました。
チームメンバーにあれだけ訴えた手前、リーダーの立場としてもまあ必要だよねってことで。気持ちもかなり落ち着いたので、粛々と読み進めます。読み終わったら書く
わけわからん状態になった時にもサポートしてくれる、セーフティネットがちゃんとあるから安心してのびのび悩めるなあと日々感じています。ほんと、うちの会社はこういうとこが良いですよね。ありがたいです。
さいきんいっぱいほめてもらえるし、いま仕事が旬ジャンルだから勉強とアウトプットをがんばりたい
定時に帰りたい
残業しても仕事が終わらなくてつらい！なぜ
最近ゲーム買ったからはやくかえりたいです、リディー＆スールのアトリエ、良いゲーム。素材集めメッチャ好きだから永遠に遊べる、いろんな素材の特性と成分を組み合わせてベストマッチな調合をするのだー。すごくたのしい、ゲームがしたいのでとにかくはやくかえりたい
最強の設計をしたい
バッチの設計ミスってスパゲティなサービスができてしまってつらい、もう繰り返したくないんだけどこれをしないような勉強はなにをすればよいのか？
現場で教えてもらったことのモノマネしかやれてないので、理屈のほうも勉強したい。設計ここ半年くらいかなり熱いので最近は設計ミスったなって感じるときが一番くやしいーー。つぎはまけない
タスクの先にある目的を見失わないために
目の前にあるタスクをなんとかすることに手一杯になってしまいがちだけれども、目指すべきゴールを明確にしておけば迷いが生まれにくくなるかもしれない。
最近なんでこんなことやってんだろーって思うことが多いので、いまやっていることが自分にとってどういうメリットがあるかを家に着くまで考えます。
良いチームを作ること
生産性アップ。
チームビルディングスキルが身につく
仕事行くのあんまり嫌じゃなくなる
仕事楽になる
職場が快適になる
残業減るかも
飲み会が楽しくなる
プロジェクトを進めること
チームや個人の評価になる。ほめられる
ボーナスが増える。
休出にならない
一応会社の目標だし
達成感ある
もうかるプロジェクトだったら偉い人からもほめられる。ボーナスが増える
メンバー育成
チームの生産性アップ。
育成スキルが身につく。
育成の成果が認められたらボーナスが増える
代わりに仕事してくれる手が増える
その間に好きなことができるかも
運用してもらえるかも
リーダーや先輩をするモチベーションがほしい
人やチームの面倒を見るのは自分の成長に役立つのか？わたしのメリットってなに？なんかわたしばっかりみんなのこと考えてない？って感じて元気なくなるからやる気を出したい
最近チームとか人を見ていると、人に対する不満ばっかり目についてしまってやだ。自分を振り返りたい。ノイズを追い払って自分の至らないところに目を向けたいです。
チームリーダーになりたくない
って最初に言ったんですけど任されてしまいましたね。
リーダーを任されて数ヶ月、いろいろ考えた話。
そもそもチームリーダーはいないはずでは？
スクラム開発にいるのはプロダクトオーナーと、スクラムマスター、チームメンバー。
スクラム開発にはチームリーダーはいない。
が、スクラムやってるはずのうちの会社、なぜかチームリーダーがいる。
リーダーの仕事はスクラムマスターの領域が近いけれど、実際の作業もやっているのでチームメンバーでもあるかんじ。バックログはチームで出している。POは誰だかよくわかんない。
なので実際、リーダーはただのスーパーマン。
要件からバックログのタスクにする。調整して、みんながタスクに集中できる環境をつくってあげられる。コード書いてタスクを燃やせる。なんでもできる。リーダーすごいよ。スクラムの全役ひとりでやってるのでは？
というわけでうちのチームリーダーはなんかすごい。
模索、チームリーダーはなにをするのか
さて、リーダーやってねって言われたけど、すごいので、なにから始めればいいのかさっぱりわからない。
迷走して、プロジェクト開始からしばらく、PO寄りのスクラムマスターをやっていました。
コード書かない。タスク出しと調整に徹する。
立場がPOになったので、チームと対立する。後から学んでみればこれ自体はスクラムの構図の通りだった。
なんだけど当時はそれを理解してなくて、やってることがPOだったくせにこっちの気持ちとしてはチームの一員だったので、チーム内でギスってる感じになってめちゃくちゃにつらかった
あとコード書かないとやっぱエンジニアとしての自分の成長はどーなんの？って悩んで憂鬱になる。*1
実際、チームリーダーはなにをするのか
今リーダーしてる人たちが思うリーダーの仕事は「プロジェクトの目的のために行動できる人になること」らしい。
当事者意識。プロジェクトを自分のこととする。
チームメンバーという役割
じゃあメンバーはそれをリーダー任せにしてていいの？ってならない？スクラムにおけるメンバーは役割のないその他ではない。チームを作るのはチームメンバーたち自身。
自分たちにそんな役割があることをメンバーは理解しているか？わたしは理解していなかった。それはわたしが働きだして3年経つのに今更こんなことを考えていることに現れていると思う。
これまで見てきたリーダーは調整もできるしコードも書いてて、自分はタスクのことだけ考えてても困らなかった。ただのコーダーであるなら快適かもしれないけれど、現状はそんなチームリーダーに甘えてきた結果。これまでの自分がリーダーに甘えていたボンクラコーダーだったことを認めるしかない。
理想、チームリーダーはいらなくなる
自立的なメンバーによって成り立つ自己組織的なチームにリーダーはいらないはず。
現実、チームリーダーはいなくなる
チームの最初期を作ってきた人たちはいなくなる。わたしはおそらく、経験も知識もなくこのチームで育ってリーダーになる最初のひとになる。
成り立ちが全く違うんだから、いままでと同じようにはできない。これまですごいリーダーたちにしてもらってたようなこと、同じようには、いまのわたしにはできない。
わたしはみんなが知っている「チームリーダー」になれない。
「自分の得意な感覚」を知っておくと良い
vakモデル、vak理論など呼ばれる、そのいずれが正式名称かなのかはわからないのですが、そういう考え方があります。あんまり良い資料やページにあたれなかったので、詳しいことは適当にググってください。
ざっくり書くと、vakというのは視覚、聴覚、体感覚のそれぞれの頭文字を取ったものです。人にはそのみっつのうち、ひとつまたはふたつの優位な感覚があり、わたしたちは日々その得意な感覚を主に用いて認知を行っているそうです。
どれが得意でどれが不得手か、というのはその人によるみたいですが、わたしはおそらく「体感覚」派です。
◆
時は遡って3年前、新人研修を受けていたころ、わたしは言葉が出てこなくてうまく話せない、と、講師の方に相談をしたことがあります。研修時間後の立ち話くらいの感覚で、腰を据えて話したわけではないのですが、その時に講師の方から言われたのが「もしかしたらあなたは体感覚なのかもしれない」でした。
視覚、聴覚は高次の感覚であるのに対して、触覚・味覚・嗅覚を含む低次の感覚である体感覚は、言語で表しにくい傾向があるようです。見たものや聴いたものを言い表すよりも自分が感じたことを言い表すほうが難しい気がするので、それはなんとなくわかる。
おそらくわたしは体感覚が優位、サブが視覚、聴覚が劣位です。
で、タイトルに戻る。
これがわかるとなにが良いかというと、まず、考えたり学んだりするときに得意な感覚を使う方が覚えやすい。
体感覚なわたしの場合は、なんでもまずやってみるのが一番早い。
とりあえず、手を使って書く。体感覚は言語化が難しいのですぐ喋りだすのは苦手。視覚情報は比較的頭に入りやすいので、文字や図にするのはGood。聴いたことはすぐ忘れるから絶対に書きとめておく、もしくは復唱する。喋るというのは体感覚だからわりと覚えられる。みっつ聴いても最後のひとつしか覚えてないみたいなことはよくあるから、口頭で言われたことは忘れないように工夫しておかないとダメ。
もうひとつ、うまく仕事するためのコミュニケーションの方法を周りに知ってもらうことができる。
会話ベースの場合、わたしは聴いて理解するのが苦手なので「復唱する」または「自分の言葉で言い換える」ことで理解しやすくなる。ので、よくやるけど、あんまりやりすぎると微妙かなとも思うので、「わたしはこれをすると頭に入るので、うざいかもしれないけど許してください…」と周りの理解を得ておくと仕事が進めやすくなると思う。
ちなみに今自分がこれをやってるかというとあんまりやってないんですけど。これに気づいたころにはもうチームが受け入れてくれていたので。やさしいチームメンバーでよかったなあ
たぶん人に対しても同じように得意な感覚を使えるようなアプローチをしてあげることで理解を促せるようになる、気が、する……。まだそこまではいけないけど。特に春先は人に教えることが増えてくると思うので、意識してみてもいいのかな〜、とか。*1
◆
新人の、とくに自分の興味分野外の社会人研修ってだるいとかってめんどいとかよくわかんなかったみたいなこと結構多かった（すみません）けど、こんなふうに、意外と役立ってるな〜って内容もたまにはあったので、一概にナメてかからずに、一応聴いておくと良いことがあるかもしれないね、って思います。
*1:念のため記しておきますが、これは新人教育をしたいと言っているわけでは、決して、決して！ありませんので、上司各位におかれましては誤解なさらずによろしくお願いいたします。
