仕事をする上で大切にしていること

普段の仕事では、Webシステムの開発をしているのですが、改めて大切にしていることをまとめてみようと思いました。これからより意識して取り組んで生きたいなと思います。

楽しいかどうか

私が大切にしていることは "楽しいかどうか" 。

個人差もありますが、基本的には楽しくないと１つの仕事を続けることは困難だと思ってます。特にプログラマみたいな新しいもの好きな指向の職種は顕著だと思います。

これは個人的に大切だと考えますが、事業運営の観点でも大切ではないかと感じています。事業優先で働き手のモチベーションを考えない運営は長く続かない、もしくはスピードを損ねた運営に甘んじることになると思います。

現代のソフトウェア開発の最善手は、いかにメンバーを固定できるかだと思うので、楽しく継続できれば長い目でメリットが大きくなると。

100のスピードで進んでいても、人が変わって50まで下がり、また100に戻すまでも時間がかかる。80でメンバーを固定して進み続けた方が理想的になる、というようなイメージです。

昨年に読んだ、ソフトウェアの質とスピードでも紹介されている感覚に近いではないかと思います。

楽しいとは

具体的に楽しいとは何か？自分なりに楽しいと感じるポイントをあげていきます。

・ユーザーに価値を提供できているか
・やったことがない事へのトライ
・より良く改善すること
・作業の自動化

ユーザーに価値を提供できているか
プログラマにはプログラミングを技術的に極めたい人もいるのですが、私は作ったものがどれだけ喜んでもらえたか、でプログラミングをしています。なので、せっかく作っても誰も使ってくれないものや一方的な運営側の都合などでする開発はとても苦しくなります。

ユーザーが喜ぶものを作って、もっと使ってもらえるようになれば皆がwinになるのではないかと思います。

もちろん、やってみないとわからないことも多くあるので、その場合は事前調査や小さく始めることを意識して進められればいいと思います。

やったことがない事へのトライ
これはプログラマ・エンジニアなら誰しもが持っているものだと思います。新しいプログラミング言語、フレームワーク、技術、開発手法などなど。

より良く改善すること
いわゆるレガシーなコードをリファクタリングすることや、プログラミング言語・フレームワークのバージョンアップ。UIの改善やレスポンスの向上などなど。

計測できる目標を設定して、数字で改善をモニタリングしたり、定性的にも良くなったと思えるような活動は、効果が実感できるので楽しく感じます。

作業の自動化
手作業で行っていたことが自動でできるようになったら嬉しいです。

IT化が進む昨今だと単純にプログラミングで自動化することは減ってきていると感じますが、ツールとプログラミングをうまく組み合わせたり、そもそもやり方を変えたりなど、色々考えることが楽しいと感じます。

楽しさを下げる要因

一方で楽しさを下げるポイントも挙げておきます。

・コミュニケーション
・心理的安全性
・開発者体験
・コードの品質に対する意識のずれ
・コードの品質に対する活動のずれ

コミュニケーション
バックグラウンドが異なる中で、お互いの状況を抜きにしてのコミュニケーションは多くの摩擦を生むと思います。

また、知った中でもお互いを気遣いあえるコミュニケーションをしていければ、よりいい仕事につながると思います。

心理的安全性
コミュニケーションと重複する部分もありますがあえて分けて書いたのは、何か発言や質問をする際の空気感も大切だなと思ったため分けて書きました。

発言や質問をした際に、発言者が損をするような環境だと誰も意見を言わなくなり、議論がされず問題も発見できなくなってしまいます。モヤモヤしていることをうまく共有して、改善やモチベーションにできると良いと思います。

開発者体験
ここ数年でデジタルトランスフォーメーションに塗り替えられてしまったDX。以前はデベロッパーエクスペリエンスという意味で使われ始めていて、開発者の体験をよくしようという動きも起こりはじめていたと思います。Dockerの普及などである程度改善されたため、あまり話題にならなくなったのかもしれません。

開発環境の準備に数日かかったり、PCスペックを高い水準で要求されたり、開発したものを本番に反映するために手間が多かったり（インフラ含めて）するような環境だと辛さが増していきます。

コードの品質に対する意識のずれ
負債やレガシーと言葉にするのはものすごく簡単ですが、実際にこの認識をあわせることはとても大変だと思います。

はっきりと良くないコードというものはありますが、ある程度のレベルになれば複数の設計やコーディングからいずれかを選ばなければなりません。その方法の良し悪しを判断する基準は、多くの場合それまでのバックグラウンドに依ります。

バックグラウンドが異なる中でソフトウェア開発を行うであれば、方針を文書化しておくと、摩擦が減り心理的負担が抑えられると思います。

また、コードの重複度や複雑度などの静的解析でチェックできる部分は積極的に運用していくといいと思います。

コードの品質に対する活動のずれ
負債がどういうものか認識が共有できても、それが放置されている状況は健全とは言えません。

どのように負債を解消して、質とスピードを向上するか、そのためのアクションを決めたいですよね？

個人的には、負債の計測と新規変更時のチェックから始めて、まずはそれ以上負債が作られないようにすることが大切だと思います。

まとめ

楽しいと感じるポイントと阻害要因を並べてはみましたが、もちろんこれらは理想論であり全て完璧に満たされる環境や状況はないと思います。

仕事をしていて違和感を感じたら、これらのポイントを基準に振り返って少しでも改善することができたらいいなと思います。

特に、マイナスのポイントはいくらプラスが強くても"楽しい" が上がりづらいので優先的に是正したいポイントだと思います。