2020年個人としてふりかえり

2020年ももうそろそろおわりですね。 2020年は個人としてもチームとしても色々な事があったのでふりかえっておきたいとおもいます。

業務としてはあいかわらず幅ひろくなんでも現状のチームで手数がたりないところなら埋めていくというスタイルでやっているのはかわってないですが、 いくつか心境というか変化したなとおもったことはありました。 おおまかに大別すると:

• チームでの進め方や要件定義のやり方が多少向上した
• 自分の担当している領域にたいしておちついて作業をしているようになった
• 書籍や本をベースに知見を共有するというコミュニケーション手段が持てた

のような感じかとおもいます。

まず、チームの変化としてモバイルアプリ領域を専門性のたかいメンバーにまかせるようにし、 技術選定の方針や何に時間をつかうのかの上段の意思決定には関与しますが個別の判断は各領域の専門のメンバーにまかせるようにしました。

僕の仕事は

• 事業としての機能開発と、内部品質のたかい仕事をするために必要な時間の調整とゴーサイン出し
• 横断的にやってきた経験をいかして開発マイルストーンのざっくりとした見つもり
• 要求分析・要求仕様書づくり、および見つもりの補助
• チームとして穴のあいているバックエンド、インフラ、フロント領域の設計・実装

あたりに絞るようになりました。

それにともなって、要求分析・要件定義や調整等の技術向上のためにいくつか本を読んでインプットしました

意思決定、認識共有

考える技術・書く技術―問題解決力を伸ばすピラミッド原則

ロジカル・シンキング Best solution

リモートでの要求分析や意思決定が増えたため、 より文字に落した文書をベースにMTGをしたり判断をしたりする事にかかわる機会が増加しました。 それにあたり、文章としてどういった構成にするのが良いか、チームで意思決定をするにあたって メンバーが読んで納得しやすい・論理のミスに気がつきやすい文章や議論ができるようにロジカルシンキング系の代表的な本を読みました。

この本を読んだ事によって、自分の中に認識統一や意思決定のMTGを開いてすすめるる時の型が多少できた気がしています。

要求分析、プロダクト

ジョブ理論　イノベーションを予測可能にする消費のメカニズム (ビジネスリーダー1万人が選ぶベストビジネス書トップポイント大賞第２位！　ハーパーコリンズ・ノンフィクション)

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

〔エッセンシャル版〕マイケル・ポーターの競争戦略

その仕事、全部やめてみよう――１％の本質をつかむ「シンプルな考え方」

今年は流らくやってきていたサービスを一次休止し、 新規事業を模索して立ち上げていくしていくというフェーズに会社が切りかわったので、 そもそもプロダクトとビジネスの組みあわせとしてどういう戦略でいくのか、 プロダクトとしてユーザー価値をどうやって高めながらビジネスとしても成立させていくのかという視点を自分なりに持ちたいとおもい、いくつか本を読んでいました。

プロダクトとしてのユーザー価値がどこにあるのか、 たとえばある機能がありその機能がユーザーの課題を解決しているというような戦略もあれば、 低コストで実現する事によってコスト的に優位に立つのか等

プロダクトとしての提供しているプログラム的な機能が同じだったとしても背景にある戦略の方針によって 「なぜこの開発をするのか」の捉え方がかわってくるため、ビジネス的な勝ち筋についてももうすこしさらに勉強できたらなとおもっています。

また、プラットフォーム型のサービスを立ちあげてビジネスをしていくにあたって、法律面での課題にあたる事もあり、 弊社で以前インターンをしていただいていた佐野さんも執筆者として参加している

プラットフォームビジネスの法務

こちらの本を読んで法律的な観点や留意点についても勉強していました。

要求仕様書

事業的な方針や、それにともなう機能の背景等についてMTGをして意思決定ができてきたら、 次はそれを具体的な要求仕様におとしていく段階にはいります。

こちらについても、大規模なファーストリリースまでのプロジェクトや、 リリース後の学びにともなう大きな改修などもありそういった物を会社全体で齟齬なく共通理解にいたるための土台とするために要求仕様書の手法についても本を読みました

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

poketo7878-dev.hatenablog.com

要求仕様書をつくる事で、それぞれの機能がなぜ存在するのか、細かな挙動としてどういう物がもとめられているのか精緻にしていく事ができ

• 一つ一つの機能にたいして納得感をもって進められる
• 何が実装できていて、何がまだ未実装なのか確実にできる
• 事前みつもりの精度が向上し、ザックリでもより精度たかくタスクのクリティカルパス等がわかるようになる

等々いくつかメリットがあり、このプラクティスはチームでも評判がよく今後も続けていこうとなっています。

要求の背景がクリアになった事による事例

要求の背景が明確になっていると、機能を保守する価値と仕様が複雑になるコストとの間で判断もしやすくなりますし、 要求の前提がくつがえったタイミングで取捨選択する判断もしやすくなりました。

今日すこし大きめの変更をする時に、「この変更するにあたって、この別の機能Xがあると仕様すごく複雑になっちゃうけど、そもそもこの機能Xって今後も使われるんですかね」って話になって、サクっとSlack上で事業責任者と話して機能撤廃がきまったのすごくよかった。

— Pocket7878 (@Pocket7878) 2020年12月16日

ものすごい削減効果があった。 pic.twitter.com/wwRrk4rtPQ

— Pocket7878 (@Pocket7878) 2020年12月16日

QA・テスト

各スプリント毎にデモのタイミングでテストや確認をしているとはいえ、 ファーストリリース前にはチームの皆でおさらいして通しでテストをする必要があります。 テスト技法をきちんと僕が抑えてチームに方針つたえたり計画できるようになればよりチームとして生産性が上るとおもい、 いままで体感的にやってしまっていた部分を体系的にインプットしなおそうとおもいいくつかの本を読んでいました。

実践テスト駆動開発 (Object Oriented SELECTION)

Outside-inで設計していくという方針や、ユニットテストにおいて各コンポーネントと関連するコンポーネントを分離してモックしたりスタブしたりといった手法についてもより原典にあたって理解できるようになったとおもいます。

Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing (English Edition)

テストをするにあたって、要求仕様書をベースにしたテストケースだけでなく、探索的なテストについてもより強化していきたいとおもい、探索的なテストについても学習しました。いくつかテストチャーターを書いてみてセッションベースでテストしてみたところ「片方のボタンサブミットボタンを指で押下したままでも、別の指で特殊な操作をするとバリデーションをすりぬけて送信できてしまう」といったバグ等をいくつか発見できたので効果はたしかにあるなとおもいます。 よりチームで強化していければとおもっています。

はじめて学ぶソフトウェアのテスト技法

また、ユニットテスト等についても何をテストするのか、どうしてそういうテストをするのかの根拠を明確にする事でよりテストを意識的にできるようになったとおもいます。

プロのエンジニアとして

コードを書くエンジニアとして自分の能力をより高めることと、逆にジュニアのメンバーに何かを推奨したり教えたりするにあたって、なぜそれが良いのかを根拠をもって伝えられる場面が増えると良いなとおもい、いくつかの本を読みかえしたりしていました。

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

Clean Code　アジャイルソフトウェア達人の技 (アスキードワンゴ)

特にこの2冊は業界だとあたりまえになっているかもしれませんが、メンバーにコードレビューでフィードバックする時や一緒に設計を考える時にもどちらの設計が良いのかの判断の依りどころとして使えました。

担当領域にたいしておちついて作業をできるようになった

これが、今年一番感じた変化かもしれません。

今まで一人分の通常の人月では到底まわらないだろうという量をひきうけてやっていたりした経験がながかったので、 どうしても落ちついて一つ一つを考えていられないという事が自分の中で癖になっていたような気がします。

たとえばテストひとつをとっても、ネイティブアプリ2つとバックエンドインフラを1人でまわさないと事業がつぶれるという状況でやっていた頃のクセが抜けず、品質の高いコードやテストを充填的に書いていてはまわらないという経験が強く、一つの領域をやっていてもよくなってからもその癖が抜けていない時期が1年半くらいつづいていた気がします。

今年ようやくうまくそれから抜けだせたような気がしていて、今は時間が多少かかっても設計を慎重に考えユニットテストを入念に書きながらTDDをしていてもちゃんと事業はまわっていくという体感が増えた気がします。

これは

• 要求分析や要件定義等により深く関与するようになった
• (まだ今でもちょっと緊張しますが)チームの健全性のためにNoを言う機会を増やした
• そもそものやる事をよりチームとして絞りこめるようになったために時間的余裕がうまれた

という事もあるかもしれませんし、各領域に専門性のあるメンバーがジョイン・成長してきてくれたのでまかせられるようになったと共に、自分の中でようやくそういう回り方になれてきたという事もあるかもしれません。

一方で創業者として

Clean Coder　プロフェッショナルプログラマへの道 (アスキードワンゴ)

一方で、自分の中で葛藤として持っている所もあり、

Clean Coderやアジャイル系の本を読むのは好きだし大部分は同意するんだけど、プロとしてノーというというその先に「常にプロとしてふるまっておけば経営が失敗して転職する時も堂々としていられる」って書いてあって、そこだけ創業者エンジニアとしては同意できなくてむぐぐ

— Pocket7878 (@Pocket7878) 2020年11月29日

創業者と、テックリードというポジションはすごく絶妙なところにあるなぁと改めておもう。一人の起業家として「これは是が非でも早くだしたい」っておもう気持ちと、良きテックリードとしてチームの育成や心理的安全性を保たなければみたいな所のバランスがある

— Pocket7878 (@Pocket7878) 2020年9月17日

アジャイルやプロフェッショナルなエンジニアとしてなるべくYesをいえるように技術を向上させていったり要件定義に積極的にコミットしたりししていくという事はするが、 プロとしてのふるまいを妥協したり犠牲にしなくちゃいけない場面ではNoを言うべきという話が度々出てくる事もあり

このあたりはまだ正直創業者として葛藤がある部分ではあります。「常にプロとしてふるまっておけば経営が失敗して転職する時も堂々としていられる」という部分のプロという部分は「エンジニア」としてのプロというスコープなのではないかという気持もあり、会社の創業者として「エンジニアとして正しい事ができないとおもったので、マイルストーンは逃したので会社が破綻しましたが恥ずべき事はしていません」と言えるのかというと創業者としてはちょっと微妙だなとおもう気持もあり、そのあたりの葛藤は自分のなかでうまく止揚しておかないとなとおもってます。

セキュリティまわり

会社としてセキュリティの強化のためのプランニングやBCP試験の設計等を最近はやっていました。 また、それにともなってセキュリティのおさらいをしたりしていました。 ど定番ですが

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版［リフロー版］　脆弱性が生まれる原理と対策の実践

こういった本を読んだりOWASPの資料をよんだりして、セキュリティの要件をつくる時に会社としてどのラインまでもっていくのか、そのために何が必要なのかを折衝したりしていました。

データベース

事業を立ちあげるというタイミングでは、大きな仕様変更がガツンとはいる事もあり、そういう時にはDBについても柔軟に設計変更できる必要があります。

そのために、最初から負債にならない設計をする事と安全なステップをとってリファクタリングをする事の2つが重要になります

達人に学ぶDB設計 徹底指南書

失敗から学ぶRDBの正しい歩き方 Software Design plus

Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series (Fowler)) (English Edition)

そのためにこの3冊を読んでいました、Refactoring Databaseはまだ半分くらいしか読めていないのでひきつづき読んでいきます。

フロントエンド領域

いままでの事業は、社内向けにはWeb管理画面はありましたがユーザーに使ってもらうWeb画面というのはほとんど存在しませんでした。

しかし、新規事業ではクライアントがWebの画面を通して作業をする場面が多々あり、Webフロントエンドの領域をやっているメンバーが社内にもいなかったので、この機会にとりあえず勉強をしてモノをつくれるところまではならねばヤバいという事で急ごしらえですが勉強していました。

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 WEB+DB PRESS plus

CSS: The Definitive Guide: Visual Presentation for the Web (English Edition)

oukayuka.booth.pm

とはいえ、フロントエンドの領域は流れもはやく一朝一夕でマスターできる物でもないため、12月からはフロントエンド領域の得意な方に業務委託でおねがいしていって、ゴリゴリStorybookとか導入してもらっています。

RailsはRailsで完結している分には楽ですが、フロントエンドのプラクティスと相性がわるい事もおおいので、段階的に剥していく計画を検討しています。

いっそ規模が小さい内に書きなおしてはという意見もありましたが、そのあたりはどうしようか考え

レガシーソフトウェア改善ガイド

どこがイマイチなのか洗いだして、レガシーソフトウェア改善ガイドもベースにしながら、リライトをする必要があるのか、段階的なリファクタリング・部分的なリライトでやっていくのかを検討しました。

以前のプロダクトでもリライトを決断した事があったのですが、長期で2~3ヶ月ほどかかりました。

その当時の事をふりかえって考えてみると

• 根底となるプラットフォームのライブラリやプラクティスに非互換な変更があった
• 品質の観点からみてもリライトで0から設計したほうが良くなる閾値を越えているとおもわれた

という2つの点からリファクタリングよりもリライトにGoを出しました これは実際に僕もそれらのライブラリをさわってみたりしながら、グラデーションで移行するのはかなり困難な根本的な変更がはいった事、 それが現在の事業体力や各メンバーのモチベーション等をふまえても、段階的なリライトをどうすのかという知見を検討したりその間にレガシーなコードをメンバーが保守しつづける事がチームの崩壊につながりかねない等々色々な観点から総合的に判断しました。

今回の事を考えると:

• Rails側からとはいえシステムスペック等でブラウザ経由での挙動の確認のテスト資産がすでに大量にある事
• ライブラリの選定の変更はあるが、各画面をあえて独立させていたため、画面に閉じる変更である事

等をふまえて、部分的なリライト作戦でいく事としました。 個別の画面のリライトでベンチーマークとなる型ができればその型にそって各画面をリファクタしていく事はできるという見たての上での判断としました。

その他

パーフェクト Ruby on Rails　【増補改訂版】

やはり名著ですね、ジュニアのメンバーと一緒に読みあわせしたりしてここは設計の土台に活用してました。 こういう本が一冊あって共通で読めていると相互理解がすすみやすくありがたいです。

Model Checking, second edition (Cyber Physical Systems Series) (English Edition)

poketo7878-dev.hatenablog.com

学生時代に論理学やモデル検査系をかじっていてけっこう好きだったので、 モデル検査の名著という事で読んでみています。 まだ三分の2くらいですがアルゴリズムとか適用例とかのっていてとてもおもしろい。

問題解決力を鍛える!アルゴリズムとデータ構造 (KS情報科学専門書)

アルゴリズムの名著という事であたらしくでたので早速買っています。 普段はあまり複雑なアルゴリズムもデータ構造もつかう事は少ないですが、 読みながら競プロを埋めていったりしていておもしろいです。

RANGE（レンジ）　知識の「幅」が最強の武器になる

創業者エンジニアという事もあり幅広くやっていく事がおおく、 一方でエンジニアは専門性じゃ!みたいな事もわかるので自分のキャリアというか価値をどこにみいだすのかといった悩みもあり

エンジニアとしては専門性を高めないと意味ないみたいな話聞くたびになんともいえない思いをしていたのですが、創業者兼エンジニアというキャリアだと専門性に強くふろうとする事が価値につながらない事が多いからなぁっていうきもち

— Pocket7878 (@Pocket7878) 2020年8月27日

そういう観点もふくめて読んでいます。

鈍感な世界に生きる 敏感な人たち

誰か回りで困ってないかとか倫理的に問題がないかとかあの時の行動はただしかったのかとか 気になってしまってすごく長くひきずってしまったり、 人の細かい表情とかでなんかあったのかもとか気になりがちな部分があり、 良い部分でありつつ生きるのに向いてないなぁって悩む場面が多く、 ある時HSPなんじゃないですか僕も同じなのでと教えてもらった事があり心にとめていたのですが、 そういう部分との向きあいかたとしておすすめされたので読んでみています。

科学する麻雀 (講談社現代新書)

note.com

弊社でリモート環境化での交流娯楽の一貫として金曜の夜にオンラインゲームをする場面があり 雀魂もよくやっていたのですが、麻雀つよくなるにはという気持ちと、大学時代の研究室 麻雀AIの研究もされていたので、そういう事をおもいだして買ってみました。打ちての選択にたいして理論的・統計的な裏付けがされていておもしろいです。

Among Usも先週やったのですが、Crewの時はいいんですけど InposterはHSPが災いして嘘をつこうとしても手先が冷えてくるしクラクラするしで 性格的に向いてない事がわかった今日このごろ

まとめ

2020年は会社としても事業を一次停止したり新規事業を2つ立ちあげたり、 社会としても大きな変化があり生活や人々の交流の仕方にも大きな変化がありました。 それにともなって個人としても色々な領域での変化がありインプットを都度いろいろとしていた年でした。

来年はひきつづき幅ひろく色々な領域をやっていきながら、 人を採用してより専門性の高い人たちにまかせていくなかで、 自分がユーザー・組織にたいしてどういう価値提供が得意なのか見きわめそれをより伸ばせる年になれば良いなとおもっています。