うぃろぅ.log

140字で綴りきれない日々の徒然備忘録

【備忘録】 アジャイル開発発展

うぃろぅです。

vviilloovv.hatenablog.com

前回の続きの内容となります。今日も元気に参りましょう。

今日のテーマ

アジャイル開発 次の一歩

アジャイル開発を知る

  • アジャイル」は俊敏な / 機敏な と訳される
  • 「学習する」ことがゴールといえる
  • ユーザー部門と開発者が協調してプロジェクトを成功に導く、という特徴を持つ
    ウォーターフォールだろうが協調すべきでは
  • 使わない機能は作らないという決断を促すことがある
  • 「短い間隔」で「継続的」にリリースする

「要件が明確」で「要件がすることがなく」、「リリースまでの猶予期間が長い」場合はウォーターフォールが適している。

japanese.engadget.com

これは蛇足なので聞き流してほしいことなのだが、このプロジェクトに携わることになる人は頑張って強く生きてほしい。
エンドがgo.jpはホントに…ね。いや何とは言わないが。

XP

エクストリームプログラミングについてのあれこれ。

ペアプログラミング

ドライバとナビゲーターに分かれ、プログラミングに関係する全ての作業を2人で分担する。

常に会話をしながらナビゲーターが指示を出し、ドライバが作業をする。
一定時間で役割を交代して続けていく。

ペアプロFAQ

Q: 工数が倍になるのでは?
A: 工数は1.2倍程度、期間は0.6倍程度に収まる
これ以上かかる場合はやり方に問題がある

Q: ペアの決め方などコツはある?
A: くじ引きでもなんでもいい

Q: どのような効果があるの?
A: 問題が早い段階でわかる / スキル共有に効果的

開発準備

開発準備段階で利用できる手法を示していく。

計画ミーティング

  • リリース計画ミーティング
    ユーザーストーリーの相対見積もりを行い、ストーリーポイントを決める。優先順位付けも行う。
  • スプリント計画ミーティング
    タスクを洗い出し、理想時間見積もりを行う。

の2種類がある。

dojo.codebot.io

ユーザーストーリーって何よ、ということで。
「どうして」必要で、「何を」するべきなのかを明確に示す、ということがわかりやすく書かれている。読むべし。

相対見積もりと理想時間見積もり

  • ストーリーポイント: 相対見積もり
    基準値を1つ設定し、それよりもどれくらい重いか、どれくらい軽いかを相対的に評価して見積もる。

  • 作業時間: 理想時間見積もり
    作業内容を明確にし、その作業を終わらせるために必要な時間を見積もる。

良いユーザーストーリーの条件(INVEST)

  • Independent
    他のユーザーストーリーと独立していること
  • Negotiable
    交渉可能であること
  • Valuable
    有益であること
  • Estimable
    見積もり可能であること
  • Small / Size Right
    適切なサイズであること
  • Testable
    完成したことを検証可能であること

プランニングポーカー

なんか楽しそう(小並感)。

見積りのためだけじゃなかった! プランニングポーカーが開発チームとプロダクトにもたらす8の恩恵 - Appresso Engineer Blog

複数人で暗黙の理解を洗い出して共有する見積もり方法のこと。

「○○だからこの作業は重い」「××を使えばこの作業は軽くできる」といったディスカッションをすることで適切な見積もりができるということである。リーダー1人で全て見積もるより信頼性が高い気がする。

開発

開発で利用する手法を示していく。

タスクボード

ユーザーストーリーごとに実施するタスクを並べ、ToDoDoingDoneと遷移させていく。

バーンダウンチャート

残作業量を確認し、作業の進捗傾向を可視化するグラフのこと。

www.ryuzee.com

これを読むと全部わかる。すごい。
ちなみに私の会社PC環境だと「アップローダー」という理由でWebフィルタにひっかかるため全く参照できない。かなしい。

ふりかえり

PDCAでの「C」のあたり。

ja.atlassian.com

この手順どおりにやれば上手くいきそう。世の中には丁寧な資料が溢れている…感謝…。

「全員が参加している」ということが大事で、傍観者がいないようにしなければならない。

seleck.cc

解決する方法を話し合うためのフレームワークとして「KPT」がある。上記リンクが詳しい。
確かに問題点がわかったとしても「それでどうすりゃいいのさ」を話し合うことが重要。そりゃそうじゃ。

実践のポイント

  • ゴールは学習すること
    学習したチームは良いプロダクトを提供できる。
  • リリースしてフィードバックをもらう
    リリースしなければフィードバックをもらえず、フィードバックをもらえなければ学習できない。
  • テスト / ドキュメント作成は毎回実施する
    イテレーションごとに全ての作業を完了させる必要がある。マスト。必ず。リリース間隔が短いため品質保証はとても大事。
  • 品質保証の考え方
    戦略的に開発項目を決めることが重要。問題が顕在化した場合全ての見直しを行わなければならない。

まとめ

前回の内容に加え、実際の手法や発展的な内容についての学習だった。

実際にやってみるのが大事だと思う。チャンス探し中。

ではまた。

【備忘録】 アジャイル開発基礎

うぃろぅです。

なんだか久しぶりになってしまったe-ラーニング備忘録、続けていきます。

来週当たりからiOSアプリのプロジェクトに携わることになりそうなため今週で最後かも。

今日のテーマ

アジャイル開発 基礎編

アジャイル開発の歴史

  • 2000年ごろ~
    ソフト開発現場でブーム
    2001年に「アジャイルソフトウェア開発宣言」がまとめられた
  • 2010年ごろ~
    クラ独活サービスの隆盛とともに再注目
    開発技術の進化により環境が急速に整備され、期待が高まった

agilemanifesto.org

agilemanifesto.org

まずはこれを読もう。

最近のキーワード

  • UX
    ユーザーエクスペリエンス。良いユーザー体験のためフィードバックが重要。
  • リーンスタートアップ
    小さく作ったものを育てていく。最初のハードルを下げることが重要。
  • DevOps
    Development Operation の略。開発しながら運用していく。

某社のアジャイル開発の取り組み

社名を出していいのかわからないのでぼかす。

歴史のお勉強。私が所属している会社ではないため「そうですか」という感想。

アジャイル開発とは

設計・製造・テストを細分化することによって短いスパンでのリリースを継続してサービスを育てていく開発手法。

twitterでいえば

  1. つぶやく
  2. フォロー
  3. 画像添付
  4. 動画添付
  5. ライブ放送

のように優先順位をつけ、絶対に必要な機能を作った後で順次追加機能をリリースすることを続けていく。上記はただの例のためフィクション。

(フィードバック)・設計・開発・テスト・リリースの1サイクルを「スプリント」「イテレーション」と呼ぶことがある。

ユーザー部門と開発者が協調することが重要。そのため、「お客様の声」は大事な資産となる。同じ部署内でも連絡は密に。

アジャイル開発手法

  • リーンソフトウェア
    考えかた。先述。
  • XP
  • スクラム

キーワードはこの3つ。順に見ていく。

リーンソフトウェア開発

コスト・納期を固定してスコープを可変にする
「この期間でこのコストならここまでなら作れます」ということ。ログインとツイートはできるけど検索はまだ実装しないよ、とかそういうこと。

7つの原則

  • ムダをなくす
    価値を見る目を育てる必要がある
  • 品質を作りこむ
    開発しながらテストして品質を高める。レッツTDD。
  • 知識を作り出す
    自分たちのプロセスを改善していく。暗黙知を作り出そう。
  • 決定を遅らせる
    正確な情報を得てから本採用をしよう。
  • 速く提供する
    速く出して速くフィードバックを得ると素早く次に移れる。
  • 人を尊重する
    それはそう。
  • 全体を最適化する
    全体で見て整合性を図る。「図る」なのか「とる」なのかちょっとわかっていない。日本語難しすぎやしないか。

7つのムダ

  • 在庫のムダ
    リリースしていない作業(在庫)に意味はない。
  • 作りすぎのムダ
    余計な機能を作ってもどうせ使わない。
  • 加工そのもののムダ
    再学習のムダ。知識や経験をプロセスに組み込むべき。
  • 運搬のムダ
    引継ぎのムダ。伝わりやすい手法、ドキュメントを模索するべき。
  • 動作のムダ
    タスク切り替えのムダ。マルチタスク、できねえよなあ。
  • 手持ちのムダ
    遅れのムダ。ボールはすぐ投げよう。
  • 不良を作るムダ
    読んで字のごとく。どんどんテストしよう。

スクラム

「共通のゴールに到達するためにチームが一体となって働く」という方法論。

  • プロダクトオーナー
  • スクラムマスター
  • 開発メンバー

のチームで構成されている。

www.atmarkit.co.jp

5分でわかるシリーズ。5分ではわからなかった。つらい。

こうも「スクラム」という単語を見るとラグビーワールドカップを観たくなる。

そういえば今度携わることになりそうなプロジェクト、ラグビーワールドカップに間に合わせたいらしい。あと3ヶ月もなくない…??

準備計画

準備が大事。1ヶ月程度とって認識をあわせる、ということが重要となる。走り出したら止まらねぇからよ…。

プロジェクトの全体像を伝えるためのドキュメント一式のこと。バトルが始まったりはしない。認識のズレによってはバトルがあるかもしれないが、これはそれを防ぐためのもの。

passionate-po.hatenablog.com

qiita.com

テンプレート例。上手く活用しよう。

XP

eXtreme Programming の略。ライブはエクストリームスポーツなので似たようなものかも。違うか。

qiita.com

tracpath.com

めっちゃわかりやすくまとまってる…。

価値を実現するためにラクティスを実践する、ということを念頭に置いておく事が大事。決してプラクティスのためのプラクティスではない。ペアプロとか楽しいんだけどね。

CI

継続的インテグレーション(continuous integration)のこと。

サーバ上で毎日 / 毎時 / 毎分自動コンパイルして自動テストすること、と捉えておけばよい。

品質を担保するためにはコミットするには自動テストを通してからでなければいけない、ということだと思う。

SubversionとかJenkinsという言葉が出てきたのでこの講義が作られた時代の背景を感じられる。趣があるなあ。

FAQ

Q: ドキュメントは作らないの?
A: ムダなドキュメントは作らないが、必要なものに絞って作る

Q: 早く安くできるの?
A: 部分的に見ればそうかもしれないが、全機能を実装するとなると時間はかかり、コストもかかる

Q: 小規模開発向きなの?
A: 3~9人のチームを複数構成して開発する例もあるため、一概にそうとは言えない

Q: プロトタイプ開発と違うの?
A: プロトタイプはイメージをつかむためのものであるため、品質が全く違う

Q: 品質確保はどうするの?
A: 自動テストと手動テストを組み合わせることによって担保している

Q: 見積もりや契約はどうなっているの?
A: 準委任がやりやすい(請負がありえないわけではない)

Q: 追加要件が増えすぎたらどうするの?
A: 優先順位をつけて管理し、順次対応していく

Q: どんな要件が向いているの?
A: シンプルかつ変化する可能性が高い要件の場合に適している

まとめ

ウォーターフォールとの手法の違いを理解することが第一歩。
あとは上層部に納得してもらえる説明をすること
私の会社は多分まだまだウォーターフォールだよ。

ではまた。

【ライブレポ】 花澤香菜ツアー2019 -ココベース- 国内公演まとめ

うぃろぅです。

www.hanazawakana-music.net

2019年に4月に開催された花澤香菜さんのライブ、国内は愛知宮城大阪東京、海外は広州上海とありました。

その公演のうち広州以外の公演に参加したのでそのレポとか感想とかを書いていこうと思います。

こちらは国内公演のレポ。海外公演は別記事にします。多分。しないかも。

ライブタイトルは
SEIKA フレッシュ HY presents 花澤香菜 KANA HANAZAWA Concert Tour 2019 -ココベース-
長い。こうも長いとセトリ記事のリンクをTwitterに流す時の文字数制限が大変なんですよね。どうでもいいか。
ともあれ書いていきます。

はじめに

  • 個人の感想です。
  • MCでの花澤香菜さんの発言を佐橋佳幸さんの発言をとしています。
  • 本文中は常体で記載しています。
  • 親しみを込めて香菜ちゃん呼びしています。
  • 2019年2月にあったバースデーライブとセットリストが酷似しているため、感想が短い曲もあります。

vviilloovv.hatenablog.com

2月にあったバースデイライブのレポは上記リンクへどうぞ。1.4万字ほどあるので時間がある方向け。

セットリスト

セットリストにしたがって書いていきます。
セットリストは以下をご参照ください。

vviilloovv.hatenablog.com

レポ

1: マイ・ソング

夢の続きを見に行こうよ
新たなフェイズが僕を待ってる
胸の音が走り出すよ

今回のツアー、この冒頭の歌詞に全て詰まっている気がしている。
アーティストデビューした当初香菜ちゃんは

いつか武道館のステージで歌って、マネージャーを泣かすのが私の夢です!!

と言っていて、いざ武道館のステージに立ったのが2015/5/3(4年前!)のこと。

ch.nicovideo.jp

ちなみに当時のセトリはこちら。
この時のアンコール時に涙ぐんでしまった香菜ちゃんが

ずっとこのステージで歌ってみたいと思っていたのでとっても嬉しいです。(マネージャーに向けて)嬉しいかこのヤロー!!

というようなことを言っていたのがとても印象的だったのを覚えている。というか私も一緒にめっちゃ泣いた。
夢、という区切りとしては一旦ここで叶ってしまっているわけだ。

ではその夢の続きは?

ここからは私の予想となるが、そう考えた時にやはり挙げられるのは

  • アリーナ公演
  • 海外公演

あたりなのかなと。

武道館から4年経って、香菜ちゃんライブは某まとめサイト【悲報】ガラガラなんて書かれてしまうことからも窺えるように、満員御礼!とはいかなくなった。

少し擁護しておくと、今回のライブはアルバム先行予約者を対象に「ライブチケットを確実にご用意」という売り方をしていたため、見込みよりも大きめの箱を用意する必要があった。
それに加えて千秋楽の東京公演は新宿文化センターとアクセスしやすく、さらにはGWの3日めと都合がつけやすい人が多い、と好条件が重なっていた。そのため、「全通するほどじゃないけど新宿は予定も空けられるし(帰省/旅行ついでに)行こうかな」となった結果なんじゃないかなと。
めっちゃ早口で言ってそうって自分で書いていて思った。そうかもしれんね。

話を戻す。国内でのアリーナ公演が難しそうなのであれば、それでは海外公演はどうだろうか。
昨今は中国の会社のスマホゲーが日本にも多く進出してきていて、そのキャラクターの声優に香菜ちゃんが起用されていることも多くなってきた。少し前だとミラクルニキはまさにそれ。

そうして発表されたのが広州 / 上海公演である。
しかも上海公演の会場はメルセデスベンツアリーナ
これは夢の続きって言ってもいいんじゃない??

愛知・一宮公演はその最初の一歩である。楽しくならないわけがない。

閑話休題

マイ・ソングの話していたのになんでこうなったの??

国内公演では香菜ちゃんはギターを携えて登場し、見事な演奏を披露していた。

東京公演後のツイートを掲載するが、衣装はこの写真のもの。

2: Change!

この曲のコール部分、公演を追うごとに一緒に声を出している人が増えてきていたように感じられ、「そうだよこれがツアーだよな」などと考えていた。みんなで楽しい場所を作るのがライブってものだよね。

私と歌ってくれますか?

会場によっては楽器の音量がだいぶ大きくて最後のソロ部分が若干大変そうだったがご愛嬌ということで。

マイ・ソングとChange!は今後のライブでもちょくちょく歌われそうな盛り上がり曲。

3: パン

パンの歌い方がいつも楽しそうだからこの曲は何回聴いても楽しくなる。

やっぱり"ミルクフランス"の歌い方が好き。その後何人かと話して"ミルクフランス"派も何人かいた。やったぜ。

若干振り付けのある曲になっていたが振りコピするほどの振り付けではなかった。線引きが難しい。

4: おとな人間

けんけんぱっぱけんぱっぱ。

この曲の最後のコーラスも徐々にみんなの息があってきていて大満足。この曲を一緒に歌っている感、マラソンと通じるものがある。個人的にだけれど。

ツアーを追うごとに「この曲こんなに短かったっけ…?」ってなるのはなんなのだろう。テンション上がって毎回記憶を失っている説がちょっとある。いやもともと3分ちょっとの曲だから短くはあるが。でも1分くらいしか歌ってなくないってなる…ならない?

曲の最後に赤の衣装から白の衣装に早着替え。ダンサーの方々が後ろからマジックテープバリバリーみたいなイメージ。

MC

各公演共通

歌った曲の紹介の後、ギターの話。

花「マイ・ソングでは初めてギターに挑戦しました! 大丈夫?ちゃんと弾いてるように見えてた??」

一同拍手。

花「良かったー。みんなギター弾いたことある?? (パラパラと手が挙がる) おー、ポツポツいるね。私は中学の授業でしか弾いたことなくて、それ以来なんです」
花「だからほぼ初心者だったのね。そうしたら、佐橋さんが手書きのコード進行表を書いてくれて!!しかも手元をスマホで撮影した動画も用意してくれて。なんて素晴らしいんだってなったよね。あ、ギターの佐橋佳幸さんです(笑)」
佐「どうも佐橋です(笑) 香菜ちゃんも頑張って覚えたよね」
花「頑張りました…」
佐「面白かったのが香菜ちゃんに『手元見てないんですか!?』って訊かれたこと(笑)」
花「だって凄くない!?手元見てないんだよ!?」
佐「一応これが仕事だからね(笑) でもたまにチラッと見るよ、チラッと(多分冗談)」
花「あ、じゃあそれも技術なんですね(笑) ギターの方見ちゃうとマイクから遠くなっちゃうからそこを意識するのが大変でした。また挑戦したいと考えているのでその時は皆さんも暖かく見守ってくださいね(笑)」

一同拍手。新しいことに挑戦している人を応援しないわけがない。それが香菜ちゃんならなおさら。

愛知公演

ここから公演ごとに少し内容が異なるため、それぞれ書いていく。

花「私は2月で三十路になって。何か変わったかといえばそんなには変わらないんですけど、何か挙げるとしたら少しだけ思い切りがよくなりました。食べたことないものを食べてみたり、初めて入る服屋さんに入ってみたり」

ポプテピの例のアレの後だったため、若干会場がざわつく。

花「(その様子を感じ取って)あ、今私が『服』って言うとざわつくよね(笑)」
佐「え、どういうこと?」
花「あ、いや、知らないなら知らないでも大丈夫なことなんですけど(笑)、後でお話ししますね(笑)」 花「念のために言っておくとアレは私の完全アドリブです。台本で言わされてるとかじゃないからね(笑)」

逆にアドリブでアレってのもパンチがすごいと思わないでもない。
詳細をご存知ない方は"ポプテピピック 花澤香菜"で調べれば一発。権利関係のためにここには貼らないので自己責任で。

愛知公演のみのMCはこんなところ。

宮城公演

花「一宮公演の時は緊張して開演前にパンを食べる余裕もなかったんだけど今日は食べてきました!!」
花「あとTwitterに書いたんですけど、これからは日常的なことも呟いていこうと思っているのでよろしくお願いします」

当該ツイートはこちら。

で、その後に呟いたのがこちら。なんというかセンスがガラケー

花「私が携帯と格闘して投稿したツイートをお楽しみいただければと思います(笑)」

本当にねえ。

花「一宮の話の続きなんですけど、ライブが終わった後はみんなで市内の方まで(おそらく名古屋)移動して打ち上げをしました。2次会も行ったんだけど、これが佐橋さんが見つけた音楽バーみたいなとこでね。もうすっごくおしゃれ」
佐「みんな密かに心配してたんだけどかなりお喋りしてたのに全然声枯れてないよね(笑)」
花「こういうのもなんですけど仕事柄声帯だけは丈夫なんです(笑)」

確かにお仕事お休みしてる印象がない。すごい。

花「名古屋、というより愛知でも美味しいお酒が飲めて大満足だったんですけど、東北にも美味しい日本酒いっぱいあるよね??」

\一ノ蔵/ \浦霞/ 他いくつか…。

花「一ノ蔵!名前聞いたことある!! 浦霞は飲んだことある!! 美味しいよねぇ〜あのお酒」

もはや飲酒声優である。スフィアも最近打ち上げで飲んだ酒の話ばっかりしているし私は酒飲みが好きな可能性が微レ存…?
というか好きな人が気づいたら酒飲みになっていたパターン。唯ちゃんはそうはならないと信じているからよろしく頼むな。

花「あとは中国の広州と上海公演の話をちょっとしますね。中国公演は前からやってみたいと思っていた公演で、念願が叶ったので嬉しかったです。みんな日本語の勉強をしてくれてたのか日本語で『頑張ってー!!』とか言ってくれるのよ。すごいよね。星空☆ディスティネーションを歌ったんだけど、コーラスみんな日本語で歌ってくれて、内心『すげえ!!』って思ってた(笑)」

確かにすごかった。詳細は上海レポの方で。

花「あと上海では中国語の曲のカバーをさせてもらったんですけど、周杰倫(ジェイ・チョウと読むらしい)さんの"告白氣球(こくはくききゅう)"っていう曲でね。これがまたいい曲なのよ」
佐「こんな感じだっけ(メロディーラインを弾く)」
花「そうですそう!! (ワンフレーズ歌う)」
佐「よく覚えてるね(笑)」
花「めっちゃ練習したんですよ(笑) 日本のカラオケにも入ってて、"こくはくききゅう"で検索したら出てくるからみんなも覚えて歌ってみて!!(笑)」

英語の曲なら私も歌うことはあるけれど中国語はちょっとハードル高め。でも花澤勢なら歌えるようにするのがマナー…?(ぐるぐる目)

www.youtube.com

公式動画がこちら。メロディーだけ追っていても心地良い曲なので覚えてみては?

花「中国はトラブルがいっぱいあってね。まず機材がギリギリまで来なかった」
佐「いや本当にヒヤヒヤしたよね」
花「そうなんですよ。スタッフさんはしっかり仕事していてくれて、ビジネスで持ち込む荷物の申請をちゃんとしていたはずなのに税関をなかなか通過しなくて。それで空港の方に問い合わせても聞いてないって言われちゃうし」
佐「リハーサルの時はまだ機材届いてなかったんだよね」
花「そうそう。それでいざって時でもなんとか演奏はできるようにってスタッフの方が中国の業者に頼んでギターを借りてくれたんですよ。でもそのギターの色が…なんというかパステルカラーのすごく可愛い感じの色合いで」
佐「俺絶対そのギター本番で弾きたくないよイメージに合わないよーってごねてたよね(笑)」
花「言ってましたね(笑) ちょっとそれでステージに立ってる姿も見てみたかったんですけど、でも本番には間に合いました」
佐「なんかすっごく喋っちゃってる気がするけど、こんな感じで半分トークショーな感じで進めていくのでよろしくお願いします(笑)」
花「ごめんなさいすっかり話しこんじゃった(笑)」

中国はやっぱり緊張していたのだなと。もう喋る喋る。

花「そうだ、このツアーはコールアンドレスポンスもやっていくんだった」

男の子 → 女の子(香菜ちゃんの反応大きめ)と来て

花「バースデイの時も訊いたからこれも訊いておこう、外国から来た人!!」

\サウジアラビア!!/

花「出た!! サウジアラビアの人!! 本当にありがとうね!!」

バースデイの時にも来られていたサウジアラビアの方、再び。知り合いがライブ後に話したところによると出身はサウジアラビアでも現在は日本に滞在しているとのこと。東京公演にも来るということでこの後も言及する。
サウジアラビア出身の方は今日は友達を連れてきていたということで、ちょっとした話題になっていた。今回のツアーはどしどし前に出て欲しい。次回以降はもういいかな()

仙台公演のみのMCはこんなところ。長え。
そしてこの長さはこの後のMCにも影響を与える(後述)。

大阪公演

花「大阪は"ココベース"のリリイベで来て以来ですね。なのであんまり久しぶりって感じではないです(笑)」

直前に告知されたアレ。流石に仕事休めなかった。

花「私吉本新喜劇が好きなので大阪には個人的に来ることがたまにあります。この前は西梅田劇場で新喜劇見ました(笑)」

以前お渡し会の時に好きな座長を訊いたら「しげ爺とすっちー」って言われたんだけど辻本さん座長引退されて現在は誰推しなのだろうか。お渡し会外れて行けてないので今度どなたか機会あったら訊いといて(ぶん投げ)

花「佐橋さんの話になるんですけど、一宮の時にギターを弾いている佐橋さんと目を合わせて歌うことがあって。その時の佐橋さんの笑顔が…なんというか赤ちゃんの笑顔みたいなんですよね、純粋というか(笑)」
佐「僕もう60歳近いのに赤ちゃんはなんか違うんじゃないの(笑)」
花「そうですよね(笑)でもなんか見ていると幸せになる笑顔なんですよ(笑)」

楽しそうな人を見ていると幸せになるのは私も同じなので私は実質花澤香菜(とは)

花「仙台での公演が終わった後はみんなで立ち食い寿司に行ったんですよ。仙台駅に行ったことある人はわかるかもしれないんですけど、"牛タン通り"っていうのが駅ナカにあってね。その一角になぜかお寿司屋さんがあるのよ。そこのお寿司が美味しくって。仙台に行かれる方はぜひ行ってみて!!」

多分北辰鮨。また今度機会があったら行くか。

大阪公演のみのMCはこんなところ。

東京公演

花「この会場は去年の2月にあったライブぶりですね。だからついこの間ぶりって気がしちゃう」
花「でも三十路になってからコーヒー屋さんに行ったんだけどね。なんでか本当にわからないんだけどコーヒーを飲み込む時になんかうまく行かなくって『…グッ…コポォ…』って行っちゃって近くにいたお姉さんにすごく心配されちゃった(笑) でも私は三十路の人生を楽しんでます(笑)」

そのうちむせて「フォカヌポゥ」とか言いそう。ないか。

花「それと、音楽活動8年めになりました。皆さんの応援のおかげです。ありがとうございます」

"星空☆ディスティネーション"が2012/4/25に発売したため、ついこの間7周年だった。早いものだ。

花「今世間はゴールデンウィークということで10連休の人もいるらしいんだけど、みんな実際どうなの??」

\ワイワイガヤガヤ/

花「あーみんな一緒に喋らないで(笑)」

身内 \明日から3日間仕事ー!!/

花「明日から3日間仕事!? お疲れ様です…!! みんな『頑張れ』って言ってあげて!!(笑)」

完全に聞き覚えある声で連番者とめちゃくちゃ笑ってしまった。頑張ってほしい。

花「あとそうだ、大阪の打ち上げも楽しくてね。おばんざいを食べたんだけどそれにインゲンが乗ってて、佐橋さんとかが『おとなインゲン!!』とか言うのよ(笑)」
佐「おじさんだからね、言いたくなっちゃうんだよね(笑)」
花「そんなことばっかり言うもんだからずっと笑っちゃって(笑)」

続いてコールアンドレスポンス。男女からの外国の人。
\北京/ \香港/ \タイ/ \サウジアラビア/

花「出た!! サウジアラビア!! 他の国の人もみんな来てくれてありがとうね」

サウジアラビアインパクトがものすごいせいで霞んでしまっているが海外ってだけで十分すごい。
上海に言ったあとだから余計にそう感じる。

花「あとは中国の話ね。中国の方々もすごいのよ。みんな日本のアニメを見てくれているみたいで。それこそ『リーボンー』って一緒に言ってくれたりするのよ」

コールのチョイスなんでそこなん…?
東京公演のみのMCはこんなところ。

全公演共通

花「今回のアルバムは"ココベース"というタイトルで、私の音楽のベースになっている方々に佐橋さんが声をかけてくださって実現しました。すごく豪華な方々にご協力いただいているので歌っていてとてもテンションが上がります」

概ねどの公演でもこのような内容だった。

花「ここからはアコースティックでお届けしていきます。まずはカバー曲を聴いてもらおうと思います。チャットモンチーの"染まるよ"を歌います」

花「この曲はですね。この前放送されていた恋のツキというドラマの7話で主人公がエンディングの時に口ずさんでいるんです」
花「そのドラマの映像監督をされている方が何人かいらっしゃるんですけど、その中の一人に"あたらしいうた"と"春に愛される~"のMVの監督をしてくださった酒井麻衣さんがいらっしゃって。なので歌いたくなったので歌わせていただきます」

大阪公演

花「この曲なんですけど、最近あたらしい楽しみ方を思いついたんですよ。みんなPSYCHO-PASSって知ってる??」
花「知ってる?? 良かった。その作品で私は常守朱って役をやってるんですけど、その朱ちゃんがあの人に歌ってると思って聴くのよ。私これを思いついた時『うわぁ〜〜〜』ってなったのでそれ以来そのイメージで聴くようにしてます(笑)」

音MADみたいなこと言ってる…。誰かが作ってくれるはず。どなたかよろしくお願いしますねー(他力本願)。

5: 染まるよ

以前のレポで長々と書いたのでそれ以上語ることもなく。

www.youtube.com

みんな原曲も聴こう。本当に良い曲だから。

常守朱ちゃんがタバコに火をつけてこの曲を口ずさんでいるイメージ、とんでもなく良い。発想がただのオタクじゃねーの

MC

バンド紹介。
概ねどの会場も同じような内容だったため、各会場での内容を織り交ぜて書いていく。

  • Dr. 高橋結子
    けっちゃん。中国公演のために就労ビザを取得したのだが、そのための写真がなかなか大変だったとか。特に髪型に関しての規定が厳しく、写真屋さんで最初に撮った写真はその規定にあっていなかったため再審査が必要に。
    写真屋さん側も気にしておかなければならないことだった、とのことで再撮影は無料だったとのこと。その代わりに「ビザ取得用の写真に関するダメな髪型の例」に写真を提供したとか。持ちつ持たれつ…なのか…?
  • Key. 齋藤有太
    有太さん。有太さんの周りには暖かい風が吹いているイメージだとか。自身が忘れ物大王のため、飲み会後には自分も含めて忘れ物がないか入念に呼びかけるらしい。香菜ちゃん曰く顔も中身も兼ね備えた真のイケメン。
  • Mani., Horns ゴンドウトモヒコ
    ゴンドウさん。ゴンちゃんとも。飲むと非常にお茶目になる方だそうで、ふらっと席を立ったかと思えば近くのスーパーで新玉ねぎを買って上機嫌で帰ってきたことがあるとか。どういうことなの…。
    振り付けがある曲の時は僕も演奏しながら一緒に踊りますよ! と飲みの席で言ってから有言実行している。自分の言ったことに責任を持つ大人、かっこいい。

花「次の曲はこのメンバーで、関取花さんに作詞作曲をお願いした"おしえて"を歌います」
花「関取さんは以前ラジオで歌を生歌を聴いた時になんて素敵な歌声なんだ、と思ってご一緒したいと考えていたんです」
花「この曲は私から関取さんにお願いして、『母親に向けて歌う』というテーマにしました。私、もう30歳になったんですけどこの歳になっても素直に母親に甘えられていないなって思うんです。なので、この曲は母親へのメッセージを素直に伝えられたらなと」

甘える下地がないまま歳をとるともう無理だよね。

6: おしえて

おしえておしえてあなたが今の私の頃
どうやってどうやって不器用な光を見つけたの

なるほど母親への問いかけになっていると。優しい歌声と曲調に、歌が一瞬で終わったかと錯覚する。
こういう曲を聴くためにツアー通っちゃうんだよな。多分次に歌うのは数年後なんだろうな。また聴きたいものだ。

MC

ベースの井上富雄さんが再び登壇し、これで今回のバンドメンバーが再び揃う。

宮城公演

花「中国公演の時の話なんだけど、広州公演と上海公演の間の日に私は中国メディアの方に取材を受けていたのよ。それでバンドメンバーの皆さんは私が取材だった日は予定が空いたから、佐橋さんが中国でもおしゃれな飲み屋さんを見つけてみんなで飲みに行ってたんだって」
佐「良さそうなお店を見つけるのは得意なんだよね(笑)」
花「そのスキル私も欲しいです(笑) でね。バンドメンバーのみんなで飲んでる時の様子を私にメールしてくれたんだけど、その写真がね、ひどいのよ(笑) 中国にご一緒できなかったベースの(井上)富雄さんと私の写真がこう『修学旅行とかで欠席しちゃった人』みたいに集合写真の上の方にぽんぽんって貼られてるの(笑) あれtwitterに載せていいですかね?(笑)」

それがこちら。かなり雑コラだよこれ!!

やはり中国は緊張していたのか、宮城公演は香菜ちゃんが喋る喋る。

井上さん「えー登壇してそうそうだけど業務連絡です。巻けって(笑)」
花「あっごめんなさい!!次の曲いきますね」
佐「いいよゆっくりやろうよ(笑)」
花「ダメですよ、帰れなくなっちゃう人いるかもしれないし(笑)」

プロンプターに出るのではなくバンドメンバーから直接指示が来るの、新しい。

ということで次の曲へ。

7: Tact

2分ちょっとの曲のため、あっという間に終わってしまう。

三つ編み、というとやはり遠子先輩が浮かぶ。

note.mu

文学少女といえば、版画展開催記念で半年ほど前に新作SSが公開されている。読もう。尊いよ。

8: 春に愛される人に 私はなりたい

流石にそろそろこの曲に関しては書くことがないような気がしないでもない。

短いけれどイントロが好き。あと2番のコーラス部分。

まっすぐに 生きていくひとり

美しく 生きていく ひとり

のところで香菜ちゃんと一緒に人差し指を空に突き上げる振り振りコピをするととても楽しいからみんなもぜひ。

MC

花「ライブ最初の方でも早着替えしたんですけど、今回のライブは衣装にも注目してね!」

新宿では珍しく\回ってー/という声が上がった。そんなコール、まだ花澤現場に残っていたんだな…。

花「え? 回ってって?? 回らない!! ということで衣装のお話なんだけど…ってそういうわけにもいかないか(笑)」

回れ右して回れ左した。確かに回ってはないが後ろは向いた。なんだこれ中途半端に新しい…。

花「緑色っぽい衣装なんだけど、これは今回のスポンサーになってくださっているSEIKAフレッシュHYさんが洗剤の会社ということで、爽やかさをイメージしています」

衣装レポは…多分誰かしてるやろ。うん。

花「ツアーのリハーサルからそのままツアーが始まって、もう4月だけどお花見行けてないんですよね。なのでスープストックっていうスープの専門店で春野菜スープを週3で飲んで春感を満喫してます(笑)」 花「ここで30歳の目標を話したいと思います。2つあって、1つ目は『中国語を話せるようになる』です。中国の方とお話する機会があるときに、中国の方は日本語をしっかり勉強してくださっている方が多いんですよね。なので中国の方にも私の言葉で感謝の気持ちを伝えられるようになりたいな、と思っています。今はまだ発音を追いかけるだけで精一杯なので、自分の言葉で表現できるようになりたいな。それでね、私に中国語を教えてくれる女の子がいるんだけどその子がまた可愛いのよ。『発音大事なので発声の仕方よく見ててください』って言われてよく見ると見とれちゃったりするよね(笑)」

おまわりさんこっちです。

花「もう1つの目標は『肩の力を抜いて、色々なことに挑戦する』です。最近は中国でライブしたりとか、ナレーションのお仕事をさせてもらったりだとかでまだまだやりたいことはいっぱいあるなって。来年も再来年も楽しそうな挑戦ができそうなので皆さんも楽しみにしていただけたら嬉しいです」

花「あとこの前新幹線で移動してるときにぼーっと自分の手を見てたら気づいたんだけどね。小指の甲のところに黒子ができてたのよ。それで気になって調べたら『あなたは企画力があります。新しいことを始めると良いでしょう』って出てきたのね。だから何か思いついたら企画しようと思います(笑)」

私は中指の第二関節より手の甲寄りの部分に黒子がある。どうでもいいか。

花「ということでそろそろ次の曲。ミトンを歌います!!」

9: ミトン

ダンサーの2人(りさぴー、あやか)も登壇して振り付き。

ダンサーの方々のツイートにもある通り、ミトンを一緒に振るお客さんもいたとか。念のために断っておくと私ではない。花澤勢の身内ではあるが。

わかりやすく盛り上がる曲はやはり楽しい。毎回歌おう、な??

10: Brand New Days

どんちき♪└(^ω^ )┐♬┌( ^ω^)┘どんちき♪

以前冒頭のどんちき部分を使ってラップ作っていたツイートが話題になっていた。この曲リリースしてからもう5年くらい経っている気がするのに今になって…? という気はするけれどどんな形にせよ話題になるのはいいことだようん。

ラップパートがあるのが良い。撫子感あるよね。

11: 大丈夫

PVの振り付き。振りコピが楽しい。

特に語ることもなく。まぁしょっちゅう聴いているからね。

www.youtube.com

PVだけ貼っておく。

12: 25 Hours a Day

こちらはバースデイの時も歌った曲。ダンサーの方々がいたので若干振り付けがあった。

コーラス部分、みんなで歌いたいが歌える人が減っているため中途半端になりがち。みんな声を出そう。能動的にライブを楽しもう。

13: CALL ME EVERYDAY

もしもし曲。たまには「なんだ弊社の井口裕香か」とか言ってもええんやで。ちなみにその小ボケを披露したのはclaireライブの時だったか。過去に生きるオタク。

「もしもしタイム」はわかりやすい盛り上がりどころ。そろそろ"melody"を歌って花澤香菜に全力で「キライ!!」って言う機会を設けてほしい。普段言う機会全くないし。

2番の

でも そういうのって 重いかなぁ。。。

のところの言い方が好き。重くてもいいからどんときてほしい。おっと心の声が。

14: 恋する惑星

わかりやすく盛り上げにきている。ライブ終盤に盛り上がる曲が連続すると終わりの近さを感じて寂しくもなる…ならない??

大事な願いは たやすく  
口にしちゃダメさ  
言葉にした途端に 形を  
変えてしまうから こっそり育てようよ

確かに言葉にするとそれで満足してしまう、ということが往々にしてある。
とは言ってもたまに自分の目標を再確認しなければ現在地がわからなくなってしまって前に進めなくなる。なんて難儀な生き方なんだ。

これをやりたい、なんてことはいくらでも浮かぶけれど油断するとすぐに楽な方に流れてしまう、私の悪い癖(CV. 右京さん)

MC

花「今日は本当にありがとうございました!! とってもとっても楽しかった!!」
花「次で最後の曲です。聴いてください、"あたらしいうた"!!」

15: あたらしいうた

たたみかけてきている。あるいはライブをたたみにきている。

この曲、しょっぱなのあたらしいうたの入り方がライブによって結構違っていて、聴くたびにあたらしい顔を見ることができる。毎回あたらしいうたになっていると、きっとそういうことなのだと思う。

ふと気づくとこの曲もリリースしてから3年が経過していて。3年かぁ。

大丈夫なときなんて  
一瞬もないって  
気づいてしまわないように

この後に大丈夫なんて曲を出すわけよ。なるほどなぁ。

アンコール

16: 恋愛サーキュレーション

全キャラソンの中でも知名度が高い名曲。この曲聴くためだけにライブ来てくれてもいいんだよ。

物語フェスでは"もうそう♡えくすぷれす"も聴けたので撫子関係はもうコンプリートしたと言っても過言ではない。撫物語は…まだアニメ化してないからね。うん。

17: We Are So in Love

久しぶりに歌ったような気がする曲。

サビのコーラス部分、歌詞を忘れがち。でもアダムとイブだけはしっかり言える。これってトリビアの種になりませんか??なりませんか。はい。

ディスティネーションズがバンドの時の末永華子さんのコーラスの声が好き。若干ピンポイント気味。

MC

物販の宣伝。ツアー終盤になると

花「物販の話をしようと思ってたんだけど…みんな身に付けてくれてるし多分私よりも詳しいからいいよね」

ってサボっていた。企画に携わっていない人の方が詳しいってことはないと思う。

また、今回のスポンサーであるSEIKA フレッシュ HYの紹介。
それつながりで「洗濯川柳」なるものを披露していた。そんなんだからバラエティ声優なんやで

  • 柔軟剤 洗剤逆に 入れてまう(愛知)
  • ちょっと誰!? ティッシュ入れたの 私だよ!!(宮城)
  • 侵入者!? 違うわ洗濯 回してた(大阪)

東京では詠んでいなかった。はず。

一番「あーわかる」って空気になっていたのは宮城公演で、確かにあるあるである。なんでティッシュ洗っちゃうとあんなに散らばるんだろうね。

yourmystar.jp

事後策としてはいくつかあるみたい。そもそもの予防が大事。何の話をしているんだ。

あとは打ち上げの話をしていた。最近ライブ終盤には酒の話しかしてない。私としてはそういうのもっとちょうだい、といったところ。一緒に歳をとるということはそういうことだと感じている。楽しい明日のために、美味しいご飯と美味しい酒の話をしよう。

花「今日は本当に本当に、ありがとうございました。本当に最後の曲です。私が作詞をさせていただいた、"Ready to go"を歌います」
花「この歌詞には今の私の想いがたくさん詰まっています。悩んでしまってどうしても前に進めないときでも、少しでも前に進みたいと努力していたら誰かがそれを見ていてくれる。そんな気持ちで書きました」
花「お仕事のことで悩んでいるときに、皆さんのお手紙やラジオのお便りでいつも力をもらっています。なので私からも皆さんにお返しをしたいといつも思っていて、私も勝手に皆さんを応援しています(笑)」
花「この曲の最後のコーラス部分は覚えやすいメロディになっているので皆さんも一緒に歌ってくれたら嬉しいです」

18: Ready to go

アンダンテ、という言葉がぴったりくる曲。まさに歩くように歌っていて、音楽と一体になっていることが強く感じられる。

この曲を聴くとライブも終わりか、という気分になる。香菜ちゃん曲には結構終わりを感じさせる曲があり、「あ〜〜今日も楽しかったな〜〜帰るか〜〜」という気分にさせてくれる。終わりよければ、というやつである。

MC

全員で前に出て挨拶。

東京のみ

花「はい! 私、星空☆ディスティネーションを歌いたいです!!」

ということで東京のみこの後に星空☆ディスティネーション。他会場は佐橋さんだけ残り"おやすみ。また明日"という運びとなった。

19: 星空☆ディスティネーション(東京)

東京公演でも"おやすみ、また明日"をこの後に歌ったため紹介順としてはこちらが先。

"コンサート"と銘打ってこの曲をメインのセットリストに入れていなかったのはおそらくこのツアーが初。毎回聴いているため、絶対に歌ってほしい曲ではなくなってしまったが、やはりないと寂しく感じるものである。

という事情もあり東京で聴けるのはやはり嬉しかった。確かな安心感がある。

だからといってたくさん語れるかといえばそういうことでもないのだけれども。とりあえず落ち着くよね。

20: おやすみ、また明日

もはや定番となりつつあるトークコーナーエンディング曲。

間奏部分ではパンの話やご当地のお土産の話をしていた。

大阪ではリュックにパンを入れていたからパンの香水いらず、という話をしていたような気がする。そしてそのまま顔から火が出ちゃうような失敗を~の歌詞を歌い出したため佐橋さんに「本当だよ!!(笑)」と突っ込まれる一幕も。

花「そうだよね、こんな感じで歌い出しちゃダメだよね(笑)」
佐「皆さんお気づきかとは思いますがそうなんです、ギター漫談なんです(笑)」

真面目な挨拶をした後歌い直していた。自由かよ好き。

おわりに

国内公演のMCまとめは以上。いくつか書けていない事があるような気がするが、網羅できていない自覚はある。でもたくさん書いたから許して。

今回のツアーは4月に全行程が詰め込まれていて非常に濃い1ヶ月となった。これでしばらくは落ち着けるかな、といったところ。香菜貯金に励もう。

最後に、ここまで読んでくれた方がいらっしゃったら最大級の感謝を。平成中に書き上げるつもりだったのに1ヶ月以上遅れちゃってごめん。

中国公演の様子は…多分書かないかな…。書いてもボリューム抑えめになるかなと。期待はしないでほしいとだけ。

今回のツアーも楽しかったなぁ、酒は美味しかったし海外にも行ったし。
次はどんな景色を見られるんだろうなぁ、私も頑張っていこうか、といったところで今回はここまで。またお会いしましょう。

ではまた。

f:id:vviilloovv:20190415001820j:plain

【備忘録】 「楽々ERDレッスン」を読む

うぃろぅです。

今日も今日とて備忘録。ですが今日はe-ラーニングではありません。読書です。 ここのところDBについて学習していたため、その流れで実践的な本を読みます。 所用と重なって読むのに4日かかってしまった、かなC。

Fjord BootCampのプラクティス対象にもなっているため、一石三鳥ですね。

今日のテーマ

楽々ERDレッスン (CodeZine BOOKS)

楽々ERDレッスン (CodeZine BOOKS)

「楽々ERDレッスン」を読む

とはいえ本の内容を詳細に書くわけにはいかないため、大事だと思ったことをいくつか記録しておく。

正規化について

業務視点から見た正規化が大事。
例えば「商品」と「単価」は従属しているが、セール等で割り引くことがあるのならば「商品」テーブルにも「明細」テーブルにも「単価」カラムを設定しておく必要があるよね、という話。
2つの「単価」は名前が同じでも指し示しているものが違う(設定価格と実売価格)ため、むしろ両方に設定してしかるべきであると。なるほど。

IDの重要性

主キーに「○○コード」を設定することが多くある。
たとえこれがユニークだとしてもコード体系が変わる可能性が0でないのであれば、この値は外部キーとして設定するべきではない。郵便番号ですら5桁から7桁になったのだから恒久的に変わらないという保証 はどこにもない。
確かにそのとおりで、そうなってしまうのであれば「○○コード」とは別に「○○ID」を定義するべきなのである。すなわち識別子(アイデンティファイア)。これならコード体系が変わっても大丈夫。どんどん疎結合にしよう。

標語

One Fact In One Place

1つの事実は1つの場所へ。

正規化のコツは「いかに無理なく無駄なくするか」を念頭に置くこと。
この「無駄なく」が曲者で、先ほどの「実売価格」や例えば「セット価格」のように、「事実を重複なく記録できる」状態になるように正規化しなければ「作業の無駄」が生じてしまうことになる。重複項目のように見えるが事実を記録する上で必要な項目なため重複はしていない、とそういうことになる。

可逆性に注目する

可逆性のあるものは項目削除としてよいが、不可逆性のあるものは項目として設定しないと正規化とはいえない。

2部

2部は歴史のお勉強が主な内容となっている。成り立ちから必要性を明らかにしていくわけである。
こちらは詳細に書くような内容ではないため割愛。

3部

3部がこの本の核となっている。とてもわかりやすい(小並感)。

実際に表組みになっている用紙や入力欄を見かけたらDBに落とし込んでみようよ、という試み。

手順

  1. イベント系
    「予約」とか「注文」とか、入力結果が最終的に何をするものなのかを見出す。
  2. リソース系
    「誰が」予約 / 注文するのか、「何を」予約 / 注文するのか、といった風に主語や目的語を見出す。
  3. 項目追加
    作ったテーブルに項目を追加していく。
  4. 識別子追加
    何はともあれ識別子を追加する。
  5. リレーションシップ設定
    外部キーは識別子を対象にしてリレーションシップを設定していく。
  6. 完了!!

ざっくりこの流れに沿えば数分でER図が完成する。私はまだ数分では終わらないので基礎連を重ねて基礎体力を身につけていく所存。

「~日」と語尾につけて違和感がないのはイベント系、「~名」と語尾につけて違和感がないのはリソース系と判断できる。「予約日」「予約者名」と考えるとなるほど、となる。

ファーストフードが難しい

実際にSQL Fiddleあたりを使ってやってみると、第3回のファーストフード店レシートがなかなか曲者。セットがあるわここで食べるか持ち帰るかの選択肢があるわレジナンバーも管理するわでもうね。てんやわんや。順番に基礎力をつけるべし。

ファーストフードのセット商品の表示に若干手間取ったため、実際に作ってみた。これが美しい形なのかは不明。自己参照は慣れが必要。

導出項目と向き合う

ガス料金、電気料金の例では導出項目の排除がポイントとなっている。読み進めていくと「確かにそうだな」となってシンプルな形に落ち着くが、自分で手を動かしてみると全くそうはいかない。基礎体力、つけよう。

4部

付録。SQLについてのあれこれ。
簡単そうに見える処理でも内部的には多くの処理が走っているんだよ、という話。
「書き順」についても触れられていて、処理順に沿って書くと可読性が上がる。心がけよう。

さらにRDBMSボトルネックについて。最近はネットワーク自体がボトルネックとなってきていて、そのことから「NoSQL」という考え方が広まりつつある。私は詳しくないため詳しく書かれている記事を以下に貼っておく。

qiita.com

まだまだ学びが溢れているなあ。

まとめ

この本、非常に実践的でためになる。実際に手を動かすのが一番の勉強になるため、これからもサクサク手を動かしていこうとなる良書だった。

DBまわりの座学はいったんこんなところかなあ。

ではまた。

【備忘録】 DB / SQL基礎

うぃろぅです。

今日はDB基礎。やっていきましょう。

今日のテーマ

DB基礎

vviilloovv.hatenablog.com

設計編を先にやってしまっているからいまさら感がすごい。まぁ何か身につくものがあるでしょう。

DBとは

データを一元管理する仕組みのこと。

変遷

台帳(紙) → ファイル(データ) → DB(データ)

フォルダ内にファイルをぶわーって並べて管理するイメージがファイル。経験はない。
年賀状の住所録をフロッピー内に保存、みたいな。被りが生じることが大いにある。

でもhoge_(日付)とかfuga_r1みたいにつけるのは…バージョン管理かそれは。

RDB

RDB(リレーショナル・データベース)はリレーショナル・モデルに基づくデータベースのことである。

トートロジー感ある。要は複数の表を関連付けて管理する、といったところ。

構成要素

表(TABLE)

RDBにおいてデータを管理する基本単位。

関連付けは「主キー」「外部キー」といったキーを参照して行う。

RDBMS

Relational
DataBase
Management
System

RDBを管理するシステムのこと。障害発生時にリカバリしたり、データの不整合を防いだりと重要な役割を担っている。

SQL

Structured
Query
Language

DBを操作するための言語。

  • DML
    Data Manipulation Language - データ操作文。selectとかdeleteとかのよく使うものがこれにあたる。
  • DDL
    Data Definition Language - データ定義文。createとかdropとかのテーブル自体の操作に使うのがこちら。
  • DCL
    Data Control Language - データ制御文。grantとかcommitとかの権限、トランザクションといったデータ外のことを制御するのがこれ。

以上の3種類がある。

基本的なデータ検索

実際に何ができるかを見ていく。

表の照会

表から必要なデータを取り出すことができる。

例として

  • 射影
    列を取り出す。
  • 選択
    行を取り出す。
  • グループ化
    読んで字のごとく。

が挙げられる。

射影

select (列名1, 列名2, ...)  
from (表名)

よく見るやつ。select *で全列取り出し。

選択

select (列名1, 列名2, ...)
from (表名)
where (検索条件式)

条件に合う行を検索して抽出する。

演算子として、

  • 比較演算子
    >とか<>とかのExcelでもよく見るアレ。
  • BETWEEN演算子
    (列名) between 値 and 値で範囲をとってこれる。
  • IN演算子
    (列名) in (値1, 値2, ...)でor検索が簡単にできる。
  • LIKE演算子
    (列名) like '文字'でパターンマッチできる。IDが1で始まって9で終わる、とかそういう調べ方。
  • NULL演算子
    (列名) is nullで空値を検索できる。

がある。between以降の演算子not指定も可能。

select *
from sample
where id not in (101, 201)

id101201以外の行を引っ張ってくる。

select *
from people
where address like '%区%'

addressという文字を含んでいる行を抽出する。

論理演算子

  • and
    条件を全て満たす
  • or
    条件をどれか満たす
  • not
    否定を表す

これらを適切に使うことで欲しいデータを的確に引っ張ってこれる。

並べ替え

order by (ソート対象列) asc / descで昇順(asc)か降順(desc)に並べ替え。

select *
from sample
order by price desc

priceで降順に並べ替え。省略した場合はデフォルトでascになる。

グループ化

集合関数

  • count (列名 / *)
    行数をカウント。
  • sum (列名)
    総和を算出。
  • avg (列名)
    平均値を算出。
  • max (列名)
    最大値を算出。
  • min (列名)
    最低値を算出。

ができる。

select count(*)
from sample

とすると対象テーブルの件数が出力される。件数を算出するだけのため、countしない場合より処理が軽い。

select (列名1, 列名2, ...)
from (表名)
(where 条件)
group by (グループ化する列名)

基本文法。

select id, sum(price), max(income)
from item
group by id
having sum(price) > 10

集合関数を使った条件を記述する場合having句を用いる。

応用

基礎とは

結合

複数の表から同時に情報を抽出し、1つにまとめる。

  • 内部結合
  • 外部結合
  • 自己結合
  • クロス結合

の4種類がある。

www.techscore.com

TECHSCORE先生に訊くのが手っ取り早いが、つらつらと書いていく。

内部結合

共通の列の値が結合条件に一致する行の取り出し。

  • item
item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
  • shelf
shelf_id shelf_name floor
101 紙類 1F
102 筆記類 2F
103 食器類 1F
104 日用品 2F
105 工具 2F

この表に対して

select item_id, item_name, shelf_name, floor
from item inner join shelf
on item.shelf_id = shelf.shelf_id

を実行すると

item_id item_name shelf_name floor
001 メモ帳 紙類 1F
002 付箋 紙類 1F
003 鉛筆 筆記類 2F
004 ボールペン 筆記類 2F
005 玄翁 工具 2F

この表が得られる。同一のカラム名が存在する場合(表名).(列名)と書いてどの表のカラムなのかをはっきりさせる必要がある。

例を書くのか一番時間かかる…。

外部結合

主キーの値が一致しない値も抽出してくる。

  • item
item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
  • shelf
shelf_id shelf_name floor
101 紙類 1F
102 筆記類 2F
103 食器類 1F
104 日用品 2F
105 工具 2F

さっきの表を再掲。この表に対して

select item_id, item_name, shelf_name, floor
from item right outer join shelf
on item.shelf_id = shelf.shelf_id
item_id item_name shelf_name floor
001 メモ帳 紙類 1F
002 付箋 紙類 1F
003 鉛筆 筆記類 2F
004 ボールペン 筆記類 2F
005 玄翁 工具 2F
食器類 1F
日用品 2F

この表が得られる。

left outer joinとすることで左側の表を全て出力、rightでその逆。今回はshelfの一致したいものも出力するのでright outer joinとしている。full outer joinで両方の一致していない行も含めて出力される。書き方が難しい…。

ちなみにleft right full が書いてある場合outerが省略可能で、innerは左右の別がそもそもないため省略可能となっている。

select a, b from hoge join fuga on b = a; -- 内部結合
select a, b from hoge right join fuga on b = a; -- 右外部結合
select a, b from hoge left join fuga on b = a; -- 左外部結合
select a, b from hoge full join fuga on b = a; -- 完全外部結合

つまりこう書けるということ。

自己結合

同一表を結合する。

codezine.jp

例書くの疲れたわかりやすい例が載っていたため詳細はこちら参照。

重複行削除に力を発揮するみたい。
他には例えば社員ID上司IDがあり、上司ID社員IDに含まれている場合に使える。
社員表から上司表を作成すると。なるほど。

select (別名).(列名)
from (表名) as (別名1) inner join (表名) as (別名2)
on (別名1).(外部キー列) = (別名2).(外部キー列)

同一表を参照するため、asで別名を宣言することが多い。asは省略可能。

クロス結合

ある表とある表の組み合わせを求める。

select (列名1, 列名2, ...)
from (表1) cross join (表2)

特に難しいところもなく。
これを何に使うかといえば、各データの組み合わせに対してテストを実行する、ということでテストデータ作成に有用。

  • item
item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
  • shelf
shelf_id shelf_name floor
101 紙類 1F
102 筆記類 2F
103 食器類 1F
104 日用品 2F
105 工具 2F
select item_id, item_name, shelf_name, floor
from item cross join shelf

これをうっかり実行すると

item_id item_name shelf_name floor
001 メモ帳 紙類 1F
001 メモ帳 筆記類 2F
001 メモ帳 食器類 1F
001 メモ帳 日用品 2F
001 メモ帳 101
002 付箋 紙類 1F
002 付箋 筆記類 2F
002 付箋 食器類 1F
002 付箋 日用品 2F
002 付箋 工具 2F
003 鉛筆 紙類 1F
003 鉛筆 筆記類 2F
003 鉛筆 食器類 1F
003 鉛筆 日用品 2F
003 鉛筆 工具 2F
004 ボールペン 紙類 1F
004 ボールペン 筆記類 2F
004 ボールペン 食器類 1F
004 ボールペン 日用品 2F
004 ボールペン 工具 2F
005 玄翁 紙類 1F
005 玄翁 筆記類 2F
005 玄翁 食器類 1F
005 玄翁 日用品 2F
005 玄翁 工具 2F

こうなる。この例は実用性はないがあくまで例ということで勘弁して欲しい。

複問い合わせ

ある表を照会した結果を用いて別の表を紹介する。

where (検索条件) = (select文)と続けていく。これが何階層にもなってしまうと処理時間が大変なことになりがち。

www.atmarkit.co.jp

よくわかる解説がこちら。

データ検索以外の操作

データ追加

insertを用いる。

insert into (表名)(列名1, 列名2, ...)
values (値1, 値2, ...)

全ての列に値を設定する場合列名は省略可能。

  • item
item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105

おなじみのこれに対して

insert into item
values ('006', '', '105')

これを実行すると

item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
006 105

こうなる。かんたーん。

こちらも複問い合わせを利用可能で

insert into (追加する表名)
select (列名1, 列名2, ...)
from (検索する表名)
(where 条件)

とすれば条件に合うデータをまとめて追加できる。

データ更新

updateを用いる。

  • item
item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
006 105

先ほど変更したこの表に対して

update item
set item_name = ノミ
where item_id = '006'

これを実行すると

item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
006 ノミ 105

こうなる。where句の条件が複数行に当てはまる場合全てに対して更新が走る。

データ削除

deleteを用いる。

  • item
item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
006 ノミ 105

この表に対して

delete from item
where item_id = '006'

これを実行すると

item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105

こうなる。こちらも複数同時に消すことが可能なため

delete from item

うっかりこれを実行すると全部消える。落ち着いてrollbackだ。

トランザクション

データベースに対する処理の基本単位。

リモートリポジトリとローカルリポジトリの関係に近い。手元の修正はリモートには反映されていないため、変更を確定するためにはcommit、変更を破棄するためにはrollbackを実行する。

表の定義

ここまでが表に対する操作、DML。ここからは表自体の作成や削除を行うDDLについて。

表作成

create tableを用いる。

先ほどのitem表を作成するのであれば

crate table item
(item_id CHAR(3) NOT NULL,  -- 固定長文字列、必須項目
item_name VARCHAR(20),  -- 可変長文字列
shelf_id INTEGER(3) NOT NULL)  -- 数値、必須項目

こんな感じ。型が適当なのは例なので許して。

大文字小文字の区別はないがなんとなく型名は大文字のイメージ。SELECTとかも大文字で書いてある場合が多いけれども。

表削除

drop table item

消すのはとても簡単。そしてテーブルの変更はrollbackできない。要注意。

RDBMSの機能

  • データの物理構造管理
  • データ定義情報管理
  • データ操作機能提供
  • 同時実行制御
  • 機密保護
  • 障害回復

概ねこんなところ。データ管理はお任せ!みたいな感じ。

データの物理構造管理

db-study.com

データの格納位置を一切気にすることなくSQLを扱える。

データ定義情報管理

  • データファイル
    ユーザーが定義した表のデータ
  • データ辞書
    データ構造、関連付け、容量等のDB自体の情報
  • ログファイル
    変更履歴。

を管理してくれる。

データ操作機能提供

SQLで操作できるよ、ということ。微妙に方言はあるが概ね似たり寄ったり。

同時実行制御

多重更新を防止するための排他制御。ロックをうまいこと掛けてくれる。

デッドロック

お互いに更新したい箇所をロックしあってしまい、ロックがとけなくなる。
片方のSQL文をエラーにすることでRDBMSデッドロックを回避させることが多い。

そもそもの更新順を設定する、1更新につき1行に限定する、といったことでデッドロックが起きないようにすることが大事。

トランザクション同時実行時の現象

  • ダーティーリード
    commitしていないデータが検索できる現象。
  • ノンリピータブルリード
    以前の問い合わせと同じデータが検索されない現象。
  • ファントムリード
    以前の問い合わせ結果に含まれないデータが検索される現象。

qiita.com

わかりやすい。Qiitaは頼りになる。

トランザクション分離レベル

(分離レベル) ダーティリード ノンリピータブルリード ファントムリード
READ UNCOMMITED
READ COMMITED ×
REPEATABLE READ × ×
SERIALIZABLE × × ×

下にいくほど同時実行性が低くなる。

機密保護

DB内へのデータアクセスを制御する機能。権限を操作して制限をかける。

障害回復

データが破損したときに元に戻す機能。

  • システム障害
  • メディア障害
  • アプリケーション障害

等様々な事情でデータは破損する。

バックアップとログファイルを組み合わせてデータを復元していくことになる。

ログファイル

2種類のログを比較して復元する。

ロールバック処理

更新前ログを使用して更新された部分を元に戻す処理。

ロールフォワード処理

更新後ログを使用し、障害発生直前の状態に回復する処理。

応用情報技術者試験を受けたときに勉強したなぁって。

まとめ

以上の知識を基に、各種ベンダーのRDBMSに関する知識を拡充していくべし。

めっちゃ書いた。先週より時間短かったのに表を作ったせいでよっぽど面倒なことに。

ではまた。

【備忘録】 DB設計 基礎編

うぃろぅです。

たまには実務的なところもやっておこうということでやっていきます。

今日のテーマ

DB設計 基礎

内容

  • ER図
  • 正規化
  • 設計タスク

大学のときにうっすらやった記憶があるようなないような。あと応用情報技術者試験とか。受かったら大体忘れるよね。

qiita.com

わかりやすい記事があった。インターネットには知見があふれている…。

DB設計の位置づけ

ウォーターフォール型の工程においての上流工程である。

抜け / 漏れがあると手戻りの幅が大きくなるため、コストが増大する。
そのため、DE設計はおざなりにせずきっちり行わねばならない。どの工程もおざなりにするな

DB設計の流れ

  • 概念設計
    エンティティ抽出、属性抽出、正規化等。
  • 論理設計
    サマリ・エンティティのの検討、非正規化等。
  • 物理設計
    テーブル設計、インデックス設計、セキュリティ設計等。

DBかするかしないかというところから検討していく。

概念設計

  • 業務 / データ分析を行う
  • DBMSには非依存

必要なデータ項目を漏れなく洗い出すことが重要。
アウトプットは概念ER図で行う。

論理設計

  • パフォーマンスを考慮

性能を意識して概念設計のデータモデルを見直す必要がある。
アウトプットは論理ER図で行う。

物理設計

  • 実際のマシンに応じて考慮する
  • 領域設計を行う

仮想化も選択肢に入れればいいんじゃないですかね…?
運用形態を考慮し、物理設計書にアウトプットする。

ER図

it-koala.com

この記事を読み込めば大体理解できる。

ERとは

Entity
Relationship

属性の関係を表す図。
「顧客」「受注」「明細」「商品」のように必要な要素をエンティティごとに分け、線で繋ぐ。

書き方にはいくつかタイプがあり、IE型やIDEF1X型等がある。

エンティティとは

業務処理の過程で処理 / 管理の対象となる情報のこと。
具体的なインスタンス(Oさん 女性 20代、Hさん 女性 30代等)を抽象化したもの(氏名 性別 年齢層)がエンティティということになる。

もの、組織、場所、出来事がエンティティになることが多い。

f:id:vviilloovv:20190524115140p:plain
エンティティの種類

種類としてはこんな感じ。大きく分けて2種類。

属性

エンティティで保存すべき情報。エンティティって書きすぎて頭おかしなるで。

  • ID
  • 氏名
  • 誕生日
  • 住所

みたいな感じ。識別キーをIDにすることが多い。

識別キー属性とは、「その情報があれば対象が一意に定まる」属性のこと。
識別キーが1つのこともあれば複数の事もある。

リレーションシップ

業務処理上必要となるエンティティ間の関係。
「何対何か」「必ず結びつくのか」「どういう関係なのか」を表す。

カーディナリティ

インスタンス同士が何対何で結びつくか。

  • 1つのキャラを1人の声優が演じる場合1対1
  • ポプ子とピピ美のCVは1対多
  • 収録スタジオと声優の出先は多対多…ちょっと苦しい

外部キー

カーディナリティの多側に1側の識別キーがコピーされて外部キーとなる。

オプショナリティ

自分側に対して相手側のエンティティが任意か必須かという性質のこと。

  • 声優が事務所に所属するのは必須ではない、みたいな。

多対多の分解

多対多は2つの1対多関係に分解できる。
交差エンティティを追加して分割する。

  • 「声優」「スタジオ」をまとめて「訪れた回数」で履歴管理するとか…ええい例がわかりにくい
  • 「商品」「倉庫」を「在庫」で仲介する、というのがわかりやすい例 「倉庫番号」と「商品番号」を外部キーとして管理する。

多対多は必ず分解して概念設計を終える。

ER図記述時の留意点

「線は直角に引く」「リソース系は同じ列に並べる」等ルールを決めて運用するといつ誰が見てもわかりやすい図となる。心がけるべし。

スーパータイプ / サブタイプ

プログラミングで言うスーパークラス / サブクラスと捉えるとわかりやすい。共通属性を抽出して継承するイメージ。

応用的な関係

木構造1対多の自己ループとなる。営業所の下に部があってその下に課があって…が例。

正規化

ext-web.edu.sgu.ac.jp

この記事がわかりやすい。

データの冗長な部分を排除し、重複なくグルーピングする手法。

データ更新 / 追加 / 変更に強いDBにするために必須。

基本的には第三正規系までで充分取り扱えるが、第四、第五…とまだ続きがあるにはある。

第一正規化

単純に複数持っているデータを分割するのみ。

商品番号 商品名
001 メモ帳
002 ボールペン

これを

商品番号 商品名
001 メモ帳
001 メモ帳
002 ボールペン

こうする。

主キーないけど例ということで。

第二正規化

複数の主キーで一意に定まるデータ、1つの主キーで定まるデータが混在しているDBを分割する。

商品番号 色番号 商品名
001 01 メモ帳
001 02 メモ帳
002 01 ボールペン
002 02 ボールペン

「商品番号」「色番号」を主キーとする。

この場合、「商品番号」「色番号」が決まれば「色」は一意に定まるが、「商品名」は「商品番号」がわかれば一意に定まる。

なのでこの表を

商品番号 商品名
001 メモ帳
002 ボールペン
商品番号 色番号
001 01
001 02
002 01
002 02

こう分割する。

第三正規化

主キー以外の部分が決まれば一意に定まるDBを分割する。

商品番号 商品名 棚番号 棚名
001 メモ帳 101 紙類
002 付箋 101 紙類
003 鉛筆 102 筆記類
004 ボールペン 102 筆記類

主キーは「商品番号」。

上記の例だと「棚番号」がわかれば「棚名」がわかる。メモ帳は筆記類じゃないかって?細けえことはいいんだよ!!

なのでこれを

商品番号 商品名 棚番号
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
棚番号 棚名
101 紙類
102 筆記類

こうする。第二正規化と第三正規化はよくわからなくなりがち。

トップダウン / ボトムアップ分析

概念設計時に情報を抽出するときの分析方法。

itmanabi.com

わかりやすかった記事を貼っておく。

要件(全体像)をもとに「これが必要になりそう」「そのためにこの情報が必要」と分析していく。考慮漏れがおきることがある。

既存のDBや資料を基にデータ分析を行う。現状分析が主となるため新しく何かを始めるにはデータが足りない。

相互補完して進めていくのがベター。

ボトムアップ分析の手順

  1. エンティティ抽出
  2. 属性抽出
  3. 識別キー決定
  4. リレーションシップ抽出
  5. 正規形確認
  6. ボトムアップモデル統合

現在使っている伝票や発注表等から「顧客」「受注」「商品」等を抽出し、それを細分化していく。

識別キー決定やリレーションシップ抽出は順番が前後することも大いにある。

トップダウン分析の手順

  1. エンティティ抽出
    「商品の注文を受け」、「発注する」なら「商品」「受注」「発注」が必要だな、みたいな。
  2. 属性抽出
    将来的に必要になるであろう要素から属性を抽出する。
  3. 識別キー決定
    要件には出てこない要素のため、一般的に「商品番号」が必要だな、とくみあげていく。
  4. リレーションシップ抽出
    「1回の注文で複数注文ができる」のであれば「受注」と「商品」が1対多だな、といったところ。
  5. 正規形確認

トップダウンはインプットに対して1つのモデルが作成されるため、統合が不要。

ER図統合

トップダウン分析によって得られたER図とボトムアップ分析によって得られたER図を統合して1つのモデルにする。MECEに。

モデル見直し

目的

検索パフォーマンス向上のため。

join hoge join fuga(以下ループ)ってすると重くなるもんね。適度に結合するのも大事。

必要な情報

  • 非機能要件
    レスポンス時間、業務の運用要件等。
  • データアクセスの頻度 / 量
    1時間当たりどれくらい、ピーク時にどれくらい等。
  • データの性質
    各エンティティのデータ件数、1対多関係の多側のカーディナリティ、データ蓄積時間等

非正規化

テーブルの結合を行う。

www.accessdbstudy.net

詳しい記事があったので詳細はこちらを参照。

リンク先にもあるが「正規化を行わない」のではなく「正規化を行ったが、様々な要素を考慮した結果、あえて正規化したモデルを結合する」という手順が大事。それなら質問されても明確に答えられる。

導出項目の取込

導出項目とは、他のテーブルや列から導き出せるデータ項目のこと。

例としては集計が挙げられる。単価と個数から金額を計算するのか、注文数が膨大になるため「金額」を属性とするのか。こちらもパフォーマンスとの兼ね合いとなる。

サマリ・エンティティ

導出項目を保存するエンティティをサマリ・エンティティと呼ぶ。

集計する項目数が非常に多い場合は集計した結果をサマリ・エンティティに保存しておき、そこを検索することで処理時間を向上させるのが狙いとなっている。

代替キーの検討

amg-solution.jp

しばしば議論に上がるナチュラルキーとサロゲートキー。どちらにもメリットがありデメリットもあるのでよく検討することが必要。

物理設計

テーブル変換

ERモデルからテーブルに変換する。

  • エンティティ → テーブル
  • 属性 → 列
  • 識別キー → 主キー
  • 外部キー → 外部キー

と置き換える。

ささにデータの型や桁数なども決める必要がある。

ドメイン定義

属性の取りうる値の範囲を管理する。

属性の一元管理を行えるため、変更に強くなる。

codezine.jp

ドメイン定義を使おう、という記事(乱暴)。

テーブル分割

パフォーマンス向上のためにテーブルを分割することがある。

  • 垂直分割
  • 水平分割

cat-p0k0pen.hateblo.jp

わかりやすい。でもこの事例にはとりかかりたくないね。ディスガイアアプリ、元気してるかな…

月ごと、頻度ごと等で分けることで検索を迅速に。インデックスもこの考え方に通じるものがあるはず。

インデックス

www.atmarkit.co.jp

ややこしい内容だがしっかり理解するべき。

実データ検索ではなくポインタ検索、がポイントになりそう。C言語みがある…ないか。
検索したいデータとそのデータが存在するポインタのオブジェクトを検索し、そのポインタを用いてデータに直接アクセスするため、大量のデータを上から順番に見ていくより早くなる、という流れ。

更新に時間がかかるようになるため、データ量とにらめっこしてパフォーマンスが向上するかを判断する必要がある。

インデックスの効果

ガイドライン

  • where句で頻繁に使用する
  • 列の値が比較的一意
  • テーブルの結合で使用する
  • 更新の少ない
  • 比較的大きなテーブル

といった列にインデックスを当てると良い。

ビュー

実データを持たない仮想表のこと。

よく使うselect文に名前をつけ、そのデータに対して条件検索を行うことでパフォーマンスが上がる。

oracle.na7.info

必要とならないデータを隠す、という点でも利点がある。

仮想表に対しても普通のテーブル同様の操作ができるため、テーブルとビューの意識をせずに取り扱える。

物理設計

物理設計の範囲

  • OS / ハードウェア / RDBMSの選定
  • DB構造の定義
  • 運用計画の定義

DB内容以外のほぼ全て、ということになる。すごく広い。

物理設計の全体像

  1. OS / RDBMSの選定
  2. テーブル / インデックス定義
  3. 資源見積もり
  4. ストレージ構成選択
  5. セキュリティ計画
  6. パフォーマンス監視計画作成
  7. バックアップ / リカバリー計画作成

という流れとなる。最初から最後まで。

OS / RDBMSの選定

どの要素を落とすか、トレードオフ要素は何になるのか、等考えることは多い。頭を抱えよ。

テーブル / インデックス定義

テーブル

  • ヒープ表
  • 索引構成表

インデックス

  • 単一型索引、コンポジット索引
  • 一意索引、非一意索引
  • ビットマップ索引

資源見積もり

  • テーブル / インデックスの見積もり
  • RDBMSシステムファイルの見積もり
    ログファイルの領域、作業用領域、ディクショナリ等も考慮

ストレージ構成選択

安全性や性能を考慮し、どこにどのデータを格納するかを検討する。

ファイルアクセス

  • テーブルデー
  • インデックスデータ
  • ディクショナリ
  • 作業用
  • ログ

といったようにアクセスを分散させるようにする。

データ格納方式

  • ファイル・システム
    頻繁にやり取りする場合パフォーマンスが低下する。
  • RAW
    ファイル・システムを使わないため読み書きの速度が速いが要領の拡張やファイルコピーが難しい。

セキュリティ計画

構成要素

  • ユーザーアカウント
  • 権限
  • ロール
    ユーザーに対する権限の付与 / 剥奪を楽にする機能。ユーザーに対して権限を1つずつ与えるのではなく、予め一定の権限が与えられたロールを付与することで権限操作が楽になる。

不正アクセス防止のため、監査機能が重要となる。

パフォーマンス監視計画作成

パフォーマンスが悪くなっている兆候が見えた時点で対応する方が当然ながら良い。

そのため、定期的にパフォーマンスをベースラインと比較して監視する機能を活用すると対応が後手に回らない。

バックアップ / リカバリー計画作成

  • バックアップ

「データは壊れるもの」である。そのため、オンラインバックアップ / オフラインバックアップを定期的に行う必要がある。

バックアップ方式により環境構築に変化があるため考慮が必要。

まとめ

今日の内容はあくまで基本。実際に手を動かす過程で得られる知見、経験を大事に知識を拡充させていくのがベスト。

めっちゃ書いた。今日の執筆時間は動画が4時間くらいあったため調べる時間と併せて3時間程度。

ではまた。

【備忘録】 モチベをマネジメントする

うぃろぅです。

今日も今日とて。

今日のテーマ

PLに求められるモチベーションマネジメントスキル

プロジェクトリーダーでなくともモチベをマネジメントする機会はあるでしょ。何かの準備をみんなでするとか。

定義

モチベーションを「働く意欲」と定義する。

理由付け、動機付けというイメージ。

観点

  • 価値観
    個々の違いを認識してアプローチすべき。
  • 使命感
    お客様に感謝されたい / 会社の目標を達成したい / プロジェクト目標を達成したい等。
  • 自信
    能力、環境が充足しているか

で成り立っているものとする。

モチベーション維持の要素

  • 目標に向かってやるべきこと
  • 個々がやりたい仕事内容
  • その仕事をできる、という気持ち

を相互理解するコミュニケーションが重要。

基本動作

全体像

コミュニケーションの基本

マネジメントの基本はコミュニケーション。

そのために大事なことが以下。

  1. 積極的傾聴
    具体的な問いかけが重要。
  2. 説明責任
  3. マナー

それぞれに対する内訳

  • 方針明確化
  • 指示明確化
  • 正しい評価
  • 体制最適化
  • 部門間調整
  • 人材育成

モチベーションの創造者 / 破壊者

  • 創造者
    「問題があったら俺が責任を取る」「困ったことを相談したらいつでも真剣に乗る」が大事。
  • 破壊者
    「明日からうまいことやってくれ」「上司の言いなりになっている姿が見える」はダメ。

相手からすると、「正当に評価されているか」はかなり重要な点。しっかりとコミュニケーションをとり、相手に評価を伝えるべき。
メールの返信は忙しくともきっちりとするべき。

「いまどきはメールのコミュニケーションも多い」とのことだがいまどきはSlack等のコミュニケーションツールなのではなかろうか。

積極的傾聴

スキルは以下。

  • うなずき
  • 鸚鵡返し
  • 言い換え
  • 引用
  • 接点の発見
  • 共感
  • 意味づけ
    相手の話から重要な点を見つけて指摘すると相手はより積極的に発言する。

説明責任

プロジェクトの内容に変更があった場合、速やかに説明をしなければならない。反応を予想して萎縮する方が良くない。

異動の話を喫煙コーナーでしかきかない。
見通しの悪い典型例。私の会社がまさにそれ

コミュニケーションのマナー

  • 成長のために叱る
    自分のイライラをぶつけるのはNG。
  • 叱る基準をしっかり持つ
    かわいい子は叱らない、はNG。むしろかわいい子に言うのが楽しいって言っていた高校時代の同期、この前飲んだら「泣き顔もかわいかった」って言っててやべえなこいつってなった。
  • 叱り方に注意する
    責めるような口調はNG。
  • TPOに配慮する
    「すぐに」「1対1で」「内容を考慮して」叱るべき。
  • 褒める時は褒める

方針の明確化

  1. ビジョンを提示
    長期的
  2. 戦略を提示
    中長期的
  3. プロジェクト方針、役割、方向性の提示
    短期的

を明確に行うことが重要。

指示の明確化

  1. 命令系統の明確化
    「どの作業が」「誰から」指示されるのかを明確にする
  2. 納得する指示

  3. 自ら考えて指示を行う
    言いなりにならない

  4. メンバーの状況を把握する
  5. 作業目的 / 背景を明確に示す
  6. 作業負担を考慮する

「お願いできませんか?」という訊き方をすると現在の状況を示しつつ引き受けてくれることが多い。譲歩の選択肢があるということが大事。

正しい評価

日々のコミュニケーションの中でこまめにフィードバックすることが重要。

「こういったことを期待しているからね」と事前に伝え、達成できているときは「すばらしい」と褒めるとモチベが維持できる。

「私だったらこうするかな」という言い方は強制力が弱いため伝えやすい。

「君らしくないな」から始めるといい、と講義では説明されていた。どうなんだろうねこれ。

私だったら「らしくないじゃん、どうしたの?」って訊かれたら「私の何がわかるんだ」となってしまう。根っこがひずんでゆがんでいるので。「ひずむ」も「ゆがむ」も同じ漢字なの面白いよね。
「私のことは私で決める」という人ほど「君らしくない」とは言われたくないんじゃないかなあ。そこはコミュニケーションの過程で見極めることなのかしら。

体制明確化

  • 実現可能性を考えた体制作り
  • 柔軟な見直し
    横並びにするとか人数を調整するとか。
  • 体制改善提案は堂々と働きかける
    交渉する姿を見せる、ということが重要。「やってくれている」感。

部門間調整

  • 壁を越えた協力支援体制の構築
    困ったときに他部門ならあっさり解決できることはいくらでもある。
  • 役割分担量定義
    仕事が役柄にではなく人につきがち。調整はしっかりと。難しいところなのだけれどね。
  • 仕組みづくり
    コミュニケーションの方法は事前に調整しておく。

人材育成

  • 現状把握
  • 育成計画策定
  • 徹底した計画実行

人は勝手には育たない。

私は会社外を見始めているので勉強しているがそうでない人のほうが多いよねという話。私が真面目に取り組んでいるかは別の話だよ!!

まとめ

今回の内容はあまり具体的ではないため、参考にしつつ掘り下げて習得していく必要がある。

2倍速で聴いたから1時間ぴったりくらい!!2500文字くらい!!会社のキーボード入力しづらい!!!

ではまた。