PME (Product Maintainability Engineer) （自作造語）を目指してみる実験

GWにキャリアについていろいろ考えたので、アウトプットの第一歩として書いてみます。

---

目次

---

キャリアを考えるきっかけ

エンジニアのキャリアについては正直、今まであまり深く考えてきませんでした。ところが最近は、キャリアについて考えることが面白くて自発的に思考しています。きっかけは以下の２つです。

• 毎週の1on1で、なりたいエンジニア像の言語化にチャレンジした
  • 「なりたいエンジニア像」をいきなり考えるのではなく、次のような段階を踏んでいた
    • 最近の仕事ぶりを振り返ってみてどうか → 理想とのギャップはあるか → その理想ってどんな姿だろうね
  • この段階的流れはとても良かった。自発的に理想を考えるきっかけになった
• SOFT SKILLS を再度読んだ
  • キャリアについて関係のある箇所をつまみ食い的に
  • 具体的な考え方が書かれているので、今の自分に刺さった

1on1がきっかけでキャリアについて考え始め、積読していた SOFT SKILLS で具体的に思考し、どんどんおもしろくなってきた、という流れです。

自分の目指したいブランド

SOFT SKILLS で印象に残っているのが「自分のブランドを持とう」という話です。自分のブランドを確立し、自分を売り込んでいくのです。自分のブランド、、、何も思いつかないな。そう思ったので真剣に考えてみることにしました。

ただ、「今の自分のブランド」ではなく「目指したいブランド」を考えます。今後は、なりたいエンジニア像を「目指したいブランド」として話を進めます。

まず、ブランドに必要な要素は以下の４つです。

• メッセージ
• ビジュアル
• 一貫性
• 反復的な接触

この中でも一番大切なものは「メッセージ」です。自分のブランドは何についてなのか。自分はどういう人なのか。例として著者は「シンプルプログラマー」を挙げていました。「私なら、複雑なものを単純にして、誰でもわかるようにする」というメッセージだそうです。

メッセージを考案する際はニッチ戦略が重要です。市場の隙間を狙って優位性を得ることが大切です。広い一般的なメッセージではなく、ひねりを加えたメッセージにします。メッセージは戦略的に考えていきます。

はて、自分はどうなのか。目指したいブランドがぱっと思いつきません。そこで戦略的に考えていきましょう。例えば、今の会社の期待と全くズレたメッセージを掲げると、なんだか厳しいことになりそうです。なので、会社の期待に沿ったメッセージを考えてみます。かつ、自分のモチベーションが上がるメッセージです。今の会社はレガシーな部分があり、なかなかスピーディに開発が進まない場面があります。保守性の問題です。そこで思い浮かんだのが以下の資料でした。

speakerdeck.com

何度読んでも良い資料です。改めてこれを読んで生まれた感情が「今の現場でも保守性を上げ、スピーディに開発したい！」というものでした。そして自分の目指したいブランドのメッセージとして「保守性を向上させるエンジニア」が浮かび上がりました。その姿に向かっていき、キャリアを構築していこうと考えました。

より良いメッセージ

自分の目指したいブランドのメッセージは「保守性を向上させるエンジニア」に決まりました。まだこの領域には至っていませんが、向かうべき姿は決まり、キャリアの構築を始めていきます。ただ、「保守性を向上させるエンジニア」という言葉だけだと、モチベーションがどんどん湧かないというか、何か勢いが足りないと感じました。「シンプルプログラマー」のような、端的でかっこいい何かが欲しいのです。再度 t_wada さんの資料を見ると「Maintainability：保守性」という単語が目に入りました。ここからはもう一直線でした。

• ~ability という単語はいろいろ聞く
• Maintainability Engineer とかどうだろう
• ~ability Engineer って SRE があった
• 「プロダクトの保守性向上を目指す」ということで PME (Product Maintainability Engineer) ってどうだろう

自作造語です。

PME (Product Maintainability Engineer)

PME は、プロダクトの保守性向上を目的とします（と定義します）。先述の資料の中で、Maintainabilityの構成要素は以下の３つとありました。

• Testability：テスト容易性
• Understandability：理解容易性
• Modifiability：変更容易性

これらの要素にアプローチして保守性向上を目指します。そのためには、どこがボトルネックになっているかや、修正コストはどのくらいかなど、多方面の知識や技術が必要になってきます。また、３つの構成要素の分かれているおかげで、スコープを絞って学習・実践ができるのではないかと思います。

ブランドのメッセージとしてはキャッチーですし、期待してほしいことも明確になっていると思います。言葉からくるモチベーションは意外と重要だと思います。

メッセージを決めたことによる効果

自分の目指したいブランドのメッセージを掲げたことで、以下のメリットがあると考えます。

• 学習の意味付けができる、学習の方向性が決まる
• その姿に近づくことによる満足感と、さらなるモチベーションの獲得
• 日々の行動に一貫性が生まれる
• 自分を表現できる

こうして内発的に「目指したい姿」を定義できれば、これらのメリットが得られると思います。

PMEを提唱するわけではありません

自分は今回、PMEを提唱したいわけではありません。勝手に自分のやる気が出る言葉を作ったに過ぎません。その点をご了承いただければと思います。

今後

PMEを目指して日々の行動を変えていけるのか？という実験をやっていきます。うまく回ったらまたブログで報告します。「やっぱりだめだった」という場合も、何らかの対策を考えてブログに書こうと思います。

まだ「ニッチ戦略としてどうなの。広すぎない？」という疑問も残っていますし、具体的に日々をどう変えていくかも考え中です。とりあえず宣言をしてみる意味で今回の記事を書きました。

技術書典６終了後メモ

技術書典６、お疲れ様でした！ 今回も大盛況でとても楽しかったです。

終了して記憶がおぼろげにならない内に、半年後の自分に向けての箇条書きメモです。

目次

頒布物紹介

• 「におうコードの問題集」の新刊既刊合わせて３種類
  • BOOTH
    • 【PDF】におうコードの問題集 〜ソフトウェア設計に立ち向かう編〜 - Grand Pa-Ma - BOOTH
    • 【PDF】におうコードの問題集 〜セキュリティホールに立ち向かう編〜 - Grand Pa-Ma - BOOTH
    • 【PDF】におうコードの問題集 〜バリエーションに立ち向かう編〜 - Grand Pa-Ma - BOOTH
• 【委託】「Introducing Crystal Programming Language」
• お品書き

レビューをお願いしてよかった

• 構成案の段階でレビューを依頼
  • GoogleDocsにて箇条書きで各章の内容を書いて共有
  • コメントを書いていただく
• 鋭い指摘をいただけたり、言葉の定義の曖昧さを指摘していただけた
• ただ、もう少し余裕を持ってお願いするべきだった
• 次回はPDF版でレビューをお願いできる余裕を持ちたい
• 関係者の皆様、本当にありがとうございました

もうちょっと早めに早めに動くべきだった

• 毎回言ってる
• ねこのしっぽさんの「116P以上最終締切」までに書き切ろうと思ったが、その日付の時点で「ガーッと書き切ったけど未推敲」という状態だった
  • ページ数は118pくらいだった
• この状態で出せないと判断し、もう一週間で推敲する決意＆116p以内に収めないとダメという制約が発生
• そこから一週間は推敲＆ダイエット
• 最終的に慌てずに入稿できた
  • 前回よりは進化した（前回は大慌てだった）

委託文化がもっと広がると良い

• 事前のイベントやTwitterなどでいろんな方と話していると、「落選したけど委託で販売できた」というケースを多く見た
• この流れがないと「その本が世に出なかった」
• これを考えると、委託の流れはもっと広がると良いなーと思った
• 委託による交流も生まれる

ワンオペの辛さを改めて実感した

• 今回はワンオペではなかった（急遽売り子をしてくださった知人の方が！感謝感謝です🙏）
• ちなみに前回はワンオペだった
• ワンオペではない今回の体験を持って「ワンオペやばい」を再認識した
• 「休憩できる」ってほんと大事
  • 途中、体調悪かったので本当に助かりました
• 「列整理」「支払い対応」「在庫を箱から出す」などなど、これを並列で一人で全部とか無理
• 頒布状況の改善案を出せる余裕ができる
  • 先にDLカードを本に挟んでおくとか、机の上の配置はこっちのほうが良いよねとか、お釣り出しやすいように5000円札だけ別にするとか
  • ひとりでやってたら、会期中に改善する余裕はない

高速頒布テクニックが知りたい

• 開始から10分くらいでブース前に行列が（ありがとうございます🙏ありがとうございます🙏）
• こちらの捌き次第で列の消化が決まる
• ひたすら頒布したけど、滞る場面がいくつかあった
  • 以下の２点
    • かんたん後払いのQR読み取りに時間がかかる
    • 見本誌を見たい方と会計したい方の入り乱れ
• 改善提案
  • 高いポスターを掲げるのではなく、高い位置にかんたん後払いのQRをデカデカと掲げて、遠くからでも決済できるようにしたら良かったかもしれない
    • そうすれば、レジ前に来たときには確認画面のチェックだけでok
  • 各サークルの島の間に、近隣のサークルの立ち読み場があると良さそう
    • 読み手も「ブースの前で読む」という若干のプレッシャーを回避できる
    • 売り手としても、会計の人の割合が高くなり、頒布しやすくなる
    • 立ち読み後、サッと近くのブースへ買いにいける

現地割引は効果があったと思う

• 売り手側の戦略の話になってしまうが、一定の効果はあったと思う
• 現地のみ、２冊セットは500円引き、３冊セットは1000円引き
• かんたん後払いのために、マイページの頒布情報で、全パターンの頒布情報を記載した
  • 「赤＆緑2500円」「赤&青2000円」など、全パターンを登録
    • セットもアプリで選べるようになる
  • DLCもzipで固めて、全パターンアップロードした
• 最初は頒布オペレーションで戸惑いがあったが、すぐに慣れたので問題なかった
• 前回の技術書典５でも思ったが、セット購入してくださる方が思ったより多い
  • ありがとうございます🙏

高く掲げるのは効果アリ

• 中盤から後半にかけて、スキがあれば本を頭上に高く掲げた
• やはり、１秒でもちらっと見てくださる方が多い
• 結果、掲げたときと掲げないときでは、（肌感ではあるが）掲げたほうが購入頻度が多かった
• 一瞬でも目に留まってくださるのはありがたいし、一定の効果はありそう

エゴサ絶対するよね

• 戦利品ツイート、本当に嬉しいです
• 書籍名を入れての感想ツイート、鼻血が出ます
• 本の内容についての質問、失神します
• こうやって盛り上がりが循環して、技術書典自体が盛り上がっていくのは本当に良い流れだと思う
• 次回も書きたくなるよね

シリーズ化の強み

• 最初から意図したわけではないが、シリーズ化することでいろいろ恩恵があることがわかった

今回、「におうコードの問題集」シリーズ３作目を出したけど、徐々に「シリーズ化」の恩恵が大きくなってきている。

・執筆環境構築がほぼゼロ
・表紙デザインの考案コストが少ない
・上記２点より内容に集中できる
・認知度が徐々に上がっている
・登場キャラクターのファンの方を発見🎉 #技術書典

— at_grandpa@技術書典-く06 (@at_grandpa) April 16, 2019

• マゴのファンの方のツイートをみて、イラストレーターさんにも伝えて、二人でめちゃくちゃ喜んでました

まとめ

次回、上記で改善できそうな部分は改善していこうと思います。 他の方の後日ブログも見て、いろいろ吸収していこうと思います。

次回

第４弾はDBをテーマに考えています。

次の「におうコードの問題集」、テーマはDBかなと考えてる。モデリング、アンチパターン、パフォーマンスなど、分野は多岐に渡るけど、例えば「こういうテーブル構造があります。どうクエリしますか？」というのは問題にしやすそう。

そして何より、表紙の色を決めるのに半年かかりそう。 #技術書典

— at_grandpa@技術書典-く06 (@at_grandpa) April 15, 2019

何卒よろしくお願いします。

技術書典６で「におうコードの問題集〜ソフトウェア設計に立ち向かう編〜」を頒布します

「におうコードの問題集シリーズ」の第三作目は「ソフトウェア設計に立ち向かう編」です。 問題集形式でソフトウェア設計について学ぶことができます。

また、委託で「Introducing Crystal Programming Language」も頒布します。 Crystal言語の入門本です。

共に「く06」でお待ちしています。

techbookfest.org

#設計飲み という勉強会を開催しています

設計飲みという勉強会を開催しています。

前回

sekkeinomi.connpass.com

次回（締切済み）

sekkeinomi.connpass.com

connpassグループ

sekkeinomi.connpass.com

技術書典６に向けての Re:VIEW+CSS組版 環境構築

前回の技術書典５では、Re:VIEW+CSS組版にチャレンジしました。

at-grandpa.hatenablog.jp

今回もこの構成で行こうと思っていますが、docker周りが複雑で分かりづらかったのと、自分のリポジトリとして公開してもいいかなと思ったので取り組みました。また、Re:VIEWがちょうど3.0.0になったので、良い機会だと思いました。

目次

「依存性逆転の原則」の自分なりの解釈

「依存性逆転の原則（DIP：Dependency Inversion Principle）」に関して考える機会があり、自分なりに言語化できそうなのでまとめます。ご指摘は大歓迎です。

目次

TL;DR

• より安定したモジュールの方向へ依存するよう設計し、ソフトウェアの安定性を高めることが重要
• 不安定なモジュールが 依存されている と修正範囲が大きくなるため、 依存されない ようにしたい。そのために、依存方向を逆転させたい
• DIPは「モジュールへの依存方向は逆転可能」ということを示し、「その方法」を解説している

プログラミング言語 Crystal の解説書同人誌「Introducing Crystal Programming Language」

この記事は Crystal Advent Calendar 2018 の15日目を埋める記事です。

Crystal言語を触ってみたい方に、技術書典５で頒布された同人誌「Introducing Crystal Programming Language」をおすすめします。日本語で書かれており、Crystalの基本的な文章から開発方法まで網羅しています。

crystal-jp.github.io

トップページの説明を抜粋します。

Crystal の基本的な文法から Web アプリーケション・ CLI 開発の方法まで解説したこの一冊があれば、Crystal での開発を今日から初めることができるでしょう。

Web上でも閲覧できますし、PDF版もダウンロードできます。Crystalに興味のある方はぜひご参考にしてください！

Crystalの自作CLIビルダーライブラリを使ってgitコマンド風のCLIツールを作ってみる

この記事は Crystal Advent Calendar 2018 の３日目の記事です。

自作のCrystalのCLIビルダーライブラリをアップデートしたので、AdventCalendarに便乗して紹介します。

githubは以下です。 clim と言います。簡潔に、直感的にCLIツールを書けることを目指しています。

github.com

過去に紹介したブログ記事はこちらです。

at-grandpa.hatenablog.jp

この記事が古くなったのでupdate記事です。

目次

技術書典５でチャレンジしたこと・うれしかったこと

おつかれさまでしたー！めちゃくちゃ楽しかったですね！

#技術書典 撤収完了しました😆一般参加、サークル参加のみなさまご来場ありがとうごさいました🎉🎉🎉また来年、春の技術書典6でお会いしましょう🙏 pic.twitter.com/CPXL5UuY06

— mhidakaあ11@技術書典5 (@mhidaka) October 8, 2018

次回に向けてのメモと感想を書いていきます。ブログを書くまでが技術書典。

【技術書典５】執筆から入稿までをちょっとまとめておく

長かったーーーーー。

無事、入稿が終わって 10/08 には物理本を頒布できます。

入稿完了したあああああ🎉 当日頒布できます！💪

前回の「におうコードの問題集」（84ページ/1000円）から大幅パワーアップして、今回は倍の160ページ/1500円です！新刊&既刊の同時購入の方は2000円です。全てPDF付きです。

長かった〜〜😂当日お待ちしています！https://t.co/PsjvKWvfbJ #技術書典 pic.twitter.com/3lgVfSTylR

— at_grandpa@技術書典5-け33 (@at_grandpa) 2018年10月2日

台風25号さんには来場をご遠慮願いたいです。（来たら来たで「やっぱり技術書典だな」となりますが）

目次