概要
「つぎの一歩が見つかる、気づきと学びの場」 Forkwell Library シリーズ 第14弾
これまで Forkwell のイベントで登壇されたエキスパートの方々は、先達が記した書籍から「気づき」を得て実践し、振り返り、再現性のある「学び」として身に付けていく中で、実績を築いてこられました。
しかし、日々限られた時間の中で知識や情報をアップデートし続けるのはそう簡単ではありません。 Forkwell Library では、著者・訳者・実践者らを登壇者として招き、そんな思いを抱えた開発者の皆さまが「学びのきっかけ」を得られる勉強会を目指します。
今回の第14回目では2022年12月7日に発売されたばかりの『ちょうぜつソフトウェア設計入門』を取り上げます。オブジェクト指向考え方の基礎から、UML記法、アジャイル開発など、モダンなソフトウェア開発のなかで、開発の現場で問題となるテーマを取り上げている本書はポップな表紙とは裏腹に骨太な技術書として高い評価を得ています。今回は著者である田中ひさてる氏をお招きして、ちょうぜつソフトウェア設計者になる為の学びを共有していただきます。
基調講演：ちょうぜつ<改め21世紀ふつうの>ソフトウェア設計入門
著者の田中ひさてる氏の言葉
2022年12月、おかげさまで「ちょうぜつソフトウェア設計入門」を無事出版することができました。
ソフトウェア開発に対する認識は、20世紀末から21世紀のはじめにかけて、大きくアップデートされています。書名には「ちょうぜつ」などとたいそうなタイトルが付いていますが、この本に書かれた内容は、現代ではごくありふれた考え方ばかりです。にもかかわらず、今なおソフトウェア開発の現場のエンジニアには、この本に書かれた知識が、その名のとおり「ちょうぜつ」で特別なもののように映るかもしれません。21世紀がもう20%過ぎた今、どんなエンジニアが求められるべきなのか、エンジニアはどのようにその求めに応えていくべきなのでしょうか。
本イベントではこの「現代のふつう」の視点から、拙著「ちょうぜつソフトウェア設計入門」に書かれた内容の意義を解説させていただこうと思います。
感想
#Forkwell_Library#ちょうぜつ本 の技術側面はあえて触れず、もっと大きな視点で、良いソフトウェアエンジニアキャリアを目指すか、といった良い話だった。21世紀のふつう ができるようになりたい。
— アジャイルクマムシ@個人開発 (@agile_kumamushi) January 25, 2023
※どう良いソフトウェアエンジニアキャリアの「どう」が抜けていた。
20世紀のコンピューター
設計は予測可能だった。ウォーターフォール的。
ふつうになるべきだったこと
人月の神話
20世紀までに発達した思想
- どれだけ大きくて強いものを作れるか
- 労働者はマニュアル通りに動く機械 <=????!
たった10年で巨大なPCからファミリーコンピュータができた。
ムーアの法則。集積度は10年で10倍。
ふつうの感覚が変わった。
箱モノ製造 -> 個人がコンピュータを使って何かやる
最後にWindowsが出た。
ソフトウェアにハードウェアが依存する逆転現象が起きた。
ソフトウェアはハードウェアに対して最適化するより、無駄があっても人間が使いやすく。
ところが、ソフトウェア開発は・・・
重厚なプロジェクト管理・ミドルウェアの肥大化
おかしなことが起きた。
全時代的な思い込みが残した「あってほしい形」 ウォーターフォールモデル
- 人の思考は常に現実から何年か遅れる。
- 米軍もこれがいいと言ってしまった
21世紀のコンピューター
従来型ソフトウェア開発へのアンチテーゼ
- デザインパターン・オブジェクト指向への再注目
- オープンソース / LAMP (Linux, Apache, MySQL, PHP)
- 「ハッカーと画家」 ”Beating The Averages”
- XP (TDD / 反復 / 少数精鋭）
- アジャイルソフトウェア開発宣言
端末は身体の一部へ・本質はクラウドサービスへ
ソフトウェア開発の比重
20世紀：モノの扱いがスキル。どれだけ多くの定型的な操作が頭に入っているか。専門オペレーター
21世紀：柔軟に・・・・
巨大なモノリスが飽和している。
XP
- オンサイト顧客とペアプログラミングの直結
- TDDが原則（XPはマネジメントではない）
- TDDは暗に「単体テスト可能な粒度への問題分解が前提」意味している
- オブジェクト指向はもともと「小さな計算機がメッセージを介してネットワークを成した再起的構造」みたいな意味だった
- 今でいうマイクロサービス
アジャイルは小規模プロジェクト用と言われた。。。
が、分割・反復・部分テスト・自己完結、よりスケーリングできるのはどちらか？
-> 当然アジャイル
設計は予測可能な機械の問題から予測不能な人の問題になっている。
ユーザーニーズに応えるためには、アーキテクチャが重要
ソフトウェア設計は自転車の両輪。
ドメインモデル（前輪）、アーキテクチャ（後輪）どちらが欠けてもうまく走らない。
各ソフトウェアに固有の問題
重要だが共通した一般化はできない。
どうやってスキルを上達させれば？->反復訓練しかない。
要件定義には熟練が必要？->プロジェクトの中で反復する
共通した基本原則がある領域
反復的な開発の駆動効率を高める方法
集中すべき問題を小さく閉じられる作り。高速にテスト駆動を回せる。
-> 良い設計の発見チャンスを増やして育てる。
オブジェクト指向だけわかる、はない
天才のアラン・ケイが手を動かしながら掴んだ感覚を、説明だけでわかるわけがない。
オブジェクト指向をまず理解するというのは無理。
オブジェクト指向できる != 仕事をもらえる
トレンド技術 != 労働資格
20世紀は、答えが決まっていた。作業が直接お金になった。
21世紀は、答えのない問題。そこにどう貢献できたかがお金になる。
技術はそれだけでは０円。
20世紀から21世紀へのシフト期
「ハッカーと画家」
Webがブルーオーシャンだった時代で、ずば抜けた技術がアドバンテージとなって競合を出し抜けた。
世界は最新技術と優秀なエンジニアをこぞって求めるようになった。
最近だとAIがいい感じのコードを簡単に生成してくる。
もうすぐこれが「普通のやつら」になる。
下手でもこいつらが作れないユニークな価値を作れるかが重要。
普通（以下の20世紀的労働）だとAIにやられる。
いまだに、求人票でJava開発経験５年以上が求められていたりする。
顧客が本当に欲しかったもの？共通の語彙がないので経験何年となってしまう。
知識量ではなく、問題解決の苦労や成功体験のほうが欲しい。
無駄にオーバースペックさをアピったとしてもそんな人材はマッチしない。
現代のふつうをちゃんとできる人材がいい。
こういう採用するなら、有望な会社では？
-> 資料公開されているので、そちらを見た方が良いかも。
関連ツイート
ほんと、どうしてロイスの論文が元にあるのに、それがいわゆるWFなんてものにされてしまったのか。https://t.co/iWVpRthX5p#Forkwell_Library
— Siena. (@n_siena) January 25, 2023
事例講演「CTO から見た、なぜスタートアップ初期のソフトウェア設計は壊れがちなのか」
めもりー 氏（@m3m0r7）
はじめまして、めもりーちゃんのフォーク元の実めもりーさんです。
スタートアップに入社や転職をして「なんてひどい設計だ」と心のなかに秘めて吐き出せない気持ちを抱えている方も多いのではないかと思います。なんなら、設計されたものとさえ思えないかもしれません。
無数に散らばる require/include、N+1 なんて日常茶飯事。第一引数しか使われていない htmlspecialchars。
いわゆるこういった技術的負債に対峙した場合どうしたらよいか、そもそもどう変えたほうが良いのか、ハウツーをひさてるさんが話す一方で、CTO という経営により近い立場から「なぜ、このような設計が生まれるのか」「なぜ、事前に察知して対処できないのか」そういった疑問を解決できればと思います。
生まれる理由や察知して対処できない理由を知ることで、ソフトウェア設計がいかに組織設計に引きづられるか、など様々な視点からソフトウェア設計について理解をしていってもらえればと思います。
感想
スタートアップには縁が無いが、スタートアップの内情がよくわかる講演だった。
ついでに、めもりーさんがやられている知育玩具のサブスクは面白そうと思った。もう少しで子供が生まれるので検討したい。いっぱい買わないといけないかと思ってたけど、さすが最近はサブスクが充実してきてる。本筋とは全然関係ないけど。
スタートアップのお金事情
スタートアップは本当にお金がない。
どうやってお金をとるかは３択。
- デットファイナンス＝融資
- エクイティファイナンス＝株式分割してそれを投資家に売る
- 売上->純利益を増やす
デットファイナスは借金。利子をつけて返さないとダメ。
株式は渡さないため経営権に影響がない。会計上のメリットも大きい。
その分、デメリットも大きい。代表自身が保証人となるため、会社が潰れても責任を負う必要がある（数億円レベル）。
余談：デットファイナンスを行わない経営を無借金経営という。
エクイティファイナンスで、どれくらいお金にできるか
投資家からの投資には、段階に分けたものがある。これを投資ラウンドという。
投資を受けたお金＋自己資金で会社が存続できる期間をランウェイという。
人を採用するとランウェイが短くなる。投資家に対して、どれだけ価値のある会社となるのか成長戦略を見せる必要がある。
そうしないと生き残れない。成長戦略が跳ねれば跳ねるほどバリュエーションが上がるので、エクイティストーリーを考えるにあたって、エンジニアリングは要となる。
売上->純利益を増やす。売り上げ!=会社が使えるお金。売上ー原価＝粗利。粗利ー販管費＝営業利益。営業利益ー営業外費用＝経常利益。
スタートアップだと売上がないため、赤字であることが多い。受託系の会社だと、システムを納品した翌月末支払いが多い。売上は上げやすい。販売原価はほとんど人件費になる。資金繰りの不安はスタートアップよりは少ないと考えられる。
投資ラウンドの説明。エンジェルラウンド、シード、シリーズA〜シリーズCまでの５段階ある。エンジェルラウンド（アイデア段階）だと数百万円〜数千万円程度。人一人雇うと1年ランウェイが持たないかもしれない。
会社に金があるかどうかどう見るか。基本的には決算公告（バランスシート）及び官報。キャッシュイン、キャッシュアウト、ランウェイなどがある程度予測できる。スタートアップへ転職する際はチェックした方が良い。上場企業だったらIRを見れば良い。
スタートアップはお金がない。いきなり激つよエンジニアを採用はできない。
1000万の資金調達。５００万円のエンジニアだとランウェイは2年。次の資金調達まで生き残れる。
年収1000万円だとランウェイは1年。次の資金調達が間に合わずにショートしてしまう。
経営側としては、500万のエンジニアを選ぶ可能性が高い。ランウェイを伸ばせる方が色々できるため。
すぐに資金調達すればよいのでは？と思うかもしれないが、資金調達をするには、事業上のKPI（会員数、GMV（流通額、クロス）など）としている数字の成長戦略を証明する必要がある（＝エクイティストーリー）。色々とあって、難しい。
いきなり伸びると、伸びるサービスと思われやすいため、２回目の資金調達の時点で成長が鈍化しているように見えてしまう＝伸びしろがないように見られる。
そのため、経営判断として、業務委託を使ったり、外注したり、創業者本人が書いたりといったことになる。経営陣に知識がなければソフトウェア設計がハチャメチャになる。タイミングによって、どういったタイプのエンジニアを雇うかを選ぶ必要がある（雇えない可能性も高い）。
物理的にも金銭的にもエンジニアの採用が難しいため、ソフトウェア設計もへったくれもない状況になる。
競合他社がいる場合、差別化して顧客を獲得する必要がある。そのため、綺麗なコードで動かないよりも、汚くても動くコードの方が重宝される。
会社としては、初期から一緒に課題を乗り越えた初期エンジニアを評価しやすい。だから後から入ったエンジニアがもっといい設計をしているのに、初期メンバーばかり評価される・・・といったことがあり得る。評価基準は変えていった方が良い。
->こちらも資料公開されているので、そちらを。
コメント