生産性を後押しする情報群

3 min read読了の目安(約3000字

背景

新卒1年目にして大規模&超過密スケジュールの開発プロジェクトを経験し、
本気(マジ)で急がないと間に合わないような状況で、
追い詰められながら開発をしてみたら
超しんどいけど学びもあったのでメモです。

特に、開発中に一瞬でも手が止まった時

  • 情報を整理するためにほんの少し考える
  • 知識不足を埋め合わせるために情報収集をする

のどちらか以外が許されない状況だったので、
「開発の生産性を上げるためにどんな情報を手元におくべきか」 を考えるきっかけになりました。

以下の情報は今後自分がどんな開発案件でも常にアクセスできるようにしたい
(無いと困る)ものです。概ね優先度順です。

生産性を後押しする情報群

🙋🏻‍♂️🙋🏻‍♀️人

聞くのが一番早いと感じました。

特に僕みたいに知らないことの方が多い、経験の浅い人間は
一人で悩んだり闇雲に情報収集しにいくより
信頼できる人に質問をする方が良さそうでした。

チームでの開発は様々な興味関心・得意分野を持ち合わせる人と仕事ができ、
自分が行き詰まったことでも他のメンバーに聞いたら一瞬で答えが返ってきたり、
あるいはもっと詳しい人まで取り次いでもらったりして大変有益です。

超忙しい中でも幸いだったのは、
自分より10年以上経験のある先輩社員が一緒に仕事をしてくれたことで、

質問するたびに自分にとって予想だにしない新たな答えが返ってくることで
自分はどんな知識が足りていなかったのか、
どれだけ知る必要があるのか、ということを考えさせられました。

ただ、質問される側も僕と同じように忙しい中で時間を割いてくれてるので、
いざというときは頼りにしつつも自分なりに生産性を上げる努力をするべきだと思い
以下に続くような情報をもとに予習することを決めました。

🏢社内ドキュメント

開発組織に限らず、
ドキュメントをどれだけ・どのように残すかは各社様々な文化があると思います。

僕が入った案件では開発者向けに社内の技術ドキュメントが多く用意されており、
案件での技術スタック・アーキテクチャ・実装方針など様々な情報にアクセスが可能でした。

また、それら技術ドキュメントの多くは社内の優秀なエンジニア兄貴の方々が
実装例を交えながら解説してくださったもので、

  • 技術方針を実際のコードから学ぶ
  • 自分の実装の参考にする

という2点で主に効果的でした。

技術ドキュメントに限らず、
要件や仕様についてのドキュメントも必要になると思います
(僕は超必要だった)。

自分が向き合う要件ごとにドキュメントはざっと把握しておくのと、
関係のありそうなドキュメントの場所も知っておくことで
仕様をタスクに落とし込む 過程で必要以上に悩むことが減った気がします。

💻ネットで見れる公式ドキュメント

社内ドキュメントでカバーされていない、
あるいは要件に特有の機能について自分で実装の見通しを立てる必要がある場合は、
社外の頼れる情報を調べます。

エンジニアの情報共有サイト、ブログなど
エラー名で調べるだけで大量の情報にアクセスできる昨今、
公式のリソースをしっかり読む意志 を持つべきだと感じました。

公式ドキュメントは

  • 信頼性が高い
  • 体系的

の2点で価値があります。

開発者コミュニティの管理・議論の元
日々アップデートされる公式ドキュメントは
新鮮・正確な情報にありつけるという意味で信頼性が高く、

トピックごとに内容が整理され
自分が必要な内容にアクセスでき、他トピックとの関連も把握できるという意味で体系的です。

情報共有サイトに投稿されている内容は
公式よりもわかりやすかったり
あるいはコピペすればそのまま動くこともあったりするのですが
上記の2点に関して公式ドキュメントに劣るので

まず公式ドキュメントを見て、ちょっとわかりにくいと感じたら
噛み砕いて解説してくれている非公式の情報をざっと見る、
みたいな使い方の方が良さそうだと思いました。

補足:公式ドキュメントを読むその他のメリット

開発者コミュニティによってメンテナンスがされる公式ドキュメントはサイト自体のソースコードが公開されているケースが多いです。

公式ドキュメントを読んでみて
「ここは他の書き方がいいかも?」or「ここは内容が古そう?」と思った箇所は
issueやPRを通じて簡単に手を加えることができます。

そのようなドキュメントの修正もOSSへのコントリビューションと言えるため、
OSSに貢献したいというモチベがある方にとってはその機会を得ることができるという意味で
公式ドキュメントに触れることはおすゝめです。

🐙ソースコード(実装例)

前々項「社内ドキュメント」では
先輩エンジニア兄貴の方々による実装例が僕を救ったことについて触れましたが、

いくつも案件を抱えているような企業となれば
その数だけソースコードもあり、
学びの資源が手に入ります。

また、GitHubでは特定のTopicsやLanguageでOSSをExploreでき、
世界中のStrongな💪EngineerのCodeをDiscoverできます。

もちろん見てばかりじゃなくて書くことが一番勉強になるのですが、
自分で書くとなったときに
こういう時はどう書けば良いだろうか
もっといい書き方はないだろうか

と考えるための知識の引き出しを増やせるという意味で

参考になるようなソースコード(というよりリポジトリ?)は
いくつか手元に用意しておくのが良いと思います。

あとはコードレビューする時にも
「こういうやり方を知ってます!」みたいな感じでおすすめができます。

🚀補足:情報の整理に良いツール

どの情報も基本的にブラウザでアクセスすると思うのですが
ウインドウやタブがやたら増えて簡単に情報が氾濫すると思います。

僕はWorkonaというChromeの拡張ツールを用い、
ウインドウやタブの整理を徹底しています。

最初は
ウインドウをまとめて名前をつけて一時待避、という目的だったのですが
上記のようにいろんな情報にアクセスする必要が生じた場合

情報の目的ごとにウインドウのグループを作成し、
必要になったらそれらウインドウ単位でアクセスできる体制を構築しています。

例えばドメイン層の実装に役立つ社内ドキュメントや公式ドキュメント、ソースコードなどを
「ドメイン層_実装資料」みたいに名前をつけて保存しています。

評価の高いおすすめの拡張機能なのでぜひ使ってみてください(販促ではない)。

まとめ

種類としてはそんなに多くない情報群ですが、
実装しながら情報収集してみると
結構頻繁に人に聞いたり
多くのページを閲覧・保存しているので
日々様々な知見に支えられていることを実感しています。

僕自身は生産性を今後もさらに高めたいのと
個人の情報収集力だけに依存しないナレッジのため方についても関心があるので
もっと生産性を上げるための情報やその収集方法を
引き続き学んでいこうと思います。