「ポスト見てきて」を忘れる問題を解消する
夜、今日も近所のコンビニへ行く。 在宅勤務だと歩く機会は少ない。平均歩数はいよいよ5,000歩に近付いてきた。
ルーチンとして軽い散歩を組み込むと、ポストのチェック業務は自然と私の担当になる。 朝と夜、機械的に確認して空っぽにする。
同居人はよくメルカリで買い物をする。 メルカリでは、品物を受け取った側が評価をしてはじめて入金される仕組みらしい。 送った時点で入金されると問題になるので、よく考えてみればそりゃそうである。
一方この仕組みから、「速く評価することが高く評価される」という現象を引き起こしている。 何日も入金を止める人は、低評価されてしまう忙しない世界なのだ。
19時に注文していた品物が届くと、それを朝ポストから取り出して評価したのではもう遅い。 いや、遅くはないが、速くもない。そんなわけで、「忘れずポストを見てきてね」と今日もまたオーダーを受ける。
「ラジャー！」と言ってコンビニへ行くものの、カップ麺の新商品をチェックしたり、一服ついたり、えなこを眺めていたりすると、帰り道にはすっかりポストのことを忘れている。 「忘れました」と報告すると、そりゃそんなことは普通の人だと起こり得ないので、「いいよ」と言いつつまぁ変な空気が流れる。
これは同居人も辛いし、自分としても辛い。根本的解決がなされず、同じ過ちを繰り返すのは、精神衛生上あまりよろしくないのだ。
タイマーは何度も試した。コンビニへ行く時間を測り、ちょうど帰り道でタイマーが鳴るようセットする。 これは上手くいく時といかない時がある。 コンビニで何か面白いものを見つけてしまうと、時間はただただ過ぎ去り、タイマーはスヌーズ化され、スヌーズ化されたタイマーは通知バーへ常駐化する。 こうなるともう家まで見られることはない。
ただ念じるというのも何度も試した。 家を出てから帰るまで、ただひたすらに「ポストポスト」とぶつぶつ言う。
これも上手く行くときは上手くいく。ただ、レジで戸惑ったり、弁当選びに頭を使ったりするとアウトで、ポストは遥か思考の彼方に放り出されてしまう。
そんな紆余曲折も経て、今日ようやく根本的解決策に辿り着くことができた。 「帰り際にポストを見る」ではなく、行きの時点で確認してしまえばよかったのだ。
とても簡単なことであった。 要は小さな手提げカバンを持ち、「ポストポスト」と念じてエレベーターを降り、真っ先にポストを開けて荷物をカバンに放り込んでしまえば良い。
おそらくこの方法は上手くいくだろう。この見込みだけでも、幾分か気持ちが楽である。
まず下に降りるまでに課題を忘れてしまうことは何とか防げる。「ポストを見るまではスマホは見ない」など、最低限のルールを定めてしまえば良い。 コンビニへ行くだけであればカバンを置く機会もないため、置き忘れるようなリスクも無い。
ここから得られる教訓は、「めんどくさいことは真っ先にやれ」である。片付けてしまえば、管理するも何もない。やってしまえば全てそこで解決するのだ。
僕は一体何を書いているのだろう。 でも、小さいようで大きな悩みが一つ解決したことは確かである。
DrupalCamp DEN 2023 Iwakuni 振り返り
2023/1/21, DrupalCamp DEN 2023 Iwakuni に参加してきました。 ハイブリッド開催イベントでしたが、私は懇親会含め現地での参加です。 自分が見たセッションを中心に振り返ります。
DrupalCamp DEN 2023 Iwakuni とは
Drupal DEN 自体の設立経緯は下記あたりをご参照ください。
https://groups.drupal.org/den-japan
DrupalCamp DEN 2023 Iwakuni のイベントページです。 DrupalCamp DEN 2023 Iwakuni
DrupalCamp DEN としては4度目、私は2度目の DrupalCamp DEN 2019 名古屋からの参加です。
名古屋のイベントページもまだありました。
https://drupal-camp2019.den-japan.org/
参照
私がのんびりブログを書いている間にいろいろコンテンツが出てきたので合わせてどうぞ。
セッション動画・スライド
公式 drupal-camp2023.den-japan.org
振り返り記事
DrupalCamp DEN 2023 Iwakuni の参加ブログを書きました。https://t.co/UuwGgDguzU#DrupalCampDEN
— kazunoko (@kazunoko_m) 2023年1月24日
セッション振り返り
A, B, C と3つトラックがあったので、聞きたいのに聞けないセッションもたくさんありました。 他の皆さんの感想もお伺いしたいところです。
挨拶
まずはじめに岩国市長からのご挨拶がありました。
市長が登壇されるケースはエンジニアイベントでもなかなか見ないのではと思います。
山口県はご飯もお酒も美味しく、気候も過ごしやすく、昨今の地方でのサテライトオフィス設立やUターン需要などととてもマッチしているなという印象を受けました。
今回訪れた岩国市も、厳島神社なども近く、ある程度リモートでの仕事が成立してきた今、田舎と都市部の中間として良いところだと思います。
Dries ビデオメッセージ
Drupal の話題に入る前に、Drupal の創始者である Dries のビデオメッセージです。
はじめて Drupal イベントを訪れた方や、なんとなく技術的に気になって触ってみたという方には新鮮なテーマだったと思います。
改めてはじめは数十人という規模から世界へ広がっていった流れを見て、日本も今それを数年遅れてやっているのかなぁという感じを受けました。
スペシャルセッション
今回のスペシャルセッションは OIST での Drupal 9 移行の裏話でした。
特に日本語のソートにおける複雑性の話が印象的でした。
最後に「神は細部に宿る」という話がありましたが、これは本当に日々感じるところ。 細かいところにこだわって作っていると「大変やな〜」と思うこともあるのですが、そういう取り組みが間違っていなかったと勇気付けられる締めくくりでした。
A-1, 国際農研Webサイトの構築と運用
はじめはAトラックから。
特に 2020 Osaka からですかね。技術者だけでなく顧客側視点での登壇が増えてきて、とても良い動きだなと思っています。
懇親会でも少しお話させていただいたのですが、図書館学なんかを専門とする方のようです。 「情報を丁寧に分類する」という点が図書館学と Drupal 構築で共通しているのかな？という話がとても興味深い。
実際のサイトはこちら。
ホーム | 国立研究開発法人 国際農林水産業研究センター | JIRCAS
作り手の顔というか、こだわりが随所に見える良いサイトです。
一方でやっぱり発注側が熱量を持って取り組めないとプロジェクトって盛り上がってこないので、開発者だけでなくいろんな方向から「良いものを作ろう」と考えて実行できる人が必要なんだなーと感じたセッションでした。 あとプレゼンって絵じゃなくて中身ですね。平易な言葉と正しい構成。これが一番分かりやすし伝わるというお手本。
トラックA-1 「国際学会サイトの事例紹介」
— Gengo Kikuchi (@gengo_k) 2023年1月21日
とても分かりやすいプレゼンテーションでした。
運用担当者の教科書とも言える内容。ベンダーとの協業関係がとても良く取れている事例。
Drupal の特性も活かしたとても良いサイト。https://t.co/UEUo39hKMu#Drupal #DrupalCamp #DrupalCampDEN
B-2, DrupalとFastly！～究極の柔軟性と高速性を手に入れよう～
Fastly と業務提携もされているインフラレッド代表の登壇。
Drupal と一緒に Fastly が使われている事例は結構あると思うのですが、DrupalCamp では意外と今まで出たことの無いであろうテーマ。
技術的な面は分からない部分も多いですが、個人的には Fastly は全体の構成が分かりやすく、UI も綺麗で、Drupal とセットで使うのにもちょうど良いケースが多いんじゃないかなーと思ってる。
調べてみると drupal.org も Fastly を採用しているようで、英語だとベストプラクティスなんかもたくさん出てきそうな気がします。
Drupal Association : ケーススタディ | Fastly
「Drupal 側でやると大変な部分を上手く Fastly で吸収する」というのはとても理にかなってるので、いろいろ試していきたいですね〜
トラック B-2「Drupal と Fastly」
— Gengo Kikuchi (@gengo_k) 2023年1月21日
Fastly 良いですよね〜
知らないことがたくさんあり勉強になる。#Drupal #DrupalCamp #DrupalCampDEN
A-3, Drupalを始めるあなたへ、豊田支部発刊書籍の紹介
Drupal Meetup 豊田から Drupal 本の紹介。
ここ数年本当に頑張ってくださっている方々のおかげで、日本語の Drupal 本が増えてきています。
目次を振り返りながら、どんな内容が書かれているかを振り返るセッションでした。
複数人執筆の良さが出ていて、トピックが多岐に渡るのでとりあえず手に取って気になるところから読んでいくと面白いと思います。
トラック A-3 「豊田支部発刊書籍の紹介」
— Gengo Kikuchi (@gengo_k) 2023年1月21日
1年前はよく分からなかったところで、今読めば入ってきそうな内容がたくさんあった。帰ったら読み返してみよう。
特に settings.php 探訪や Feeds モジュール、Webform あたり。
最後には次回作の告知も。#Drupal #DrupalCamp #DrupalCampDEN
B-4, エンジニア向けノードのアクセス制限方法まとめ
今回の Meetup を振り返る時、まずはじめに思い出すのはこのセッションでしょう。 「そこそこ良い」は努力して作れても、「めっちゃ良い」は才能なんやなー、自分にはできんなーと思いました。羨ましい。
これは必ず資料ではなく動画で閲覧ください。プレゼンという名のエンタメです。
2019 の時もそうでしたが知見溢れる内容で、Drupal でアクセス制限がどういう仕組みになっているかをまず整理し、デフォルトの機能でできること、コントリビュートモジュールでできることとそのパターン、最後にカスタムする場合、というように徐々に高度なテクニックに移っていきます。 この構成が完璧すぎですね。Drupal の仕組みを踏まえると、確かにこの順序で説明しなければならない。
終盤の強さ比較なんかは努力の賜物で、スペシャルセッションでもあった「神は細部に宿る」という話をそのまま体現した素晴らしい発表だった。
トラック B-4 「エンジニア向けノードのアクセス制限方法まとめ」
— Gengo Kikuchi (@gengo_k) 2023年1月21日
なんともおちゃらけたプレゼンだったが、内容は至極真っ当。レベルの高い内容だった。
ただそれ以上に腹が痛い。#Drupal #DrupalCamp #DrupalCampDEN
B-5, Drupal × Tailwind CSS
これは自分も関わったプロジェクトで、振り返りも兼ねて拝聴。 Tailwind CSS はそのコンセプトはとても良いし、デザインシステムなんかとも実は親和性が高そうと思っているのだけれど、Drupal と組み合わせるにはやっぱりそれなりに超えなきゃいけない壁があるよね、みたいなことを日本語ではじめてちゃんと説明した機会なんじゃないかな。
実際のソースコードもあがっているのでお試しください。
Drupal で TailwindCSS がすぐに使えるように設定しました。ほぼウミの Github リポジトリの内容で恐縮ですが、それに Tailwind を使用できるように変更を加えました。是非試してください。動かない箇所があればコメント等いただけると幸いです。https://t.co/CU27EZgubw
— toshitaka (@toshita50806196) 2023年1月22日
日本ではそこまで流行っていないようですが、海外では凄い伸びているという話も聞くので、もう一歩洞察を深めていく必要があるのかもしれない。
やや話がそれますが、今回の知見も踏まえると Token CSS も面白いかもな〜と少し思っている。 Token CSS
トラック B-5「Drupal × Tailwind CSS」
— Gengo Kikuchi (@gengo_k) 2023年1月21日
この掛け算の議論自体が日本語では全然出ていないので貴重な内容。
少しやってみた感触としては相性良くないなーですが、この結論を超える知見に期待。個人的には Tailwind CSS の思想やシステムは結構好き。#Drupal #DrupalCamp #DrupalCampDEN
A-6, Drupalモジュール紹介 100本ノック
あっという間に最後のセッションです。
公式のサムネを見れば分かりますが、はじめはフリップ芸かと思いました。それくらいにテンポ良く淡々とモジュールを紹介していく。
でも途中から気付くんですよね。これだけ短い言葉でそのモジュールを説明できるって、逆にすごくね？と。
端的に説明するということは、そのモジュールがどこまでを担っていて、他のモジュールとどう噛み合わさって何を提供しているのかということが肌感で分かってないといけないんですよね。
特にコアモジュールの一つ一つまではあまり意識できていなかったので、とても参考になった。
だいたいのサイトはここに出てきた100本のモジュールがあればいけるのでは？と思わせる、Drupal へチャレンジする様々な方へのとても良い導入になったと思います。
トラック B-6「Drupal モジュール100本ノック」
— Gengo Kikuchi (@gengo_k) 2023年1月21日
最後のセッション。コア〜コントリビュート、開発者向けまでカバーされていてとても良い選定でした。
8割くらい分かったのが結構（かなり）嬉しい。
1位のモジュールが何とも「らしい」回答で素敵でした。#Drupal #DrupalCamp #DrupalCampDEN
総括
記憶にある限りであれこれ書きました。皆さん本当に素敵な発表ばかりでした。 見れていないセッションはこれから少しずつ見て Twitter で呟いたりしたいと思います。
何より画面や名前だけ知っていた方と直接お会いできてとても楽しかったです。
いや本当に運営の皆さまお疲れさまでした。
— Gengo Kikuchi (@gengo_k) 2023年1月21日
DrupalCamp DEN は文字通り私の人生を変えたイベントであり、今回また大きなバイブスを貰いました。
それぞれの場所で頑張りましょう🙌#Drupal #DrupalCamp #DrupalCampDEN
そんな感じ。また会いましょう！
他者が書いたコードが理解できない時に聞くか読み解くかの判断基準
「他者が書いたコードを読んで理解できない時に聞くか自分で読み解くかの判断基準」が書かれていたのでシェア。
処理なら頑張る / 意図なら聞く
分からない部分が処理についてなら、自分で読み込むべき。分からないメソッドはググり、呼び出される関数を追い、理解に努めるべき。
対して処理は理解できるが意図が理解できない時は、素直に聞くべき。 意図を深く考えて推測してもそんなに意味がない。どちらかというとエンジニアリング力よりは単に要件が頭に入っているか等の背景に問題があることが多い。
意見・補足
ここからは私の意見や補足。
沼にハマりそうだったら頼ろう
もちろん処理であっても、沼にハマって全体の工程に影響を及ぼすなら相談すれば良い派。 基本的には働いた時間に対して報酬が発生し続けている訳なので、無限に頑張っていただくとそれはそれで困るという別の問題もある。すいません。
エンジニアとしてというか、仕事に対するスタンスとして、自分でやり遂げたいということ自体は悪いことではないんですけどね。
基準を決めておけば仕事が速くなる
スタンスを
- 処理の部分は頑張って読み解きます
- 意図の部分は分からなかったら素直に聞きます
と決めておけば病むことも減るし、判断が速くなる。 判断が速くなると、仕事はどんどん速くなる。
深い沼にハマり続けるよりは、浅い沼に何回も潜って時間の密度を上げることによりフォーカスすべきかなと。
自分の責務は何か
ちょっと脱線しますが、良いエンジニアは処理は自分でしっかり練るけど、そもそもの要件が分からなかったらソッコーで聞いてくる。
これはとてもありがたくて、自分の価値提供ポイントを理解しているとも言い換えられる。
基本的には割いた時間に対して報酬が支払われている。であれば割ける時間で最も自分が価値提供できるようにバランスを取るべきでしょう。
理解しようとするスタンスが大事
ここでこの本が言いたいのはスタンスの話である。 何をしているか分からないコードをそれこそコピペすることは、それこそアラビア語を写生しているのと何ら変わらない。
思考をくぐらないプロセスは、その場で上手く問題が解決されても、それ以上は何も生み出さない。
日々分からんことだらけですが、理解しようとするスタンスは常に持って、一歩ずつでも進んでいきたいですね。おっさんになっても。
そんな感じ。
Literature Notes は Literature 自体のページとは切り分けるべきではないか
最近は読書メモを Obsidian で取っている。
メモといってもたいそうなものではなく、引っかかった言葉や考え方を自分の言葉で要約して書き記すというもの。
これは Zettelkasten でいうところの、Literature Notes に相当する（と思っている）。
この Literature Notes の取り方にはいくつか方法がある。
まずは本一冊に対し一つのページを用意し、ここにすべて書いていくという方法。 おそらくこちらの方が多い。だいたいの解説記事ではこのスタイルが取られている。
対して私は本一冊のページにはあくまでメタ情報を書き、読書メモは独立したページとして書くスタイルを取っている。
こちらの方が Literature Notes 本来のあり方に近い気がする。
要は本からエッセンスなり知見を繰り返し使える状態で抜き出すというのが Zettelkasten の考え方なので、こうしないと意味が無いのではとすら思っている。 京大カード式などもそうだろう。
私の場合は本のページにそのままメモを書いても、なかなか見返さない。見返さないというか、見返しても粒度が大きすぎてそこから得られたものは何かと問われると速やかに答えられない。
それよりは本の中から何かを抜き取ってバラバラにし、それを自分の中で再構成していくという作業の方が大事だしやりたい、という考え方である。
読書メモを切り分ける形だと、その本が参照されている読書メモのタイトルを見ていけば、そこから得られた知見はすぐに引き出せる。 特に Obsidian だと参照されているページのリストがあって、これがそのまま本の要約というか自分が気になった点のリストになる。
なんとなく言葉だけだとイメージが付きづらいので、スクショ。
この一つ一つが読書メモで、どの本から得られた知見かはすべてリンクを貼ってある。
ちょっとめんどくさいけど、この読書メモが一つでも取れたらその本から何かを得られたことが可視化できるし、このメモを取ろうと思って読むと読み方も変わってくるので今のところは結構気に入っています。
そんな感じ。皆さんどんな風にしているのだろう？
ツェッテルカステンについてはこの本も読むと理解しやすいです。（というかほぼこれしかない）
Obsidian 本も少しずつは出てきてます。
読書についてアドバイスすると結局「たくさん読め」になる理由
10年くらい、時には間も空きつつだが本を読んできた。 世の中には「読みたいのに続かない」とか、本を読みたいけど自分が思ったほどは読めていない人が常に一定数いるように思う。 そういう人へ一言でアドバイスを送るなら、結局「たくさん読め」ということになる。
読書習慣がなんかしっくりこない時期もありつつ、試行錯誤した結果、結局ここに帰着する理由を言語化しておく。
多く読むことは目的ではない
まずはじめに、より多くの本を読むこと自体は目的ではない。 多読は結果である。
そういう意味では、1年間で読んだ冊数とか、毎日何時間読むと決めるとかかはさして重要ではない。
「たくさん読め」のその過程こそが重要である。
脳は没頭を求めている
高いお金を払ってセミナーに参加して何を得られないことがあるように、お金と時間をかけて読了しても何も残らない読書はある。
対して、「はじめに」や一章しか読んでいなかったり、15分くらいパラパラと読み切った本が大きな影響を与えることもある。
これは集中の度合いによって違いが生まれる。 没頭と言い換えることもできる。没頭の効果は下記のような本が伝えているところで、一つの目の前のことにのめり込むことは、明らかに脳にとって心地が良い。
没頭した読書からは、必ず何かが得られる。 逆に没頭できない読書は、何も得られないのでしなくて良い。没頭するための必要条件が何か欠けていると考え、別の入門書を読んだり必要な周辺知識に思いを巡らせると良い。
没頭し続けるには適度に切り替える
一方でこの没頭状態を続けるには、適度に切り替えを行う必要がある。
単純に学校のカリキュラムが６時間すべて同じ教科であったら飽きるのと同じである。
人は同じことをし続けると飽きる。しかし切り替えを細かく頻繁に行いすぎると飽きる。不便な脳だが、どうやらそういうものらしい。
飽きたら違う本を読む → 多読になる
読書も同じで、一冊の本をすべて読み切ってから次に行く必要はない。 常に読みかけの本を作っておき、飽きたら切り替えることで没頭状態を継続できる。
そうしていると逆に残り2割とかになると読み切りたい意識も働いてくる。そこでまたエンジンがかかるので、気付いたら結構読んでるなという状態になる。 この状態が多読である。
切り替えられる環境を用意しておく
飽きた時に次読む本がある状態を維持し続けることが大切で、これにはさまざまな工夫がいる。
簡単なのは毎週図書館に通うこと。ただこれは図書館が近くに無いといけない。 読み切っていない本でも、熱量が失われた本は一旦返す。
そうやって手元にある本をずっと入れ替え続けていくと、常に読みたい本だけが手元に残る。 目安としては毎週5冊は入れ替えるようにしている。
ブックタワーもおすすめである。 注意点はもう読まないと決めた本は取り除くこと。タワー内の本が直近読む本のみで構成されていないと、放置している自分に罪悪感が生まれてしまう。
Kindle も併用すると良い。マンガや小説のような片方向に流れる本は Kindle でも全然読める。 私の場合はこれをトイレ専用端末とした。
多読のすすめ
思うに、何か分野を極めるならその分野の本はすべて読むつもりでいなければならない。 ダメな本も含めてすべて。そうしないと今どこまで分かっていて、どこからが新しい要素なのかも見えてこない。
今自分にとってちょうど良い本を選んで没頭し続けないと、時間はいくらあっても足りない。でもそれを見極めるためにはダメ本も手に取って潰していく必要がある。
スイッチングして没頭状態を維持し、今じゃない本はどんどん後回しにしていく。完全に理想的な形ではないけど、こうやって高速サイクルを回してだんだんと読書精度みたいなものを上げていけば良いのではないかなーと。
そんな感じ。
アクイア認定デベロッパー - Drupal 9 を取得した
取得しました。
Drupal 9 のアクイア認定デベロッパー試験合格。これは嬉しい。
— Gengo Kikuchi | Drupal でWebサイトを作る人 (@gengo_k) 2022年9月30日
ギリギリも良いとこだったので精進します。
広告代理店から Drupal 開発会社へ転職して8ヶ月くらい。1年目で取ると宣言していたので、素直に嬉しいです。
デベロッパー試験の位置付け
デベロッパー試験はサイトビルダー試験の上位に位置付けられる試験で、Drupal 開発者の登竜門的な内容です。 2回目の受験ですが、サイトビルダーと大きく違うのは「管理画面以外の Drupal を理解しているか」を問われる点だと感じました。
管理画面から見た Drupal とその裏側
サイトビルダー試験では、Drupal の管理画面を操作して、コンテンツタイプの作成やビューの作成などのサイトビルディングスキルを問われます。 もちろんこれも重要な要素ですが、実際には管理画面のみで作成できる Drupal サイトは多くありません。
というかビジネス利用においてはコードの構成管理はマストであり、その点でまず Git の知識が必要となります。 デベロッパー試験は、この Git を用いた Drupal サイトの構成管理を含めて、コードレベルで Drupal 開発に携わった経験が求められます。
熟練した開発者にはそれほど難しい内容ではないですが、それでもコードを書いたことが無ければまず受からないとは思って良いでしょう。
実際にコードを書く経験
恵まれたことに、1年目から少しずつではありますがコードを書く機会を得られました。 大型プロジェクトで簡単な hook を書くところからはじめ、社内プロジェクトで Twig テンプレートを書く機会がありました。
バックエンド・フロントエンド双方のスキルを簡単なところから少しずつ始められたのは良いスタートだったと思います。
これは Drupal 開発をキャリアの一つとして選択する上でもおすすめしたいポイントで、初心者が少しずつステップアップしていける開発パターンが多く用意されています。
オブジェクト指向とか、基盤となる知識
その他、オブジェクト指向への理解や、CSS / JS の基礎知識も求められます。
この点は IPA 関連資格でコツコツ勉強してきたり、今完全に分からなくても書籍を眺めたり、なんとか理解しようと努めてきた蓄積が意外と活きるなあと感じています。
もちろん分かると出来るの間には大きな開きがあるわけですが、熟練したエンジニアでも完璧は無いので、自分が関わる範囲の知識を少しずつ吸収していけばそれで良いんじゃないかと思います。
これから
今回デベロッパー資格を取ったは良いですが、まだまだ氷山の一角しか理解していません。まずは Drupal 10 で同等の資格をサクッと取れるくらいにはスキルを高めていきたいところ。
一方で PM/ディレクター を主戦場としながらエンジニアリングスキルを高めていくのは簡単ではない。単純に時間が全然足りないんですね。
これからどこを伸ばしていくかというのは周囲にどんな人材がいるかにも依存するので、緩く考えて頑張っていきます。
やっぱりちゃんと PM できる人が少ないなという印象なので、あくまで軸足はそちらに置きつつ、そのうえで自分でもできることの幅を増やしていきたい。
その方が面白いからね、といった感じです。
エンジニア一年目に読んだ本（上期）
転職して半年が経った。
転職して半年経ったので Facebook に近況報告を書いた。まだまだできることは少ないけど、半年という期間を考えたらまあ良しとしよう。
— Gengo Kikuchi | Drupal 開発者 (@gengo_k) 2022年8月1日
今回の転職と同時に「エンジニア」という職種に足を踏み入れた。社歴＝エンジニア歴ということになる。
一年目の振り返りとして、入社して１年経った頃に読んだ本をまとめようと思っていた。が、せっかくなので比較できるよう一度ここで区切っておく。
読んだ本
期間は 2022年2月 〜 2022年7月。
ちょうど今読んでいる『理系読書――読書効率を最大化する超合理化サイクル』という本に「読了の定義は本から有益な情報を抽出できた時」と記載があった。
ここでも、はじめから最後まで完全に読んだ本だけでなく、役に立ったと思えるものは含めるようにした。 逆に業務に直接的に関係ない一般的なビジネス書は含めていない。
1冊ですべて身につくHTML & CSSとWebデザイン入門講座
HTML と CSS はある程度ドットインストールで勉強して、この本を手に取った。MDN も充実しているが、やはりとりあえず一冊は本を手に取るべきだろうと。
私の場合 CMS 専門のため、普通に HTML / CSS / JS で Webページを構築した経験が無い。 この点をある程度まとまった知識で解消できればと思ったが、やや基本的なレベルに留まり、これだけで現場で使えるという類のものでは無い。
とはいえ一冊やれば精神的に次に進みやすくなるので、「まず一冊」戦法はおすすめである。 よくある「入門編症候群」に陥らなくて済む。
WEB+DB PRESS Vol.109
CDN についてまとまった知識を提供してくれる貴重な書。調べてみると分かるが、少し具体的なトピックになる専門書が存在しないケースは多い。
『WEB+DB PRESS』は、そういったトピックの取っ掛かりとして良い。都市圏ならだいたい図書館で見つかるだろう。
これで CDN の超基本を押さえ、Fastly の管理画面が怖くなくなった。あくまで基本レベルなので、突き詰めたければネットワーク周りをちゃんと理解しなきゃなーといったところ。
Linux 基礎から順にやっていけば、もう少し分かるようになってくるのかな？
「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか
遥か昔にチラ見した本を再度手に取った。
基本的な MVCモデル とか、Web アプリケーションの仕組みを理解できる。JSP あたりをベースに書かれており、現在の Web ではあまり目にしないコードがメインになっている点は注意。
後半の方はやや難しくなってきて断念。また必要に応じて参照したい。
独習Git
なんといってもこれが一番大きな収穫かな。Git が普通に使えるようになった。
Git の概念はなんとなく知っていたが、まったく使ったことがなかった。
これもドットインストールでざっくり勉強して、各種 Webチュートリアル を見てみたりもしたけど、結局一冊書籍を通すのが最も良かった。
はじめは rebase に苦労したが、今はそんなに間違えることなくできるようになった。reset コマンドはすぐ忘れてしまうので、最近は VSCode の GUI で取り消しちゃうことが多いのは内緒。
Webディレクションの新・標準ルール 改訂第2版 現場の効率をアップする最新ワークフローとマネジメント
広告代理店のディレクターは、Webディレクター というよりはプロデューサーやプロジェクトマネージャー的な要素が強い。
そんなわけもあり、Web制作 のディレクターに必要なスキルセットやマインドを改めて確認。
ある程度基本的な進行管理やコミュニケーションができるようになってきたら、この本を読むと少しレベル上げできると思う。続編で開発に特化した書籍も出ているので、そちらも参照したい。
チケット駆動開発
あらゆる実装に対して、まずチケットを書いてからはじめましょうという内容。何とか駆動開発の中でもややマイナーだが、すぐに活かせるかなと思い読んでみた。
基本的な内容はほんとにこれだけなのだが、Redmine を駆使してリポジトリとチケットを同期させる方法なども書かれている。
この辺はややロマンかな。現代はツールの進化もすこぶる速いので、ガチガチに開発フローを作り込むのにはやや反対である。一つのツールが使えなくなると回らない開発現場はよろしくない。
ただ、「いきなり実装に入るな」はまあ正論だと思うので、これは意識したいところ。
結局レビューする際にもそのコードが書かれた経緯が無いとレビューしづらいし、ざっとでも書き出しておかないとそもそもの作り方からずれが生じてやり直しになるケースが多いな〜というのが最近の感覚。
カンバン仕事術
『チケット駆動開発』からの流れ。カンバンって当たり前に使ってるじゃないですか。でも活かすためには原理原則があるんだよということを教えてくれる。
カンバンでいう列はプロセスになっていて、ここにこだわることは非常に大事。業務毎に違うプロセスになるはずで、このプロセス設計が雑だとあまり上手くいかない。
To Do / Doing / Done の3つでも良いけど、実際にはもっと細かいステップがあるはずで、それを可視化してはじめてカンバンの意味が出てくる。
とりあえずはじめてみて、ボトムアップ的にプロセス改善ができるところもカンバンの強みである。
あとは「WIP の制限」の概念が非常に重要で、要は取っかかった仕事を終わらせることを優先して、あれこれ手を出してがんじがらめになるなということ。
これは普段仕事をする上でもそのまま活きてくる。アイドルタイムが出ない程度には並行して着手して良いが、自分持ちのタスクが積み上がってしまう時は気を付けよう。
WIP の制限を超えているアラートなので、すぐ終わりそうなタスクからどんどん片付けるべし。
情報処理教科書 出るとこだけ! 情報セキュリティマネジメント テキスト&問題集 2022年版
新人エンジニアといえば IPA でしょということで、情セキを取得した。
これは完全に逃げ。基本情報は結構勉強範囲多くてしんどいから、先に下位資格を取って少しでも楽に取れるような準備をしようと。
結果的にそんなに有効な資格では無いが、セキュリティの基礎が身に付いたから良かったかな。
人生長いので、毎年一個ずつくらい進めればそれで良いんじゃね？くらいの緩い気持ちで取り組んでいる。
次は基本情報。来年から受験形式が変わり、どうも簡単になりそうな予感がするので来年以降に受けようかなーと思っている。
基本情報の教科書で勉強するのも良いけど、各トピックそれぞれ別の方法でも並行して勉強を進めていくと、試験だけじゃなく活きた知識として身に付く感じがするよ。
WEB+DB PRESS Vol.123
最近話題の HTTP/3 についてお勉強。Web 上にドキュメントはたくさんあるけど、マイペースに読める書籍の方がやっぱり好きかな。
ついでに WAF も特集があって読めた。
振り返り
日々の学習に書籍を積極的に取り入れだしたのが遅かったので、一年目としては読書量はやや少ない印象。
この反省を活かし、最近は月に2-3冊くらいは購入して読み進めています。Kindle より紙。個人差あるけど、これも経験則で学んだこと。
残り半年、大きな目標はアクイア認定デベロッパー試験に合格すること。なんか正式に「デベロッパー」と名乗りやすくなるじゃないですか。
もちろん試験は通過点で、実際に実装できるかどうかが焦点であることは間違いない。
その先はまだよく分かっていない。とりあえずフロントエンド・バックエンド双方一人前レベルを目指しつつ、今は「用意されたものを使う」という感じのインフラや開発ツール周りを自分でも触れるようになっていきたいな〜と思っている。
効率化とか組織開発とか考える PM 的職種とも、相性良いのかなーと。
エンジニア一年生、半年ではまだ何とも言えないけど、好み的にはフロントエンド < バックエンド。両方一人前にできるようになった前提で、インフラできるようになりたいな〜というのが所感。
— Gengo Kikuchi | Drupal 開発者 (@gengo_k) 2022年8月1日
ミドルウェアとかクラウドとかサーバー監視とかCIとか。分からんだけにちゃんと分かりたい。
そんな感じ。
