プログラマとしての良心に従い続けるためにはどうすれば良いのか？ / Agile Tech Expo #2

2021/07/10 Agile Tech Expo #2 講演スライド

[Abstract]
迫り来る期限、急に降ってくるビジネス要求、常に時間との戦いとなるソフトウェア開発の現場において、それでもなお「あるべきソフトウェアの設計」に対し、プログラマとしての良心に従い続けるためにはどうすれば良いのでしょうか？
私たちは月額定額の顧問型サービス「納品のない受託開発」を通じて、あらゆるお客さまの持続的な事業の成長をサポートしてきました。現在では100サービス近くのソフトウェアを継続的に開発し続けています。中には10年近く絶えずアップデートが続いているサービスもあります。この継続的な改善を支えるものは何なのでしょうか？　開発プロセスでしょうか？　それともビジネスモデルでしょうか？
本セッションでは、私が「納品のない受託開発」に関わり続けてきた10年間を踏まえて、この問いに向き合っていきます。

Transcript

1. プログラマとして 良心に従い続ける ために どうすれ 良い か？ 2021/07/10 Agile Tech Expo #2　SonicGarden 西見 公宏 (@mah_lab)
2. 西見 公宏（にしみ まさひろ） 移住先で庭いじりする様子 ソニックガーデン執行役員 / ファシリテータ 中学生からずっとプログラマー 2011年入社、n2jk※ 経営チームフロント担当 2021年4月に東京から山梨に移住 / 3児 父 年間100件以上 新規事業企画、既存システム 見直し、業務システム（DX） ご相談を担当、 プロジェクト 立ち上げを支援 ※n2jk＝「納品 ない受託開発」 略称
3. ソニックガーデン ご紹介 社名 株式会社ソニックガーデン (SonicGarden Inc.) 設立 2011年7月1日（決算期：6月） 事業内容 「納品 ない受託開発」 、自社企画 クラウドサービス 各種資格 届出電気通信事業者： A-27-14398 プライバシーマーク付与事業者： 10824905 関連会社 ケアコラボ株式会社、株式会社ジェントルワークス 沿革 2009年5月　TIS株式会社 社内ベンチャーとして創業 2011年10月　TIS株式会社からMBOを実施 2015年9月　取締役に西見が新任 2021年7月　野上・遠藤が執行役員に就任
4. 創業当初からリモートワーク 社員数：5名→52名（※常勤 業務委託も含む） 2015年にリモートワーク関連書籍を出版 2016年、オフィス廃止
5. 納品 ない受託開発 まるで優秀な内製チーム、しかもマネジメント不要 月額定額 顧問形式で、事業 成長を支え続けます 新規事業を 立ち上げたい 既存システムに 課題がある 基幹業務を システム化したい 業務改善で 効率化を図りたい
6. 納品 ない受託開発 ひろがり • 創業年度 8社 → 現在 105社 お客さまをサポート • 創業年度 10サービス → 現在 104サービスを運用 • プログラマ43名で開発・運用を継続的に提供 ※運用サービスに 死活監視を導入しているも みカウント
7. なぜ今、良心 話な か？
8. 既製品 カスタマイズ 方がコストが低いと思われる とてもやりづらい 既にあるコードを改修すれ すぐですよ 6年前 コードだけど よろしく いや、これムリじゃ ？ （現実的に） と、プログラマが 言ってまして マジかよ プログラマー空気読めよ 良いじゃん！
9. よく分からない人が勝手に仕様をまとめてくる とてもやりづらい こ 仕様 XXXでいきま しょう！ こ 仕様 XXXだから、 よろしく いや、これムリじゃ ？ （現実的に） と、プログラマが 言ってまして マジかよ プログラマー空気読めよ いい ！
10. 勝手にクリティカルなスケジュールが決まってしまう とてもやりづらい 連携サービス 仕様が決 まる リリース直前です 仕様 未確定だけど 何とかよろしく いや、これムリじゃ ？ （現実的に） と、プログラマが 言ってまして マジかよ プログラマー空気読めよ まぁ大丈夫っ しょ
11. あらぶる技術的負債ループ ミドルウェア バージョンアップがで きない フレームワーク バージョンアップがで きない 無理な設計 変更しづらさ ライブラリ バージョンアップがで きない セキュリティ脆弱性 バージョンアップ 放置 そ 場し ぎ コード そ 場し ぎ コードによって バージョンアップが困難になるループ メンテナンス性がどんどん 落ちていくループ 要素技術 幅 特定 人へ 負荷 書かれないテスト 人材採用 人的コスト 売上を増やすため 開発加 無理な 期限設定 メンテされない コード量 機能削減ができない 2019/8/23「技術的負債を生み出す構 とそ 対処について」講演資料より抜粋
12. プログラマとして 直感と現実が異なる 現実として現れる問題 直感的に正しいと思う振る舞い テストを書くよりも機能を実装する テストコードを土台に機能を実装する 生産性を高めるために細かく分業する チーム全員がシステム全体を把握する 動いているコード わざわざ触らない 実態にあわせてリファクタリングする 一度設計を進めたら後戻りできない いつでも設計を見直すことができる 最初に決めたことが正で、それ以外 悪 ふりかえりながら仕様をチューニング 急ぎなら設計がいびつでも仕方がない 無理なく品質を向上させながらリリース バグゼロが前提で全て 不具合 許されない リスク評価にあわせて不具合に対処する 本当にやりたかった どちらか？
13. プログラマ 願いと ？ たくさん 人を入れても 生産性と品質を出せる ように考える 少人数 ままで一人当たり 出来ることを増やして生産 性と品質を高めるように考え る 抽象化や仮想化を重 る ソフトウェア開発技術 進化 方向性 どちらな か？
14. それで 一体どうすれ 良い か？
15. 「ソフトウェア 事業 写像である」という前提 事業 ソフトウェア 事業とソフトウェア 表裏一体で切っても切れない関係 事業とソフトウェア アップデート 同時に行われる
16. そもそも事業にあわせてアップデートできない構 何が必要か 予想が難しい 納品したら 開発者 解散 使い始めてから 不満が出てくる 直したくても 直せない
17. 本当にありたい姿を実現するために ？ 少しずつ 相談しながら作る 開発者にいつでも 相談できる どんどん便利に なっていく 安心して 事業展開できる 継続したアップデート
18. 「納品 ない受託開発」 キーコンセプト • 投資に対するソフトウェア 価値を最大化する • お客様 パートナーとなって事業を支え続ける • 習慣を変えること できるソフトウェアを創る 月額定額 見積りなし まるで内製
19. 「納品 ない受託開発」 技術戦略 • 継続的バージョンアップを前提にした開発プロセス • 技術的負債ゼロを実現するプラットフォーム型戦略 • コード品質を最重要視するコードレビュープロセス
20. 継続的バージョンアップを前提にした開発プロセス 開発期間 定例ミーティング ...繰り返す 決定 開発 デモ タスク ソフトウェア • 事業に関する状況 共有（事業） • 開発してきた機能 デモ（開発） ◦ 成果へ フィードバック • 次に開発する機能 ディスカッション ◦ 機能・画面設計、見積もり ◦ 優先順位 見直し 内容 開発期間 • プログラマ 運用しながら、定例で決めたタスクを実装する • 事業サイド 次 定例に向けた調査や検討を進める 専用プロジェクト管理ツール「 Sonic」 納品 ない受託開発 開発プロセスにあわせてスムーズに開発を進 めるため、本サービスで 専用プロジェクト管理ツールである「 Sonic」 をご提供しております。日常 コミュニケーションや、定例ミーティング 時に出てきたタスク 管理機能など、納品 ない受託開発に必要な要 素が全てそろっています。
21. 技術的負債ゼロを実現するプラットフォーム型戦略 n2jk運用基盤 サービスA サービスB サービスC ・・・ 要素技術 共通化 インフラ アップデート 運用環境 （本番、テスト） サービス 監視 アップデート 監視 専用ツール セキュリティ 対策 顧問プログラマが基盤を利用する と共にアップデートなど 整備にも 参加する（DevOps) • サービス個別に技術選定する で なく、採用技術 も含めて共通 基盤 上で運用されるというプラット フォーム型 世界観 • プラットフォームをアップデートすることによって、そ 上で運用されるサービスが最新化される • 特定 誰かがアップデートを担う で なく、プログ ラマ全員がアップデート 責務を担っている
22. コード品質を最重要視するコードレビュープロセス • レビュー 観点を明確にすること • 我が身に返ることを恐れずに指摘すること • 何故悪いコードな かを論理的に説明すること • 良いコードについて共通認識を持つこと • 小さい単位でレビューを繰り返すこと • 指摘 素直な気持ちで受け入れること • 指摘 人格否定でないことを理解すること デキるプログラマだけが知っているコードレビュー7つ 秘訣 読む チェック する 改善 する プル・リクエスト 意思疎通 できる（可読性 高い） コードになっているか？ 性能・リリース時障害・ロジック不備な ど品質に関わる観点で問題 ない か？ 他に同様 問題が発生していない か？こ 学びをノウハウとして蓄積 できるか？ • 「あくまでコードがソフトウェア 中心である」という基本思想 • だからこそコード 品質が何よりも大切で最重要視するポイント • コード 品質が高いからこそ、迅 な変化へ対応が可能となる
23. 「納品 ない受託開発」 技術的全体像 定例ミーティング テスト環境 本番環境 CI コード レビュー Sonic n2jk運用基盤 （AWS、Firebase） Copytuner ※リリースなしで アプリ 文言変更が できる自社製ツール 委員会 AWS Firebase セキュリティ 参加 ツール開発 情シス 技術要素、セキュリティといった重要な要素に応じてチーム化。メン バー 社内公共活動として各委員会に関わる。 メンテナンス アップデート 顧問プログラマ お客さま
24. 「何をどうやる か」で なく そ 行動を「どこ」からする か
25. 本日お伝えしたかったこと • 本当に開発者がありたい姿を無視してエンジニアリング組織 設計 をすること できない • ありたい姿を開発者 良心をもって実態から明確にすること • それを反映できる変更容易性 ある組織／事業構 にすること Don't just do agile, BE AGILE ニューノーマルに適応できる考え方
26. プログラマを一生 仕事に
27. ご清聴ありがとうございました