把手付けたような開発ブログ

スクラムマスター/ソフトウェアエンジニアとしての学びをつらつらと

ChatGPT にエレベーターピッチを書いてもらう遊び

遊び AI

どうも皆さんこんにちは。
鞍馬ぽめると申します、よろしくお願いいたします。

はじめに

最近至る所で話題になっている OpenAI が開発した AI チャットサービス ChatGPT
ぼくも流行りに乗っかって遊んでみました

エレベーターピッチを書いてもらってみた

今更書くことでもないかもしれないですが、 エレベーターピッチ について軽く紹介しておきます

アジャイルサムライを引用させていただきます


アジャイルサムライでは ごく短い時間でアイデアの本質を伝えるための手段 と紹介されており、以下のような効能があるものとされています

  • 明快になる
  • チームの意識を顧客に向けさせられる
  • 核心を捉える

またアジャイルサムライでは２センテンスで表現するための下記のようなテンプレートが紹介されています

今回はこれを こちらから一切のコンセプトを提示することなくフルスクラッチから ChatGPT に書いてもらう という遊びを思いついたので試してみました

先にお伝えしておくと、エレベーターピッチのテンプレートに則って書き出してもらえたわけではございません
ただ、個人的にはエレベーターピッチを書くに充分足りる情報を教えてくれたと思っておりますので良かったら最後まで遊びに付き合ってやってください

プロダクトの方向性を問う

全くなにも用意していないので、ひとまずどんなプロダクトを作るべきかを教えてもらいました

どうやら 再生可能エネルギー市場 がおすすめのようです

続けて再生可能エネルギー市場に刺さりそうなプロダクトのコンセプトを教えてもらいました

この時点でだいぶワクワクしていました
どれも確かにそれっぽくて、雑な質問にもかかわらず答えてくれることに感動しました

誰にとって価値あるものなのかを問う

再生可能エネルギー市場なんてぼくにとっては完全に専門外なのでペルソナイメージがつきません
ということでこれも聞いてみました

次いで、そのペルソナについてもっと詳しく知るために、彼らがどのようなペインを抱えているのか、そしてなぜ今回のプロダクトがソリューションになり得るのかを聞いてみました

なるほどなあ
真偽は定かではないですが、このように説明されると確かにそういう悩みを持っていそうだなと思えてきました

既存プロダクトとの差別化

ここまででプロダクトのコンセプトやターゲットとなるペルソナがわかってきました
次に競合となるプロダクトが既に存在するのかを聞いてみました

差別化のことについても聞こうと思っていたのにむこうから提案してくれるのはすばらしいですね

具体例を出してくれるのがすごいですね

教えてもらったものをもとにエレベーターピッチを書いてみる

もうここまで来たら名前も考えてもらいましょう

プロダクトの名前決めるのってなかなか悩みますよね
たくさん候補を出してくれるので助かります

さて、ここまでで ChatGPT さんはたくさんの情報をくれました
これをもとにエレベーターピッチのテンプレートに当てはめてみようと思います

[煩雑な作業から解放され、より効率的な運用を可能に] したい  
[再生可能エネルギー発電所のオペレーター] 向けの、  
[Renewalytics] というプロダクトは、  
[エネルギー生産データの分析ツール] です。  
これは [運用状況に関するリアルタイムのデータを提供することで、問題の早期発見や予防が可能となり、発電量の最適化やメンテナンスの計画立案などに役立てること] ができ、  
[再生可能エネルギー発電所の設計と構築を支援するソフトウェアや再生可能エネルギー発電所向けの監視・制御システム] とは違って、  
[再生可能エネルギー発電所のメンテナンス管理に関する機能や、再生可能エネルギー発電所の設計や建設に関するコンサルティングサービス] が備わっている。

できました、凄すぎませんか
なんか、それっぽいですよね

まとめ

今回の遊びの直接的なことではないですが、個人的に興味深かったのは、返答の内容が 発電所も含めてプロダクトとして捉えること大切 だということを伝えようとしているように読み取れたことです
システムを導入するだけの部分最適ではなくて、フローを見直そうとする全体最適な考え方は好きです

さて、なにも用意がない状態からそれっぽいものが作れてしまいました
ただ、今回できたものがどれだけ現実的なのかは、やはり専門知識を持っている方へヒアリングを行ってみたり、検証してみたりしなければ判断できないですね

とはいえ個人的にはなかなかに面白い結果が得られて楽しめたので遊びとしては十分でした
このままいくとユーザーストーリーを考えてもらったり、価値探索の優先順位を考えてもらったりして、プロダクトバックログのリファインメントまでしてくれそうな予感さえします
更にそこからコードを自動生成してもらって、、、と考えると本当にぼくらの仕事がいつ奪われても不思議じゃないように思えてきますね

遊びに付き合っていただきありがとうございました

ドメイン駆動設計をスクラムで実践する方法について考えてみました

アジャイル スクラム アーキテクチャ

どうも皆さんこんにちは。
鞍馬ぽめると申します、よろしくお願いいたします。

はじめに

先日、実践ドメイン駆動設計（以下、 IDDD 本）を読了しました


幼い頃から読書が苦手なぼくにとって、 600 ページを超える鈍器のようなこの一冊を読み切るというのはひどく根気のいるものとなりましたが、これまで DDD に関する優しい書籍で積み重ねてきた知識の地盤を埋めてくれるような価値ある知識が得られたことは間違いありません

DDD を勉強する上でこの本を一読することは欠かせない なというのが素直な感想ではありますが、そんなぼくもまだ エヴァンス本 は読めていないですし、その価値を理解した上でも簡単に人に勧められるボリュームでもないなと思っています

もし需要があればぼくのように読書が苦手な人向けに、ぼくがどのようして IDDD 本を読み進め理解を深めたのかについてまとめてみようと思います

アジャイルを前提とする DDD

IDDD 本のだいぶ序盤にも書かれてますが、 DDD はアジャイル開発を前提 としています
たしかに、ドメインエキスパートと開発者の間で対話を重ねながら問題領域の分析を進め、解決領域を見つけ、ユビキタス言語の定義とモデル駆動で開発サイクルを回していく DDD の手法は、ウォーターフォール型の開発では無理が出てきてしまうと思います

普段ぼくは、スクラムをベースにアジャイルコーチとしてお仕事をさせていただいているので、今回はアジャイルを実践するフレームワークであるスクラムと DDD の親和性について考えてみることにしました

DDD は技術至上主義の考え方ではない

特にエンジニアの方は DDD と聞くと、「値オブジェクトとかを使ってコードの堅牢性を高めるためのデザインパターン」のようにイメージされる方がいるかと思います
ぼくも DDD をちゃんと勉強する前はそのように捉えており、いわゆる戦術的設計の武器を扱えるようになればエンジニアとしては DDD できていると言えると誤解していました

しかし IDDD 本を読んで理解した DDD の本質は戦術的設計の武器を使いこなすことではなく、 ドメインエキスパートと開発者がユビキタス言語とドメインモデル図を通じて言語の壁とドメインに対する認知差を減らし、共に手を取り合ってプロダクトを成長させていける ことにあるということでした

DDD においては、戦略的設計によって開発者もドメイン分析に加わることで戦術的設計がその真価を発揮します
ドメインエキスパートのメンタルモデルをプロダクトに反映できるという構造から戦略的設計こそが重要であり、故に技術至上主義の考えではないのです

スクラムにおけるプロダクトバックログアイテムの詳細化具体化

スクラムにはさまざまなイベントが定義されておりますが、プロダクトバックログアイテム（以降、 PBI ）をスプリントプランニングの俎上に乗せるためには Ready な状態になっている必要があります

チームによって Ready の定義は異なりますが基本的には詳細化具体化が済んでおり、開発者だけでタスク分割ができるようになっていることが求められます

2020 版のスクラムガイド では各項目の説明に内包されてしまいましたが、 PBI を Ready な状態にしていくイベントを プロダクトバックログリファインメント と呼びます

PBI はプロダクトバックログに追加された時点では「誰に、どんな価値を届けるか、それはなぜか」くらいの抽象的な記載しかされておらず、プロダクトバックログリファインメントにおいてプロダクトオーナーと開発者との会話により Ready な状態にしていきます

プロダクトバックログリファインメントと DDD の戦略的設計

Ready な状態にするためには、どのようにして会話を進めていけば良いでしょうか
ぼくはここに DDD の戦略的設計が使えるのではないかと考えました

前述した通り DDD ではモデル駆動で実装を進めていくのですが、 「モデルの初版ができていること」を Ready の定義のひとつとしておく 1 ことで、プロダクトバックログリファインメントではドメインモデル図とコンテキストマップ、ユビキタス言語の定義を成果物とする DDD の戦略的設計で用いられる手法を適用することができるようになります
もちろんそれらの成果物が整っている状態なので、スプリントプランニングやスプリント期間中の活動も、戦術的設計を駆使した開発に集中することができるようになります

スクラムと DDD の親和性

先述の通り DDD はアジャイルを前提としていることもありますが、前項のように当てはめられることからアジャイルのフレームワークであるスクラムとの親和性は高いと言えると思います

それどころか、ドメインエキスパートとしての プロダクトオーナーのメンタルモデルをよりプロダクトに強く反映できるようになり、逆に開発者のメンタルモデルもプロダクトオーナーに理解してもらえる繋がりが生まれる ため、プロダクト開発チームとしての力がさらに向上すると思います

ぼくの知る限りでは、「プロダクトバックログリファインメントをどのようにして進めるか」の手法はまだあまりスタンダードなものがないように感じてます
もし上手く回せていないと感じているチームがあれば DDD を導入してみるのはいかがでしょうか

ちなみにこの辺の内容を Miro を使ってまとめてみましたので、良ければこちらも目を通してみてください

これから

実は今支援先のチームで DDD の導入を試みております
現行サービスのリアーキテクチャに合わせて開発者だけで試験的に導入している状態なのですが、想像以上に馴染んできており驚いています

とは言えこれは、すでにサービスとして存在しているものだからこそなんとか開発者だけでもドメイン分析ができている状態にあるという実感もあります
新しい領域を攻めることになれば途端に多くの戸惑いが生まれるようになることでしょう

まずはこのリアーキテクチャで小さな成功を作り、ゆくゆくはチーム全体として DDD を実践していけるよう支援を続けていきたいと思います

  1. 初版としているのは実際に実装に入ってみるとドメインモデル図が無理を言っていることがわかってくることもあり、スプリント期間中にもドメインモデル図を直すことは当たり前に出てくるためです↩

AWS Certified Solution Architect Associate に合格しました

どうも皆さんこんにちは。
鞍馬ぽめると申します、よろしくお願いいたします。

はじめに

AWS を初めて利用したのは 2017 年頃
その後５年くらい使ってきてましたが、ずっと「なんとなく」で使ってきました

今回はそんなぼくが先日 AWS SAA に合格できましたので、どうなふうに学習を進めてきたのかと受験にあたってちょっと困ったことが起こりましたので、そのへんの話を記してみようと思います

badge
aws certified solutions architect associate

学習前の知識レベル

まず、学習前の自分のレベルを知るために、ノー勉の状態で AWS WEB問題集で学習しよう さん（以後、 koiwa の問題集）の 模擬試験 を受けてみました

結果は 360 点、、、惨敗でした

これまでの AWS の業務での使用は

  • 開発者としてインフラエンジニアが構築した AWS 環境上でのアプリケーション開発
  • エンジニアリングマネージャとしてインフラエンジニアとインフラ構成の設計検討

程度でしたので、抽象度の高い使い方しかしてきておらず、具体的な部分は全く理解できていないことがはっきりとわかりました

正直５年間も使ってきていて、主要サービスの概要は理解できていると思っていたので、「なんだかんだ余裕でしょ」と高を括っていましたが、本腰入れて学習しないと受からないことに気付かされました

学習のすすめ方

ちょうど SAA を取得しようと決めたときに、会社の同僚が合格したことを報告していたので、すぐさまチャットでどうやって対策したのかを伺いました

教えていただいた進め方としては koiwa の問題集、 80~145 セクションを解く という方法でした

それを聞いたぼくは以下の方法で学習を進めることにしました

  1. セクション 90~130 を解く
  2. 明らかに分かる問題も含めて、回答後の 解説を自分の言葉に翻訳してメモする
  3. だいたい 10 セクションごとに模擬試験を受ける

koiwa の問題集は解説がとても丁寧 で、加えて間違いの選択肢についても「なぜ間違いなのか」が記載されているため、一問につき４つから５つの知識を得ることができました
解説を自分の言葉に翻訳してメモする というのも効果絶大で、次第に頭の中でそれぞれのサービスを使った構成図がある程度描けるようになっていきました

ちなみに模試の結果は

  • 一回目: 360 点
  • 二回目: 490 点
  • 三回目: 630 点
  • 四回目: 750 点

と順調に向上し、 700 点を超えたため試しに一度本試験を受けてみることにしました

ちなみに今回学習を始めたのは、実は去年 12 月末ごろでした
ただ、４月末まではプライベートが忙しく 1 、実際は １ヶ月ほどの期間で 30h ほどの学習時間だった と思います

本試験受験にあたって

本試験はもともとオンラインで受ける予定でした
オンラインで受けられる資格試験は便利でいいですよね
ぼくは受験方法について特に調べもせず、「自宅で手軽に受けられるでしょ～」と考えていました

これが大間違いでした

これから AWS SAA を受験しようと考えている方に知っておいていただきたいことなのですが、 AWS の認定試験は 全く手軽ではありません
以下のような条件があるので注意しましょう

  • 試験日程は事前に予約が必要
    • オンラインであっても一週間くらいは予約が取れませんでした
  • 試験を受ける空間はクリーンデスクと四方すべてに受験に必要なもの以外が視界に入らないように片付ける
  • 試験中は運営から配布される特殊なソフトを起動し、それ以外のアプリケーションはすべて閉じなければならない
    • これがあるので、会社から配布されている PC などでの受験は絶対にやめましょう

想像していたオンライン受験とはだいぶ大きなギャップがありました
ぼくはそのような環境を用意できる余裕がなく、結局お一人様レンタルスペースを借りて受験することにしました

ちなみに２つ目の条件に関しては当日確認が入ります
というのも、 オンライン試験でありながらカメラ越しに試験官にチェックされる んですよ、これがすごく新鮮でした

そして、これが大きな困りごとにつながりました、、、

オンライン試験当日

予約時間の 30 分前には用意しておいたほうが良いという記事を見ていたので、準備万端、レンタルスペースには大げさなくらい早めに入室し用意を済ませていました

そして予約時間になり、配布されているアプリケーションを起動し、表示される手順に従って進めていきました
途中スマホを使って室内の写真を撮影する場面なんかもあり、お一人様レンタルスペースでこれがすごく大変だったのですが、そんなこんなでなんとか試験官とチャットでやり取りするところまで進みました

そして試験官とチャットでやり取りしていると

「お客様のお顔が確認できません」

という衝撃のリプライ

もともと PC のインカメラを使って監督されるということは調べていたので、アプリケーションにアクセス権限は付与していたのですが、その後何度か繰り返しても返ってくるのは

「お客様のお顔が確認できません」

結局、試験官と相談し、後日試験場にて受験することにしました 2 orz...
レンタルスペースの時間まだ余っていたのですが、その日はしょんぼり帰宅することにしました

本試験

その後、改めて本試験の予約を入れ、無事一発合格できました

試しとはいえ一回 15,000 円
なかなか高いので正直緊張しました

模擬試験の時は 30 分くらい時間を残すことが多かったのですが、本試験では時間ギリギリまで見直しに使いました
結果に影響したかはわかりませんが、見直しで２問ほど答えを選び直したので、見直し大事ですほんとに

結果ページへ遷移し「おめでとうございます」の文言が表示された瞬間、受験ブース内ですが思わずガッツポーズをしてしまいました

嬉しかったですね
ぼくは、高校受験も大学受験もしてこなかった人間 3 なので、試験勉強というのはすごく苦手なのですが、苦手だからこそ結果が出ると素直に嬉しいです

これから

今まさにアジャイルコーチとしてのお仕事の傍ら、 AWS 環境構築の案件をひとつ進めております
「あっ、これ、 AWS SAA の学習でやったところだ」が実務で出てきているので、ワクワクしながらお仕事できています
自分の知識が増えただけでなく学んだことが実務に活かせているので、学習してよかったなと思います

ぼくは エグゼクティブとアジャイルチームが一体となった組織を推進できるアジャイルコーチ を目指しています
これを実現するためには技術面ビジネス面両面での幅広い知識と経験が求められます
そのため今後も知識と経験の枝を増やしていきたいと思います

最後まで読んでいただきありがとうございました

  1. この話も後日ブログにあげます↩

  2. この場合受験料は即日返金されました↩

  3. 高校は内申点による推薦枠、大学は内部のエスカレータ枠で入学しているため、人生で入学試験受験経験はないです↩

渋谷で働くゲームエンジニアを卒業しました

自己紹介

どうも皆さんこんにちは。
鞍馬ぽめると申します、よろしくお願いいたします。

退職エントリとかいうやつです

私事ではございますが、この度 2018 年 02 月より約３年半勤めた エルアンドエル・ビクターエンタテインメント（以下 LLV ）を八月末日を以て退職いたしました
今回はその振り返りと今思っていることを退職エントリという形で記してみようと思います

LLV ってどんな会社？

llvictor.com

主にタレントさんのマネジメントや舞台イベントの企画運営などをやっている会社です
面白いことを色々やってる楽しい会社ですよ

入社に至った経緯

もともとは新卒で入社した独立系 SIer 企業でソフトウェアエンジニアとして働いていたのですが、４年目になり「モダンな環境で開発がしたい」「よりユーザーに近い仕事がしたい」「給料もうちょっと上げたい」など、転職に対する意欲が少しずつ湧き始めていました時期でした

そんな時に以前出向先で仲良くしていただいた方から、「知り合いから新規事業を立ち上げる話を聞いたんだけど、エンジニアを求めているらしく話を聞いてみないか」とお誘いいただきました

実際にお話を伺ってみたところ、仕事の内容や裁量、待遇面などどれも素晴らしい条件でしたので、事業立ち上げという不安定さは少し心配にはなりましたが、 「まだ若いし、チャレンジしてみよう」 ということで承諾させていただきました

在籍中はどんなことをしていたの

スクラムマスター と リードエンジニア を兼任 1 させていただいておりました

入社当初

まずはアジャイル開発の導入や技術選定など開発の土台作りから始めていきました

とはいえ SIer 時代は Scrum で言うところの 開発者 として働いており、リード経験はございませんでしたのでどれも手探りでした
幸いなことに自分よりも専門性の高いエンジニアばかりがジョインしてくださったので、ひとりで背負うことなく助けていただきながら進めることができました

ただ、この頃は 「自分が引っ張らないと」という思いが強く、今思うと自分の意志を前面に押し出しすぎていた なとちょっと恥ずかしくなります

ある程度の土台が整ったところでまずはモックアップを作ってみようということになりました
この頃はエンジニア内で意見がぶつかることがとても多かったのですが、 ひとつひとつ時間をかけて話し合うことでお互いの価値観を共有する ことができ、モックアップを作りきる頃にはお互いを尊重しながら自分の意志を伝えることのできるエンジニアチームが築かれていました

ステークホルダーの方々へのモックアップのプレゼンも成功、その後みんなで食べに行った青物横丁の焼肉屋さんは最高でした

開発前期

良いスタートが切れたので本格的に開発がスタートしました

しかし徐々にタスクが溢れるようになってしまいました
やはり、 スクラムマスターとリードエンジニアの兼任はかなり厳しい ものがありました

昼間はスクラムマスターとしての顔、メンバーが帰宅した定時後はエンジニアとしての顔、といった仕事の仕方をしていたため、どんどんパフォーマンスが落ちていきました
周りが見えなくなってきていて、たぶんこの頃はメンバーからの信頼もだいぶ失っていたと思います

そしていよいよ耐えきれなくなりました
今だから言える話ですが、この頃はネガティブな理由で会社を辞めることも視野にいれるくらいには思いつめていました
「自分がやらないと」という思いに対して出せない成果、その現実に押しつぶされそうになっていたんですね

そんな悩みをプロデューサーに相談したところ 「もっと周りを頼って良いのに、むしろ辞められる方が困るよ」 と一言
今思えば当たり前のことなのですが、どうしても「デキるリーダー」はそういうものだと思いこんでしまっていて、そういうものになろうとしてしまっていたのですね
プロデューサーから頂いたこの言葉が転機となり、この頃から少しずつ人にお願いすることを大事にするようになってきました

開発後期

この頃はパートナー企業さんにも助けていただきながら開発スピードが爆発的に上がった時期でした

ぼくはというと社内フレームワークのようなもの 2 を実装仕上げてからはメインの開発業務を離れ、 サーバントリーダー 的な動きを心がけるようにしていました
この頃から徐々にメンバーからの信頼も回復できていたのではないかと自負していますが、思い違いでないことを祈ります

またこの頃からチームの障害を取り除くため、今まで経験したことのない様々な業務を経験するようになりました
監査対応などはその代表的な例で、 監査の方々向けに資料をまとめてプレゼンするといった経験はソフトウェアエンジニアとしては得られないもの であったと思います

様々な障害を乗り越えながらもなんとかリリースすることができ、リリース後はたくさんのユーザー様に愛していただける素敵なプロダクトになりました
ゲーム会社ならではですが、ありがたいことにユーザー様からお手紙などをいただくこともあり、それはどれも感動するものばかりでした

ぼくたちのプロダクトが誰かの人生に少しでも良い影響を与えることができているという実感が、本当に喜ばしいことでした

終盤

リリース後数ヶ月で新しいチームの立ち上げが決まりそちらに異動、その後 事業部長 3 という役職がつきました

またこの頃、改めて Scrum について学び直そうと思い、 Certified ScrumMaster の資格を取得しました

kuramapommel.hatenablog.com

面白いことに 他社様からアジャイル導入支援のご依頼をいただき、簡単なスクラムトレーニングを行ったこともありました
この辺の経験が今回の転職を考える切っ掛けになりました

なんで辞めるの？

「アジャイルコーチという仕事に魅力を感じたから」 というのが大きいです

ぼくは昔から人の成長を支えるような活動が好きでした
具体的な内容はちょっと恥ずかしいので伏せますが、学生の頃からしばしばそのような活動を行っておりました

加えて、これは言うまでもないのですが、アジャイルの考え方がすごく好きなんですよね

そんなぼくにとってスクラムマスターというお仕事はとてもマッチしたお仕事でしたが、アジャイル導入支援のご依頼のお話を頂いたときに、 自分のチームだけでなく様々なチームへの支援をするアジャイルコーチというお仕事にチャレンジしてみたいという気持ちが生まれてきました

そして少しずつアジャイルコーチとしての求人を探し始めました

ちなみに LLV に対してネガティブな思いは全くありません
すごく大好きなチームで毎日楽しく働かさせていただき、数多くの学びある充実した経験を積ませていただき、感謝してもしきれません

沢山の方々に支えていただきながら歩んできた３年半でした

これから

お陰様で無事某社より内定をいただきまして、 アジャイルコーチとして働けることが決まりました
新しい会社のことは時期を見てお話させていただければと思いますが、正直自分でもびっくりするぐらい素敵な企業に拾っていただけたので、貢献できるよう精一杯努めてまいりたいと思います

今は、たくさんのチームを笑顔にしていきたいと考えています
ユーザーの幸せを実現することは幸せなことです、そんな幸せなチームを少しでも増やしていけるようがんばりますので、何卒応援の程よろしくお願いいたします

ちなみにソフトウェアエンジニアとしての活動はひとまず休憩しようと思っています
ソフトウェアエンジニアというお仕事も自分にとっては天職だと考えておりますが、まずは新しい会社のお仕事に集中して、ある程度慣れてきたら副業という形で活動を再開していこうと考えておりますので、その際はお声がけいただけますと幸いです

最後になりますが、在職中お世話になった方々本当にありがとうございました
会社が変わってもまた一緒にお仕事させて頂く機会はあるかと存じますので、引き続きよろしくお願いいたします

最後まで読んでいただきありがとうございました

  1. 兼任はアンチパターンなのでおすすめしません。↩

  2. Success か Failure の結果を持つ Result 型を作って、各レイヤーの処理結果を Result 型でラップしてやり取りする機構。ちなみに今同じことをやるならわざわざ自作せずに louthy/language-ext の Either とか使います。↩

  3. 恐れ多い役職名ですが、プロダクトマネージャみたいなものです。↩

Zenn の books 機能を使ってみました

ポリモーフィズム オブジェクト指向

どうも皆さんこんにちは。
鞍馬ぽめると申します、よろしくお願いいたします。

はじめに

エンジニア界隈でここ数年話題になっている Zenn さんというエンジニア向けの情報共有コミュニティサービスをご存知でしょうか

エンジニアの情報共有サービスといえば、昔から Qiita さんがポピュラーでぼくもよくお世話になっていますが、最近はいろいろな理由から少しずつ Qiita 離れが起こっているようです
Zenn はその代わりとしても注目されていて、最近ではあの クラスメソッドさんが買収した ことでも再度注目された話題のサービスです

Zenn の特徴として books という機能があります

その名の通り、 自ら書籍を執筆して公開できるというユニークな機能 なのですが、今回はその books を使ってみたので、宣伝を兼ねて感想を書いていきたいと思います

どんな内容の本を書いたの？なんで書こうと思ったの？

記念すべき第一作目は 「if しか知らないあなたのためのポリモーフィズム入門」 というタイトルで執筆させていただきました

zenn.dev

内容としては主に プログラミング初学者の方をターゲットに、ポリモーフィズムをボトムアップに解説していくもの となっております
永遠の β 版と称しており、相変わらず拙い内容ではございますが、もしも気になったら読んでみてください
（できればレビューをお願いします）

で、書こうと思った理由は大きく分けて２つあります

  • 最近周りにエンジニアを目指したいという人が増えてきてよく相談をいただくので、その時ぱっと出せる資料を何か作っておきたかった
  • せっかくだから最近話題の Zenn の books 機能を使ってみたかった

こんな感じです

Zenn の books 使ってみてどうだった？

まず、 git で管理できるのが強い ですね
master にマージされたタイミングで自動デプロイまでやってくれるので、そこがめちゃくちゃ便利だと思いました

あとはいくつかの記事を「本」という形でまとめることができるというのがすごく便利です
技術的な情報の共有ってどうしても何段階かステップを踏んで説明する必要があったりすると思うんですけど、それを「本」という形でまとめることで、ページによって段落を表現できるのがわかりやすくていいなと思いました

あと、些細なことではありますが、画像が svg 非対応なのがちょっと残念な点でした
こちらは今後のアップデートに期待でしょうか

とはいえとても便利なサービスなので、今後も使っていきたいと思います

これから

本文内にもありますが、まだ書ききれていない部分が多くあるので、少しずつ育てていきたいと思います
また、他にも書きたい内容がいくつかあるので、チャレンジしていきたいですね

それにしてもテクニカルな内容を公開するのはいつも以上に緊張します
間違ったことを書いてしまっていた場合、特に初学者の方向けの内容だと、誤った知識を与えかねないためなかなか責任が重い ですよね

ただ、若手の頃から思っていたこととして、プログラミング関連の技術書籍って入門レベルのものか専門レベルのものかに二分されていて、 脱初学者レベルのものって極端に少ない ように感じていたんですね
（個人の感想です）

ぼくは専門書を書けるほどのエキスパートになるのは難しいと思いますが、 脱初学者を目指すためのお手伝いならいくらかできるかな と思っているので、そういった情報の共有に今後も挑戦していきたいと思いました

今回も最後まで読んでいただきありがとうございました

初めてのスクラム導入が、なぜ失敗してしまったのか

アジャイル スクラム

どうも皆さんこんにちは。
鞍馬ぽめると申します、よろしくお願いいたします。

はじめに

初めてのお仕事、皆さんはどんな思い出が残っていますか

ぼくのスクラムマスターとしての初めてのお仕事は、完全に失敗してしまいました

結果としてリリース予定を守ることができず、売り上げも伸びず、最終的にはサービスを閉じることとなってしまいました

今回は当時のことを振り返りながら、今後同じ失敗を繰り返さないために、なぜ失敗してしまったのかを考えていきたいと思います

ちなみにすごく長くなっちゃったのと、ポエム感満載ですので、お時間ある時にでもどうぞ

スクラムマスターをやることになった経緯

お仕事の内容はあまり詳しくお話しすることができないのですが、スクラムマスターとして初めて携わったプロダクトは、すごくざっくりとお伝えするとフルスクラッチから始めたゲームアプリでした

当時、スクラムにおける開発者としての経験が一年くらいあったぼくは、今回も是非ともスクラムでやっていきたいという旨を上司に伝えたところ、
言い出しっぺということでスクラムマスターを任せていただくこととなり、そこからぼくのスクラムマスター生活が始まることとなりました

失敗した主な要因をあげてみる

そんな形でスタートしたスクラムマスターとしての活動ですが、失敗につながったと思われる主な要因を 4 つほど上げてみたいと思います

  1. そもそもスクラムに関する知識が足りていなかった
  2. ステークホルダーを巻き込む動きが足りていなかった
  3. リードエンジニアとしての帽子を同時にかぶってしまっていた
  4. 現実と素直に向き合っていなかった

はい、今ならわかりますが、 スクラムマスターとしてやってはいけないこと一覧 みたいになってしまっていますね

もちろん他にもたくさん要因はあると思いますが、今回はこの 4 つを振り返ってみたいと思います

そもそもスクラムに関する知識が足りていなかった

スクラムマスターの役割について スクラムガイドのスクラムマスターの項 には、その一節目に以下のように記されています

スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ。

スクラムマスターのお仕事は

などがあげられますが、どれをとっても必ず必要となってくることが スクラムのプロセスや考え方を深く理解していること です

しかしながら当時のぼくのスクラムに関する知識は、開発者としての経験の一年ほどの知識しかありませんでしたので、全くと言っていいほど足りていませんでした

結果として、以下のような問題につながってしまいました

  • スクラムの勉強会を行うも、 借り物の言葉になってしまう ため、十分に伝えることができない
  • フルスクラッチからスクラムのサイクルに乗せる方法を知らないため、スタートから戸惑いが生じてしまう
  • スクラムのプラクティスを部分的に取り入れたような なんちゃってスクラム になってしまう
  • 失敗した時のリカバリーの仕方も知らないため、ずるずると失敗が積み重なっていってしまう

目も当てられませんね、、、

スクラムにおいて「 守破離 」で進めることは物凄く大切です
特に初めてスクラムを導入するのであれば、丁寧すぎるくらいに「守」して、プロセスと考え方を組織に浸透させることを強く意識した方が良いです

当たり前の話ですが、スクラムマスターの知識が足りていないのであれば「守」で進めることもそれを支援することもできません

ステークホルダーを巻き込む動きが足りていなかった

スクラムマスターの重要なお仕事の中に、スクラムチームとステークホルダーのジョイント役になる（繋がるように支援する）役目があります

当時チームから最も近い位置にいたステークホルダーは事業責任者の方でしたが、チームとステークホルダーのやりとりは全て、その間のポジションの方（ PdM にあたるマネージャ職の方）を介しての伝言ゲームで行われる形になってしまっていました

伝言ゲームによって透明性は失われ次第にチームとステークホルダーはお互いを不振がるようになってしまいました

スクラムマスターとして、 伝言ゲームによって透明性が失われることの危険性 を指摘できず改善を促さなかったため、このような事態につながってしまいました

副次的な作用として、リソース追加の依頼が出しにくくなったり、ビジネスレイヤーの考えが伝わらなくなってしまったりするなど、さまざまな良くないことにつながってしまいました

リードエンジニアとしての帽子を同時にかぶってしまっていた

エンジニアのスターティングメンバーとして参画したぼくは、 リードエンジニア としての役割も任せていただきました

スクラムではスクラムマスターが他のポジションを掛け持ちするのはアンチパターンとされてますが、
スクラムの運用に慣れてきて自己管理化が進んでくると誰かがスクラムマスターを兼任する場合もあるかと思います

そういう時は、「どちらの役での言動か」がわかるように 帽子を被り替えると良い なんて言ったりしますが、ぼくは両方の帽子を同時に被ってしまったわけですね

判断する立場と判断を支援する立場が自分の中でぶつかってしまい、メンバーにも混乱を生んでしまいました

現実と素直に向き合っていなかった

そんなこんなでずるずると負のスパイラル、デスマーチにハマっていってしまったのですが、極め付けはそんな現状を何かしら理由をつけて改善に動けなかったことでした

話はちょっとそれますが、ぼくは何事も 一番成長する瞬間は「ふりかえり」を行った時 だと思っています
継続すべきことも改善すべきことも、振り返りを行うことで明確になり、実践することで今より良くなっていきます

ふりかえりはレトロスペクティブという形でスクラムのプロセスにも含まれていますが、価値あるふりかえりを行うためには 目の前の現実を明らかにして、素直に受け入れることが大切 だと考えています

ただ、当時のぼくは目の前の現実に素直になれていなかったんですね
有意義な「ふりかえり」が行われず、正しくスクラムを回せていない現状をぼくは素直に受け入れることができず、「スクラムをやっている」気になっていました

もともとウォーターフォールでの開発に慣れていたメンバーが多かったことから、開発の進め方は徐々にウォーターフォールを繰り返し行うような形になっていってしまい、
結果としてチームからは「現状はスクラム開発で進めているとは言い難いよね」という声や「スクラムの良さがわからない」という声が上がってしまいました

どうするべきだったか

まず スクラムマスターとしてちゃんとしたスクラムの知識をつける こと、もしくは 知見のある方にコーチングを行なっていただく ことから、スタートするべきでした
Scrum Boot Camp は入門書としてはこの上ない良書ですが、それ一冊の知識を付け焼き刃で身につけただけのスクラムマスターが易々と回せるほどスクラムの実践は簡単ではありません

人に説明するときも借り物の言葉ではなく、自分の言葉で話せるようでなければ、相手に理解してもらうことは難しいです
スクラムを導入するすることでどういった効果が期待できるのかを理解してもらい、スクラムチームのメンバーだけでなくステークホルダーも巻き込んでいくためには、自分の言葉で話せることはとても大切なことです

加えて、 サーバントリーダーシップ を持ってそれを実践していくべきでした
そもそもスクラムの知識が不十分であったことから、そういう考えに至ることができなかったのですが、「 自分が周りをリードしなければならない 」という思いで行動してしまうと、自己管理型のチームは実現できません

最後に素直であることですが、チームをより観察し、良い面だけでなく改善すべき面があることを認め、その改善が行われるように促す動きを取るべきでした
時には誰かが言いにくいようなことを言う必要が出てきます
透明性を確立しアジャイルな開発を成功させるためには、スクラムマスターとしての重要な働きになります

もちろんポジティブなチーム作りとして心理的安全性を確保することが重要なので、その塩梅には気をつけないといけません

その後

結果としてそのプロダクトはサービス終了してしまいましたが、その後二本ほど新作のためのモックアップをスクラムで作る機会がありました

その際にぼくは、スクラムマスターとして以下のようなことを意識して実践しました

  • 正しい知識を身につけるため、 認定スクラムマスターのトレーニングを受け、資格を取得 する
  • フルスクラッチからスクラムを回す方法を いくつかの書籍を跨いで学習 する
  • モックアップ開発に携わる数名に対して、まる２日かけて 改めてスクラムの勉強会を一から行う
  • 仕様や設計について自分から答えを示すことは絶対にせず、 PO と開発チームの直接的なやりとりで次に進めるように 会話の場を積極的に設ける
  • チームを観察し、誰かがうまく行っていないようなときは、 個人ではなくチームで解決するように話題を広げる
  • PO や開発チームからスクラムの回し方で質問があった場合に 自分の言葉で説明する

かなり丁寧なやり方ではありましたが、一週間スプリントの４スプリントでモックアップ一本の完成を目標にとにかく「守」を意識して実践した結果、一ヶ月に一本、二ヶ月で二本のモックアップを残業ほぼ 0 で PO と開発チームが同じ方向に向かいながら作り切ってくれました

この先のことは、またお仕事のことなので詳しいお話しできませんが、失敗から得た学びを活かすことができたと自負しています

これから

アジャイル開発やスクラムは一般的になってきたとはいえ、まだまだ導入がうまく行っていないチームやこれからチャレンジしていきたいと思っているチームも多いと思います

ぼくはそんなチームへのスクラム導入支援として、スクラムマスター、アジャイルコーチとしてのお仕事を今後もっと広げていきたいと思っています

また、より幅広い知識を身につけるように学習を続け、 A-CSM, CSP-SM とスクラムマスターとしてのスキルアップも継続して努めていきたいと考えています

最近は転職も考え始めておりますので、もしスクラムマスターを探している方がいらっしゃいましたら、 Twitter の DM までご連絡ください

めちゃくちゃポエムになってしまいましたが、同じように導入がうまくいっていないと感じている方にとって、少しでもリスタートのヒントになることができていましたら幸いです

今回も最後まで読んでいただきありがとうございました

初めてスライドを公開してみました

アジャイル スクラム スライド

どうも皆さんこんにちは。
鞍馬ぽめると申します、よろしくお願いいたします。

はじめに

スライドを公開するサービスって、いままで使ったことがなかったのですが、 得てきたことを何かしらアウトプットしたい と言うモチベーションと、スライド作る練習も兼ねて、
今回 スクラム開発を実践するための大切な考え方とよく使われるプラクティス とかいう、とても恐れ多いタイトルのスライドを公開させていただきました

マサカリは優しめにお願いします笑

スライドの概要

ターゲットとしては、 これからスクラムを導入しようと思っている方 や、 よくわかっていない状態でスクラムを始めてしまい失敗したなと感じている方 です

内容としては、序盤はアジャイル開発やスクラムのことをざっくりとまとめ、
中盤以降は、ぼく自身のスクラムマスターとしての経験といくつかの書籍から学ばさせていただいたことから、ぼくなりに「 こういう意識を持つことが大切だな 」と思ったことと、「 おすすめしたいプラクティス 」についてをまとめさせていただいてます

書いてみてどうだったか

素直に難しかったです
正直内容はかなり拙いですが、公開することでいくつかご意見いただければ自分の成長にもつながると思い、今の状態で公開させていただきました

仕事の立場上、普段から資料を作って人に何かを説明するような機会はしばしばあるのですが、
ぼくのスタイルは 資料は小さく作って、板書と口頭でその場の理解度に合わせながら動的に説明する 事が多いので、 ペラの静的な資料を読むだけの人に伝えることの難しさ がありました

「 この書き方だと言葉足らないよな 」と思いながらも「 これ以上広げると文字ばかりで見にくくなってしまうよな 」というジレンマがあり、その辺の塩梅がとても難しかったと感じてます

これから

資料作りに慣れたいですね
他にも書いてみたい内容はあるので、少しずつ慣れていきたいです

ちなみに皆さんはスライド公開系のサービスは何を使ってますか
Twitter の方でも同様の質問を投げてみた結果、最近リリースされたばかりの Docswell さんというサービスをご紹介いただきました

すでにいくつかスライドも上がっているようなので、見比べてみようかなと思っています
他にもおすすめがございましたら、おすすめのポイントなども含めてご教示いただきたいです

今回も最後まで読んでいただきありがとうございました

スライド内で紹介している参考にさせていただいた書籍や WEB サイト

今回は SpeackerDeck さんを使ってみたのですが、 SpeakerDeck さんは pdf のリンクが効いてくれないようです
なのでここで参考文献のリンクを貼っておきますね

書籍

WEB サイト