はじめに
この記事は BrainPad Advent Calendar 2021 5日目の記事です。
今年、僕は開発プロジェクトがどうすればうまくやっていけるだろうか？ということを考えて、調べたり試したりしてました。 が、ぶっちゃけ上手くはいきませんでした。 とはいえ振り返ると反省点や勉強になったところはいくつかあるのでそれをまとめていこうと思います。
また関連する書籍のリンクも掲載しています。
技術的な話はほぼ無く、開発プロセスの話になります。
また僕はリーダー的なポジションではなく、あくまで開発メンバー視点にはなります。
若干1日目とネタが被ってるのもご了承ください。
プロセス改善も実装力もどちらも必要
当たり前といえばそうなんですが、個人的にプロセス改善の方を注視しすぎたという話です。
今年の前半、どのようにチケットを調整すれば、どのように会話していけばもっと効率よく開発を進められるだろうか……。
ということを色々考えてましたがなかなか改善しませんでした。
後から振り返ると、単純に実装力（技術理解、コードの質、スピード）不足も大きな要因の一つでした。
そもそも、僕自身技術そのものよりもプロジェクトマネジメント、組織論といった分野への興味のほうが強いというのもあります。
が、技術領域がある程度わかるという慢心があったなと思ってます。
今年の後半は別のプロジェクトに移ったのに合わせて、言語仕様を学びつつ進めてみました。
それ自体は良かったのですが、今度は仕様検討に時間がかかる、テストを拡充できてないなど開発体制への課題が見えてきました。
今年の前半でやってきたことも無駄ではなかった、というところでプロセス改善も実装力も必要だなと思った次第でした。
難しい本を最初から最後まで読もうとしてはいけない
読書術に関する本ではよく言われていることなんですけど、僕は結構苦手でした。
なんかもったいない気がするというか、一通り読まないと読んだことにならなくね？というか。
なんなら出口治明さんのように読書家には最初から最後まで読むべきだ！という人もいます。
ビジネス書、自己啓発に近い書籍だったりすると、平易な言葉で書かれているし内容もわかりやすいので最初から読むのでも1,2日で最後まで読めちゃいます。
しかし技術書だとそうはいきません。オライリー本なんて大体厚いです。
僕は社内輪読会を開いていて、それで読んできた本も多いですが1冊読み通すのに数ヶ月かかります。
休日に頑張って読むこともたびたびありますが結構しんどいです。
というところで全通はすっぱり諦めて、気になったところを読む、助けが必要なときに読むことが増えました。
やってみると明らかにこちらのほうが楽で、精読ができ、効果的であることがわかります。
web検索的な使い方ですが、それよりも詳細がわかる、ノイズが少ないのが読書のメリットです。
あとは書籍に期待しすぎないというのも一つ。
基本的に書籍は汎用的な話になるので、今自分の目の前の課題をまるっと解決してくれる可能性は低いです。
でも後々役に立つ可能性がある……かもしれないです。
対話を恐れない
僕は比較的喋るエンジニアだと思ってます。理解力、説明力があるとかではなく、ただ陰キャの中では陽キャ寄りという程度の話です。
しかし目上の人に業務の相談をするのはちょっと勇気がいります。
別に、理不尽にブチギレられるとかはないです。基本的に優しく教えてもらえます。
単純に技術力に大きな差があって誤りを指摘されるのが怖い。
でも相談しないと作業は停滞します。
単純に、喋ってみたらすぐ解決する話であることが多い、という経験も多いです。
これに関連するところで心理的安全性に興味を持って調べてました。
心理的安全性が無い職場だと報告、連絡、相談ができず、重大な問題が発生しても隠そうとして状況は悪化してしまう……というやつです。
どうすれば恐れがない組織にできるのか。文化を変えるのには時間がかかるし難しいという前提はありますが、無知であることを隠さないことが心理的安全性を高める一因であるそうです。
どちらかというとマネージャーへの提言にも見えますが、下のポジションでも無知であることを隠さずに聞く、それを続けて空気、文化を徐々に変えていく、というのはできそうです。
他社の情報にもアンテナを張る
普段仕事をしている限りだと目の前のタスクとか社内のことしか目に入りません。
たまに競合製品とかお客さんを検索してみたりはしましたが……。
それとは関係無く、他のweb企業のブログとか発表を見てみると面白いです。
最近聞いたのが、毎朝10分程度の勉強会をする、というものです。
これは面白そうだしうちでもすぐできるかも、と思い提案し、今では自分のいるグループで実施しています。
他社のいいなぁ、と思うことが案外自社でもいける、かもです。
ストレッチゾーンにいる
新しい仕事を任されそうになると、ビビリます。
荷が重そう、負担が増えそう、自信が無い……。
でもやってみると意外とできたりします。
コンフォートゾーン / ストレッチゾーン / パニックゾーンというのがあります。
コンフォートゾーンは快適な状態です。特にストレス無くいつも通りやれば良い状態。
ここにいる限りは特に変化は無いです。
ストレッチゾーンは少し背伸びした、ちょっと大変な状態です。
ただその成長が見込めるのもここです。（僕は成長という言葉は好きではありませんが……）そして徐々にコンフォートゾーンは広がります。
パニックゾーンはそのまんま、ストレスが過度な状態です。これは心身ともにボロボロになってしまう。
成長とかどうでもいいからずっとコンフォートゾーンでええやん、という気もしないでもないです。
ただ僕としては、コンフォートゾーンを広げていくのが結果として後が楽だろう、という先行投資的な考え方です。
単純に後で緊急事態が発生したときに何もできないのが怖いというのもあります。
というところで先にリハーサルをちょっとずつしていこうとしています。
kindle unlimitedという素晴らしいサービス
美容室でdマガジンを読んだとき結構衝撃を受けました。まさか美容室で週刊プロレスを読めるとは……。
お試しでdマガジンを登録したのですが、これが良かった。
さらにタブレットを買って、kindle unlimitedも始めてみて……とみるみる電子書籍ユーザになりました。
kindle unlimitedには漫画、小説といったエンタメも多いですが、ビジネス書もあるし、意外と技術書もあります。
書籍を買う、というのはそこそこハードル高いですが、これだと図書館みたいなもので、ちょっとだけ読んで別の本を読むということができます。
あとkindle本はスマホアプリのalexaで音読してもらうこともこともできます。正直使いにくいですが……ながらで聞いてみるというも一つの読み方です。
もっと自由でいい
これこそ自己啓発っぽい見出しですが、書籍を読んだ結果こういう考え方をしても良いんだ、と自由になれることがあります。
仮に環境に不満があれば、転職するのも一つだし、環境を変えていくのでも良い。
やりたいことをもっと口に出しても良い。成功した話だけでなくて失敗した話もしても良い。
これらは以下の書籍を読んで僕が印象に残っている話です。
この記事自体も、すごい技術をめっちゃ活用した話とかはできないけど上手くいかなかったからその話を書こうと思ったのがきっかけです。
- 達人プログラマー
- ハッカーと画家 コンピュータ時代の創造者たち
- SOFT SKILLS ソフトウェア開発者の人生マニュアル
- 人生の土台となる読書――ダメな人間でも、なんとか生き延びるための「本の効用」ベスト30
さいごに
本当はプロジェクトマネジメントとか課題解決にまつわる書籍の話もしようかと思ったんですがまとまらなかったのでここに残しておきます。
正直これらの本を読んだけど成果あんま出なかったと書いちゃってはいるんですが、どれも即時的なものではなく頭を使うときの根底に役立ってはいると感じてはいます。
- イシューからはじめよ ― 知的生産の「シンプルな本質」
- エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング
- アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法
- 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
- 考える技術・書く技術―問題解決力を伸ばすピラミッド原則
色々書きましたが、読書が何もかも解決してくれるわけじゃないけど読んでみると面白いよという話でした。
以上です。