2021年やったこと振り返り | マネジメント と 停滞

はじめに

会社に入って１年が経ち、任される仕事量も大きく増えた１年でした。一方で、自分の中に積み上がったものという観点で考えると、少し停滞を感じています。

要件整理と設計

年明けから春頃までは大きなシステムの設計を進めていましたが、失敗で終わりました。今振り返ると「顧客の求めていることがわかってない」状態になのですが、まさか自分がその状態になるとは思っていませんでした。

顧客が本当に必要だったもの という有名な（?）画像がありますが、まさにあんな感じです。

まだないものを作る

元々私は食品の営業として働いていました。出来上がった商品を売るので、納品物に対して認識齟齬はあり得ませんでした。ところがシステム開発においては、まだ存在しないものを作成します。したがって、顧客と私たちの脳内イメージを一致させなければなりません。

ウォーターフォールにしろ、アジャイルにしろ、この「認識の一致」はとても難しいです。まず顧客の業務を理解しなければならないと改めて感じた１年でした。

業務要件の理解

業務要件を理解するためには、できれば顧客の業務全体を理解する必要があるように思います。全体の中でどのようにシステムが役立つのかを知らなければ、局所的なシステムを作成してしまう恐れがあるからです。加えて、顧客が話す業務の中にも正確でないものや、本来連携して然るべき業務同士の繋がりが網羅できてない場合もあります。

その業務を見たこともやったこともない状態で、いきなり話だけ聞いて「はい完全に理解しました」となるはずがないのです。

ではどうしたらいいかですが、例えば

• 業務アプリケーションであれば、実際に使用される現場を見たり、
• to C のアプリケーションであれば段ボールでもいいのでモックアップにして、実際にロールプレイしたり
• XDなどデザインツールをもっと活用して、想像を膨らませる

こういった時間が十分に（顧客と）取れると良いと思いました。

ちなみに現実で起きたことは、上記の逆です。

• 口頭でしか業務について聞く機会がない。しかもリモート。
• すぐに作り始める。さっさとプロトタイプしたほうが話が早いと考える。
• XDの使い方を学ぶより、MVPを実装したほうが早いと考える。

では、どうしてそうなってしまうのか

**「システムとして考える」**発想と能力が足りていないのでは...と仮説を立てています。

顧客の要望をシステムに落とし込み、まだ見えていない要件を見出すためには、やはり技術力が必要ではないかと思います。ここでいう技術力とは「要件を満たすためのシステムを想像する」能力であり、「ExpressでWebアプリケーションが書ける」などとは異なります。

加えて、この「システム」とは、デジタルの世界で作るアプリケーションだけではなく、それを使用する人々を含む全体的なまとまりを指します。このシステム全体を想像するための「技術力」が自分には不足していると考えています。

具体的には以下の２つがあるといいなと思っています。

1. アプリケーションのライフサイクル全般にわたっての運用経験（システムの一生を知る）

• 開発
• テスト
• デプロイ
• 障害対応
• スケーリング
• ...
• サービスの終了

受託開発の現場で働いていると、「開発〜リリース」までで止まってしまう案件が少なくないと感じています。つまり実際にユーザーが使用し、それをサポートするところまで想像が及ばないわけです。もちろん努力はしますが、どうしてもリリースが目標になってしまう現実があります。（納期もあるし）

そもそも使われないもの、使いにくいものを作ってもしょうがないですし、運用する中で直面するであろう様々な困難を想像できないと、どうしても「その場しのぎのシステム」しか描けないかな、と思います。

2. 低レイヤーに関する知識（現状動いているシステムの理解に必要）

• OS
• ネットワーク
• データ構造
• ファイルシステム
• ...etc

これから作るアプリケーションがそれ単体で運用される状況は、よほどのイノベーションでない限り滅多にないのではと思います。多くは現状動いているシステムの一部を引き継いだり、 toCのアプリケーションであればユーザーの生活システムの一部を担当するでしょう。

したがって、「現状どうなっているのか」という前提を理解するための技術力として、所謂低レイヤーの知識が役立つのではないかと考えています。これはひょっとすると、情報系の学校出身の方には当てはまらないかもしれません。私個人は表層の部分だけを見て生きてきましたので、上記のような理解を今後は意識的にする必要があると思っています。

開発のその前に

システム開発が仕事かと思いきや、その前段階にもっともっとやるべき仕事がある、と身にしみた１年だったかなと思います。しかも、2021年の前半からわかっていたはずなのに結局年末までその反省を活かせず仕舞いでした。正直いって得意ではないのですが、だからといって諦めていいものではないので、来年以降もこの戦いの継続を予想しつつ、少しづつ上手くやれるようになれればと思います。

チームマネジメントとプロジェクトマネジメント

また、2021年はチーム開発をリードする、いわゆるPL的な役割を全うした一年でした。メンバーの方々が本当に素晴らしい方ばかりでしたので、なんとか助かった...という心境です。

一方でプロジェクトの管理に関しては、まだまだ課題山積です。

チームの皆様: やっていただく

チームとの関わりに関しては、「お仕事をしていただく」意識を持って取り組んだ１年でした。

前職では指示出しするシーンが多かったです。自分でやったほうが早い。質も高い....。驕りです。なんでも自分でやって、見せて、覚えてもらう、というスタイルでした。その結果としては自分が潰れてしまったのですが。

そういう経験もあって、なるべく「指示しない」という方針で、2021年を過ごしました。ちなみに、１０名行かないくらいの小さいチームの話です。

マネージャはメンバーに仕事を「やっていただいて」、その分け前をもらうようなものかなと思います。したがって私のすべきことは指示出しではなく環境づくりです。メンバーの方がなるべく自分で判断してトライできる環境こそ一番大事。

...と、頭では思っていても実際は自分が割と動いてしまうシーンも多々ありました。自分で動けるときに動くのは全く悪い行動ではありませんが、無意識的にそういう状態になっている状況が多いことには問題意識を持っています。もっともこれは、チーム管理ではなくて自己管理の問題なのですが。

顧客の皆様: こちらでやる

チームマネジメントと両輪で考えなければならないのが、プロジェクトマネジメントです。こちらは反対に、もっと自分が主導権を握ってコントロールすべきだったと感じています。

「まだないものを作る」という特性ゆえに、どうしても不確実な部分を孕んで進むのがシステム開発なのかなと、この１年で思うようになりました。重要なのはその不確実な部分を、当然のものとして自分ごとに捉える必要があります。

不確実な部分をいかに確実なものにしていけるか、そのためにはどれくらいのスケジュールが必要で、決まった内容はいつまで変更できるのか、...など決まっていないものを決めていくプロセスがなかなかうまくできない期間を過ごしました。

お客様あっての受託開発なので、どうしてもそういう不確実な部分は顧客側で決めていただく心境になりやすいです。しかしそれでは上手く進まないのではと考えるようになりました。

使用したフレームワークなど

モバイルアプリ関連

• React Native
• Recoil
• SWR

メインの業務で使用。Recoilがついに案件でも採用できるようになり、構成として安定した感じがあります。Expoも大型のアップデートがあり、機能がさらに充実しています。Bare React Nativeで立ち上げて、必要なモジュールだけExpoから使用するケースが多いです。

AWS関連

サーバレスの構成について、学習しアプリケーションを作成しました。SAMのおかげでリソース管理がしやすいのでかなり敷居が下がったように思います。

• SAM
• Lambda
• Cognito
• DynamoDB
• APIGateway

特にDynamoDB特有のテーブル設計については新しい概念として楽しく学べたと思っています。今後他の案件でもどんどん使用できると嬉しいです。

Rust関連

• Bracket-lib
• Actix-web
• Rocket

相変わらずちまちま学習しています。ようやくなんとなく掴めてきた。（掴めてきたとは言ってない）

stack overflowでの回答

回答者として多少活動してコード書きたい欲を発散していました。しかしながら、なかなかどうしてバシッと解決できたことは少ないですね。ましてやベストアンサーなど。

あと世界中にはありえないくらい初心者がいっぱいいることを実感しました。別にマウント取ってるわけではないのですが、自分以外にも悩む人がたくさんいるのだなあと思うと少し楽になります。

ランクが上がって、upvoteできるようになったのは嬉しかったです。

Github Copilot

今年一番の驚き、感動みたいなものを感じました。劇的に作業効率が上がったわけではないのですが、確実に手札は増えました。

ちゃんと変数名とか関数名とか名付けをできればタイピングしなくていい場面が増えるので、英語得意な人はどんどん使えると思います。

それと、Rustとの相性もすこぶるいいです。Rustは厳格なコンパイラが知られており、学習元のデータが綺麗です。元データが綺麗なので必然的にAIが生成するコードも品質が高いです。

• AIがコードを書く
• 優秀なコンパイラによるチェック
• Push
• それをもとにAIがコードを...

という正のサイクル。（違ったらすみません）

まとめ

やはり去年よりインプットが少ないなあという印象です。性格的に流されるままにお仕事をすることが多くなってしまうので、来年は自分のコントロールできる範囲をもう少し増やして新鮮な体験を増やしたいです。

過去の振り返り