補習ほぼ確

学びや好きなことをただ自由に書く

テストは怖くない

考察

GMOペパボ Advent Calendar 2019の10日目！の記事です。
qiita.com

テストコードについて、どう思いますか？
私は書くのがとても嫌い！！！！！！！
...でした。

それまでは精々独自バリデーションのテストくらいしか書いてこなかったのを Ruby on Rails での開発ライフを始めるとともにそのテストフレームワークとしてよく使われる RSpec を使い始めて、TDDの波に...乗るぞ...! と意気込んだものの、大苦戦してました。
いや、今もめっちゃ苦戦するけど。

テストをDRYにするとは？遅延評価とは？を何度も調べたり、
これはプログラミングなの？？？これはパズルでは？？？と何度も頭を抱えたり
「進捗は（実装は終わってるの！！でもテストが書けないので）無いです」と昼回で報告するばっかりだったりでものすごくテストコードを書くという行為が苦手でした。

そんな状態だったのが気が付けば......今では結構好きだしドンと来いよ！！的な勢いでテストに取り組めています。

どうしたらそうなったんだっけか。自分なりに何だかんだで好きになれてきた、克服するためにやったことをつらつら書いてみます。

1. とにかく小さな単位から切り出してテストに起こしてみる、テストファーストを意識

テスト駆動開発（TDD）はテストファーストな開発手法ですが、これに慣れてないので

  • 必要な実装を終わらせてからはじめてそれを Green にさせるようなコードを書く
  • 実装を完璧なものにしてからテストに取り掛かる

ということをやりがちでした。「必要な実装をすること」「テストコードを書くこと」を別々の工程に捉えているので、テストをいつも後回しにしてしまう。
そしてそこから実装に対しての全部のテストコードを書いて検証していこうとするので、テストが通らないとどこで間違えているのかの切り分けをするのも効率が悪い。どこまでを1つのテストで検証したいのか、テストする単位も見失いがちになる。
実装した内容を元にテストケースに起こしていくので、絶対に成功するであろうテストを書くことにしか目が向かず、検証すべき項目の見落としが発生する。
すっごい悪循環。。。。。

設計方針が固まったらすぐ実装に入るのではなく
まずはテストする項目を列挙する。
テストの対象(describe)、テストすべき特定条件(context)、テストで期待するアウトプット(it, example)といった具合に大きい粒度から落とし込んでみる。
思う通りにテストコードを組んでみて必ず失敗するテストを作成してから、一つずつテスト単位に合わせて実装する。
と取り組んでみることで、
もっとこのテストは簡潔に書けないか？もっとモジュール同士が依存しないように、実装部分を疎にできないか？ということにもより目が向けられるようになり、設計を見直す引き出しも増えました。

2. 詰まったら地道にデバッグすることから

テストどうこうでもないけど、見慣れないエラーを解読しても内容が分からない、どこが原因で失敗したか分からないとすぐ助けを求めていました。。
テストが失敗する原因はすぐに分からなくともデバッグはすぐにできるのでどんどんデバッグする。
まあ1をちゃんとやってたら「テストが失敗する原因がすぐに分からない」ということはないのですが。

3. 答えは基本ドキュメントに書いてある

マジでそのまんまなのですが、Capybara を使った E2E テストを書くとき中々思うようなマッチャでテストが通らないよ〜〜とよくベソかきました。ちゃんとドキュメントがあるならばそれを読めと...。

4. ペアプロでテスト→実装→テスト→実装を繰り返す

まだまだテストに対して苦手意識が高かったとき。
スプリントで速が出せていないよねというのをチームで振り返ったとき、
エンジニア歴/チーム所属歴が長い人短い人含めてチームで圧倒的成長をするためには、高速なフィードバックが必要になる。そのフィードバックを高速に回すための底上げしようぜ、とチームで意見がまとまり、ペアプロを導入しました。

  • ひとつのスプリントタスクをスクラムチームの一個人が受けるのではなく、チームで受けてチームで捌く
  • ペアプロをする2人は、1つのタスクに対して入れ替えていき、同じペアで長時間ペアプロを行わない
  • ナビゲータとドライバーは、1つの作業単位を終えた時点で交代していく

大まかなルールはこんな感じでやっていました。
qiita.com
こちらの記事にとても近いですね。
ここでやってみて面白かったのが、3つめの点を対象のテストを書く、テストの対象のコードを実装する、といった感じでテスト→実装→テスト→実装とナビゲータとドライバーを入れ替えてやったことでした。

この間最初にドライバー側（テストを書く）に回ったらしばらくテストを書くことに徹するので、そうなると当初は RSpec だけ書くのやだよ〜〜〜っていうかどう書けばいいかわからないのだが？？？？？泣って感じなのですが、テストを書くことにもなんとか鳴らしていきつつ、上記のことも頭に覚えこませて進めていくと 1つの実装単位をペアで作り上げていくので認識のズレも1つ1つ解消していくことができてとても気持ちいい。

チームの誰とペアを組んでも1つのタスクを確実に仕上げられる、変化の強いチームができるし自分のこういう弱いところも無理やり引き上げることができるという「チームが成長する」という大きな目標達成の中で、副次的効果がたくさんありました。

===

克服した方法というか、振り返るととにかく書かなきゃ書けるようにならないな。というのがつまるところなのですが、自分自身に対して感じているだけでも以下が改善されてきたんじゃないかなと思っています。

1. 設計スキルが上がった
2. 機能実装で担保しなきゃいけない点を明確にして進められる
3. 「こうあるべき」への意識

あと、前の自分のようなあんまりテストを書いた経験がなかったインターンの学生さんに対してもテストの重要性を説いてまずテストから書こうぜ！って言って書いてる（...）

3については特に人力で品質担保はがんばらない！
サービスの品質と改善スピードを保つために、守るための環境を整えておくんだという意識がちゃんと自分の中でも持てるようになったなと。

テストコードがうまく書けるようになる、練度の高いテストを作り上げられるようになるのに
周りの人間がテストコードについて真摯にレビューしてくれること、チームがテストしっかり書くぞ！という軸をちゃんと持っていること、自分にとってはこの恩恵が大きかったなと思います。

「サービスとして、アプリケーションとしてどうあるべきか？」を常に考える、開発チームの土壌ができあがっている。
そういう土壌に身を置けるのはすごく幸せなことだなと思うし、だからこそ自分もその土壌を守るぞという意識が生まれる。
ひとつテストに取り組むことを通して、土壌の整え方に対する意識も以前と変わりました。

テストは怖く無い！！！テスト難しいけど、楽しい、難しいけどそういう再発見もあって楽しいよ。

===

めちゃめちゃお世話になりました。何度でも読み返したい。

www.slideshare.net


leanpub.com

『ルノワールとパリに恋した12人の画家たち』に行ってきた

すき！ 美術

ブログ書くの久々すぎるぞ.....

artexhibition.jp
に行って来たので、手元の出品リストに書いたメモをみつつ印象に残った作品を振り返る。

展示数とかどんなもんなんだろと思ってたけど、今年開催のなかでもかなり満足度の高い展覧会なんじゃないかな〜〜
本当に贅沢で充実した展示だった。
読んで興味を持たなくても、行ったら引き込まれるからぜひ行ってほしい。

クロード・モネ

  • 『アルジャントゥイユ』

タイトルはこれだけどアルジャントゥイユというのはモネが移り住んだ土地の名前で、この土地の風景は比較的多く描かれているっぽい。
水面が綺麗で緻密な絵。いきなり圧倒される。

ポール・セザンヌ

  • 『りんごとビスケット』
  • 『わらひもを巻いた壺、砂糖壺、りんご』

いつもあんまり、静物画はふーん...という感じなんだけどりんごがイキイキしていて目を惹かれる
解説にはセザンヌは「リンゴひとつでパリを驚かせてみせる」と絵（静物画）を描き続けたとあった。本当にこの「りんご」を手元に置いておきたい気持ちになる...不思議...

  • 『小舟と水浴する人々』

色彩、モチーフがゴーギャンっぽくて好き

アンリ・マティス

すべて、ググって見る著名な作品群より比較的青年期の作品っぽい印象を受けるような、そうでもないような...。
『青いオダリスク』はイスラム文化も融合してる感じが、ああ20世紀初頭の作品たちなんだなと改めて実感する

ギュスターヴ・モロー（象徴主義）のアトリエで学んだというのは意外...こないだモロー展に行ってそんな解説も読んだような気がするけど覚えてない。。

アンリ・ルソー

空の色がとにかく大好き

  • 『嵐の中の船』

作家の解説で、ルソーは税関の官吏で仕事の余暇に絵を描いていたとあったので（もちろんずっとその生活なわけではないけど）最初にこれを見て「仕事の余暇でこんな緻密な絵を描けるのか...」とバカな感想を抱く

  • 『婚礼』

大きいし迫力にのまれる
今回の展示は記念写真っぽいなと思わせる絵の割合が高かったのでなぜかじんわりくる
「記念写真」なんて印象を持つ絵ってそんなに無いからかな

  • 『人形を持つ子ども』

同行者はこの2つの印象がとにかく強いとのこと。まあそうだよね...

パブロ・ピカソ

前回どこかの展覧会で見た時「青の時代」の作品が多かったけど今回見た作品もよかった

  • 『白い帽子の女』
  • 『布をまとう裸婦』

「青の時代」の作品もそうなんだけど色使いは派手すぎる？重すぎる？と思うのにでもキチッとおさまっている。面白い。

オーギュスト・ルノワール

今回展覧会のメインがルノワールだけど、あらためて見るとやっぱり、おしゃれでムードがあるなあ
人物画、解説にもあるんだけどどの人物も生きる喜びに溢れている表情、すごくわかる。

  • 『桃』
  • 『花束』

もーほんとに緻密で美しい。。。。ルノワールのグッズ買うつもりなかったけど気付いたらポストカード一番買ってしまってた。。

アンドレ・ドラン

  • 『台所のテーブル』

静物画で、どの物も色合いは似たような感じで果物があったりするわけじゃないのに美しい構成。

  • 『長椅子の裸婦』

横たわる裸婦、って絵画のモチーフとしてはめちゃめちゃありふれてるっていうのを前読んだ気がするけどプラド美術館展で見た 着衣のマハ - Wikipedia の印象が強くてそれを思い出す

  • 『黒い背景のバラ』

見てすぐに「絶対にポストカードを買う」と思った（あってよかった

  • 『道』

なぜかルソーっぽいなと思ったけどこっちのほうがルソーの絵より希望に溢れてる感じがある
現代のCDジャケットとかにありそうなおしゃれな絵だなと惹かれた

マリー・ローランサン

小学生のとき伝記漫画を読んだのをよく覚えていて、絵を見たことは少なくてもなぜか「知っている画家といえば...」となると思い出す。

  • 『牝鹿』

今回の展示だとこれが一番好きなんだけど、他の絵のほうが完成度が高いからなのかなぜなのか、どのグッズにもされておらず悲しい。。

  • 『女たちと犬』

これは本当に1920年代の作品なの？？と思うくらい絵自体が発光している（ような感覚）

  • 『マドモアゼル・シャネルの肖像』

ココ・シャネルの肖像画。
詳細は解説になかったが受け取りを拒否されたとあり、それまで見てきた解説になかったワードがいきなり飛び込んで来てちょっと笑ってしまった...

モーリス・ユトリロ

  • 『サン=ピエール教会』

白い建物を美しく描く画家だな〜と思った。
ほかにノートルダム大聖堂を描いた作品が2つあり、
見たことのある風景でもない風景でも、こんなに美しいのにそのまま記憶から出てきたような親しみを持つような絵が多い。
なんか、悪夢でうなされているときは夢の中でこういう風景を見たい....。

シャイム・スーティン

コントラストの強い色彩が多い。
他の画家の作品たちと年代は変わらないのに新しめの絵だなという印象を抱く。

花、、、ルノワールの『花束』のように、色彩ははっきりしてるけど淡いロマンチックな印象の絵を見てきたあとにここで...この絵？と思わされた、
禍々しい印象なのに引き込まれる絵。
これも手元に置いておきたくてポストカード買った。

横浜美術館、前に行ったのがいつか忘れたけど中も回りやすいしロケーションも最高だ
今回の展覧会では minne と作家さんがコラボした作品も販売されててグッズのラインナップもより充実してる。

mag.minne.com

オルセー美術館は研修でちょっとだけ行けたけど、オランジュリー美術館は行けてないので行きたいな...というか秋にパリに行きたいよ....。

ラジオの話し

懐古

最近たまに、二週に一回程度なのだがラジオを聞いている。
そのとき気になった番組を見つけてAlexaに「文化放送つけて」って言ったらradiko経由で流してくれるのでめっちゃ便利。

先日欅坂４６が好きな同居人が「欅の新曲がメンバーが出てるラジオで初公開になるから」ということで、平日の疲れて帰ってきた夜に、自分の特に好きじゃないアーティストのラジオを聞く気になれなかったけどコンビニで調達した夕飯を準備しながら共に聞いていた。

新曲がフルコーラスで流れる。
聞いてるとあんまり欅坂４６の曲を好きだと思ったことはないけどなぜかこれは今までより良いなという直感。
同居人は案の定めっちゃいいと褒めちぎっていたけど確かに良い。

というかラジオで聞く曲って普段聞こうと思って聞く、TVでパフォーマンス観つつ聞くより特別にすごくよく聞こえるなと、久しぶりの感覚を思い出した。

いやTVでパフォーマンス観つつの方がそりゃいいかもしれない。でも基本的にラジオでかかる曲っていうのは新曲本邦初公開！！とか
新しい曲が聴けることはわかっても、何が聴けるかはその番組を聞くまでわからない。やっぱりそのワクワク感がいい。
映画ボヘミアン・ラプソディで、ラジオでかけるには曲が長すぎると断られてフレディが激怒して、自らラジオに出演して曲を公開したエピソードがあったけど（事実に基づいてるのかは確認してないけど）好きなアーティストの新曲がいきなりラジオで流れて初めて聴く、その感動たるや・・・今じゃなかなか感じられないなぁと思ってしまった。
 

ラジオは最近まで聞いてなかったけど昔は「放送室」をずっと聞いていた。
松ちゃんと同級生の放送作家の高須さんの番組、今も好きだけど中学くらいの時ダウンタウンがとにかく好きで、昔の番組から毎週のラジオまで欠かさず漁っていた。

金曜の26時、ポン、ポ、ポンポ、ポン、ポンポ、ポン、ポン～というあの音で始まる
（「You're So Cool / ハンス・ジマー」（映画『トゥルー・ロマンス』サウンドトラック）だそう。Wikiより）
これ地元の局だけなのかもしれんけど絶対直前スジャータのCM入ってた思い出なんだよな。

寒い冬の家族が全員寝静まった夜、自室でひとりファンヒーターの音を出しながら時にはネットで出会った人とお絵描きチャットしたり、友達に渡す手紙書いたり、試験勉強すると教材を広げつつ漫画読んで、そんなことをしながら聞いてたり、

冬の夜、ベッドの中で寒い寒いと思いながらコンポから直接イヤホンを繋いで寝静まる前のひとときを楽しむために聞いてたり、

学生時代の思い出に密接に絡み合っている時間だったように思う。
なんか冬が好きなので冬の記憶ばっかりだな。
 

このラジオは松本人志と仕事仲間であり旧くからの友人である放送作家高須光聖、のふたりがパーソナリティなので会話の中身は仕事の話だったり会話から派生した小学校時代の友人の話がわりとよく聞いた内容だったように思う。

一時間特にリスナーからのお便りだとか、コーナーも決めず、合間に二曲くらいそれぞれが選んだ曲を挟みながら会話の主題を決めずに２人がただ話す、それだけのラジオ。
（がCD聞き返してたら「僕はいまだにゴムをつけるときの適切なタイミングがわかりません。」というお便りに回答してた。）


なのに聞いていて心地良い。

そして上で書いた合間に挟まれる曲、これがまた大体が聞いたことない曲で、２人の選曲で２人とも音楽は流行を追ってる、とかそういうタイプの人じゃないように思うので昭和の若い頃に聞いた曲だろうと思うんだけど「自分から聞こうとしない」曲をそこで聞いてあぁいい曲だなぁって流れる時間がとても心地よかった。

ラジオで耳だけで得るはじめて得る情報たち。今になってとても尊い時間に思える。


関連してちょっと別の話で、
歌詞のレビューを読んでいてその歌詞は誰を思って書いたのか、どういう状況何だろうかということを聴き手に自由に想像させる、歌詞の中での”情報制限”がクリエイターの腕の見せ所、というようなことが書かれていて
そのワードが腑に落ちて本当にそうだなぁと。
先の「２人の主題を決めずただ話す内容が聞いていて気持ちいい」ということについてもじゃあなんでそうなのかというと、
仕事の話でも少しプライベートな話でも、人の話でも、ラジオだからもちろん公表してはいけない内容とかその辺をぼかしながらになるわけだけど
なんの話を2人は真剣に話てるんだろう、あぁ今この話をして面白かったから高須さんの方が笑ったんだろうなとかもっと深掘りして聞きたいなとか身振り手振りもない耳から得る情報のみで聴き手は事実と推測も交えて楽しむことができるから、絶妙な情報制限があって「もっと教えて」と話にグイグイ引き込まれるからラジオを聞くことってこんなに楽しいんだなと。完璧にわからないから引き込まれる。
「情報が少ない方の楽しさ」をラジオで感じてたのだと思う。

 

ラジオで話すのを通して楽しいな気持ちいいなとリスナーに思わせられる人は本当に人を魅了させるのがうまい人だと思う。
その人の言葉からしか何も感じ取れない中でもっと聞きたい、その人のことをもっと知りたいと思わせる　＝情報制限がうまい人。

自分のことをさらけ出せるツールがごまんと存在する中、ラジオという媒体を使ってさらけ出すことが適切にできる人、簡単にファンになってしまう。

 
放送室がなくなった今、ひいきにしたい番組をなかなか見つけられずにラジオジプシーなんだけど他の人の純粋におすすめしたいラジオ番組というのを知りたい。

 
余談
調べて初めて曲名を知ったけど放送室のエンディングはこの曲だった

人間の証明 テーマ曲　ジョー山中

これが凄く良い曲。これを聞きながら眠りにつくとき、大人になったらこれ流しながら夜の首都高を走りたいわ～ってよく想像してた気がする。

大人になったいま実際はペーパーで運転すらしてないわけだけど・・・


放送室 VOL.326~350

放送室 VOL.326~350

CocoaPods で Chameleon Framework を使ってみる

アプリ やってみる

毎回 CocoaPods 導入手順を調べている＆Swift4で動作確認済みだよと明記されてる記事意外と無いので、一通りの流れをまとめる自分用のmemoがてら

今回はフラットデザインに使えるカラースキームが自在に取得＆設定できたり、テーマの定義がいい感じにできちゃうこちらの Chameleon Framework というライブラリをpods経由で導入してみる。 github.com

  • 動作確認環境
$ swift -version
Apple Swift version 4.1.2 (swiftlang-902.0.54 clang-902.0.39.2)
Target: x86_64-apple-darwin17.5.0

$ pod --version
1.5.3

Cocoapods インストール

$ sudo gem install cocoapods

CocoaPodsのセットアップ。かなり時間が掛かった

$ pod setup
Setting up CocoaPods master repo
Performing a deep fetch of the `master` specs repo to improve future performance
  $ /usr/local/bin/git -C /Users/Hikari/.cocoapods/repos/master fetch origin --progress
  remote: Enumerating objects: 27, done.
  remote: Counting objects: 100% (27/27), done.
  remote: Compressing objects: 100% (13/13), done.
  remote: Total 18 (delta 12), reused 7 (delta 4), pack-reused 0
  From https://github.com/CocoaPods/Specs
     03e813aace0..d31082052cf  master     -> origin/master
  $ /usr/local/bin/git -C /Users/Hikari/.cocoapods/repos/master rev-parse --abbrev-ref HEAD
  master
  $ /usr/local/bin/git -C /Users/Hikari/.cocoapods/repos/master reset --hard origin/master
  Checking out files: 100% (367530/367530), done.
  HEAD is now at d31082052cf [Add] MapsIndoors 3.0.0-alpha36
warning: inexact rename detection was skipped due to too many files.
warning: you may want to set your diff.renameLimit variable to at least 224792 and retry the command.

CocoaPods 1.6.0.beta.2 is available.
To update use: `sudo gem install cocoapods --pre`
[!] This is a test version we'd love you to try.

For more information, see https://blog.cocoapods.org and the CHANGELOG for this version at https://github.com/CocoaPods/CocoaPods/releases/tag/1.6.0.beta.2

Setup completed
Podfile 作成

ライブラリを導入したいプロジェクトファイルのあるディレクトリに移動

$ ls -la
total 8
drwxr-xr-x   8 Hikari  staff  256 10 14 17:32 .
drwxr-xr-x   7 Hikari  staff  224 11  8 00:26 ..
drwxr-xr-x  15 Hikari  staff  480  1  4 00:19 .git
drwxr-xr-x   9 Hikari  staff  288 12 12 02:22 Mojiire
drwxr-xr-x@  5 Hikari  staff  160 12 11 01:35 Mojiire.xcodeproj 
drwxr-xr-x   4 Hikari  staff  128  8 19 03:12 MojiireTests
drwxr-xr-x   4 Hikari  staff  128 10 14 17:14 MojiireUITests
-rw-r--r--   1 Hikari  staff   10 10 14 17:32 README.md

ここで pod init を叩くと Podfile が作成される。
（以前は気にしたこと無かったけど、Cocoapods は Ruby 製なので Podfile もXcodeから確認するとRubyのファイルとして認識される）

$ cat Podfile
# Uncomment the next line to define a global platform for your project
# platform :ios, '9.0'

target '{プロジェクトファイル名}' do
  # Comment the next line if you're not using Swift and don't want to use dynamic frameworks
  use_frameworks!
  1 # Uncomment the next line to define a global platform for your project

  # Pods for Mojiire

  target '{プロジェクトファイル名}Tests' do
    inherit! :search_paths
    # Pods for testing
  end

  target '{プロジェクトファイル名}UITests' do
    inherit! :search_paths
    # Pods for testing
  end

end
ライブラリインストール

上記Podfileの10行目あたりに以下を追記。

pod 'ChameleonFramework/Swift', :git => 'https://github.com/ViccAlexander/Chameleon.git'

pod install を実行。

$ pod install
Analyzing dependencies
Pre-downloading: `ChameleonFramework` from `https://github.com/ViccAlexander/Chameleon.git`
Downloading dependencies
Installing ChameleonFramework (2.1.0)
Generating Pods project
Integrating client project

[!] Please close any current Xcode sessions and use `Mojiire.xcworkspace` for this project from now on.
Sending stats
Pod installation complete! There is 1 dependency from the Podfile and 1 total pod installed.

[!] Automatically assigning platform `ios` with version `11.4` on target `Mojiire` because no platform was specified. Please specify a platform for this target in your Podfile. See `https://guides.cocoapods.org/syntax/podfile.html#platform`.

プロジェクトファイルと同じ階層にCocoaPods関連のファイルが作成される。git管理してるとわかりやすい。

$ git status
On branch add-chameleon
Your branch is up to date with 'GitHub/add-chameleon'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   Mojiire.xcodeproj/project.pbxproj
    modified:   Mojiire.xcodeproj/xcuserdata/Hikari.xcuserdatad/xcschemes/xcschememanagement.plist

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    Mojiire.xcworkspace/
    Podfile
    Podfile.lock
    Pods/

no changes added to commit (use "git add" and/or "git commit -a")

また初回インストール以降新たにライブラリを定義していく場合は pod update を実行する。

ライブラリを利用してみる

pod install 完了後、{プロジェクト名}.xcworkspace （CocoaPods のワークスペース）を開き、
利用したいファイルで import 宣言する

import ChameleonFramework

Cannot load underlying module というエラーが表示されたら、 Product > Clean でプロジェクトをcleanする。

Cameleon で定義されているフラットカラーを使ってみる。

let pinkColor = UIColor.flatPink
let coffeeColor = UIColor.flatCoffee

UIColor.f... の時点でインポートした ChameleonFramework のコード補完が表示されるのが確認できる。
https://github.com/ViccAlexander/Chameleon#-product-features これでこちらに定義されているようなカラーがアプリ内で表示されているのが確認できた。

Chameleon がいったん使えるまでが今回のゴールなのでここまで。
こういういい感じのデザインがちゃっと用意できちゃうライブラリすばらしいな

2018年、変わったこと、変わらないこと

すき！ 懐古

前回のアドベントカレンダーについて、
ave-h.hateblo.jp
当初技術ネタ書くにもボリュームがいまいち足りず、折角なら自分しか自分にしか書けない題材で書こうと思いこの内容にしたんだけど
書いてる最中も書いた後も
「何こんなあたりまえのことしか言ってない記事をわざわざアドベントカレンダーという枠の中で書いてるんだ・・・・」
と自己嫌悪しかなかったけど、「大体どういう本でも最後は”あたりまえ”な内容に終結するもんだからいーんじゃない」と言われたので
まあ確かにそうなのかもしれない。


仕事納めて先日、カードキャプターさくら展 －魔法にかけられた美術館－ に行ってきた。
さくらは同年代で漫画とかアニメ見る女子は皆好きな作品だったと思うけど、わたしも漏れなくリアルタイムでなかよしを読み、アニメを見、劇場版を見、現在のクリアカード連載も読んでいる。

f:id:ave-h:20181230215637j:plain:w560
1巻、＝初代OPのあのコスチュームの衣装。いや〜〜〜どれも最高可愛いんだけどまず好きなの挙げろ！って言われたらまずは何だかんだコレだ！！！

公式サイトからはあんまり分からないけど、今回のこの展示は連載時のカラーイラストと原稿が計50枚以上はあったんじゃないかなという感触でとにかく原画のボリュームが半端じゃない。

漫画/アニメ作品の展覧会で原画を見るのが大大大大大好きなんだけど、今回のさくら展はじっくり一枚一枚見てると今になって改めて感じたことがあって、画面の構成がすごく考えられているということ。

原画は見開きの2ページでそれぞれ飾られているんだけど、その2ページだけをひとつのシーン内の画面として見たときに、必ず『ここを伝えたい』というような、見せ場のコマが入ってるなと思った。
そしてそれを擬音とか、過剰な装飾で見せるのではなくあくまであのシンプルな筆致だけで見せている。

headlines.yahoo.co.jp
↑この「消」のカードの時のシーン、絵、このあたりのさくらと小狼の関係性すっごく好きだ・・・

CLAMP先生のこのさくら連載時の絵、線がスッキリとしててでも力強くて、トーンなどは使われてても「ペン一本で描かれている」という印象がとても強くて。
あ〜こういう風に修正（ホワイト）も入ってるんだなと見つつ改めてすっごく絵が綺麗で上手いな〜と感動した。

その”スッキリとした線で、絵で魅せる”というのが、カード捕獲したりのアクションシーンはもちろんそうなのだけど、日常で誰かと話すシーンとかさくらが自分の気持ちに自覚するシーンとか、そういうところで凄く効果的に使われているなと思ったのです。

このコマでは顔の影がトーンで入ってるけど、次のコマじゃトーンの装飾も一切ない見せ方に変わっていたりとか。
なんか人物の細かいところにトーンが入ってる作家の絵って他のコマでも同じようにトーンが入ってたりとか、何気なく使われているのが当たり前と読んでて気にしなくなっているけど、
あくまでベタやトーンって「効果的に」装飾する、ための技法で。すっごく絵が綺麗で上手いし、漫画としての見せ方も本当に上手い。

さくらの物語を紡ぐための画面と、さくら達を『魅せる』ための画面がきれいに共存しているという印象を原画を見て改めて受けた。

そしてさくらはともかく今後漫画の作画もどんどんデジタルに移行していってアナログの原画見れなくなっていくと思うと辛い。
カラーはともかく白黒原稿はアナログでずっと見ていたい・・・

連載開始からの年表も。
f:id:ave-h:20181230215628j:plain:w560
右の着物の表紙いとこの家でキャッキャ読んだ記憶がある・・・。

さくら、連載時は一年に3巻とか出てて月刊なのに刊行ペースがかなり早いな〜と思った。週刊ならともかく。
1話あたりのページ数結構多かったっけ？と思ったけど、何にしろそのペースなのにあれだけクオリティの高い作画を保つのすごい。。。

ずっと好きな作品、好きになった当初と変わらない熱量を自分に思い起こさせてくれた時間だった。


昔と変わらない熱量、自分の中で欠かせないものというとB'zも。

今年30周年でわたしも Pleasure ツアー3ヶ所行ったのだけど、やっぱり、初めて聴き始めてライブ映像を見出して、好きになったころと変わらずにその姿を見せてくれる2人に本当にありがとうという気持ちしかない。
ちょっと好きだったアイドルの引退の報道とか見てると、活動休止もなくずっとやってきてくれたことがどんなにすごいことなのかを日々思い返していた。







変わったことの話

上半期が終わったところで完全に書くタイミングを逃したので、その当時より色々な思いは薄れているけど
（距離的には近いけど）引っ越しもしたし、転職したし、転職したので所属するプロダクトも変わったし、言語も新しく学ぶしでここ数年では比較的変化の多い一年だった。
会社を辞めることを決めてからよくあんな短期決戦で、自分の今までについて棚卸しして有給とって面接詰め込んで結果一月くらいで決められたな〜と今思うと行動力に感心する。

中の体制も日々目まぐるしく変わっていったけど、人々を巻き込んでのチーム開発はやっぱ楽しい。いや、やっぱ辛い。いややっぱ楽しい。という気持ちを繰り返していたような気がする。

そして仕事だったりキャリアとどう向き合うか、「意識的に変えた」年だったようにも思う。
そう思うと停滞って怖いなと思うので安定するところは安定しつつ、これからも変えないといけないなぁと。

それでもって環境も変わったので、新しい人に沢山出会った一年でもあった。
あらためて自分ってコミュ力低いな？？！と痛感した。。。。いや、環境変わってみないと対人関係でどうふるまってるか、自分のことかえりみられない。本当に。
新しい人との出会いを大事にしつつ、そして来年はより積極的に出会いを広げようと思う。

来年はどのくらい新しい感動に出会えるか、生きてて良かったと思えるか、より一層1日を大切に生きてこう・・・・。

エンジニアのホスピタリティについて考える

考察

この記事はGMOペパボ Advent Calendar 2018の20日目の記事です。 qiita.com Qiita で初めてアドベントカレンダーを見てから、3年位？ついに自分も書く側に回ってみたいなぁと思い書いてみることにします。
年が締めくくられていくこのワクワク感とても好きです。いや、やっぱもう2018年のこり10日とか嘘

自分が「書く」時に気を付けていること

さて今回の表題に関して。
わたしはWebのエンジニアなのですがここでの「書く」というのはコードライティングのことではなく、普段仕事ないしプライベートで書く文章のことをさしています。

というのもここ数年ずっと感じているのが、書く力を伸ばす　のを怠ってはいけないなぁということで、
社会人歴＝エンジニア歴が長くなるにつれて仕事で関わる人が最初は同じエンジニア同士しかいなかったのが、他の職種の人も巻き込んでいかなければいけないことが多くなっていきました。
それはデザイナーだったり、マネージメントをする人だったり、営業やディレクター、エンドユーザの声を直に聞くカスタマーサポートの人だったり。
今は事業会社ですが前は受託開発を主にやる会社だったので上で書いた職種の人でも、相手は同じ会社だったり、請負元の事業会社だったり、同じ事業会社から請け負っている会社だったり様々でした。

色んな立場の人と働く中で、基本的にはオンラインのコミュニケーションで完結するこの業界で
エンジニアとしての技術はもちろん、 「文章を書いて人に伝える力」 も磨き続けなければならないとつくづく実感しています。
文章だけじゃなく対面でのコミュニケーションも然りなのですが。
前置きが長くなりましたが、そんなオンラインでのコミュニケーションで自分が「書く」「伝える」時に意識していること（スタンス）をまとめました。

基本的には

  • 読んだ人にどう動いてほしいかを見据える
  • 読む人がどう想像するか、どんな情報が欲しいのかを考える

に帰結すると思っています。

知りたいことを訊きたいとき

  • なるべく簡潔に、結論を先に
  • なぜそれを知りたいのか
    • 自分が掴んでいる内容は？
    • 背景・状況を詳しく
    • いつまでに知りたいのか
  • どのくらいの粒度の回答を求めているのか

「知りたいことを訊く」時って、何らかの課題を解決したいからという理由がほとんどだと思います。
例えば SQLを使って検索しても返ってくる結果が0件になる という困りごとに対して、その解決方法を人に聞きたいとき。
この事象を伝えられただけで、その人が解決方法をサッと導き出すのは難しいです。
「何をやってそうなったのか」という背景が分からないと聞かれた側も下手に助言をすることができなくなります。

この事象を深掘りすると、例えばこういうことだったとします。

困っていること：
　・検索結果が0件
やりたいこと：
　・12月の人気ランキングに掲載されているブランドの販売する商品のうち、単価が安い順に10件取得したい。
 　取得したい項目は商品名、商品単価、販売しているブランド名、購入者数、販売開始日時。
期日：
　・明日
やったこと・今わかっていること：
　・このようなクエリで試している（以下SQL）
　・取得するのにA、B、C、DのテーブルをJOINしている
　・必要な情報はAテーブルとBテーブルに含まれている

自分が具体的に何をしたのか、やりたいことは何なのかということが、多少相手に伝わる内容になりました。
これによって伝えられた相手は、得たい情報を取得するのに参照するテーブルは果たしてそれで正しいのかとか、JOINは内部結合でいいのか外部結合にすればいいのかとか、
「やりたい（解決したい）こと」に対して
何を助言すべきか？実現する手段は他にあるか？をその課題に寄り添って考えられるようになると思います。

これは極端すぎる例ですが、ついこういう時って詳細をすっ飛ばして「これってXXをやればいいんですかね！？」っていきなり聞きたくなってしまいます。
なるべくつとめて「答えるのに相手が欲しい情報は何だろう？」を整理するようにしています...

判断を仰ぎたいとき

  • 実際に起こっていること、これから起こりうることはどんなことか
    • 事実と考察は違う
      • それが調査した結果の事実なのか、事象に対しての自分の推測なのかは人にわかるように伝えなければならない
  • いくつか案を提示したならば
    • 採択にあたってのそれぞれのメリデメ
      • 発生する工数
      • 保守性
      • 影響範囲だったり
  • どのくらいの粒度の回答を求めているのか
    • Yes/Noでいいのか、その理由も欲しいのか

例えば障害発生時とか、
その障害の大きさ・程度の差は有れどある程度決められているフローに沿って対応を進めることがどの現場でも多いと思うのですが、
事実と考察 って割と混同してしまうことが多いです。
挙げていることが「調査した結果の事実なのか」、あるいは「事象に対しての自分の推測なのか」は人にわかるように伝えなければ、決める側も適切な判断が下せなくなってしまいます。

また、これこれこういう状況です、と詳細に伝えても、果たしてその相手には何を決めて欲しいのか？その人から誰か他の人にも判断を仰ぐ必要のあることなんだろうか？と、伝えられた人が何をすればいいか分からない、 着地点が分からなくなるような伝え方 になってしまうのも良くないです。
こういう報告時にきちんと精査した内容を書いておくのは

  • その事柄についての今後発生するやり取りの手間が減る
  • 説得力を増す

というメリットもありますね。大事。

相手がどれだけ自分が伝える内容について理解しているか?

個人的に気をつけているのは対エンジニアでも、そうでなくとも「なるべく低いレイヤーから」「誰にでもわかりやすく」伝えるということです。
例えば極端な例で言うと

この Hoge クラスの fuga メソッドのここ、XX機能の処理を重くしてるので修正したい。

みたいなことを開発を統括するディレクターなどに伝える時。
ある機能の具体的な仕様の話をされても、それがどういう条件で発生するのか、人から見えるところであればどこで動いているのかとか、それを知ってるエンジニアならこれだけをプルリクエストの説明に記載しても「なるほど」で終了する話だけど、それを詳しく知らない人にとっては親切な内容とは言えません。

この画面からこう遷移して表示するこの画面で、XXを入れて検索した時のみ結果が表示されるのにすごく時間がかかってしまっている。
それはXXX呼んでさらにYYYという処理をしてるのが原因なので、これらをZZZをすることで速くなるのでそうするように修正したい。

ちょっと細かすぎ＆実装的なところに寄った話になってますが、落とし込んで説明する、といったことです。

以外と自分達が普段話してる内容って、外から聞いてもごく一部の人にしか内容がわからないことって多いのです。
また

  • エンジニアが有してる技術的な見解だとか知識ってある程度共通のものだろうとか
  • 機能の仕様であればある程度開発を見てる統括者なら認識してるだろうとか
  • そのプロジェクト歴が長い人でも知ってるだろうとか

いうとそんなことは全然ないのです。
全てを知ってる人っていないんですよね。

また上2つで書いた内容は細か目ですが、あくまで「相手がどういう立場の人か、それに合わせて内容を用意する」というのも大事です。
なにかを報告するにしても、報告する人に対しての適切な内容、伝えるべきところはどこまでだろう？を意識します。

ちょっと語り

わたしは、基本的には相手と自分の認識（知識）してるレベルに差がある、という前提で伝える内容を考えます。
自分より相手がその内容に詳しいであろう場合でも、その逆で自分の方が詳しいかもしれないという場合でも同様です。

「相手はこの内容でわかるだろう」という思い込みで「具体的な話だけして認識のズレを生んでしまう」というのはすごく怖いです。

だってお互い安心し合いながら話したい。お互い同じ認識をした上で小気味なギャグとかボケとか挟んで会話終了したい。
まあこれは会話していて極力雲行きを怪しくさせたくない・・・という自分の予防線を張る性格がそうさせているのかもしれないですが。

これって正直、結構しんどいし難しいんですけど、あらためてどういう問題起こってるのかな？を俯瞰してみることもできます。
また色んな人に協力を仰ぐのにも、「誰にでもわかる内容で事象を伝える」 って大事なのです。
協働するって、多少の不便を伴っても、結果的により良い方向に早く導くためには労を惜しんじゃいけないなぁと。

エンジニアの人々はコードを書くときって色んなことを考えて書きます。
書くときの視点は色々あります。よりDRYに、よりステップ数は少なく、よりその言語っぽく書く。etc,...
「自分のコード書く時の流儀」って誰でもあると思いますが、やっぱりわかりやすさを重視するのは大事で

  • どう関数をつくろうか？
  • I/Oはどうしようか？
  • 負荷は？速度は？
  • 正常系以外はどうハンドリングしてやるか？
  • ログはどう出力しておこうか？

とかとか色々ありますが、コードという資産って自分ではない使う誰かのために書いてますよね。
普段自分が書くコードと同じように、自分以外の誰かのために文章を書くその視点ってすごく大事だと思うのです。

おわりに

…なんだかんだと抑圧された堅苦しい内容になっている気がする。

（ビジネスでも使われる）文章の書き方に関しては、やれPREP法で書けだの、こうこうこういう形式に沿って書けだの、どういう場でも文章を扱う以上ルールにうるさく言われますよね。
作業手順書ひとつ、お客さんとやりとりするバックログひとつ、レビューしてもらって書き方を正されたりしていると「自分の意思で書いた内容なんかもはや残ってないのでは・・・」と思うことが沢山ありました。

が、自分の意思をちゃんと持つということは大事なことであり、その自分の意思が相手に伝えられるようにことばというツールを駆使してやろう！！という気持ちでやってて、何とかやってられていると思います。

「仕事をしていて楽しいと思う瞬間」、人それぞれと思いますがわたしは「関わるメンバーとちゃんと意思疎通ができて」その上でプロダクトを推進できるのが楽しいです。
意思疎通ってあたりまえじゃん、と思うのですが、仕事以外の生活で関わらないであろう人とかトラブルに遭遇して、でも言葉やコミュニケーションで何とか渡っていけるのってすごく尊いことだなぁと改めて思うのです。

わたしは今年の4月にGMOペパボに入社しましたが、我が社の人は職種を問わず「表現力」を磨いている人が多いのが好きです。
ここで書いた内容だけには留まりませんが、ちょっと今回の内容には自分もずっとそう有りたい、という思いを含めました。

フェルメール展の感想

すき！ 美術

先月フェルメール展に行って来た。

f:id:ave-h:20181112005305j:plain
www.vermeer.jp

上野の森美術館... 昨年怖い絵展で朝から2~3時間並ばされた思い出でなんとなくここに来ると入場まで長時間並ぶのは当たり前、みたいな印象がついてしまった。
私が行ったのは月曜の夕方なので入場制限もあるしまぁそんな混まないだろうと思ってたけど、普通に人多かったなぁ。でもあれだけの点数を一度に見れたので、鑑賞後は全然並ぶ時間もお金も惜しくないという感覚。

以下の展示構成で、17世紀オランダの絵画を鑑賞。1650~80年くらいの作品が多かった。

  1. オランダ人との出会い：肖像画
  2. 遠い昔の物語：神話画と宗教画
  3. 戸外の画家たち：風景画
  4. 命なきものの美：静物画
  5. 日々の生活：風俗画
  6. 光と影：フェルメール

画のそばに解説文がない代わりに配られるガイドに解説が詳細に載っていてとても良かったのでどこの展覧会もこれがスタンダードになってくれるとうれしい... あとで見返せるし。

印象に残った作品達

  • パウルス・モレールセ / ヴィーナスと鳩

ローマ神話の愛の女神ヴィーナスを若い婦人が演じており、右手には矢、左手には鳩を載せて居る。
この矢は愛の神クピドが放ったもので「心臓を射抜かれると人は恋に落ちる」ということを象徴していて、鳩もまた愛の象徴だそう。
分かりやすく綺麗なロマンチックな絵で、ヴィーナスの頭上で咲いている赤いバラと相まってよりそれを際立たせている。（バラはヴィーナスの象徴）
ニコラス・マースの『窓辺の少女、または「夢想家」』も窓から見える少女の周りにみずみずしい桃とアプリコットが描かれていてちょっと近い雰囲気。こちらも美しかった。

この「東方三博士の礼拝」はもっとも頻繁に描かれた宗教主題の一つらしい。3人の賢人がイエスの誕生に贈り物を携えてやって来る、という絵なのだけどこの絵でイエスは幼子として描かれていて、"理想化されていない" "実際に居るような赤ん坊の姿" で描かれている、というのが解説文にあった。
「東方三博士の礼拝」で調べるとだいたい登場人物の姿構図が同じなのだけど、これで思い出したのが以前読んだ本で、新しい宗教を広めようとする時には祭日だったり崇拝の儀式だったり、他の宗教の要素を取り入れたりするのがあって、信仰する神の姿も同じようにされたという話。
キリスト教での神の姿は「白い顎髭を生やした老人」であることが多いが、これは人々がキリスト教の神はどんな姿をしているのかというのを教会に尋ねた時に、もっとも人々に馴染みのあるギリシャ神話に登場するゼウスの姿を答えたというもの。
あえて知られている神の姿ではなく、「理想化されていない姿」を描く、それが頻繁に取り上げられたのは何故なんだろうというのが気になった。
理想化されていない姿を描いて、民衆に広めることでより神を身近に感じたい、とかそういう背景があったりするんだろうか。

  • シモン・デ・フリーヘル / 海上のニシン船

作者は17世紀における重要な海洋画家のひとりだそう。船と漁師達を丁寧に描く一方で霞んだ光や湿気のある海の様子が圧巻。
海洋画何点かあったんだけど、どれも不安定な気候を表現しているのが面白かった。
何となくイギリスやフランスって曇りが多い印象だけどオランダもそうなのかな。しかし悪い天候でも光の表現がどれも素晴らしい。
あと自分の故郷が曇りの日が多いので「気候が不安定だけど美しい画」なんて本当に...良い。

神話画、宗教画が特に好きなのだけど「洗礼者ヨハネの斬首」、「ユーディトとホロフェルネス」がモチーフの画よく見るなぁという感想。どちらも緊迫した雰囲気が好き。

1~5章までで感じたこと

上記の肖像画から風俗画まで一通り見て気になったのが、肖像画のモデルだったり風俗画で描かれる市民がとにかく裕福な印象を受ける。
身なりとかそれに使われている色の豊富さや食べ物。ちょっとした貴族階級でも構えている家がすごく現代的に感じる。
1600年代ってこれってオランダってそんな裕福な国だったっけ？と思ったら、ネーデルラント諸州の独立戦争である八十年戦争（1500年代後半〜1600年代前半）の終わりから17世紀にかけてオランダ黄金時代とのちに語られるほどだった。

スペインからの独立を宣言したネーデルラント連邦共和国は当時のヨーロッパで最も富裕な国で、貿易、学問、芸術の最先端国家だった。（Wikiより）

そういえばそんなこと習った覚えがあるけど、世界史上でそんな重要じゃなかったので（自分の中で）忘れてた。こうやって昔学んだこととリンクするのも鑑賞してて楽しい瞬間。
よく見る1700年代以降のフランスの風俗画とか、民衆の姿はそれはもうひどいのに（記憶）。ひとつの国のひとつの時代だけ切り取って見てるから尚更だけど違いがすごい。
この時代のオランダの繁栄ぶりがわかる。

フェルメール作品

展覧会の目玉！作品は全部で8点。（来年1月以降は1点追加展示される模様）
自分が思いつくフェルメールの作品、「牛乳を注ぐ女」「真珠の耳飾の少女」くらいしかなかったのだけどただでさえ現存する作品が少ないのにそのうちの8点も鑑賞できて、やはり生で見る画は想像を絶する美しさだった。
新たに知った作品では「取り持ち女」「手紙を書く女」「マルタとマリアの家のキリスト」が印象深い。だいたいどれもポストカード買っちゃったけど...。

Wikiも見てると、フェルメールは "左から光が差す室内に女性が立っている" という画が多い。その光の表現がもう自分の語彙でうまく書けないけど、この時代にこんな精緻な、繊細で柔らかい光を表現することができるなんて考えられない。
会場の中で作品自身の光の描き方をもってまさに浮かび上がって見える、神々しい画だった。
そして「手紙を書く少女」の少女とかもだけど、画の中に悲観したような人物が全然居ない。かといって幸福そうな顔をしているかという訳でもないのだけど、現代に通じるような時代、人生を達観してるように描かれている人物が多いなという印象。
それはやっぱり、裕福なこの時代に描かれているからというのもあるのかなぁ。
こんなに美しいのに、親愛の情を持って見ることができるそんな魅力がある。

5章まで鑑賞した時点でもかなり満足したし、フェルメールの作品はいくらでもネット上で見られるものではあるけど、やっぱりこの機会に生で見られてよかった。圧巻だった。
www.artagenda.jp

画を見る楽しさ、歴史から再発見する楽しさ。贅沢だった。
「牛乳を注ぐ女」の格好してるミッフィーもやはり予約した！