2022年振り返り、出産と育児
たまには振り返りでも。
お仕事
2021年の12月に別の事業部に異動になった。 異動前のプロジェクトでは主にYiiを使用していたが、異動後のプロジェクトではLaravelを使っていた。ようやくLaravelをまともに触った気がする。
それ以外にもALPSを使った開発をやってみたり、久しぶりに機能開発をやったりなんだかんだ楽しかった。 お仕事で関わる人もかなり変わって違う会社に来たみたいな新鮮さがあった。
割とチームのこと考えて動いてたりして、どうやったらよくなるとか考えてた。
7月でお休みに突入。
お休みに突入してからは、こっそり週一でALPSのもくもく会にお邪魔してお話ししてる。
プライベート
出産
年明け早々に妊娠が分かった。幸いつわりは軽かったけど、眠くて眠くて仕方なくて、裁量労働制に甘えて夕方仮眠して起きて少し働くみたいなことしてた。（結局最後まで吐くことはなかった）
上司に伝えたら、「私も今度育休に入ります。なんなら、ついさっき10分前に1on1したメンバーからも育休入りますって話をしました。」と。 怒涛の育休ラッシュ👶
7月に一足早くお休みに入って、技術書読み漁ってゲームして寝まくってた。（今思えば保活しときゃよかった）
予定日より少し早く陣痛きて、3時間くらいで産まれた。超絶スピード出産&安産。痛かった。
都立病院で産んだから42万からお釣りがきた💰
育児
マタニティブルーズから始まり怒涛の毎日。 産まれて1ヶ月は毎日泣きながら育児してた。
頻回授乳頑張ってたけど子どもが小さすぎて大きくなれなかったから結局そこからはずっと混合。 メリット→夫に気軽に任せられる。 デメリット→出費やばい。授乳に時間かかる。
生後2ヶ月ですでに夜通し寝てくれるようになったから、すごく楽。早起きして子どもと一緒に二度寝してって感じ。
もうすぐ4ヶ月だけど、指しゃぶり大好きマンになった。
我が子、世界一かわいい。
趣味
妊娠する前はずっと空手とキックボクシングを週3くらいでやってたけど、すっぱりとやめた。心残りしかない。
とはいえ、自分の中で頑張れない理由みたいにもなってたから、まぁ仕方ないしな。くらいな気持ちですんだ。多分またいつかやる。
あとは、ライブに月6くらいで行ってたけど、これは諦めきれなかった。
安定期入ってから〜8ヶ月手前くらいまで行ってたんじゃないかな？幸いコロナ禍で立ち位置指定だったからギリギリに一般チケ取って逆最でみてた。たのしかった。
産んだ後は2ヶ月くらいで復帰した。さすがにまだ2回くらいしか行けてない。ひさしぶりに身軽でできるヘドバンも折りたたみも最高だった🤟
これから
保育園が4月に入れたら5月に復職する予定。 わたしの住む地域は社会保険料免除とかの関係で4月末ではなく5月1日復職でも大丈夫とのこと。
来年は、仕事時間の中で頑張るそれ以外は育児に全振りする。を目標にほどほどに頑張ろう。
Webアクセシビリティを支えるための技術
概要
まずはじめに、私はWebサービス屋さんです。 Webサービスを提供し続ける以上、誰もが使えるものを提供するというのは自然なことであり一定の条件を満たさないと使うことができないサービスを提供するのは本意ではないと考えています。
しかしながら、多くの場合Webアクセシビリティを意識してサービスを作る場合には、デザインであったり、デザインを実装するためのマークアップであったりが意識されがちです。 そのためサーバーサイドには無縁であると感じる人も少なくはないのではないかなと私自身は考えています。実際にサーバーサイドに出来ることがどこかに明確に書かれている項目も多くはありません。
そんな中で、サーバーサイドが、Webが、どこまで現在のWebアクセシビリティに取り組むという基礎知識になっているか、またサーバーサイドエンジニアとして出来る何かがないのかということを模索していきたいと思います。
Webアクセシビリティとは
詳しくは『デザイニングWebアクセシビリティ』を読むことをおすすめします。
WebアクセシビリティはW3Cで勧告されている規格です。（Web Content Accessibility Guidelines (WCAG) 2.1） 何をもってWebアクセシビリティと言えるかは、WCAGで定義されているレベルA、AA、AAAの項目に準拠しているかどうかが明確な指針とも言えるでしょう。
ただし、Webアクセシビリティに関わるものはそれだけではありません。WCAGに記載されている内容は、これをするとよりアクセシブルになるという内容が多く、その前提についてはガイドラインには含まない内容となっています。
Webアクセシビリティを支えるための技術
先述した書籍にもあるが、Webは圧倒的にアクセシブルです。 今までは本、新聞、回覧板、お店の情報、など何もかもの情報が異なる方法で収集され、それらになんの繋がりもありませんでした。
現代ではインターネットが普及し、誰がどこからでも欲しい情報はインターネットブラウザを経由して得られる時代になりました。 インターネット上にある情報は、URLさえ知っていればなんでも情報を手に入れることができ、情報から他の情報へのリンクだって存在します。さらには、同一のURLでも古い情報は捨てられ、常に新しい情報へ更新することだって可能です。
それらには、Webが成功したいくつかの基本的なものがあるからです。Webが成功したことについてこれから説明していきます。
ハイパーテキスト（ハイパーメディア）
ユーザーはインターネット上の情報を見るためにはURLを辿って、特定の情報にアクセスをすることができます。 私たちは普段あまり意識をせずに使っているが、それにはハイパーテキストという複数のテキストを相互に関連付け、結びつける仕組みがあります。 また、テキスト同士を結びつける参照のことをハイパーリンクと呼びます。 ハイパーテキストはローカルでもインターネット環境でも利用が可能です。
ハイパーテキストは、もう少し意味を広げてハイパーメディアとも呼ばれています。 ハイパーメディアはハイパーテキストに加え、グラフィックス、音声、動画、テキストを絡み合わせた情報媒体です。
それを実装している最も有名な方法がWorld Wide Webであり、WWWは最も有名なハイパーメディアの実装です。
Hyper Text Markup Language（HTML）
ハイパーテキストを記述するためのマークアップ言語のうちの一つであり、World Wide Webで使用されています。テキスト間を結びつける参照のことをハイパーリンクと呼び、HTMLはハイパーリンクをテキスト中に埋め込むことによって、他のハイパーテキストを結びつけることを実現しています。
HTTPプロトコル
ブラウザとブラウザが通信を行うためのプロトコル、お約束です。 大きく分けると、メソッド、ヘッダー、メッセージ、ステータスコードなどがあります。HTTPプロトコルに従うことによって、サーバーとの通信の状態を知ることができたり、リソースの操作をおこなうことができます。
World Wide Web
インターネット上で提供されているハイパーメディアシステムです。俗に、World Wide Webは「インターネット」を指すような言葉でもあります。World Wide Webではドキュメントに主にHTMLやXHTMLなどのハイパーテキストの記述言語が利用されます。
World Wide Webは、急速に普及をし現代では当たり前のものになってきました。その大成功の理由の一つにはシンプルさがあります。
World Wide WebにはHTTPプロトコルが利用されており、それらはシンプルに定義されています。
私たちに出来ること
それでは私たちには何が出来るのでしょうか？WCAGで勧告されているものは、フロントエンドエンジニアやデザイナーが実装するものだと思われがちです。しかしそれ以外にもなにか私たちに出来ることがあるのではないでしょうか？
私は一番は"自分ごと化"することが大事なのではないかと思います。
とはいえ、サーバーサイドエンジニアに何か出来ることがないかという指針についてはいくつか挙げていきたいと思います。 後述することはあくまで指針であり、これらのことに解答はありません。
適切なHTTPメソッドを選択する
GET？POST？PUT？DELETE？
これらは実装によっては、どんなことでも可能です。実装はサーバーサイドエンジニアに委ねられています。HTTPメソッドが適切でなければどうでしょうか？もしGETをしたつもりなのにデータが消えてしまう。
適切なHTTPステータスコードを返却
401？403？それとも500？503？これらは似ているものも多くときに適切なものを間違ってしまうこともあります。極端な例でいうと、200を返しているのに実際にはページのリソースがなかったら？エラーを吐いていたら？
アクセスの速度を保証
レガシーなサービスに限らず、Webはアクセシブルという以上それなりに速さも気にしなければなりません。なんらかの条件に限らず普段からWebページを開くのが遅すぎたら、そのページからすぐに離脱していませんか？Webページが見られることなく閉じられるというのは私はとても悲しいです。
フロントエンドを意識したDB設計
Webサービス内で統一した用語を用いていますか？それらはマスターデータとして管理されていますか？全てが全て管理される必要があるというわけではありません。しかしサービス内での専門用語等に表記ゆれがあると、ユーザーは迷子になってしまいます。Webという広い世界で迷子になってしまったらあなたはどうしますか？
はたまたフロントエンドエンジニアは、こんなのサーバー側でデータ持ってよ…と思っているかもしれません。例えば画像の代替テキスト（alt属性）です。全ての画像にベタ書きで書いていくのは嫌ですよね？設計の初期段階で、タイトルや画像名以外に代替テキストが必要であることが分かっていれば、そのカラムを私たちが持っておくことだってできます。
and more...
これら以外にも、私たちが出来ることは無限にあります。それらは常日頃からやっていることかもしれません。普段の中でちょっとだけ気にすることで、もっともっと自分たちが開発しているサービスを使ってくれる人が増えるかもしれません。
最後に
本記事で述べたことはきっと、私よりも他のサーバーサイドエンジニアのほうが詳しいこともあるでしょう。
World Wide Webを発明したTim Berners-Leeはこんなことを述べています。
The power of the Web is in its universality.Access by everyone regardless of disability is an essential aspect. （Webの力はその普遍性にあります。障害の有無にかかわらず誰もがアクセスできるというのが Webの本質的な側面なのです。）
これこそが、Webの本来の姿です。ときにこれを思い出しながら私たちはWebサービス屋さんとして、日々Webサービスを提供し続けて行きたいと思います。
PHPerKaigi2020 資料
本記事の内容について、2020/02/11にPHPerKaigi 2020にて発表を行いました。下記に公式サイトと、発表時の資料を掲載します。
