JaSST'23 Kyushuにオンラインで参加しました！
11月2日、JaSST'23 Kyushuにオンラインで参加しました！
参加のきっかけは、運営の方からの紹介でした。
内容はQAやソフトウェアテストに関するもので、今回は特に大学生やテスト業務を始めて2年目の人が対象でした。これが私の状況に合致していたため、参加を決めました。
S1 基調講演 「わからない？をわかる！に変えよう！- QAエンジニアが実践している基本的な考え方と方法」
私の課題
自作アプリのテストを作る時や問題解決時に、ディシジョンテーブルに似たものを手元で書くことはあれど、因子や基準値が曖昧な状態なことでした。それによって期待する結果が得られないことがわかっていたので、仕様の曖昧さを無くしたり、何を基準に考えればテストがしやすいかを考えました。
テストを書くためには、ディシジョンテーブルで解決する以前に整理する力、そのための抽象化が足りないと感じていました。
登壇者の講演を聞いて、注目すべき部分や仕様の曖昧さに気づくにはテストパターンを考えるための整理力が必要だと思いました。
テストパターンを考えるワークでは、デフォルト表示系、動作系、マルチブラウザ系に分けるためとても考えやすかったです。その後の同値分割法や境界値分析の説明では、クラス名をどういう名前にしようかなとか、どういうディレクトリ構成にしようかなといったことが頭の片隅にぼんやり浮かんできました。
アプリのデフォルト表示や動作といったユースケースから整理を始めると、注目すべき点が自然と見えてきやすく感じました。
S3) 招待講演 「テスト自動化から、開発と品質を支える継続的テストへ」
私の課題
以前参加していた勉強会で、QAになりたての人がシニアエンジニアの方にQA勉強会の資料をもらって自分の会社で配布してそのままやるとか、どういう動き方をすればいいのかを指示してもらい、そのまま動くということをしていました。
QAの役割は会社やチームごとでも違うのに、別の会社の資料を「他社の資料をそのままコピーして自社で適用するリスク」はないのだろうか？と疑問に感じていました。
登壇者の講演を聞いて、他者がやっていることをそのまま当てがってうまくいくわけがないということがわかりました。
テストの役割分担を考える説明では、E2Eテストが多く、時間がかかりすぎるという問題について、E2Eテストのしすぎを減らす例を教えて下さりました。これによって、テスト時間の削減や効率化を図ることができるとの洞察を得ました。
ここでのユースケースは主にE2Eテストでカバーされていましたが、そもそものアプリの設計によってはほとんどがUnitテストでカバーできるかもしれないとも思いました。
E2E多すぎ問題をきっかけに課題感が変わり、品質やデプロイまでの時間短縮、必要なテストについて皆で議論しましょうという話がありました。ここでは必要なテストは決まっていて、何のテストレベルに割り振るかを決めることで問題解決をしていました。
最後に登壇者が「特定の手法が全ての問題に対する万能薬ではなく、チームの状況に応じたアプローチが必要である」と強調しました。
たとえば、私自身はE2Eテストの実施を積極的に検討していましたが、自分のアプリではコンポーネントテストと単体テストである程度担保できるため、先にコンポーネントテストを書こうと思いました。E2Eは教材を使って練習をしたいと思います。
最後に
この度は素晴らしいQAワークショップを企画してくださり、ありがとうございます。ワークショップが多く含まれていた点が特に印象的でした。良いQAとは何かを考えることから始めるアプローチは、理解を深めるのに非常に効果的だと感じました。他の学習にも活かしたいと思います。
JaSSTさんのイベント行動規範が素晴らしい
参加者として、イベントの行動規範を事前に確認することはとても大切だと常々感じています。JaSSTさんの行動規範は違反行為への対応方法まで定めており、完結さと具体性が安心感を与えてくれました。参加者一人ひとりが安全で快適な環境でイベントを楽しめるよう考慮されていることが伝わりました。
また、福田さんが勤務されているメルカリのイベント行動規範に関しても、わかりやすくて参照される数が多いと聞きますが、楽しい時間を過ごすための細やかな心遣いが感じられ、とても参考になります🙏
🔗 JaSSTイベント行動規範
🔗 mercariイベント行動規範
🔗 JaSSTに引用されていたベルリン行動規範
雑誌企画「Sequence -- 旅と音」
以前参加していた読書会のイベント「雑誌の企画を考える」に参加しました。
私は以前からの自分の研究テーマ「旅と音」に取り組み、
雑誌名、コンセプト、初回の企画を考えました。
今回の特集内容は「旅と音」です。
『STUDIO VOICE』とか実験音楽、jazz、classic、音そのものが好きな人に読んで欲しいです。
consept
Sequenceは生物学におけるシーケンスからきています。
タグラインは「Personal Sequence」。
意味は「パーソナルな視点で世界を読み取る」です。
性別、世代、国籍、人種、ジャンルなどにとらわれることなく、複雑に様々な考えが横断する世界において単一の要素を選ぶことができないような瞬間に、パーソナルな視点から世界を読み取る人々の観察眼を取り上げます。また編集制作にも様々な専門家の方に加わってもらいます。
現代を創造的にタフに生き抜きたいと願う、すべての方々に向けてお届けします。
「Alternative」かつ「Ethical」な選択肢を提供できたら。
※ Sequence=DNAの塩. 基配列を調べるための分析法。 転写・翻訳 によって作られるメッセンジャーを読み取り、RNAの情報からタンパク質を作ります。
雑誌の仕様
対象：
雑誌全体の対象年齢や性別はありません。全体主義的なものの見方をラディカルに問い直したいと感じている人。かつ特集内容に興味がある人。
発行サイクル：
年１回（面白いネタが集まれば増える）
判型：
B4変形。糸を使った中綴じが理想
ページ数：
160-180ページ
紙の種類：
柔らかな手触りのある紙。長く持たなくてもいいので、あまり強くない紙を選びたい。微塗工紙：OKピクシード、微塗工中質紙：モンテシオン、中質紙：フロンティアタフなどがイメージ。
置き場所：
美容室 ／ 病院 ／ ホテル・宿 ／ 本屋 ／ メガネ屋
今号の特集テーマ：
旅と音
次回以降の特集テーマ（案だしレベル）：
- 病むこと
- 測ること
- 遊びの部屋
- 建築解体
- 本
今号の特集
旅 と 音
「旅と音」について
1970年代、フランス革命の16年前、一人の貴族が音楽を求めてヨーロッパ中を旅した。その旅の記録をまとめたのが、 『チャールズバーニーの音楽見聞録』 だ。
音楽家を訪ねたり、訪れた土地の音楽会で聴いた音や、出会った人々との出来事を書き連ねている。
まだ世界がつながっていない頃、音楽は限られた人のものであり、文献もあまりなかった時代。音楽が注目されていないと感じたチャールズバーニーが世界の音楽を求めて旅を始めた。
いまや音楽は芸術に近いものとして受け取られ、音質の良いコンサートホールでの音楽提供が当たり前となった。だが人々に認められる前の野良の音=ノイズ音楽とはどのようなものか。
集まることが困難となったパンデミック2021。日常に潜む野良の音を求めて旅をするとどのような音に出会えるのだろう。
ノイズ音楽家たちは、ポピュラーな音楽から影響を受けるのではなく、日常に潜む音に耳を傾けて音楽を作っている。音を掘り下げていくと必然的にノイズ音楽にたどりつく。
目次：
- 旅と音とは（1P）
- 『チャールズバーニーの音楽見聞録』とはどんな本なのか（１p）
- 世界中から探した音楽会（4P）
- ダムでライヴするとしたら？ Ryoji Ikedaと田中克のダム考察（16P）
- 松本一哉のノイズ音楽の楽しみ方（6P）
- 廃屋や川、電車、マンホールの中でライヴをしてきた
山川冬樹によるノイズ哲学（6p) - 金沢健一の日常の振動（2P）
- 藤田陽介の日常の振動（2P）
- Lucy Railtonの日常の振動（2P）
- Stephen O'Malleyの日常の振動（2P）
- 世界のローカルノイズ（10P）
- pickup台湾ローカルノイズ（2P）
- アーティストが作る自作楽器！（3P）
- アーティストインタビュー（6名 ✕ 2P）
- 音楽を２倍楽しむためのファッション考察（2P）
- 突撃！！ 都内の建築物音響（4P）
- アンビエント・ミュージック現象を考える（3P）
- 世界のノイズ・アンビエント・実験音楽レーベル、レコ屋図録（16P）
- 音楽を２倍楽しむためのファッショングラビア（8P）
- ノイズ・アンビエント・実験音楽関連の書籍（2P）
連載：
- 今月の温泉（2p）
- 今月のお昼（4P）
目次詳細
1. 旅と音とは_1p
2. 『チャールズバーニーの音楽見聞録』とはどんな本なのか_1p
3. 世界中から探した音楽会_4p
音楽は大事にされるものと認められている日本。ホール等のかしこまった場所での音楽会は普通になった。世界では音楽を特別扱いしないこと、音そのものをより楽しめる場所で音楽を発表することがある。より音の根源を楽しめる場所とは。今まで開催されてきたライヴをざっと紹介する。
場所（写真はアーティストに提供してもらう）：
扉的な意味が大きいので、ここは写真メインで。
- 洞窟
- ダム
- マンホール
- 沖縄の基地
- 廃工場（鉄材などそのままで、ホコリかぶったままのライヴ）
- クジラの鳴き声が聴ける場所
- 日本の廃屋
- ヨーロッパの廃屋
- 電車の中
- 廃校
- 原っぱ（国によって認められていない特定の音楽は、原っぱやアパートの小さな部屋で開催される）
- 川
- 夜の砂浜（子供の声と波の音をかけあわせたライヴ）
- タスマニアの Dark Mofo
※ Dark Mofo：コンピューターサイエンスで儲けた（一部ではギャンブルで儲けたとも言われている）デヴィッド・ウォルシュが私財を投入して作った世界最大級のプライベートミュージアムが行う冬のイベント。
4. ダムでライヴするとしたら？ Ryoji Ikedaと田中克のダム考察_16p
内訳：
- Ryoji Ikedaとダム音響研究家の田中克で日本のダムをいくつか回って、ダムでのノイズ音を音、物理、数学などの面から考察（6P）
- 田中克によるダム音響の研究についてのまとめ（4P）
- 世界の辺境と言われる場所での音楽会について二人の対談（6P）
Ryoji Ikeda： 池田 亮司 は、フランス・パリで活動する日本の電子音楽、実験音楽のミュージシャン、現代美術作家。
田中克：ダム音響研究家。 論文：「絶滅種の側（がわ）から」 。以前、音楽家・打楽器奏者の 松本一哉 とダムで録音したことがある。
5. 松本一哉のノイズ音楽の楽しみ方_6p
山などの自然環境で見つけた廃材を元に楽器を作っている音楽家・打楽器奏者の 松本一哉 。日本中を旅しながら、環境音との即興ライヴや一発録音を主としている松本ならではの音の楽しみ方を探る。
※ 松本一哉はフィールドレコーディングをした音源に後で楽器の音を足して制作するようなフィールド音楽ではなく、偶然に起こる環境音との即興によるドキュメンタルな音源制作をしている。
6. 廃屋や川、電車、マンホールの中でライヴをしてきた山川冬樹によるノイズ哲学_6p
アーティストの中でも特別丁寧でまじめな印象の山川冬樹だが、ライブはタイトルの通りぶっとんでいる。 山手線の中で、骨伝導と電車の鉄の擦れる音をまじえたゲリラライヴ（乗客は気づかない） 、こがらしの音と日本の廃屋、 『LIVE（生きる／ライヴ）』をテーマとした、70時間連続ライヴ 、 東京港海上での"DOMBRA"
山川冬樹：アーティスト。音楽、美術、舞台芸術の分野で活動。身体内部で起きている微細な活動や物理的現象をテクノロジーによって拡張、表出したパフォーマンスを得意とし、国際的に公演を行う。歌い手として2003年「第2回日本ホーメイコンテスト」グランプリと観客賞をダブル受賞。また声についての連載エッセイを「未来」で2007年より2年間執筆。2014年舞台「金閣寺」に出演など多方面で活躍。2015年横浜文化賞文化・芸術奨励賞を受賞。
7. 金沢健一 の日常の振動_2p
そろばんやガムテープ、振動の物理現象など視覚、聴覚、触覚を結びつける作品を制作をしている金沢健一。私達が日常的に使っている道具は金沢健一の眼にはどのように（どのような楽器に）見えているのだろうか。数点ピックアップして掘り下げる。
8. 藤田陽介 の日常の振動_2p
自作パイプオルガン、声、水（水槽）などを用いたソロ・パフォーマンスを主軸に、サウンド・インスタレーションや映画音楽、ダンス作品の音楽など多岐に活動する藤田陽介。聴いたことのない音を聴きたいという興味（欲求）に従って、あらゆる現象／メディア／状況を取り込みながら音楽を探求している藤田には、私達が日常的に使っている道具はどのように（どのような楽器に）見えているのだろうか。数点ピックアップして掘り下げる。
9. Lucy Railton の日常の振動_2p
ロックダウン下のベルリンの印象を描いた崇高なサウンド・ドキュメントとして出したサウンド『S-Bahn（LUCY RAILTON）』はプレンツラウアー・ベルクの自宅アパートの前でS-Bahn（ドイツの鉄道列車）とデュエットしている。私達が日常的に使っている道具や景観はどのように（どのような楽器に）見えているのだろうか。数点ピックアップして掘り下げる。
10. Stephen O'Malley の日常の振動_2p
SUNN O)))のメンバーであり、Editions Mego傘下のIdeologic OrganのディレクターでもあるStephen O'Malley。原点とも言えるのは、漆黒爆音ドローン。戦闘機、工事現場、洗濯機などの騒音はO'Malleyにとってどのような楽器に見え、どのように聴こえてているのだろうか。数点ピックアップして掘り下げる。
11. 世界のローカルノイズ_10p
世界中でノイズやアンビエント、実験ライヴが行われた場所とライヴ内容をその場所だからこその音と雰囲気を含めて紹介。（扉で紹介している写真の具体的内容を掲載する）
12. pickup台湾ローカルノイズ_2p
11 にプラスで、台湾のアーティストを紹介。
台湾ではノイズがまだ世間的に認められていないため、地下や小さな部屋でライヴが行われている。世間的認知が低いからこその、守られていない野良の音の良さがあるので伝えたい。
音楽がアングラとして扱われ、あまり人が介入して来なかった国については、音楽を通しての異議申し建てが潜んでいる場合があるので、ライターおすすめの国の事例があれば紹介したい。
台湾のアーティスト：
台北を拠点に活動するアーティスト、実験音楽プロデューサー兼ライブパフォーマー。東南アジア/東アジア、中国、ヨーロッパで、過去数年間に20か国以上をツアー。ノイズ、クラブ、奇妙な音、時には儀式的なパフォーマンスを想起させるフィールドレコーディングの概念的なアイデアと、台湾自身の精神的な風景にまでさかのぼるソースが組み合わされています。
狭い部屋でライヴを行っている。蜘蛛が出る部屋で行われている場合も。音楽に合わせて？ 蜘蛛が動く姿がinstaに上げられていた。
13. アーティストが作る自作楽器！_3p
14. アーティストインタビュー_6名 ✕ 2p
インタビュー内容：
それぞれの質問に対する回答の理由や捉え方を深く訊く。
- 過去から現在までで、どんなノイズが印象に残っていますか？
- 今向かっている興味についても教えてください。
- 音楽好きとはどういう人をいう？
- ノイズやアンビエントをとりまく現代の事情をどう捉えている？
- 土地によって違うと思うので、印象に残っている土地とノイズやアンビエントの相性についても教えてください。
- ノイズが愉しくなるオルタナ都市or街とは？
アーティスト（インタビュイー）：
- 世界的に支持される日本のアンビエント・アーティスト Asuna
- 鬼才Lawrence English主宰の音響系名門〈Room40〉にも作品を残すニューヨークの女性即興演奏家 Marina Rosenfeld
- 叙情的なノイズに唖然とさせられるインダストリアル・オペラ Roly Porter
- アンビエント、エクスペリメンタル・プロデューサー PAUL JEBANASAM
台湾からも一人欲しい。アジアからもう一人欲しい。上記アーティストに固めず、質問に適したアーティストや評論家、キュレーターをコントリビューターにも紹介してもらう。
15. 音楽を２倍楽しむためのファッション考察_2p
環世界研究家とファッションデザイナーで考える、音楽を身体的に楽しむための音圧ファッションを考える。蛇は音が聞こえないが皮膚で音を感じる。魚は背骨とエラ。植物のマクルグラビア属の花は超音波を反射してオオコウモリに見つけて貰いやすくする。そうした人間以外の生物の音の機能や感じ方もヒントにする。
16. 突撃！！ 都内建築物音響_4p
建築家と音響家、イラストレータ（記録係）で巡る。
建築家はホールの設計者か、路上観察研究や都市を人間以外の視点でも観察している建築家の 藤森照信 が良い。
オーナーとの交渉の結果OKだった建築物は施工図面に、音に関して工夫されている部分、建築家と音響化の考察を書き込んだ図面をコンビニのコピー機から出力できるようにする。
「わざわざコンビニで図面プリント」というのが良い。
出力して施設を訪れて欲しい。わざわざ出力までして訪れる人は建築や音楽が本当に好きな人なので、同じ人を見つけた読者は嬉しくなるはず！
17. アンビエント・ミュージック現象を考える_3p
- アンビエントが好きという有名人をリサーチ。「リラックスするための音楽」をよく聴くという起業家の音楽体験を探る。少し皮肉る。（2P）
- 自分が好きなアンビエント・ミュージックを見つけて聴く音楽好き（リラックスするための音楽は聴かない）な人の考察。（1P）
18. 世界のノイズ・アンビエント・実験音楽レーベル、レコ屋図録_16p
19. 音楽を２倍楽しむためのファッショングラビア_8p
撮影場所は家、ライヴ会場、原っぱ、騒音など音がある場所。
- 家でのシーンはインテリアとして、誰でも簡単につくれるかっこいいライティングを伝授。たとえば、こちらのようなユニークな形のライティング で家用に点滅がゆるやかなものを応用して作れるように伝授する。（2p）
20. ノイズ・アンビエント・実験音楽関連の書籍_2p
連 載
今月の温泉（2p）
旅するアーティストに温泉を紹介してもらう。日本各地をライヴで巡りながら、日本中の温泉巡りをしている松本一哉に依頼。旅の思い出として、ライブの話、入浴中に考えていたことなどを書いてもらう。
松本のインスタには 訪れた温泉の写真 が多く上げられている。
旅におすすめの音楽も掲載。Sptify APPに連携。
今月のお昼（4P）
料理人に自分で作ったお昼ごはんを自分の店で食べてもらう。
そして料理や食材に対する独自の視点を語ってもらう。
出来たときのにおい、塩の種類による変化、一回目の咀嚼音と２回目の咀嚼音に変化をつけて食べる時の驚きを演出していること。2分44秒のゆで卵がベスト。スーパーで人気なく端っこで鎮座していた食材の演出、味の分類など。作る人だけが知っている科学的な面白い部分や工夫を書いてもらう。
さまざまな料理教室に通った結果、食材に対する偏愛を持つ人が多くいた。わたしは料理関係の仕事もしていたが、人命よりも食材を育てるための土と水が大事といった人も多くいた。豆料理しか作らない／出さない料理人もいた。そうした料理人たちの偏愛ダダ漏れの連載にしたい。海外に食材の勉強の旅に行く人も多いので、ときどき同行させてもらいたい。
Contributor候補 特集「旅と音」の目次詳細に記載した人以外
編集ライター：
- 『ele-king』や『デンシノオト』などで執筆している 三田格
- 『ele-king』や『デンシノオト』などで執筆している 野田努
- 元レコ屋で少し癖のあるアンビエントに詳しい 綾門優季
- 電子音楽家であり医者でもある 伊達伯欣
- 世界各地のダンスミュージックや祭り文化を追いかける 大石始
- 『デンシノオト』で執筆し、多くのノイズ音楽を聴くブロガー デンシノオト
- STUDIOVOICEの執筆陣
- 音楽を中心にしながら、文学、映画など他分野と音とのかかわりを探る批評を展開する 小沼純一
キュレーター、録音技師、サウンドデザイナー：
特集 photo：
ざらっとした感触の写真が良いので、STUDIOVOICE 陣が近い。（とはいえ安易にトーンを決めず、見せ方を探りたい）
洞窟での撮影など場合によってはアーティスティックなフォトグラファーも良い。
次号以降でやりたい特集テーマ詳細（案だしレベル）
- 遊びの部屋
音楽が好きな人は自分でライティングを考えて部屋を作る。アートが好きな人はすごく使いにくいけれど、建築家顔負けのかっこいい家具を作る。タスマニアの Dark Moho はコンピューターサイエンスでバカ儲けした個人の趣味から始まったイベントだ。世のため、人のため始まりではなく、自分個人のために作られた空間がかっこいい理由と（洗練された人からは悪趣味に映るかもしれないが）、どのように探求され作られているのかを探りたい。
- 建築解体
建築家の思想がつまった建築を解体、再建する場所に出向いて取材する。
設計図を元にどういう思想のもとその素材が使われ、工夫されていたのかを解体現場や再建現場から探る。
- 本
モノそのものを探求するには、どの順序で本を読むと良いのか。
専門家とか信頼できる大学院OB生に、非専門家や別領域の専門家に本の紹介をしてもらう。
專門・非専門関わらず、読書会ではどの順序で読んだから詰んだという話をよく聞く。
專門を学ぶときはコミュニティに入るのが手っ取り早いと思うが、大学院入学レベルまでの専門性を（なるべく詰まずに）つけるには、どの順序で土台を築くのがいいか。本の順番のセレクトをしてもらう。
また何の本を紹介するかというよりも、「どう読んだか」に焦点をあてる特集も入れたい。何を知りたくて読んだか。読んでいる間に見つけた疑問が、どう解決していったかなど、その人だけの視点や読み方がわかるようなものにする。
他にも、食、服、公園、（何かにハマっている人の）部屋の特集がしたい。
***
よければこちらも
プログラミング初学者が、参加していた読書会の課題「読後のアウトプットの質が高まらない」という課題を解決するためにアプリを作成しました。企画から実装まで、アプリを作る上で考えたことを書いています。
よければご覧ください。
いま読んでいる本が「自分にとってどのぐらい大切な一冊」なのか、「見える化」するアプリを作りながら考えたこと
はじめに
いま読んでいる本が「自分にとってどのぐらい大切な一冊」なのか、「見える化」するyondeco アプリをリリースしました。
今回は使い方や技術の概要を伝えるためのリリース記事ではなく、タイトルの通り、初学者の私が開発を通じて、さまざまな技術的な選択や学習のアプローチを経験してきたので、その経験と学びを共有し、今後の展望についても触れたいと思います。
このブログは４部作になっています。
詳細は自己紹介の後の目次を見て気になった箇所から読んでいたければ幸いです。
- サービスの概要：コンセプトと問題
- アプリを作る上で決めたこと ：アプリの仕様
- 技術詳細：上記問題を解決する技術的工夫
- 所感：学習の気づき、リリースの判断、今後の展望
自己紹介
デザイナーからエンジニアを目指して一年半、プログラミングを学習してきました。デザイナーとしてはグラフィック、エディトリアル、事業などのデザインやアートディレクションを担当しており、時にはクリエイティブディレクションも担当しました。デザインの際、わたしは表層部分だけでなく、背後にある構造そのものをデザインすることを心がけていました。この姿勢が"構造家展"で見た建築分野のエンジニア、構造家の取り組みに共感を感じさせました。彼らの姿勢や、コーディングの経験、エンジニアとの出会いを通じて、ソフトウェア分野で"構造家エンジニア"としての道を追求したいと考えるようになりました。
【目次】
サービス概要
yondecoアプリは、いま読んでいる本が自分にとってどのぐらい大切な本なのか、見える化できる読書アプリです。 アプリの機能に沿って読書メモをとることで、書評家のように自分だけの本のレビューが完成していきます。
yondecoアプリの対象像
- 自分にとっての大事な本を見つけたい人
- 自分がどういうフレーズに惹かれるのかを知りたい人
- 読書を通して自分自身と向き合いたいと考える人
- 自分だけの視点や感じたことをまとめて書評やレビューを書きたい人
- 読書をしてはいるが、その読書から得た知識や感じたことを具体的なアウトプットにつなげる方法になれていない人
- 『ゆる言語ラジオ』のような探究エンタメが好きな人
- 特に小説やエッセイのような文学的なコンテンツを好む人
yondecoアプリが取り扱うサービスの範囲
開発に至った背景
yondecoアプリを作るきっかけは数人の読書会グループに参加していたこと。
読書会ではアウトプットの質を高めるための話し合いで、以下の課題があがりました。
読書会で出た課題
- 読書の手順がわからない
- 合わない本を読み続けてしまう
- 読書メーターやamazonレビュー、twitter で発散して満足してしまう
- 読書を通して自分自信と向き合うことができない。そのため自分だけの本のレビューができない
アウトプットの質を高めるための施策で良かったもの
- 読書メモの数が多いほど自分にとって大事な本とする。
- 上記で見つけた大事な本を精読しながらアウトプットに必要なメモを取る
- アウトプットに必要なメモ：要約、著者の意見、自分の意見、引用された事実
- 自分が好きなフレーズや気になった部分を前後の文脈含めてストックして読み返せるようにする
アプリを作る上で決めたこと
yondecoアプリの特徴は次の通りです。
- yondecoアプリでは2つの読書体験を以下のように名づけました。
大切な本と出合うための私的な読書 👉 さらさら読書
アウトプットにつながる学びの読書 👉 じっくり読書
- 「さらさら読書フェーズ」の読書メモは気になったページの写真を撮るだけ。
- 「保存したメモの数」をもとに 自分にとって大切な一冊かどうかがわかる。
- 現在の読書フェーズと「 じっくり読書」に進むために何をすべきかがわかる
- 読書のアドバイスを受けることができる
- じっくり読書フェーズでは「著者の意見」や「自分の意見」を引用・要約したメモをとれる
- 「著者の意見の数」に対する「自分の意見数」が見える化される
- 自分の意見数が増えるとアウトプットの基盤になります
- 横断的にメモの絞り込み検索ができる。「気持ちが上がったメモ」や「要約」など
コンセプトや使い方の詳細は yondeco アプリの「Topページ」を参照してください
本の状態を判定する基準値を決めた
アプリを作るにあたり、自分のとって大事な本かどうか、アウトプットに進めるフェーズかどうかを判定するために以下の基準値を設定しました。
- メモの数が足りない「さらさら読書」の基準
- メモの数が、読書ページ数に対して1/8未満
- メモの数が一定数あってアウトプットのための読書「じっくり読書」に進める基準
- メモの数が、読書ページ数に対して1/8以上、未読の数が1/4未満
- メモの数が一定数あるが、内容を咀嚼できていないために通読したほうがいい「さらさら読書」の基準
- メモの数が、未読の数が1/4以上（未読の数を減らせばアウトプットに進める）
アプリにとっての憲法「ユーザー体験設計書」を作成
アプリを作るにあたり、目的をしっかりとさせるため、ユーザー体験設計書を作りました。
ユーザー体験設計書はアプリにとって憲法のようなものです。今後、定期的に見直しますが、ここから外れるものはyondecoアプリ内では作りません。
ユーザー体験設計書では、ソーシャルゴール、読書する人のライフゴール、感情的ゴールを設定しました。
詳細はユーザー体験設計書にまとめています
ユーザー体験設計書の作成後はユーザーストーリーにそって、目的を阻害する要因を洗い出し「問題解決のための機能一覧」（リンク先のスプレッドシートの詳細体験設計タブ）を作成しました。
Topページのライティングを編集さんに手伝ってもらった
yondecoアプリは、読書に対する新しい定義をしているため、「Topページ の文章」は丁寧に取り組みました。
仕事仲間の編集さんにリライト依頼し、アプリに興味をもっていただいた方にアプリの特徴やコンセプト、使い方が伝わりやすい文章を心がけました。
利用者が迷わず使えるように工夫した「画面設計」を作成
- 読書メモの専用スライド：利用者が読書メモを楽しんで読み返すことを目的として、余計な情報を排除したシンプルなモーダル上でスライドを表示します。
- 直感的なタブ機能: どの読書フェーズにいるのかを簡単に切り替えられるよう「さらさら読書」「じっくり読書」というタブを採用しました。
- yondecoアプリの２つの軸。
- 横軸： 読書中の本やメモの一覧表示。
- 縦軸： 本の登録から、メモの撮影、そして読み返しまでのフロー。
- この2つの軸が交差する点、つまりメモの一覧ページは、このアプリの中心的存在です。
- UI：UIに関しては利用者が迷わず使えるよう工夫をしましたが、これに関しては今回は省きます。
見た目のデザイン
このアプリの対象者は『ゆる言語ラジオ』のような探究エンタメを聞いている人なので、真面目すぎず、知的に遊ぶような精神をデザインに取り入れました。
具体的なデザインは yondecoアプリを参照 してください 。
「読書で遊ぶ」とか「知的にふざける」といった精神を大事にしたかったため、POPなデザインやシュールで遊び心のあるイラストで体現しました。
アプリのキャラクターデザインを作成
キャラクターは猫です。夏目漱石とはじめとする文豪は猫を飼っていることが多いこと・私自身が猫を好きなことから猫をモチーフに選びました。 キャラクターのタッチはイラストレータ「しろくじらぷらすし」さんのポートフォリオから選びました。
各キャラクターの説明
りす：
「さらさら読書」のイメージキャラクター。未読の読書メモを口いっぱいに溜め込んでしまう。ちゃんと読み返しましょう。
たこ：
「さらさら読書」のイメージキャラクター。沢山の本を読んで自分にとって大事な一冊を見つけようとしている。
ふくろう：
「じっくり読書」のイメージキャラクター。アウトプットが得意で知的。
技術詳細
使用した技術・言語・ツール
その他お世話になったツール・サービスなど
Swiper、Panzoom、ImageMagick、Makefile
バックエンド
Ruby
リース直前、本の状態名を利用者に親しみやすい名前に変更したことでクラス名を変更する必要が出た
アプリのリリース直前、利用者にとって親しみやすい本の状態名への変更が必要となりました。具体的には、「乱読」「通読」を「さらさら読み」、そして「精読」を「じっくり読み」へと変更しました。この「さらさら読み」には「乱読」と「通読」の両状態が含まれるため、クラス名の変更だけでなく、名前空間の導入をすることで整理・構造化をする予定です。
フロントでは将来的に React を使いやすいように実装した
- Helper メソッドの使用を最小限にし、表示のためのロジックを書く module 「ViewModel」を自前で実装しました。これにより Controller から View にローカル変数を渡し、View には表示のみを任せることができました。これらの実装方法は将来的に React への移行を見越してのものです。
- View にローカル変数を渡している理由は View で @を使わないようにするためのものです。 View で@を使うことによる難しさを Ruby コミュニティで聞いていたので、@を使わないで実装できるように考えました。
表示のためのロジックは ViewModel に、DB に近いロジックは Model に置いた
- 現在、 Rails の Controller 内にロジックを記述している箇所がいくつか存在しますが、これは最適ではないと思っています。 DB に直結するロジックは Model に、それ以外のロジックは適切なクラスに分割して実装し、 Controller からはそれらを呼び出す形をとっています。
- また、 ViewModel 内にもいくつか DB に近いロジックがあるため、これを Modelに移動させる計画です。そうすることで、 ViewModel は状態の操作や管理を中心に担当させたいと思っています。
ActiveRecord 型をあまり長く持たないようにした
- ActiveRecordとDBが密接に結びついていることによる難しさをコミュニティのエンジニアから聞くことがあります。このため、データ取得時にはなるべくRubyで使える基本的な型、例えばArrayに変更して扱うようにしています。
コードのリファクタリングと単体テスト
- 今まではテストを実装の後に書いていましたが、今後、リファクタする時は先にテストを書いて修正していきたいと考えています。
- 各メソッドには用途と期待する戻り値をコメントアウトで残しているため、それらをもとに足りない単体テストを追加していく予定です。せっかく学んだテスト技法もここで活かしたいと思います。
自前でアップロード機能を作成
よく使用される Carrierwave や Active Storage を使わず、独自のアップロード機能を実装しました。
画像処理には、主流の Gem 「mini-magick」や「r-magick」の代わりに直接 ImageMagick を活用しました。
画像名のサニタライズ
- system コマンドを使う必要があるため、ファイル名に関してはActiveSupport::Inflector.transliterateを使用して非 ASCII 文字を ASCII の近似値に変換し、さらに正規表現を使ってスペースやワード文字以外の文字を除去することで、ファイル名を安全な形式にサニタイズしました。
- シェルのメタ文字や特殊文字によるインジェクションのリスクを回避するためsystem コマンドではカンマで区切りました。
ファイルの内容自体のチェック
- アップロードファイルの初期の検証は正規表現を使用していましたが、実際のファイル内容も検証する必要が生じました。
- ファイルの Mime-Type を検証するために「Marcel」という Gem を採用しました。
ユーザビリティの向上
- 古いスマートフォンでも yondecoアプリでの画像投稿をサポート。特定の「HEIC」形式の画像も「jpg」に変換し、必要に応じてリサイズ処理を施しました。
複数枚の画像投稿の際の仕様
- yondeco アプリでは、ユーザーは複数の画像を一度に投稿可能です。
- もし投稿された画像の中に保存不可のファイルが含まれていても、他の問題ないファイルは正常に保存されます。
- すべての投稿処理終了後、エラーメッセージは改行で区切られ、 JavaScript を使用して flash メッセージとしてユーザーに表示されます。
ビルドツールに「Vite Ruby」を使用
「Vite Ruby」は Ruby や Rails のウェブプロジェクトで、 webpack の代わりとして使える、より速いページ更新とビルドを実現するツールです。
- webpacker のメンテナンスが終了したことを知り、生の webpack を使おうと思いましたが、少し使っただけでも管理の大変さを感じたため、いくつかのビルドツールの候補を出した上で Vite Ruby を選択。アプリから webpacker を剥がし、代わりに Vite Ruby を使用しました。
- 現在の yondeco アプリは Rails の中でフロントを作成しています。 Vite Ruby は特定の Js ファイルから特定の HTML.erb ファイルだけを読み込むことができず、 Js ファイルがすべての HTML.erb を読み込んでしまう問題が生じました。これを解決するために、 If 分岐を利用して、特定の条件下でのみ必要な HTML.erb ファイルを読み込むように回避策を施しています。
-
このとき、私はソフトウェアの問題点を「ISSUE」として報告するだけのスキルしか持っていませんでした。今後は OSS にパッチを提供できるようにしていきたいと考えています。
フロントエンド
Vanilla JSを選定して基礎理解
Vanilla JS と Railsでの状態管理の理解
当初、私は React を導入することを検討していましたが Vanilla JS を選定しました。React では state の変化時に component が更新され、Reducer を通して状態管理が行われます。この仕組みは MVC モデルに似ていると感じました。しかし、 React を直接導入する前に、 Rails 内での View や Controller の操作を Vanilla JS が担当することで、その動作の理解を深めたいと考えたためです。
ユーザー体験の最適化
ユーザーにストレスフリーな体験を提供するため、部分的な表示の更新やフロントエンドでの入力バリデーションを導入しました。
非同期通信のアプローチ
Rails の Ajax 機能を利用せず、より深く非同期通信を理解するために、remote: true や .js.erbファイルではなく、fetch 関数を使用して非同期処理を実装しました。
JSライブラリの統合時の課題
モーダルのスライドページにおいては、複数の JavaScript ライブラリを使用しています。これらのライブラリ間での機能の競合が発生し、一時的な困難に直面しましたが、ドキュメントを丁寧に読み解き、デバッグを行いながら問題を解決していきました。
バケツリレーとの向き合い方
JS 単体での todo リスト作成時には、「バケツリレー」という状態管理の課題を体験しました。しかし、今回のアプリケーション開発では、JSから直接 html.erb の子要素へデータを渡す方式を採用したため、この課題を特に感じることはありませんでした。次回の React の利用時には、 状態管理ツールを使用せずに開発し「バケツリレー」を経験してみたいと考えています。
まずはピュアなCSSを使ってCSSを書けるようにした
CSSツールの技術選定で迷う
- 特に「TailwindCSS」とピュアな CSS の間で迷っていました。 TailwindCSS は、「Bootstrap」のように JS が組み込まれていない UI コンポーネントが多いことから CSS が苦手な私にも魅力的に感じました。また、クラス名が長くなるという懸念については設定によって短縮できることもわかりました。
- しかし、最終的な技術選定は、業務での経験者の意見を聞きたいと考え、 MENTA というサービスを利用して複数のメンターと相談しました。
- 自分のスキルと制限時間、期待値を明確に伝えた上で、6 名のメンター全員からピュアな CSS の使用をお薦めされた。これによって、基礎を積む意味でも、まずはピュアな CSS を採用することに決めました。
毎日１時間 CSS のペアプロ・質問時間を１ヶ月間設けた
- デフォルトでペアプロ・質問時間を 1 ヶ月の間、毎日 １ 時間設ける設定にしました。
- 何をどう進めたいのかの計画をメンターさんに伝えた上で実装を進め、困った時に質問をしました
- 月の後半では、 CSS の整理方法への興味が自然と湧き、マージンやフォントの大きさをクラス化するなど自分で工夫しつつ、メンターさんのやり方を見せてもらいました。メンターさんはSASSを使っていたが、最近の CSS は変数機能を持っているので、その機能を活用して色を管理したいと思います。
必要を感じて Linter / Formatter を使った
- CSS でスタイリングをする場合、HTML構造の修正が頻繁に発生するため、自分でインデントを修正するのは非効率でした。 学習初期は Linter があることを不便に感じることがあったが、スタイリング段階ではインデントの自動化が重要と感じ、保存のたびに Lint を通して自動コード整形をデフォルト有効にしました。
- 自分で作成した以下の全てのファイルに対して、自動整形をデフォルトにしました。
対象ファイル：Ruby（.rb）、JavaScript（.js）、JSON、ERB（.html.erb）およびCSS（.css）
インフラ
インフラ周りのステップアップ
アプリ作成初期から手動でデプロイしていたが Github Actions で自動化
- Github Actions を使うまでは手動でデプロイしていました。
- その後は Makefile を使ったデプロイに変更したが、デリバリーはできるだけ早い方が良いと感じ、 Github Actions を使って CI/CD を自動化しました。
- ローカル環境での開発には、 Docker を使用する前は Vagrant を活用していました。その際、コンテナや仮想マシンを作成し直すたびに、 postgreSQL 、 ruby などのツールやソフトウェアを毎回インストールし直す必要がありました。 また、自動化する前までは、何度も手動デプロイをしていましたし、あらゆる場所からEC2 や Vagrant に SSH でのデプロイも経験していました。その経験が、 Github Actions の CI/CD を書く上で非常に役立ちました。
Dockerを活用したリモート・ローカル環境の自動構築
以前は Vagrant を使用してローカル環境を構築していました。その主な理由は、リモート環境と同じ Ubuntu を使用したかったためです。しかし、コンテナや仮想マシンを新しく作るたびに必要なツールやソフトウェアをインストールする必要がありました。その際、一部のインストール作業は Makefile を活用して行っていました。この経験が、後に Docker を使って環境構築を自動化する際の基盤となりました。
AWS の Elastic Load Balancing (ELB) か Nginx か
- Nginx を利用した理由は、無料であり、小規模なアプリケーションでロードバランサーの利用が不要だったからです。
- SSL 証明の取得には無料の Let's Encrypt を使用しています。ローカル環境ではDNS チャレンジで、デプロイ先の EC2 では HTTP チャレンジで証明書を取得しています。
- Route 53 でドメインを登録し、ローカル環境ではサブドメインを作成して使用しています。
デプロイ先はAWSのEC2
- EC2 を選択した理由はIaaSの利用ができるためです。仮想マシンのインスタンスを立ち上げ、 OS やアプリケーションを自由にインストールできる柔軟性に魅力を感じました。
- 最初は EC2 上に postgreSQL サーバーをインストールして利用していましたが、学習の一環として RDS の使用に切り替えました。
認証・認可
自分のサーバーにログイン情報を持たせたくなかったため SaaS 系を利用しています。近いうちにパスワードレスの設定をしたいと考えています。
リポジトリはこちらをご覧ください
所感
開発を進める中での学習に関する気づきと改善
初期の課題
アプリを作り始めた際、取り組めるタスクが限られていました。これまでの学習方法は本を網羅的に読むことやコードの写経が中心で、実際のアプリ開発とは異なるアプローチが必要でした。
課題解決のアプローチ
アプリ制作を進めるために、以下のステップを実践しました：
- ユーザー目線で解決したい問題を明確化
- その問題を解決する機能を設計
- 何の技術を習得すべきかを調べる
- 技術の習得から機能作成までのステップ式のカリキュラム※ を自分で作成しレビューを受ける
- それに基づき機能を実装
※ ステップ式のカリキュラムでは、最低限の基礎知識だけで作成し、段階的に理想に近い機能を作成した。
新たな知識が必要になった時の全体像を掴む手順
- 信頼できそうな記事のハンズオン
- 関係性やコマンドの意味を図解して全体像を理解
- 自分のアプリに適応して実践
- 用語がわからない時はいくつかの記事を見て、共通の言葉をピックアップし理解する
わからない時に対象課題を図解化して質問
学習が後半に及ぶに従い、質問をする際は自分の理解を図解化したり、取り組んだ/取り組んでいないタスクを一覧化してから質問をするようになった。
現在の学習課題
仮説の的外れな点が多いのが現在の課題です。多方向からの仮説をすべて書き出してから少しずつ調べたり質問することを意識しています。
現在はリファクタ段階にいてプロセスを重要視している。 そのため以下のアプローチも取り入れています。
理想のプロセスに近づける方法を自分の能力でできる方法に落とす
- 現状の自分の方法と理想のプロセスとの間のギャップを特定する。
- ギャップを埋めるための方法を、自分の能力に合わせて調整し、ステップバイステップで進める。
詳細：私の学習の工夫
どこまで作ったらリリースするべきかの判断
アプリのリリースの判断基準として、「アプリを使用する際のコアな機能がすべて動作するか？」を主な基準としました。ユーザーへの価値を明確に伝えるためのチラシを作成し、その中で挙げられたコアな価値を実現する機能がすべて動作する段階を MVP （ Minimum Viable Product ）と定義しました。 その結果、「削除」などのサブ機能はMVPの段階では使えない場合があります。 デザインのお仕事では、まだないベータ版機能のボタンを配置することもありました。ユーザーの反応を見て、需要が高い場合に具体的なUI設計や実装を検討するためです。 このアプリでも利用者のニーズを取り入れつつ、優先度が高いタスクから着手していきたいと思っています。
今後の展望
サービスとして、本と利用者の関係性を強化していきたいと考えています。一方、コードの面では、テストの追加やクラス名の変更、コードの整理など、多くの改善点が見られるため、リファクタリングを進めていきたいと思っています。
サービスの向上（興味の順番）
- 自己理解の強化： 読書メモを解析し、利用者がどのフレーズに興味を持っているかを示す機能の追加。
- 音読機能：読書中に撮影したメモを二次元キャラが音読する機能。APIのリクエスト方法を工夫し、ワード数の制限を回避できることは実験により確認済みです。
- 利用者のカスタマイズ：利用者が「さらさら読み」「じっくり読み」のような本の状態の判定基準をカスタマイズできるようにする。
コードの向上
- 状態名のリファクタリング：状態名の変更を反映させ、適切なクラス名に変更。
- ドメイン名の使用：状態をフラグで示している部分をドメイン名に変更。
- クラスの導入：Hashで表現されているクラスを正式なクラスに変更。
- 新しい技術の探求：Rust製の全文検索『MeiliSearch』の導入や、フロントエンドのReactとTypeScriptへの移行、画像の保存先をS3にしたり、terraformを使うことに興味があります。
***
よければこちらも
このアプリを作るきっかけになった読書会での私のアウトプットの一つです。
架空雑誌を作り、以前からの研究テーマ「旅と音」で企画を立ててみました。
