3大今年買ってよかったもの

今週のお題「今年買ってよかったもの」

よかったもの

Inateck ラップトップスリーブケース

以前も紹介したが今年のベストバイをあげるならこれかなという気がしている。 使いやすく、また使い心地も良い。 不満点もいまのところないため、ほぼ満点に近い。 ポーチもついているのだがそれも結構収納力があるので周辺機器くらいならだいたい入る。 不満点の少なさ、満足度の高さからまだ1ヶ月ほどあるがベストバイといいきって問題ないと思う。

Bianchi リュックサック/ディパック NBTC50

スリーブケースとどちらにするか一瞬悩んだが結局スリーブケースをベストバイにあげてしまった。 このディパック自体は決して悪くない…悪くないのだけど2点だけ小さな不満点があるので順位を下げてしまった、それ以外は概ね満足いく品だと思っている。

不満点:

  • タブレット用スリーブがiPad Pro 12.9インチだとギリギリ、出し入れのときに引っかかることがあって手間。
  • 定期入れなどをすぐに取り出しにくい、ポケットは全体的に見た目以上に大容量で満足している。やはり一手間が惜しい。

今までは通勤用のディパックにNORTH FACEのディパックを使用していたのだがタブレットと書籍だけもってふらりと読書にいくには幾分大掛かりだったこともあり、もう1サイズ小さいものを探していた。 持ち物としては弁当、水筒(500ml)、タブレットに書籍。あと通勤後に汗をかくため着替えを詰め込めればOKということでこのサイズがベストになった。

このディパックで満足度が高い点としてショルダー部分がNORTH FACEのものに比べてずり落ちにくい点がある。 NORTH FACEのものはチェストストラップがあるが使うと窮屈、使わないとずれ落ちるという微妙さがあった、その点が結構ストレスになりがちだったので解消されてQOLが上がった気がする。 値段もNORTH FACEのものより安かったし、特にぼくが気にしていたディパック自体が自立する(会社で地面に置くため)という点でも安定しているので不満点がなければもしかするとベストバイにしていたかもしれない。

APPLE iPad Pro 12.9インチ 2017年モデル用【書き味向上】液晶保護フィルム ペーパーライクなペン滑り!

商品名がよくわからないけど3位がこれ。 いままでタブレットにシートを貼るなんてアホらしい…と思っていたのだけど少し考えを変えた。 そういう意味でノミネートしている。

これは使い方の問題だと思うのだがぼくはよく読んだ本の感想をiPad ProのメモアプリにApple Pencilで書き込んでいる。 ペン先をタブレットに当てたときの感触が硬い、当たり前だしそれが普通だと思っていたのだけどこのシートを貼ってから感想が変わった。

シート後にタブレットでメモを取ると書き味が滑らかなのだ。 以前は硬い、それこそ硝子にペンを当てているという感触だったのが紙とまではいわないがかなり荒い和紙に文字を書いているような感覚に近いものを感じるようになった。 それまであまり意識していなかったが、このことで硝子板にペンを当てるようにメモを書いていたことがそこそこストレスだったのだと自覚するに至った。

たまたまだが「書き味向上」という文字につられて購入したが割りと正解だった、とはいえ他のシートを試していないのですごくいいとも言い難いのだが。 また他のシートに比べて若干高めであるが個人的にはApple Pencilを使うなら買って損しないんじゃないかなと思う。

まとめ:

電子機器そのものではなく、それを運搬するものや保護するものがベストバイだったのは改めて考えてみてもちょっと意外だった。 ワーストバイをあげるならApple Pencilになる、充電方式がクソいのとバッテリー容量が単体で確認できないのは大きな設計上の問題だと思う。

2割に集中して結果を出す習慣術

結論:

なにはともあれ結論から述べる。

この本は愚にもつかない内容だし、全体的に目新しさも具体的な解決の話もほぼ皆無だ。その辺にある自己啓発本に書かれているものと然程変わり映えしないものだと思う。

だけれども疲れているときや精神がネガティブなとき、ダウナーな思考が続いているときに読み返すと「これは出来ている」「これは出来ていないから出来るようにするには○○しよう」という一種の踏み絵的効果がありそうだなと思った。

全てを満たす必要はないが「自分が出来ていない重要なこと」を見える化するのにちょうどよいページ数と文章量になっている。

感想:

殆どは「やらないことを決めよう!」とか「やることを絞って短時間でやりきろう!」とかそんな話しばかり。 なので当たり前の話ししかされていない。

その上で「これ出来ていないな?」と強く思ったのが以下の5点。

  • 最も効果を出している人にインタビューする
  • 強みを活かした成長戦略を考える
  • まずやることを決めて、とりあえずスケジュールにいれる
  • まず試しに動いて、本格化させる
  • 満足度を数値化し、グレーゾーンを見出す

気になった点や意見、反論、補足なんかをメモしていたけどやはり自分にいま大きく欠けていると自覚している点である↑の点が印象深かった。 奇しくも今は年末であるし、忘念する前に本書を読んだことで振り返りが出来た気がしている。

来年はこれらを課題としてPDCAを回していこうと思う。 そういう意味では1200円だったし、その分の価値くらいはあったかなと思わなくもない。

手元においておいて、ダウナーやネガティブな思考に陥ったときに読み返して「どう解決するのがよいか?」を自問自答するきっかけにしたいと思う。

ちなみに本書を手に取った動機だが「副業と本業忙しすぎて時間が足らん、どうすればいいんだ…」みたいに悩んでいたときにたまたま本屋で目についたから。 そういう意味では当初の問題に対する寄与は全く与えていないので解決に繋がるわけではないが見直しを行う際のチェックシート的なものだと思えば買って損したということもないのかな?というのが素直な気持ち。

ただこの本を購入することをおすすめするか?と問われたら図書館とかで借りて読んでみて面白い、あるいは買ってもいいかもな…という気持ちになったら買ってみるといいのでは?くらいに消極的な感じ。 正直本書である必要性はほぼ見出だせないと思う。

プロダクションレディマイクロサービス - 運用に強い本番対応システムの実装と標準化

概要:

satonaoki.connpass.com

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

当選した方は、11月末までに、書籍の感想をブログ、Qiitaなどで公開してくださいね。

とのことで、当選した方なのでブログを書いている。 なおなぜ11月末までかかったのかというと書籍が実際に届いたのが11月24日だったからだ。

ようやくキタ━━━━(゚∀゚)━━━━!!今月中に読了してブログ書くぞい!!!

結論:

まず最初に結論から。 タイトルにWIPがあることからわかるようにまだ最後まで読了出来ていない。 付録を除けば残り6章と7章で34ページなのだが読んでから書いた場合間違いなく日付を交信してしまうため慌ててこのエントリを書いている。 なお本書はやる気さえあれば1日で読了できる程よいボリュームであることをここにお伝えする。

そのうえでこの本を読んだ感想は「モノリシックなサービスで心を痛めている」「マイクロサービスという名前は知っているがどういうものかきちんと理解していない」そういう人に手にとって欲しいと思わせる書籍である。

冒頭にも記載されているが本書はステップバイステップなチュートリアル的教本ではない。 マイクロサービスエコシステムをUberの事例を元に8つの原則に分解してなにか特定の言語やフレームワーク、実装に依存しないように汎用的に書かれている。 この書籍から学び取れることは本書の各章で書かれた標準をきちんと理解したうえで「さあ自分たちのサービスに当てはめるためには何が必要だ?」というマイクロサービス化する際に基準となる部分を担ってくれる実用書であるとぼくは紹介する。

なおこの内容は冒頭に書かれているが実際に読んでいるとそのことが非常に体感的にわかるようになると思う。

感想:

ぼく個人の本書を読んだ感想としては「マイクロサービスを構築するのは非常に難しく、繊細で、パワーがいる」ということが学べたと感じている。 というのもぼくは今までのプロダクトでさまざまなモノリシックなサービスに触れてきた。 そうしたときに「ここの部分だけ切り出せればいいのに…」「この部分とこの部分が疎結合にして1つの群体としてのサービスが構築できればスケールしやすく現在抱える問題も全て解決するのに…」というようなことを考えてきたし、感じてきた。

それそのものは確かに正しいのだけど「じゃあ実際にマイクロサービス化すればどうなるのか?」というところまでは考えが及ばなかった。 これは当たり前でモノリシックなサービスをマイクロサービスへ移行したことがないからだ。 (疎結合にしたことはあるがそれはマイクロサービスとは程遠いものだったので含めていない)

ともあれ、本書ではマイクロサービス化することで顕在する諸般の普遍的な問題について書かれている。 「マイクロサービス化するとここが問題になるぞ、さあどうする?」というわけだ。

そして本書はアドバイスはしているが明確な解答を避けている、何故ならマイクロサービスが同じ構成になることは極めて起こり得ないことだからだ。 Uberで解決した方法が自分たちにとっての最善でも解決にもなりえないことがわかっているからだ。

あくまでも汎用的な問題に対してどういう解決のアプローチを取るとよいか?というアドバイスレベルの内容に留めているように感じた。 そしてそれは正解だろうとぼくは感じている。

書籍プレゼントのためではないがぼくはこの書籍をあと2回、つまり都合3回は最低読み込もうと考えている。

1度目はマイクロサービスとはなんぞや?という問題を解決するために読む。 2度目はマイクロサービスエコシステムの8つの原則がどういうものか、それぞれの標準とはなにか?を理解するために読む。 3度目はマイクロサービスを自分たちのサービスに当てはめてどう調整するか?という実用としての補助のために読む。

と1度目に読んでいて「これは何度か読み直したり、理解しなくては本書の本当の価値が得られないな」と感じたためだ。

奇しくもいまぼくの職場では「障害対応」や「保守性を高める」ということで議論が起こりがちになっている。 これはここ最近問題が発生し、それが人為的なミスからシステム的な対応、根本的な解決が求められるという事態になっているためだ。 ところが「やりたい」という意思は各人持っているものの実際にどこまでやるのか、どれくらい大変なことなのか?があまり理解されていないように感じることがあった。

本書を読んでもらえればどういう方針を取るのが最適であるのか?を考える一石を投じることに繋がるのではないかなと感じ、そういう意味でも実用書としての価値が高いなと感じる事ができた。

偶然ではあるものの書籍プレゼントをされ、読む機会が得られたことを嬉しく思っている。 もし当選していなかったなら恐らく自分で購入していただろうことは間違いがない。 Kindle版がでたら是非とも購入させてもらいたいと考えているので何卒ご検討のほど……。

以上! 実用書として素晴らしいバランスのよい良書でした。 とりあえず残りの6章7章&付録を読み切って週末に突入したいと思います。

追記:

読むぞ!

いただきまーす!

なお、一応サボっていたわけではなくポートフォリオサイトをVueで書いたり、人と会う予定がありそちらに出向いていたりで中々まとまった時間が確保できなかっただけなのだ!と言い訳させてほしい。 恐らく本気で読めば8時間かからずに読了できるんじゃないかなと思ってるので読書が速いひとは買ったその日に読み切れる内容になっていると思います。

追記2:

読み終わったぞ!!! 基本追記することはほぼないのだけど1箇所だけすごい刺さった部分があったのでなぜ刺さったのかだけ書いて終わりにしようと思う。

ドキュメントの更新が行われないのはサービスの技術的負債の1つ

というようなことが150ページに書かれている、原文ままではないが主旨は変わってない。

ドキュメント大事だけどどうしても実装優先だし、タスクから漏れやすいよねと常々思っていて、今の会社でレガシーなサイトを触ったときにドキュメントがオオカミ少年状態になっていて殺すぞ!!!みたいな気持ちになったので本当にドキュメントは大事だなって感じた。

だけどどうしてもドキュメントそのものはサービスの動き、そのものに影響しないので軽く見てしまいがちだったのだけど ドキュメントのメンテナンスを怠るのはそのまま技術的負債だと考えれば、定期的にドキュメントの見直しが必要だし メンテされていないならそれはしないといけないし…と考えるに至り、サービスの技術的負債という表現が非常に鋭いなと感じた。

いやいやなにいってんの、そんなの普通でしょ?と思うかもしれないがこういう現象はままあるので学びがあるなと思った。

チームの能力の下限は誰が決めるのか?

まず最初にこれは過去の経験からぼくが現在考えている仮説でしかない点を留意してほしい。 タイトルがあおり気味な点は懸念しているがこの課題の仮説を考えたときに適切なタイトルがこれ以外に思い浮かばなかったためそのまま採用している。

チームの能力の下限とは

いままでに体験したチームの中でこんなに能力の高いひとがいるのになぜこのチームの能力は低いのだろうか?と感じることが幾度かあった。 最近ふとした現実逃避を行った際に「これはチームメンバーの最も能力が低い人間に依存して発生する問題ではないだろうか?」と思い至った。

理由として「水は低きに流る」ではないがレベルの高い方にあわせるよりも低いほうに合わせるほうが簡単だし速い。 急激な成長が見込めない以上レベルのが高いメンバーが低いレベルにあわせるほうが合理的だと考えたからだ。

しかし例えばこれが新人だった場合はどうか? この場合新人は伸びしろと成長速度の早さからこの問題に適応しにくい存在であると仮定できるのではないかと考える。

犯人はヤス

つまりチームの下限を決めるメンバーというのは「そこそこ経歴が長く年齢もある程度あるメンバー」ということになる。 そしてスタートアップやベンチャーなどの能力至上主義でもない限りこの手のメンバーというのはそれなりのポジションにいることが多いように思う。

例えばリーダーやマネージャーのようなポジションだ。 もしそのような発言権の強いポジションにチームの下限を決める、あるいはそれに近いメンバーがいた場合、これはチームの能力に対する枷になっている可能性が非常に高いと思う。 単純に年齢が高いだけではそう感じることがないのでやはり勤続年数が1つのキーワードなのではないかと思う。

ボトルネックが組織の下限を形作る?

つまり、そのボトルネックとなるメンバーのカバーできる範囲でしか行動が許可されないため能力的に高い人間が挑戦しにくい環境を作ってしまうと考えられる。 少なくともぼくの経験上、良いマネージャーはある一定以上の能力値を誇っていた。 だからこそなのかは因果関係がはっきりしていないがその下で働くときに不自由さを感じることが少なかった。 ところが下限に近い能力のマネージャーのもとで働くと檻の中で働いているような感覚に陥ることがある。

これは選択できる幅の差ではないかと考えている、能力が高い場合は挑戦をしても最悪マネージャーがカバーをしてくれるという安心感がある。 ところがそこに信頼がないマネージャーと働いている場合、全て自分で解決する必要があるため心理的安全性を確保するために安全方向にマージンを取ってしまい結果として無難な選択肢を選ぶこととなり、それが檻の中で働いているという比喩表現に繋がるのではないかと考えた。

スキルアップのモチベーション

閑話休題

ぼくたちエンジニアやデザイナーは他の職種に比べて精力的に自己学習、自己研鑽に励んでいるように感じる。 これはつまるところ、自己のモチベーションであるところもあるが現状を打破するためには技術力が必要であると感じているためではないだろうか?

もちろん「こんな会社転職してやる!」とか「もっとレベルが高くなりたい!」という個々人の動機はあると思う。 会社や組織をよくするために自己研鑽に励んでいるつもりはないと恐らく多くの人が考えているのではないかと思う。 それはそれとして結果としてそれこそが現状の組織の課題であると認識してはいないか?というのがこの疑問の趣旨だ。 つまり能力の下限を引き上げなければ自分たちにとって良い未来が訪れないと感じるところがあるということだ。

そう考えたときに組織のフェイズが重要な要素になるとぼくは考える。 サバイバルフェイズのように目の前のタスクに追われ続けていては能力の下限に対する改善は行えない、これはほぼ間違いなく実行に移せない仮に計画しても中折れしてしまうか中途半端に行い有名無実化するのが関の山だろう。 結果、成果のレベルが上がらず同じようなサイクルを延々と回し続けるというつらい状態を継続してしまう。

会社組織としてみたスキルアップ

急成長したスタートアップやベンチャーが勉強会やカンファレンスなどでスキルアップに対して肯定的であるのはこの点にも一因があるのではないかと考えた。

エンジニアやデザイナーに対する福利厚生としてだけではなく、それが結果として組織の能力値の下限を引き上げる効果があると理解しているのだとしたらサバイバルフェイズでいつまでも燻っている企業との差は凄まじいものになるのではなかろうか。

業績などの目に見える部分以外のところで歴然たる差を生み出しているように感じる。 だからこそさまざまな企業や組織がサバイバルフェイズから学習フェイズへの移行、そして自己組織化への改革へと手を伸ばしているのではないだろうか?

どうすればよいか?

「チームの能力の下限が低い」という課題があったと仮定してではどう対処するのがよいか?

多くの場合、急激な成長が見込めないメンバーこそが下限の原因であると考えていることは先程述べた。 であるならば急激な指導や教育は逆効果であると思われる。 何故ならば彼ら彼女らはいま現在でも困っていないからだ。

困らないからこそ能力が低くても、自己研鑽に励まずせいぜいが現状維持レベル(少なくとも当人はそのつもり)をしているのだと考えられる。

であるならば本人の自由意志で勉強会の参加や自己研鑽を待つのは正攻法ではない。 ある程度強制的に参加させ、どういう課題があるかを自覚させるように持っていく。 それによって目的意識や目標が漠然とながら生まれる。

それらがないままに強制的に学びの場に打ち込まれても寝てるか、そっぽを向いているかのどちらかだ。

これがアメリカのような契約社会だったならば「お前はクビだ」の一言で済んでしまうのかもしれないが ここは日本なのでその対応は現実的でない、また勤続年数がそこそこあるメンバーにその発言はしにくいだろうと思う。

なのでまずは強制的にでも能力値を上げる、少しでも上がればその分業務の負担が減る。 業務の負担が減ればその分自己研鑽などに当てる時間が増える。 このサイクルをとにかく回していくしかないのではないかと思う。

ここで重要なのは勉強会に参加させることが能力の下限をあげることではないということだ。 勉強会に参加しただけではなにも能力には寄与しない、発表をする、手を動かすことで初めて「かしこさが1あがった」状態になるのだ。 ここを勘違いして講師役の人から内容を聞いただけでやった気になってしまう人がいるかもしれないので念のため注意書きを残しておく。

まとめ

  • 特効薬はないのでまず下限にいるメンバーを調教する
  • 中長期的な対応が必要になることを自覚する、一気に全てをひっくり返すことは難しい
  • 何が問題であるのか?仮設を立てて検証、実行することこそが肝要

あなたの技術書の読み方

なお、技術書はこう読め!みたいな話ではない。

愛聴?しているpodcast の通称しがないラジオで「あなたの技術書の読み方」というフィードバックテーマ(お題?)がでていて 技術書の読み方は読む人のスキルやその技術書でなにを習得したいと考えるか?がバラバラで難しいよなーと思った。

そこでそういえば技術書の読みかたを振り返るのもいいかもしれないと思ったのでKPT形式で振り返ってみようと思う。

元ネタのpodcastは↓、SIer出身じゃないけど割りと楽しく聞いている。 たまに自分のハンドルネームが読み上げられると恥ずかしくて死にたくなる。 (主に会社で聞いているので身悶えしてるときはだいたいそう。)

shiganai.org

前提:

blog.shibayu36.org

ぼくの技術書の読み方のスタンスはshibayu36さんの↑のエントリを参考に自分風にアレンジしたものになる。

  • 目次を見ながら学びたいことを探す
  • 読みながら印象に残った部分をメモ書きする
  • ブログにまとめる

Keep:

目次をみながら学びたいことを探す

shibayu36さんは疑問形式で書くとあったがぼくの場合それだと多すぎたり少なすぎたりして微妙になってしまったので一旦疑問形式は置いておいて どこらへんが目次のなかで自分の琴線に触れたのかをメモしておくようにした。

琴線に触れるものがなさすぎると自分の現状のスキルとミスマッチすぎるし、逆に何書いているかわからないのが多すぎると対象読者のレベルに達していないという判断をしていてだいたいいい感じのフィルターとして機能している。

ブログにまとめるときに気になったことが解消したか?などを後出しだが疑問形式で出せるようになったりしたので割りと自分の中ではいい感じ。

読みながら印象に残った部分をメモ書きする

かなりいい。 疑問に思った部分や自分はそうは思わなかった、完全には同意しかねるが気持ちはわかる的なやつもとりあえず書いてる。 読んだときはこう思ったが、そのあとで考えが変わった…とか時間が経過して読み直したら以前とは感じ方が違ったとかまれにある、そういうとき役立つ。

とにかく雑に書いて、雑に感じたまま書くようにしている。 その中で唯一気をつけてるのはページ数、あとで探しやすいように

以前はポストイットでやてたが管理が大変なので最近はiPad Proでメモ書きしている、その際気になったページが書かれているのであとで見返すときに捗る。

ブログにまとめる

当初気になったがあとの章で説明されて解消したとかたまにある、なのでそういう取捨選択を行う機会を作ってると考えるとやはり重要。

あとメモをそのままブログに書くと何書いてるかさっぱりわからないし、メモを読み直してもわからないことがあって結局本を持ち出して書かれたページを読んでしまう。

なのでブログにまとめたときには文体や流れにはさほど気を配っておらず、とにかくその時読んでなにをどう感じたかを出来るだけ思いつくままに書いている。

Problem:

なにを目的、目標とした読書か?

この技術書を読むモチベーションはどこにあるのか、またそれらは読了後どうだったのか?を書けていない。 だいたい書き忘れてしまう。

読み方があまり効率的でない

技術書は小説のようにさくさくと読み進めるのが難しいのでどうしても時間がかかってしまう。 時間がかかるとダレて読まなくなってしまいがち、結果長い期間読んでなくて内容を忘れてまた読み直してしまう。

Try:

購入ボタン押したらすぐにメモ取る

なにを目的、目標とした読書か?

どういうモチベーションで購入したか?を書いておく。 読了後、どうせブログ書くのでそのときにその結果もあわせて書く。

写経しない

読み方があまり効率的でない

ぼくは技術書を読むときはだいたい出来るだけ写経しながら読み進めていくのだが あまりこの方法がいいと思えなくなってきた。 軽く一読しきってしまってから写経を行ったほうが効率が良さそうな気がしている。

まとめ:

読書スピードがあまり速くないし、理解力も決して高くないので愚直に行くしかないのだけど もう少し効率よくしたいなとは思っていたので年に1回くらいは読書方法の振り返りをKPTでやっていくのはいいかもしれないとエントリを書いてて思った。 人によっては技術書を3回読むとか、いろいろあると思うけどまだ「これがぼくのなかでベストプラクティスな読書方法だ!」と言えるところまでいけてないので改善していきたい。

ぼくは才能がない、あるいは中途半端にあるということ。

響け!ユーフォニアム 北宇治高校吹奏楽部、波乱の第2楽章」を読了した。 響け!ユーフォニアムはアニメも劇場も読んだが今作がもっとも心を揺さぶる小説だった。 まだ残り2ヶ月ほどあるがぼくの中でベスト・オブ・ジ・ブックが本日確定した。

少なくともぼくが今までの人生で読んできた小説、本のなかで5本の指に入るくらい衝撃と心をかき乱した傑作だと思う。 響け!ユーフォニアムは本当に人間描写というか心理描写が見事の一言に尽きる。 この余韻が薄まらないうちに心のなかに渦巻く感情を吐き出しておかなければならないという衝動にかられて書いている。

元々ISUCON7予選に参加する予定だったのでそのあとにご褒美的なものとして終わってから後顧の憂いなく読み耽る予定でいた。

当初、1冊目を読んでいるときには普通にいつもの読書感想文を書こうと思っていたのだが、2冊目を読んだところで考えが変わった。 読書感想文はまた別で書くか、あるいは書かないかもしれない。 とりあえず読んでいて感じたり考えたエモい文章を羅列しておく。 多分あとで読んで恥ずかしくなり死にたくなるタイプの文章なのでノイズが多いことだと思う。

また、小説を読みながらその時その時で思いついたことを書き出しているので取り留めがない点と話しが飛ぶ点は容赦願いたい。 またこの話しはいわゆるネタバレを多分に含んでいるため、それがいやなかたは回れ右してほしい。

結論:

さて、普段の読書感想文ではなく何を書くのか?という話だが端的に言ってしまえばポエムである。 しかもネタバレを含んだポエムだ、これほど酷い話もない。

しかしながら、今作を読んで改めて「自分は何になりたいのだろう?」と考え直すきっかけを得た。

さて、まずは結論から入ってしまおうと思う。

ぼくは今作を読んで改めて「プロになりたい」と自覚した。 獏っとした表現になってしまうがそもそもプロとはなんなのだろうか?

お金をもらっていればプロなのだろうか?

顧客の望むもの、あるいは超えるものを作り出すのがプロだろうか?

よく巷で語られるプロフェッショナルとはなんなのか?

フリーランスのように自分の実力だけで食べていける人間はプロか否か?

ボク個人はこれらに対する解答は自分で見つけたものだけが真実であり、普遍的な答えがないのが正解だと思っている。 ではぼくが考えるプロとはなにか?

  • 顧客では出来ないことを技術的な課題を解決することの出来る人間、チーム、あるいは会社。
  • そして組織に所属しなくても十分に生活することが出来る技術力を持った個人。

この2つの条件を両方満たしている人がぼくにとってのプロなのだと考えるに至った。

とはいえ、元々の考えと改めて考え直しただけなので然程時間がかかったわけではないのだが。

努力と苦悩

自分には才能がない、とは誰しもが1度くらい考えたり感じたことがあるのではないかと思う。 少なくともぼくは自分にプログラマ、エンジニアとしての才能を感じたことはない。

今作のユーフォニアムがなにをテーマにしているのか?と問われたらぼくは努力が生み出す懊悩だと思う。

今作はさまざまなケースで努力、あるいは努力する吹奏楽部メンバーの苦悩やそれにまつわるストーリー実に詳細に描かれている。

恐らくは似たような経験が著者の武田綾乃氏にある、あるいは見聞きしたのだろうと思う。

例えば毎日遅くまで残って練習しているが努力の仕方が間違っている、努力しているように見えるほうが評価される。 実力は劣るが努力している先輩のほうがコンクールに出場したほうがいいなどなど吹奏楽に限らず社会に出てからも似たような話しは枚挙に暇がない。 そういう意味でも今作はいろいろと自分にとって考えさせられる作品だったと言える。

最初にいうとボク自身のエンジニアとしての力量は決して高くないと見積もっている、せいぜいが中の下か下の上だろう。 だからこそ努力していると思っているし、その努力の効率が多のエンジニアに比べて悪いとも自覚している。

だからだろうか、数こそ少ないが映画やアニメでは泣いたことがあった。 ただ数多くの感動作と呼ばれる小説を読んでも心がワクワクしたり、動くことはあっても泣くことはなかった。 目に涙が浮かぶ…くらいまではいったことがある。

だが生まれて初めて小説を読みながら涙が出た。 悲しくてではない、それでは泣きはしなかった。 誰かと自分を重ね合わせてか?それもない、ユーフォニアムには登場するさまざまなタイプの人物が登場するが特定の誰かに自分を重ね合わせるような感情移入の仕方はしたことがない。

では何故涙したのか? 自分自身でも半信半疑であるのだが恐らくは悔しくて泣いたのではなかろうかと思う。

自分はこうはなれなかった、それが悔しくてもどかしくて涙がでてしまったのだろうと思う。 もっと上手くやれたはずだ、もっと上にいけたはずだ、後悔の念が生まれては消え、そしてまた生まれるという感情の渦が発生し結果涙という形で現れたのではないかと思っている。

だからだろうと思うが滂沱したというよりはギリギリまで注いであるカップから水が1雫溢れおちるようにふつりと涙が流れたっきりだった。

恐らくこれは直近でISUCON7というイベントがあったことも無関係ではないだろうと思っている。

目に見えない努力というかたち

後編の330ページ以下のような一文がある。

額からにじんだ汗が、顎を伝い落ちただけだった。なんだかぞわぞわする。肌寒さが全身を覆い、なのに肝心の身体の中身は空虚しか詰まっていない。何も考えられず、思考はがらんどうだった。突き出された現実に久美子はしばし茫然となった。

この一文を今読めたことをぼくは感謝するべきなのかもしれない。

文章自体に特別な点は恐らくない。 話しの流れも恐らくは特別なことはなにもないだろう。

しかしながらぼくはこの一文の前の状態から胸がドクドクと波打ち、何十分の一かはわからないが久美子たちの緊張の一端と思いを共にしていた。

これは先日行われたISUCONで似たような緊張を味わったからこそだろうと思う。 これがなければ本作がここまで味わい深い感想にならなかったと思っている。

そしてその後の展開でぼくは自問自答することとなる「ぼくは彼、彼女らほどISUCONと真剣に向き合っていただろうか?」と。 もちろん部活動とISUCONでは意味が全く異なると思うし、それにかける時間だって全く異なる。 だけど一瞬、ほんの一瞬だけそう考えてしまったのだ。 そして一度考えてしまったものをなかったコトにすることは出来ない。

ぼくはこのことを直視せざるを得なくなってしまった。

無慈悲な才能という壁

またしても後編になるが以下の文章を読んで心の琴線が揺れ動いてしまった。 191ページ目の指導をサポートしてくれる橋本という男性、アニメでも登場したので覚えているひともいるのではないかと思う。

「ぼくは君に対しては『高校生にしては』言いたくないねんなぁ」

この一文を読んでぼくは「非常に残酷な一言だな」と感じた。 恐らくは「君」以外であったならこの一文は生まれなかったはずだからだ。 そしてぼくは「君」側の人間ではない、だからこそ感じ入るところがあったのだろうと思う。

他にも似た感情を想起させる一文がある、ページ247の以下のものだ。

「みぞれより自分のほうが上手いって、思ってたかった。だって、みぞれよりうちのほうが絶対に音楽が好きやんか。苦労してる。つらい思いもしてる。それやのに、みぞれのほうが上なんて」

この一文を読んだときぼくはみぞおちの辺りに重いものが突然発生したように感じた。 まるで我がことであるかのように感じたからだ。 もちろん状況としてぼくとでは努力の総量、質が全く異なるのだが頭の中で一瞬でも考えたことがないか?と言われたら否定できない自分がいるのだ。 醜い、直視したくない自分の汚いところがありありと噴出してきて「何故ぼくではないの?」と一瞬重ね合わせるところがあった。

氷菓で有名な〈古典部〉シリーズにも福部里志の屈託として似たようなシーンがあるがあちらは明言を避ける形で苦悩と屈託を表現していた。そういう意味ではより直接的な心を抉ってくる一文だと感じた。

「そのときにわかったの。みぞれは、選ばれた人間なんやって」

そして最後のこの一言が諦観と自分の複雑な気持ちを実に上手く表現していると実感した。 つらい、認めたくない。でもあまりの実力差を認めざるをえない。 持たざるものだからこそ、持つもののまばゆい輝きを認めざるをえないのだ…と強く実感させられた。

ぼくは響け!ユーフォニアムのキャラクターはだいたい好意的にみている。 ただし1人だけ例外がいる、それが先程から登場している鎧坂みぞれという人物だ。

嫌う理由は色々あったと思うだがこれだ!といえるのは「特定の誰かに強く依存しすぎている」点が気に食わなかったのだろうと思う。

ここだけリアリティーが抜け落ちたように感じていたのだ。 こんな人物がいるのだろうか?他の登場人物は多少の誇張はあれどもその辺の高校に探せばいるのではないかと思わせる人物ばかりだ。 それはあの田中あすか先輩にしてもそうだ、あそこまで完璧超人はいないだろうがそれに近い人物というのはいるだろうと思っている。

一点、この鎧坂みぞれはそうではない、物語めいてぼくの目には写っていたこともあり、違和感が拭えなかった。 今まで読んだ響け!ユーフォニアムのどの人物にもそのような感情を宿したことがなかっただけに純白のキャンバスについた真っ黒な染みのように写っていた。

それが今作で印象が反転した。 魅力的である、とはいえない。少なくともまだ…。サイドストーリーなどで後日談があれば更に変わるかもしれないが。

だが汚点であるような印象やリアリティーにかける印象はくるりと手のひらを返すように評価を変えた。

少なくとも鎧坂みぞれに対するネガティブな感情というのは綺麗サッパリ消えてなくなった。

音楽とシステム開発似ている

ハッカーと画家をぼくはまだ読んだことがないが恐らく音楽とシステム開発は似たようなものなのかもしれないと今作を読んで感じた。

1人でも音は出せる、楽譜通りに奏でることもできるだろう。 でもそれは合奏が生み出すハーモニーとは全く次元のことなる表現方法だ。 そして、それはシステム開発にも当てはめることができるのではなかろうかと思う。

以前なにのpodacstであるかは定かでないが響け!ユーフォニアムはチームビルディングの話しである。といった感じの発言を聞いたと記憶している。 当時のぼくは「そうね、メンバーのモチベーションもバラバラ本気で全国いきたいやつ、そうじゃないけど周りに合わせているやつ、辞めていくやつ。色々いるしあれこれ胃が痛くなるような人間関係の問題や技量的な問題がでてくるもんね」と軽く考えていた。

それはそれで正しいのだろうと思う。 ただ今作は努力の価値やその方向性という意味でいろいろと考えさせられる部分が多くあり、先のチームビルディングの話しを思い出させた。

才能あるものだけが選択できる未来

ぼくたちがウンコードを生み出してもお金をもらえて生活できているのはぼくたちの仕事が持ち得る幅が広く、なによりも分母が大きいからではないかとこのことからふと考えることになった。

もし音楽家のように誰もが自分の書いたコードを把握できてしまうような状態であったならウンコードを書いた人間は死にたくなる思いにかられるのではなかろうか。 その人は次は二度と同じ過ちはしない!と強く思うかもしれないし、もしかしたら自分には才能がないと諦めて別の道を模索するかもしれない。

もし機械がプログラムを書くのが当たり前になれば音楽家と同じようにぼくらの大半の才能がない人間は目指すことすら諦めないといけない状態になるのではないか?

それは恐ろしい、とても恐ろしい話だ。 だが同時に悪魔的な魅力もあるのではないかと感じてしまった。

いままでのぼくならそれは素晴らしい世界だと素直に感じられたと思う。 だが今作を読んだあとでは素直にそれだけを歓迎する気持ちにはならなかった、胸中複雑ではあるがマーブル模様のようにモヤモヤとしたものを感じている。 その上でぼくはやはり機械がぼくらの職を奪っていくべきだと考えているつもりだ。

かつてはプログラマも音楽家と同じくらい狭き門だったのだろうと思う。 それが一般にPCが普及し、扱える範囲が爆発的に広がったことでぼくたちは専門家の基準を満たさない人間でも生活できるようになってしまったのではないか。

将来、ぼくたちはかつての馬丁や水夫のように消え行く存在なのかもしれない。と改めて深く考えさせられた。

そういう意味ではこの時代に生きる人間の特権のようでもあるし、今作を読んで改めて考える機会が出来たのは良かったのではないかと思う。

まとめ:

まあまとまらんよな?という思いなのだが。 才能というのはやはり悲しいかな厳然たる事実としてぼくの前にあって、努力すればいいというものではないよなと改めて思った。

努力の方向性を間違えればそれは努力していても意味がないわけではないが目的は達成できない。 努力の質が低ければ無駄に時間を費やすことになり、これも目的は達成できない。

努力とはなんであるか?目的や目標を達成するための手段である。 努力の総量が足りていたとしても周りに才能があり、同じように努力していればこれまた目的を達成することが出来ない。

最後に341ページの吉川優子部長の言葉を引用したい。 いや心情的にはここで読んでほしくはない、本文を是非とも読んで感じたままに余韻を楽しんで欲しい。 だがこれを語らずにはいられないという思いから引用させてもらう。

「去年は滝先生がきて一年もたってへんかったけど、今年は二年目やん。去年に比べて、そのアドバンテージがある。上手い新入生もいっぱい入ってくれた。やけど、負けた。うちらが弱くなったんじゃない。ほかが、強かった。」

ピンクリボンの優子。

登場当初はクソウザいキャラクターだなと思っていたがあれよあれよという間に好感度がトップクラスのキャラクターに成長していった。

この「ほかが、強かった」で一度区切った辺りに苦悩や懊悩が読み取れて非常に悔しいという心情が伝わってきた。

ぼくも「やりたいこと」に対する貪欲さが足りていない、もっともっと貪欲さを表に出さないといけない。 それは驕りであり、慢心なのだと改めて学んだ。

あまり引用はしたくなかったが心が痺れる一文なので引用とその感想を述べて〆とさせてもらう。

次回作の響け!ユーフォニアムも大変楽しみにしている。 是非ともグサグサと心を抉るより、感情を揺さぶる良い作品を書いて欲しい。

駄目なコードには3つのパターンがあるが最後のやつだけはどうやっても許せない

一般的に駄目なコード、あるいはレガシーコードやウンコード、スパゲッティーコードなどなど駄目なコードに対する語彙は非常に多い。 ただじゃあこれら全部が同列の駄目さかというと個人的には違うと思っていてその所感を書いて整理したいと思う。

よくいう技術的負債というのは「きちんと書いてる時間がないのでとりあえず動くコードを書くけど将来的に直す!」みたいなコードのことだと認識していて 本来お金をもらって仕事をしている以上全ての駄目なコードはこうなっていないといけないと思ってる。 お仕事である以上納期を守るというのは最低限守らないといけない約束事なのでそちらを優先した結果あまり良くないコードが残ってしまうのは仕方のないことだと思う。 納期を無視してでも綺麗なコードを書けとはさすがにどんな人でも言わないと思ってるが世の中トチ狂った人がいないとも限らないので断定は避けたいと思う。

ピヨピヨしたコードは新しくジョインした直後のチームメンバーや使用しているフレームワーク、言語、ライブラリなどに馴染みが薄い人が書きがちなコードのことで誰もがかつては通った道だと思う。 このコードはお金をもらっている以上それを言い訳にすることはできないが少なくともきちんとチームでコードレビューすることが浸透していれば問題になることはないと考えている。 技量が急激に上がることが少ない以上、これらの状態は短いか長いかの違いはあるが必ず発生するし発生しないわけがないと考えている。 なおコードレビューやチューターがいないなどのサポートがない場合は伸びしろがあるコードだったとしてもピヨピヨしたコードではなく次に紹介するコードに該当するとぼくは考えている。

タイトルで最後と表現した一番駄目なやつ。 遭遇すると書いた人間やチームを呪わずにはいられず、ソウルジェムが一気に濁ってしまう危険な呪文。 ガンジーが核持って殴り込みに来るレベル。

そして得てしてエンジニアが揶揄して例題にあげる駄目なコードでもある。 なお伸びしろのあるピヨピヨしているコードもそれをサポートする仕組みや体制がなければ時間が経過するほどにこのコード状態になると考えている。 ぼくはこれらのコードをウンコードと呼んでいる、たまに食事の席で発言してしまい「ヤッチマッター」って顔をしている。

まずなにが駄目かというとウンコードの多くは書き捨てのスクリプトであることだ。 その場でしか使わないし、大したシステムでないからとりあえず動けばいい…みたいな考えで書き捨てられているのがこれに値する。

そしてこれらの問題は書いた時間の10倍近い労力を要さないと修正することが困難であるという一事に尽きる。 まず「なにをしているのかわからないコード」を読み解くのに時間がかかり、「不可思議な挙動をするコードを調べる」のに時間がかかり、「そもそもこれバグってんじゃねえか!」という現象に苛まされ、「直した!と思ったら全然関係ないところで使用されたあげくにエラーになってしまい」、「それらを全て問題ないかチェックした上でリファクタリングバグフィックスを行い」ようやく通常のコードリーディングや修正と同等のタスクに着手出来る状態になる。

とぼくは思っていてウンコードはどう取り繕ってもウンコードで書いた人そのものを攻撃する気はないがその状態で放置したマネージャーに対しては「殺すぞ!」くらい言っても許されると思ってる。 コードレビューがされないのはマネジメントの責任だとぼくは考えている。 テストのないコードがレガシーなコードならば、レビューのないコードはウンコードだ。

くらい言っても許されるのじゃあなかろうか。

何がいいたいかというとコードには賞味期限があってどんなに書いた当時素晴らしいコードも時間が立つに連れ鮮度が落ちていく。 問題なのは定期的に腐った、あるいは腐りそうなコードを適宜選別して捨てるものは捨てる、新しいものと入れ替えるなどのタスクが必要だということだ。

スーパーに置かれている野菜が腐って異臭を放っている状態で放置されていたら誰だって怒るだろうと思う。 それと同じことをプログラムコードで行って何故クレームが来ないと思えるのか?

本当の意味で顧客のことを考えるならサポートを充実させるよりも何よりもこの手のウンコードを撲滅することを目指すべきじゃあなかろうかと考えることが増えた。 特に顧客は自分たちでは実現できない、あるいは時間がかかりすぎることをお金を払ってぼくたちの技術力を買っているのだから、ぼくたちはその金額に見合うだけの技術力を提供する義務があると思う。 金額の結果がウンコードならそれはそれでいいが、それっきりにしてもらうか負債として会社の未来に残さないでいただきたい、書いたやつが墓場まで持って帰ってくれ。

…もう人間がコード書くより機械に書かせたほうが質の高いコードが出来上がるんじゃねえかと最近割りと本気で思ってきた。