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

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

DX 関連の書籍を３冊読みました

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

はじめに

SIer でアジャイルを広めるお仕事をしていると デジタルフォーメーション（DX） 関連の案件にアサインしてもらうことが多いのですが、ぼく個人としてはアジャイルなチームづくりなど組織全体の変革というよりは１チームへの支援としての役割を任されることが多いです
しかし最近は、チームだけでなく少しずつですが組織全体の変革を考える仕事も増えてきており、この機会に改めて DX の全体感を掴んでおきたいと思い、３冊ほどまとめ読みしてみました

今回はその内容について個人の感想ベースでまとめていきます
具体的な内容については実際に書籍をお手にとって読んでみてください

どんな３冊を選んだの？

今回は以下の３冊を読んでみました




  • REWIRED は案件でおすすめいただき、評判の良さを耳にしていたので選んでみました
  • ソフトウェアファースト は PIVOT を見て共感できる点が多かったため選んでみました

youtu.be

  • DX リーダー必修講義 は著者の方の記事を拝読させていただき、より著者の方の考えを知りたいと思い選んでみました

それぞれの簡単な印象

DX 関連書籍とはいえそれぞれ書きっぷりは異なるので、それぞれに対するおおまかな印象をまとめておこうと思います

REWIRED

「DX の手順書」という印象でした

この書籍には、もはやDXの必要性（Why）はほとんど語られていない【REWIRED: P.002】

と記されている通り、トップダウンに進めていく「何をして、次に何をして、そして何をして」が順に示されている内容でした

図による表現も多く具体的でかつ網羅的なため非常に理解しやすかったのですが、情報量が多いので全て覚えきるのは難しいと思います
必要なときに該当の箇所を再度参照するつもりで、大枠として DX はどのように進めていくのか を知るために読むのが良いと思います

ソフトウェアファースト

REWIRED とは打って変わって、こちらは WHY が多い印象を受けました

私にとってDXとは、ITの中でも最も破壊力のあるソフトウェアを使って、人と組織、事業、そして社会を変革する、ソフトウェアファーストを実現すること【ソフトウェアファースト: P.007】

と記されている通り、ソフトウェアファーストの実現こそが DX であると提言されていますが、 それがなぜなのか、そもそもソフトウェアファーストとは何なのか を全体を通して伝えてくれていました
また、他の２冊と比較して SIer との向き合い方や SIer が今後どうなっていくべきかなど、SIer についての話が濃く書かれていたようにも感じました

DX リーダー必修講義

「アジャイル」「クラウド」「DevOps」「マイクロサービス」「クラウドネイティブ」「プラットフォームエンジニアリング」という６つのキーテクノロジーが、２０００年ごろから現在にかけて どのような理由で生まれてきたのか を当時の背景と合わせて語ってくれていました
ソフトウェアエンジニアにとっては親しみのある技術群をソフトウェアエンジニアのバックボーンがない方に伝えているような印象を受けました

プロダクト主体的な組織構造への変革

改めて ドメインベースのアプローチで事業（プロダクト）主体の組織構造にしていく ことが大切だと理解しました

正しいアプローチは、ビジネスの中でいくつかの重要かつ自己完結型のドメインを特定し、それらを完全に見直すことである【REWIRED: P.036】

REWIRED ではこのように、組織変革を自己完結型のドメインベースでアプローチすることが正しいと述べられています

事業（プロダクト）にかかわるすべての職種が１つのグループになるように組成されます【ソフトウェアファースト: P.278】

ぼくは前職がゲーム会社（音楽会社の社内スタートアップ）だったのですが、組織の構造はゲーム（プロダクト）ごとに別れており、それぞれのプロダクト事でプロデューサやディレクター、ソフトウェアエンジニアやデザイナーなどを抱えていたのでこの考え方にはとても共感できました

また、ソフトウェアファーストと DX リーダー必修講義の両方にチームトポロジーの話も出てきていました
REWIRED には似たような構造として「アジャイル・オペレーティング・モデル」が紹介されていました

図表3-2.1 アジャイル・オペレーティング・モデルの構成要素【REWIRED: P.153】

まだまだプロジェクトベースな組織構造が多いのが実態だとは思いますが、ドメインベースな組織づくりをしていくことは欠かせないことだと改めて認識しました

内製化を前提としている

競争優位を築くうえで中核となるデジタルケイパビリティをアウトソースしないように注意すべきである。（中略）中長期的な視点では、価値創造の土台となるケイパビリティを社内に保持することが極めて重要である。【REWIRED: P.067】

ソフトウェアファーストの根幹をなす「ソフトウェア技術の手の内化」は必ずしも内製開発を意味しませんが、手の内化を進めると必然的に内製化比率は高くなります。従って、内製開発を基本方針とし、内製開発ができない場合やすでに開発を外部委託している場合などの対策を考えると良いでしょう。【ソフトウェアファースト: P.205】

REWIRED でもソフトウェアファーストでもこのように 内製化を前提として考えるべき であると述べられています

企業内プラットフォームが企業としての内製化にとって効果を生むポイントがある。【DX リーダー必修講義: P.205】

また、DX リーダー必修講義では明確に内製化が必要であるとは語られてはいませんが、このように、むしろ言うまでもなく前提としたうえで企業内プラットフォームの構築を勧めているように読み取れました

ちなみに、非ソフトウェア企業がエンジニアを直接雇うということについて、「開発がない時期は無駄な人件費になってしまうのではないか」 という意見をぼく自身も聞いたことがあるのですが、ソフトウェアファーストでは下記のように答えられていました

雇用したエンジニアのやることがなくなってしまうのかもしれないという心配は全く無用です。もしあなたの会社がソフトウェアを使って新しい事業をスタートしたり、既存事業を大きく進化させたりしたならば、ソフトウェアエンジニアがやるべき仕事は次から次へと出てくるでしょう。現代のプロダクト開発は作ったら終わりというものではなく、継続的な改善によってサービスの質を高めていかなければならないからです。【ソフトウェアファースト: P.212】

これはぼくも同じ意見です
デジタルをビジネスのコアとした企業では、むしろソフトウェア開発の仕事が増えていくはず ですし、それはどんどん加速していくはずです
内製化しやすいフロントアプリからはじめ、その領域を徐々に広げていくようなイメージになるでしょう

SIer はどうなっていくか

SIerの事業構造は製品販売とサービスのハイブリッド型になっていると書きましたが、日本のSIerはサービス依存の傾向が強すぎるので、製品販売の比率を増やしていくのも１つの手でしょう。その上で、提供した製品に付随するサービスを手厚くして利益を上げるのです。これを筆者は２階建てモデルと呼んでいます。【ソフトウェアファースト: P.303】

自社製品を持ちつつ開発導入支援も行っている AWS や SAP などがまさにこのビジネスモデル だと思いました
例えばモノをつくるときに、すべてを自分たちでつくらなかったとしても、部品を調達し加工し販売するというのが一般的ですが、これをソフトウェアに例えるといわゆる部品に該当するものは OSS や SaaS でしょう

まさに 部品メーカー（サプライヤー）のような存在になっていく ことが、この２階建てモデルの話だと思います
人月商売で稼ぐのではなく、部品を仕入れて加工し付加価値をつけた部品として販売するという構造はとても健全な考え方だと思いますし、ぼくは 「だれかにとってのサブドメインは、だれかにとってのコアドメイン」 だと思っているのでとても共感しました

まとめ

こんな薄い内容ではなくてどの書籍も本当はもっと充実した内容でしたので、ぜひお手にとって読んでみてください

おすすめの読む順番としては以下のとおりです

  1. ソフトウェアファースト
  2. REWIRED
  3. DX リーダー必修講義

ソフトウェアファーストで WHY と WHAT を理解し、REWIRED を読みながら実践し、途中「この技術ってなんで必要なんだっけ？」と思ったときに DX リーダー必修講義で背景を捉えにいくというのが個人的におすすめです

ちなみに、 今の自分にとって最も役に立ったものは REWIRED でした
冒頭で「組織全体の変革を考える仕事も増えてきており」と書きましたが、やはり具体的な進め方を示してくれているのはとても助かります

ぼくは今後、非ソフトウェア企業の内製化をさらに進めていきたいと考えています（その理由はまた後日どこかで）

www.ipa.go.jp

日本における情報処理・通信に携わる人材がIT企業、IT企業以外に所属する割合は2020年が73.6%対26.4%である。（中略）米国における情報処理・通信に携わる人材がIT企業、IT企業以外に所属する割合は、35.1%対64.9%である。【DX白書2023: P.192】

DX 白書にもあるように、日本における非 IT 企業の IT 人材採用比率は米国と比べてまだまだ低いです
個人的には五分五分くらいには持っていきたいと考えているので、引き続きお仕事頑張っていきたいと思います

『人月の神話』を読みました

ソフトウェア工学 プロジェクトマネジメント

どうも皆さんこんにちは。

鞍馬ぽめると申します、よろしくお願いいたします。

はじめに

プロジェクトマネジメントの必読書として前々から名前は知っていたのですが、先日やっと 『人月の神話』 を読了しましたので、本書の中で個人的に印象に残った部分をまとめておこうと思います
ちなみに全体的にやはりとても難しく、正しく理解できていないところも多々あると思うので、誤りがあればぜひご指摘いただけますと幸いです

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

人月の神話 [ フレデリック・フィリップス・ブルックス ]
価格：3,520円（税込、送料無料) (2025/3/4時点)


なお、読みながらのメモは Twitter の方に呟いていたので、下記ツイートのツリーも覗いてみてください

遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである

仕事の大きさを測る単位としての人月は、疑うべき危険な神話なのだ。人月とは、人と月とが互いに交換できるという意味だからである。【P.14】

遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである【P.23】

線形的な予測は無意味なのだ。100メートル層の記録から予測すると、人間は10キロを17分以下で走れる計算になってしまう。【P.82】

個人的に人月の神話で最も有名だと思っているのが ブルックスの法則 です
納期に対して進捗が悪いときに人員の増加を選択肢にあげることは多々あるかと思いますが、これは逆効果だということを言い表しています

とくにコミュニケーションが増えることによる負荷増を理由としているところが多いように読み取れました

チーム体制の作り方としてモブワークのような外科手術チーム

全員で豚を解体するようなものではなく、外科手術チームのように編成されたチームでなければならい【P. 28】

バベルは、大工事で大失敗した最初の例だった。（中略）彼らにかけていたのは、コミュニケーションとそれから生まれる組織の２点であった。【P.68】

少数精鋭チームが最高である - 人数はできるだけ少ない方が良い。【P.222】

本書では大規模なプロジェクトであってもチームで取り込むこととプロジェクト関係者間のコミュニケーションが取れるようにすることが大事であると伝えていますが、とくに面白かったのが “外科手術チーム” という考え方でした
外科手術チームとは、１人の執刀医を周りのメンバー（副執刀医や管理者など）が助けるようなチームの作り方で、ここでは執刀医をチーフエンジニアに例え、上司や専門家などを含めたチームメンバーが、チーフエンジニアの効果と生産性が上がるように助けるようなチームを編成すると紹介しています

この考え方はまさにモブプログラミングにおけるドライバーとオペレータ、およびモバーの関係に似ていると思いました

継続的インテグレーションのような「毎晩構築」アプローチ

最も有害でとらえにくいバグは、それぞれのコンポーネントを書く人々の間に存在する前提の不整合から発生するシステムのバグだ。【P.130】

変更の量子単位を（中略）非常に小さくて間隔の短いものにすべき（中略）［マイクロソフトのチームは少量で頻繁な作業方式にしている。だから、構築中のシステムなどは毎晩再構築（ナイトリービルド）されている。］【P.239】

すべての関数（とりあえず空のサブルーチンだが）についてのサブルーチンコール（スタブと言う）を持ったリアルタイムシステムの基礎となるポーリングループ（図19.2）を構築することを提唱した。それをコンパイルし、テストする。そのループはぐるぐる回って、実際には何も処理しないが、ただ回ることを正確に行う【P.261】

私たちは開発中のシステムを毎晩再構築［とテストケースの実行を］する。【P.263】

継続的インテグレーションという言葉が直接出て来たわけではないですが、それに似たマイクロソフトの 毎晩構築アプローチ というものが紹介されていました
当時は今と比較してビルドにもだいぶ時間がかかっていたと思いますので夜間ビルドしかできなかったのだと思いますが、今は手軽にできるようになったので “毎晩” である必要がなくなりましたね

他にもちょっと目的は異なりますが、ルールやコンセプトを統一するための方法として “直接合体する” という考え方も提案されていました
結合時に認識齟齬に気づくことは取り返しの負担が大きいので、最後にまとめて結合するのではなくテストが終わったものから順に直接合体しながら進めることで、早期に発見できるという考え方ですね

ソフトウェアを構築ではなくプロトタイピングの繰り返しにより漸増的に育成するという考え方

本質を攻略するものは、繰り返し対話しながら要件を指定していく方法の一部として、システムのプロトタイピングを迅速に行うアプローチの仕方とツールを開発すること【P.189】

どのソフトウェアシステムも漸増的開発によって育成されるべき【P.190】

そのシステムがたとえ適当なダミーサブプログラムのセットを呼び出すこと以外役立つことは何もしないとしても、まず動くように作られるべきである。それから少しずつシステムを肉づけしていく。同時にサブプログラムの方も、実行したり、下位レベルにある空のスタブプログラムを呼び出したりするものを開発していく。【P.190】

機能を１つずつ漸増的に構築してモジュールを追加する。そのどの段階でも、使える実動システムがあるのだ。【P.261】

この頃からアジャイルな開発の進め方が提唱されていたことには驚きました
後述しますが、ユーザに焦点を当て変化する要求に応え続けることを大事にしているのも印象的でした

堅苦しい標準化よりも権限の移譲やツール選択の自由を与える

私たちの多くは、怠け癖とスケジュールの圧力を克服し、プログラムの寿命まで使えるような文書の作成についての心構えを新人のプログラマには教え込もうとしてきた。そして、大方は失敗に終わったのである。誤った方法を使ってきたせいだ【P.154】

決められた堅苦しい標準に合わせたプログラムでは、往々にして多すぎる。しかし、そういうプログラムの注釈でさえ、真に分かりやすさと全体の概要を示すには不十分なことが多い。【P.162】

多くの企業にとってソフトウェア生産性を上げる最強にして唯一の戦略は、コンピュータ初心者の知的労働者にパーソナルコンピュータと優れた汎用ワープロ、描画プログラム、ファイル管理プログラム、およびスプレッドシートを装備として与え、第一線で自由にさせることだ【P.188】

権限委譲によって中央部は真の権威を獲得し、全体としての組織がより幸福で富裕になる【P.273】

中央集権的なプロジェクト管理よりも権限を委譲することの大事さを伝えていたことも印象的でした
従来型のプロジェクトは標準化チームが様々な標準化ルールを定め他のメンバーはそれに従うことが多かったと思いますが、権限委譲によって真の権威が獲得できるというのは面白い考え方だなと思いました

ソフトウェアと同じように組織も変更に対応

コンウェイの法則が予想しているように、インターフェース仕様書と絡み合っているものだ。更にコンウェイは、組織が最初のシステムデザインをまず反映するが、そのデザインはほとんど正しくないに決まっている、とまで言っている。システムデザインが自由に変更できるものだと言うなら、組織も変更に対応できなくてはならない【P.101】

組織上の変更が必要となった場合、比較的簡単に外科手術チーム全体を別のプログラミング作業に割り当てることができる。実際これが、柔軟な組織を作り上げるという問題に対する最終的な答えである。【P.110】

ソフトウェア製品はアプリケーションや利用者、慣習および機械機器（媒体）といった文化的マトリックスにすっかりはめ込まれているのだ。そしてそれらは絶えず変化し続けるものであり、その変化がソフトウェア製品に容赦なく変更を矯正するのである。【P.173】

以前チームトポロジーを読んでいたのですが、本書でもコンウェイの法則が出て来て驚きました
ソフトウェアの変更に合わせて組織も柔軟に変更できるべきという考えも深く共感しました

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

ウォーターフォールモデルは、システムテストとそれが含意するユーザテストを構築過程の最後に持ってきている。そこで利用者にとって考えられないような扱いにくさや、とても容認できそうにない性能、あるいは利用者のエラーは悪気を引き起こしそうな危険性などを発見したときには、もうすっかり完了してしまっている可能性がある。【P.259】

ウォーターフォールモデルの第二の誤りは、全システムが同時に構築されると想定していることだ【P.260】

構築の下流工程からくる経験とアイディアは時には１段階以上流れに逆らって飛び越えて上がり、上流の作業に影響を与えるようでなければならない【P.260】

ウォーターフォールの進め方では本質的な課題を解決できているかに気づけるのが遅くなってしまうことに触れ、また実際は滝の流れのような一方的な進め方では成り立たないことにも触れ、ウォーターフォールを否定していました

この部分は２０周年増訂版で書かれた部分でしたが、それでも９０年代で否定されていたので今から３０年も前のことになりますね

その他に気になったもの

システムアーキテクトは、ビル建築家に似て、利用者の代理人である。その仕事は、専門的かつ技術的知識をセールスマンやメーカーのためにではなく、純粋に利用者のために投入することである【P.39】

完全なプログラム検証を行っても、プログラムが仕様書とあっていることを立証するだけだ。ソフトウェア開発作業で最も困難なことは、完全で一貫した仕様書に到達することであり、そして、プログラム構築の本質の多くの部分は、実際には仕様書のデバッグなのである。【P.185】

ユーザ視点に立ち、その要求を紐解き構造化することが我々の仕事だと伝えてくれています
しかし、それはとても難しいことだとも述べられています

最近は AI がコーディングをだいぶ助けてくれるようになってきたので、より一層このスキルはぼくたちに求められるようになると思います

いろいろなタイプの利用者がいるが、それぞれに合わせて、異なるタイプの文書が必要である。【P.155】

ここでいう “利用者” はソフトウェアのユーザに限らず、以後開発に携わる人を含めています

以前、ウォーターフォールプロジェクトの上流工程に入れていただいた時、この後の開発工程でどんなエンジニアが来るかわからないなかドキュメントを作成していて、とても難しく感じたことを思い出しました
スキルレベルの高い人にとっては書きすぎるとノイズになってしまい、スキルレベルの低い人にとっては気をつけて書いたとしても足りなくなってしまいます

誰にでも伝わるというのは無謀なので、“その人” にとって必要な伝え方で伝えるべきだと思いました

文書はプログラムの構造や命令とフォーマットに組み込まれるのだから、その多くがプログラムが最初に書かれた時点で完成しているはずである。そして、それが書くべきタイミングだ。【P.162】

ぼくなりの持論とし”テストコードは仕様書, プロダクションコードは設計書” という考えを持っていますが、それに近い話だと感じました

ソフトウェア実体は、どの２つの部分をとっても似ることがないので（少なくとも文レベルより上では）、大きさの割にはおそらく他のどの人工構造物よりも複雑なものだ【P.171】

これも言われてみれば確かにそうだなと感じるところでした
もう少し言い方を変えると “同じ” がない、つまり金太郎飴的な作り方はできないものであり複雑であるため、ひとつひとつ考えてつくる必要があるのだと理解しました

品質にこそ焦点を絞るべきなのであり、生産性は後からついてくるものなのだ【P.206】

これは “質とスピードはトレードオフではない” 話だと感じました
内部品質を向上させることで開発にかかるリードタイムが短くなり、故に外部品質を向上させるチャンスが多く訪れやすくなる考え方はまさに品質に焦点を絞り生産性が後からついてくる話だと思います

まとめ

今回読んだのは２０周年記念増訂版でしたが、そのほとんどが７０年代に書かれており、増訂版が出たのも９５年の話です

いまから３０年も前に従来の予測型アプローチや人員の大量導入を否定し、小さなチームで漸増的に育てていくことを伝えてくれていたことに驚きました
ぼくも人的リソースを激しく増減させることより、チームをできるだけ長く存続させ成長させていく考え方のほうがソフトウェアが作りやすいと考えているので共感できる部分は多くありました

プロジェクトマネジメントの必読書と聞いていましたが、改めてソフトウェア開発プロジェクトに携わる人はマネージャからプログラマまで全員におすすめしたい一冊でした

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 非対応なのがちょっと残念な点でした
こちらは今後のアップデートに期待でしょうか

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

これから

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

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

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

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

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