きり丸の技術日記

技術検証したり、資格等をここに残していきます。

3ヵ月間のブログメンタリングの卒業

2020/10-2020/12の3ヵ月間、カックさんにブログメンタリングを受けていました。

いろいろとお世話になったので、卒業ブログとして残すことにします。

そもそも、ブログメンタリングにつきましては、次の資料をご覧ください。

ブログメンタリング行った理由

ブログメンタリングを受ける際に、カックさんに次のDMをしました。


・なぜ希望するのか(★重要) 100記事投稿しましたが、まだ読者数が多くはありません。 自己ブランディングができていない点と、ブログとして魅力が少ないという点が考えられるので、1記事あたりの品質アップを狙いたいです。

・好きな(これから好きになりたい)技術領域 QA方面に能力を特化させようと考えています。 サーバサイドとしてはjava、設計も好きです。

ブログノルマ


私のブログノルマは週2でした。

週3でも達成できたでしょうが、最初からアドベントカレンダーを見越していたので週2でとどめました。

週2投稿できなかった週はなく、安定して投稿できました。

Twitter等の推移

Twitter


タイトル メンタリング前 メンタリング後 増分
Twitterフォロワー 408 452 44
Twitterフォロー 624 684 60
Twitterフォロー比率 0.654 0.661 -

Twitterのフォロワー数だと、3ヵ月で44人増えていますがフォローは一方通行なのが多いですね。すでにフォロワーが大量にいる有名人に対してフォローしていることもあるので、フォロー返しは特に期待していません。

f:id:nainaistar:20201229223749p:plain

はてなブログ

タイトル メンタリング前 メンタリング後 増分
ブックマーク 3 21 19
読者数 16 26 10
Star 140 225 85

いままでブックマーク数1桁だったのが7倍になっているから、ありがたいことです。読者数も元の数に比べると大きく増えてますし、Starにいたっては85も貰えています。

f:id:nainaistar:20201229223804p:plain


比較のために、メンタリング前の2ヵ月を含めています。

ページビュー数
8月 1474
9月 1972
10月 3408
11月 7010
12月 5494

メンタリング期間中:16171。

映画感想が混ざっているので技術ブログとしての価値のないPVもありますが、そのPV数4145を抜いても有意に増えています。

f:id:nainaistar:20201229223822p:plain


投稿数
10 19
11 10
12 27

11月は12月のアドベントカレンダーのための準備期間だったので、投稿数は少なかったです。

ただ、週2投稿は維持できました。

f:id:nainaistar:20201229223838p:plain


ホットエントリ入りはできませんでした。残念。

のちほど振り返り感想もしますが、次のスライドのフェーズ3の内容ではない記事が多いので、仕方ないですね。

  • フェーズ1
    • 忘れないようにメモを残したい
  • フェーズ2
    • 理解を整理してもっと詳しくなりたい
  • フェーズ3
    • 誰かの役に立ちたい
  • フェーズ4

メンタリング期間中にもっとも人気のあった記事は「新しいGoogle Analytics(GA4)をはてなブログに適用する」でした。

はてなブックマーク数が7、はてなスター数が21と、じわりじわりとアクセス数を伸ばしています。

ポテンシャルとしてはホットエントリに入ってもおかしくはありませんが、「GA4を適用したい」「はてなブログ使用者」というターゲットが狭いのと、困ったときに検索される記事ですので一気にブックマークがつくような記事ではありません。 nainaistar.hatenablog.com

感想

良かったこと


自分のブログのTypoが非常に多いことが分かりました。

textlintを導入しても、音読しても、2-3回読み直しても、ぜんぜん治らなかったので独自の拡張ルールを定義しています。

基本的にはPCからの閲覧のみを考えていたので、PCでのプレビュー確認は行っていましたが、スマートフォンからの閲覧が最悪だったのは気付いていなかったです。

特にこのブログはGoogle Adsenseを導入しているので、レイアウトがひどいことになっていることは気付いてませんでした。自動で広告を付与しているので、Google側でアップデートが入っていると大変なことになっていることがありますね…。


今でも品質が上がった、とはいえないかもしれませんが、少なくともメンタリングを受ける前よりもマシになったように思えます。

迷走していた自己ブランディング


自分のせいですが、自分が迷走しているフェーズでブログメンタリングを頼んだのは悪かったと考えています。

PV数アップやホットエントリ入りを目指すためにも、自己ブランディングを「品質・QA」のエンジニアとして認知されることとしました。というのも、私の強みは「生産性」と考えていましたが「品質」に対して苦言を呈されることが多かったです。自分はパレートの法則の「80%の完成度を到達するには2割の努力で到達できるが、残りの20%の完成度を満たすには8割の努力を必要とする」ということを忠実に考えて、80%の完成度を常に目指しているだけなんですが…。

実際、今回のブログメンタリングの際にも、Typoが多く品質が悪いことを指摘されました。

ですので、品質を担保できる仕組みが作れるのであれば、生産性を維持しつつ品質を担保できる前線エンジニアとして活躍できると考えていたからです。また、品質に難があるといわれがちな私に品質担保できるのであれば、汎用的に品質が担保できると考えました。

その経緯から、「品質・QA」に特化したエンジニアを目指そうと考えていましたが、業務で品質・QAを行っているわけではないので業務でのネタは無く…。設計とかテスト観点等を考えるのは楽しいのですが、ブログとしてブレークダウンできるほどのネタもなかったです。悪い言い方をすると趣味レベルでしかありませんでした。

この乖離状態でメンタリングしても、適切な状態にはならないでしょう。

Twitter等のSNSでも、特に技術系の話は呟いてなかったですからね。SNSでのファンを増やす活動はあまりしてきませんでした。Google Testing BlogのRTしたり、意訳したものを発言したりしましたが、全体から見ると微たるものではありました。

余談ですが、私の強みは「生産性」ではありません。経験済みの引き出しから素早く取り出せるというだけで、未経験の領域に対しては「生産性」を発揮することはできません。訓練した結果「生産性」が高くなったというだけです。「生産性」が出るまで何度も訓練することができる「忍耐力」にあるようです。

これは副業先のCEOにも、今回メンタリングしていただいたカックさんのお二方から指摘していたいたので、今後の自分は胸を張って「忍耐力」が強みといえそうです。

あとはこの「忍耐力」を発展させた上で、ちゃんと周りにアピールできる自己ブランディングを見つけていきたいです。

中途半端にブログメンタリングを実践していた


これも私の良くない点ですが、ブログメンタリング参加前から卒業生の記事を既に確認し、どうすれば継続的にブログを書けるのかという点を既に実践していました。

つまり、本来メンタリングを受ける前にメンタリング後に指摘されることをいくつか実践してしまっていたので、継続することに関しては問題ありませんでした。

ノルマ未達にならないことはいいことですが、中途半端に先回りしてしまった感がぬぐえません。

実施期間中はノルマを気にせずにメンタリングを楽しめました。

独りよがりな記事になりがち


メンタリングで指摘されましたが、正直どう表現すればいいか分からないところです。

このブログを見てくれたからには、自分の持ちうる情報・感情も含めて表現して元のドキュメントにはない情報を追加するべきだと考えていました。ただし、その情報はあくまで「きり丸」のなかで有用でも、他者にとっては不要な情報です。

ホットエントリ入りを目指すのであれば、できるだけ追加属性を削ぎ落して、汎用的な情報の方が好まれるのは分かるのですが…。追加情報を削ぎ落した先にあるのは公式ドキュメントで、そもそもブログにする価値がないようにも感じます。

あとは、既にQiita、Zennとかクラスメソッドで既に紹介されていたりすると、そちらを参照したほうが早いとも感じてしまいます。

と、なると最新アップデートや誰にも知られていない情報等々、「誰にも紹介されていない情報を紹介する」以外の記事には、自分のメモ以上の価値が無さそうです。

また、私の性質として独りよがりな記事になることは仕方なさそうです。最新の情報を追っているよりも、困ったことをメモとして残したい気持ちの方が大きいです。個人メモを脱せないのも、ユーザーヘルプのQ&Aを意識しているので次の構成になることが多いです。

  1. 解決したい課題(ブログタイトル)
  2. 課題を解決できる機能・ライブラリ名
  3. 使い方

設定値の根拠を示せればいいですけど、感覚値も多いです。

私はこういう根拠のための裏付け情報を得る方法がわかりません。決定の根拠を求められるスクラムマスターのロールで働いている人には頭上がりせん。仕事で設定値を決めるときは、「現行踏襲」「他システムの値を追従」で逃げることも多いので…。

根拠を示せれば、今後のキャリア形成も含めて有利にはなるんでしょうが、今のところは苦手です。

終わりに

ブログメンタリングを受けて良かったです。

自分がまだ自己ブランディングできる位置にいない・自分の性質上自己ブランディングに昇華させることは難しいことを自覚できるだけでも、収穫はありました。また、人に教わるのが得意ではないのも改めて自覚しました。

今後もブログは週1以上で投稿する予定です。既にブログのストックは7記事あるので、2月まで新規記事を書く必要はありません。

今年は雑記も含めて142記事書きましたが、来年は技術記事のみで90記事を目指していきたいと思います。

参考資料

敬称略。

以降、ブログメンタリング卒業ブログ。

ryoKawamata note.com

kotaroooo0 kotaroooo0-dev.hatenablog.com

niwaka_plus66 www.niwaka-plus.com

serip39 serip39.hatenablog.com

動いているDBからテーブルやER図をDockerで生成する(Schema Spy)

テーブル定義やER図は自動生成できると楽です。また、本番環境のDBから生成できるともっと便利です。

テーブル定義やER図を自動生成するツールはたくさんありますが、現在のプロジェクトで使用しているSchema Spyを紹介します。GitHubのStar数が1600もあるので、多くのプロジェクトで使われていることでしょう。

なお、それなりに歴史があるツールですので、使い方等は今回の記事で解説はしません。今回の記事はあくまで「素振りしてみた」程度の内容になっています。

環境

Schema Spyから生成されるサンプルHTML

Schema Spyを使用すると、HTMLファイルが自動生成されます。先にどのようなサンプルが出力されるかを確認し、開発・運用・引継ぎに使えるか確認しましょう。 schemaspy.org

使い方

参考元のQiita記事を見ていただけると十分です。

docker run -v "$PWD/schema:/output" --net="host" schemaspy/schemaspy:6.1.0 \
 -t <DB種類> -host <DBホスト名/IP>:<ポート> -db <DB名> -u <DBユーザー名> -p <DBパスワード>

実際に実行したコマンド

Windows環境で実行する場合は、PowerShellで実行してください。コマンドプロンプトだと$PWDが解決できません。私がQiitaのとおりにできなくて四苦八苦した理由がそれでした。

docker run -v "$PWD/schema:/output" --net="host" schemaspy/schemaspy:6.1.0 -t pgsql -host localhost:5432 -db database -u user -p pass

今回の場合は、アドベントカレンダー2020で使用した次のリポジトリのDBを取得しています。ローカルで立ち上げているDBの定義を取得していますが、本来は本番環境、または本番相当環境を指定すると正確なDDLが取得できます。

JavaであればDBのマイグレーションを管理するFlywayがあるので、余計なことをしていなければローカルDBで十分ですが。

github.com

終わりに

CIで常に最新のDB定義を出力したい場合は、ローカルではなく検証環境を指定するといいでしょう。GitHub ActionsでローカルのDB定義を出力しようと思いましたが、DBの準備だったりFlywayの適用だったりと下準備が面倒そうだったので、諦めています。

毎回手動でテーブル定義を生成するのは面倒ですので、できるだけCI等で自動的に作成する仕組みを作れると良いでしょう。


この記事がお役に立ちましたら、各種SNSでのシェアや、今後も情報発信しますのでフォローよろしくお願いします。

参考

敬称略

kamukiriri:DockerでサクッとDBからER図を作成する qiita.com

公式Schema Spyリポジトリ github.com

f:id:nainaistar:20201228233250p:plain

『ここはウォーターフォール市、アジャイル町』の読書感想

翔泳社翔泳社ブックアンバサダーを100名募集というサイトにて、翔泳社の本の感想をSNSを通じて発信するアンバサダーを募集していました。応募したところ、私が奇跡的に選ばれました!

いくつかの推薦タイトルの中から、もっとも面白そうな『ここはウォーターフォール市、アジャイル町』を選んで読ませていただきました。

f:id:nainaistar:20201227105613p:plain

感想ハッシュタグ

#ここアジャ

SNS時代だからでしょうか、本の感想を上のハッシュタグで呟いてほしいと公式から発表されるのはわかりやすくていいですね。この本に関してはブックアンバサダーを募集しなくても良かったのでは、と思うくらい他の感想がすでにありました。

平鍋 健児さんと著者の沢渡 あまねさんと新井 剛さんの対談動画もこちらのハッシュタグから見つけました。

あなたの職場は半径5mから変わる!「ウォーターフォール市、アジャイル町」インタビューagile-douga.tv

読書時間

2時間程度。

アジャイルラクティスに関してはすでに理解しているので、私はサクっと読めました。

難しい内容を語っているわけではないので、一般的には3時間くらいで読めるのではないでしょうか。

著者

読んだうえでの本の想定ターゲット

  • 思考停止した組織に所属している人
  • その中でもなんとかカイゼンしていきたい人
    • 年次は問いませんが、何をやれば全く分からない人向けなので対象年齢は若めだと思いました

アジャイルの基本を学ぶことはできますが、メインターゲットではない気がしました。

読もうと思った理由

  1. 発売後にTwitterでよい反応を多く見かけた
  2. 他にも沢渡さんの別の本を持っている
  3. カイゼンジャーニーを持っている
  4. アジャイルを再勉強したかった

私はSIerウォーターフォールを経験後、現職にアジャイルをやるために転職しました。しかし、会社の仕事がアジャイルに向いておらず、ウォーターフォールに開発手法が戻ってしまいました。こんな感じの部署もあったんですが、今は無くなってしまいました。

『ここはウォーターフォール市、アジャイル町』というタイトルから、ウォーターフォールでも忘れてはならないアジャイルマインドを勉強できると思い、読むことにしました。

あらすじ

翔泳社から引用。


3月のある月曜日。大手精密機器メーカー、ハマナ・プレシジョン株式会社に勤める相良真希乃は、マーケティング部門から情報システム部門への異動を通達される。着任早々目にしたのは、見切り発車で問題だらけのシステム、地獄絵図のヘルプデスク、開発チームと運用チームの格差、融通の利かない上司、忙殺されイラ立つスタッフたち……。真希乃はなんとかしなければと思うものの、周囲は変化することに拒否反応を示す。そんなとき、ある勉強会でアジャイルと出合い、ウォーターフォールと共存できることを知る。「無力感」に包まれた現場を変える真希乃の挑戦が始まった。

感想

内容について


運用チームに異動した主人公が、クレームだらけの現状を打破するためにカイゼンを進めていく小説形式の話です。プロジェクトが木こりのジレンマで硬直してしまうことが多いので非常に共感できます。

感情起因での行動が多いので、私は開発チームですが共感できる場面が非常に多いです。

「小さくやる」「導入しても辞めてもいい」等々の行動を後押する言葉が多いです。また、「『わざわざ』を『ついでに』に変えるのが業務改善のポイント」等のいかに思考停止状態から行動誘発する仕組みにするかも記載されています。

いかに個人の活動からチームへの活動、組織への納得方法、チームを跨いだクロスファンクションチームの活動等に拡大させていくかということも書かれているので、参考になります。

各章について


主人公たちに寄り添った精神や行動「無力感」「さらなるセイチョウ」等が各章のタイトルにになっています。最低限、各章だけ読んでも時系列が分かりやすく小説として読みやすいです。更に各章にKeywords設定されているので、読む前に内容を察することがきますし、後で読み直すときにも振り返りやすいです。

ウォーターフォールの否定をしていない


ウォーターフォールの否定をしていないのはいい点です。ウォーターフォールにもメリットがあるとわかるだけで、勇気を貰えるでしょう。

アジャイルをメインに推進しているとウォーターフォール型の別組織から「アジャイルだか何だか知らないけど意味あるの?それ。」と拒絶反応をされます。されました。

また、アジャイルを導入しても論理的にメリットを説明できなければ、最終的には現状維持と変わりません。それよりは、この本のように感情から現場をカイゼンしていった方が上手くいきそうです。

この本で学べないこと

という点から、アジャイルスクラムで大事な「未来予測」と「過去分析」のうち、「未来予測」については学べません。

開発チームであれば、今週の開発タスク分解や来週以降の開発タスクの優先度付け等があります。作れば将来必ず売れるものなどわかりませんから、仮説を立てて価値を検証していく必要があります。※仮説検証は運用チームでも必要です。

私が開発チームですので、運用チームのことは分かりませんが、運用は開発に比べると不確実性のある未来に対してアクションをすることは少ないと思います。

また、逆にいうと「過去分析」だけでも300ページ弱の本にもなっています。「過去分析」だけでもこれだけのエッセンスがあるので、運用チームを題材にしたことは非常に良かったと思います。

私の追加情報

ホワイトボードの注意


どれくらいの大きさのホワイトボードを用意するかに寄りますが、置き場所によっては消防法に引っかかってしまいます。私の現場ではチームに1つホワイトボードを用意してもらって、カンバンを作成していました。しかし、通路に置いていたので避難通路を確保できず、消防法にひっかかるからと撤去されてしまいました。

最初からホワイトボードを用意されているような会社であればいいですが、後からホワイトボードを設置する場合は注意してください。

島の使い方


執務室エリアの島の使い方についてです。どちらがいい、というのは無いので参考程度にしてください。

以前の私のチームでは、1つの島を1つのチームで使っていました。ただ、実際に1つの島でチーム作業してみると、効率が悪い点が目立ちました。

  1. 対面席でもモニターで顔が見えないので声をかけづらい
  2. ペアワークをする際に、島をぐるっと回る必要があるので移動が面倒

なので、通路を挟んで1つのチームとして使っていました。ペアワーク、モブワークするのに集まりやすく、効率は良かったです。

f:id:nainaistar:20201227105428p:plain

Backlogはいいぞ


この本に挙がっていたタスク管理ツールのBacklogは私も愛用しています。

わたしのBacklogの紹介記事はこちら

第4章の解説ページにて、タスクからフェーズを追加したほうがよい、と記載されています。しかし、親子関係のタスク作成はBacklogだと有料版の機能となっています。便利ですが無料版では使えないので、注意しましょう。

ちなみに、JiraやRedmineからの移行ツールもあるので、第4章変化の冒頭にあった各チームでバラバラに管理していた運用ツールの統合は比較的やりやすいです。

終わりに

この記事がお役に立ちましたら、各種SNSでのシェアや、今後も情報発信しますのでフォローよろしくお願いします。

本のリンク

翔泳社リンク www.shoeisha.co.jp

Amazonリンク

類似記事

タスク管理・TODO管理ツールにはBacklogがオススメ nainaistar.hatenablog.com

参考記事

翔泳社ブックアンバサダーを100名募集 www.shoeisha.co.jp

翔泳社ブックアンバサダー

知っておくべき、オフィスのレイアウトに関わる消防法の知識 shokuba-design.jp