@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

「変革の軌跡」 を読んだ

読もう読もうと思っていたけど読めてなかった本をお盆で時間が取れたので一気読みしてみた。(急いで読むために弊社のとある人の机からこっそり借りてきて読んでいることはここだけの秘密

この本はHPのエンタープライズ向けプリンタであるLaserJet 製品ラインにおけるファームウェアコードの開発方法を変革してきた話である。この本で書いてあるテスト自動化、継続的デリバリーなど1つ1つの技術的な取り組みはエンジニアにとってそこまで真新しいものではないが、技術先行ではなく「ビジネス目標の設定」から始めることが必要・大事だという事を繰り返し言っていた。

僕がこの本を読んで気になったのは「第8章 しっかりした土台を作る」である。この本の中ではテスト自動化、継続的デリバリーやデプロイパイプラインの設計などを具体的に行っている。
継続的インテグレーション、自動化テスト、スクリプトによる環境構築やスクリプトによるデプロイなど継続的デリバリーを実際に行おうとした時にやりやすい設計、やりにくい設計があると思う。あまりにもモノリシックなシステムの場合ちょっとした変更だけでもソフトウェア全てをテストする、出し直す必要があるようになってしまう。エンジニアとしてこういったものを直したいと言った時にビジネス側の人に説明がうまくできなかったことが僕にはある。これは、エンジニア側とビジネス側で同じ目標を設定できていなかったことが問題だったのだと今は思う。 マニュアルテストから自動化テストへの変更など直接売上にはならない作業の必要性をビジネスの人とうまく共有できなかったことが問題だったのだろう。もしまた一緒に仕事をする機会があったら開発を始める前に仕事の進め方や目標を話し合ってから仕事を始めてみたいと思う。

エンジニア同志で読書会などをするよりも、ビジネス側やマネージャー、リーダーなどに読んでもらい継続的改善をススメていく開発体制、アーキテクチャ、ビルドプロセス、テスト自動化を組み立てていくための話し合いをしたいと思った。

最後に当たり前だけど忘れていたなと思った考え方を引用して終わりたい。

他のプロジェクトとは違い、ソフトウェアは、ほぼ際限なく柔軟である。 だからこそ「ソフト」ウェアと呼ばれるのだ。 ソフトウェアは、いつでも別の機能を実行するように変更できる。