開発における制約と自由のバランスで考えていること
あなたは開発において組織に自由を重んじますか？
もしくは制約や規律を重要視しますか？
自分は前者で、コードチェックとテストにおける仕様と動作保証がされていれば、やり方はあまり問わない方です。
しかし世の中では、後者の「制約や規律を重要視する」方を好む人が多いように思えます。
これはいわゆる
「ベストプラックティス」
と呼ばれる砂上の楼閣を信奉する人々です。
web上で「ベストプラックティス」で検索すると多くの記事が見つかるのは、それだけ多くの人に需要がある証拠でしょう。
例えば、彼らは開発において
「こういった書き方のほうがいいですね」
といった、複雑度や速度といった客観的な数値でなく、「それってあなたの感想ですよね？」的な指摘をしてくる傾向があります。
このような振る舞いは
高学歴で優秀なサラリーマン型エンジニアによく見られます。
彼らは大多数によって支持されている解答や解決方法を好みます。
「こうなれば開発がより効率化できる」
「hogehoge会社のサービスではこういった運営がされている」
といった提灯メディア記事を取り上げて賞賛し、それを自社に取り入れようと布教する傾向も強いです。
そこには
具体的な利益
という観点が抜け落ちています。
もちろん組織のイチサラリーマンにそこを求めるのはお門違いで過剰でしょう。そもそもとして、具体的な利益まで考え抜ける人は、独立しています。
しかし、こういった人が増えてくるとサービスの成長は徐々にブレーキがかかってきて、業績も落ちてきてしまいます。
ベンチャーが成長するにつれ高学歴のメンバーが集まり、会社の成長が鈍化していくというのは、ITの世界ではよく見る光景です。
じゃあ、なんでも自由にやらせた方がいいのかというとそれも間違いです。
あまりにも自由にさせすぎると問題が発生します。
サービスが成長すればするほど問題は深刻になる傾向があります。
なので、自由の中にも制約を課すことが重要なのですが、どの程度制約をつけることがサービスを最大限に成長させることができるかは、難しい判断になります。
というわけで今回は
開発における制約と自由のバランスで考えていること
について記載します。
具体的には
良い制約と悪い制約
良い自由と悪い自由
について記載します。
良い制約と悪い制約
私が考える良い制約とは
負担が少なく、全員の負担感がほぼ同じであること
複雑でなくシンプルであること
全体の生産を上げる制約
です。
逆に悪い制約は
負担が大きく、全員の負担感がバラバラであること
シンプルでなく、複雑であること
全体の生産を下げる制約
です。
制約と聞くと、ネガティブなイメージを持つ人も多いでしょうが、プラスの面もあります。
それは
制約からアイデアや解決方法が生まれることも多い
からです。
そもそも世の中には多くの制約が存在し、社会や組織内で決めた制約だけでなく、物理的な制約も多々存在します。
ただ開発における制約では、生産性を下げる制約が決められていることがよく見られます。
典型的なのは
過度なセキュリティ対策
過度な業務連絡や報告
過度ドキュメンテーションの取り決め or 過不足なドキュメンテーション
などが挙げられます。
難しいのは、これらは制約が全くない状態だと生産性を下げてしまう一方で、過剰に制約をかけても生産性を下げてしまうということです。
なので、定期的に調整をする必要があります。
そして、大切なのは
制約にベストプラックティスはない
ということです。
どれくらいの制約が適切かは、組織の規模、組織に属している人材によって異なります。
一般的には組織が大きくなればなるほど、多くの制約が必要になる傾向があります。
なぜなら、制約もなく各々が好き勝手に行動をしてしまうと、管理コストが上がり、生産性が悪くなってしまうからです。
なので、どうしてもある程度の制約が必要になってきます。
例えば、プログラミング言語pythonを利用した開発では
静的コード解析ツール「Ruff」とコードフォーマッター「Black」の実行を強制することで、最低限のコード基準を満たす
などの制約が考えられます。
他にも
複雑な仕様のドキュメント化
環境構築の自動(半自動）化
なども候補になるでしょう。
この時、気をつけなければいけないことは
制約には優先順位をつける
ということです。
理由は
制約が増えるほど物事は複雑になり、また、それを同時に満たす方法も少なくなっていく
からです。
上記の例で言えば
コードにコメントを残しつつ、ドキュメントにも仕様を記載する
という制約を決めたとしても、この両方を実行するのは困難です。
なぜなら
コードのコメントですら、実際のコード仕様と一致させるのが難しいのに、さらにドキュメントにも間違いなく仕様を記載するというのは、現実的ではありません。時間は有限なのです。
このような場合であれば
テストケースを正にしてコードのコメントとドキュメントにはテストケースのリンク先のみ記載する
ような対応にすることが考えられます。
コードのツールについても同様で、ツールを使えば使うほど、実装の幅は狭まります。改修コストも嵩みます。
どんな制約にもメリットとデメリットが混在します。
それらを考えて制約を取り決めることが大切です。
また
一つ制約を増やしたら、一つ制約を減らす
ことも重要です。
基本的には
物事はなるべくシンプルにする
ことです。
良い自由と悪い自由
私は考える良い自由とは
挑戦できる余地がある
能力を高められる
全体の生産性が上がる
です。
逆に悪い自由は
何をして良いかわからなくなる
全体の生産性を下がる
周りの足を引っ張る
ことです。
基本的に自由は生産性を高めます。
最近では、ABW(Activity Based Working)を取り入れる企業も増えてきました。
一方で、自由は混沌にもつながリます。
制約があまりに少ないと、混沌としていて対応を考えるのが難しくなるときもあります。
一般的に、小さい組織では制約が少なく、ストレスを感じることが少ない傾向にあります。
一方、大きな組織ではそれまでに積み上げてきた経緯から発生した制約があり、自由が少なくなっています。
しかし、人は自由が少なく、やらされている感が芽生えると、やる気を失います。
こうなると生産性が大きく下がってしまいます。
なので、組織が大きくなっていく中でも制約を見直し、いかに働き手が自由を感じられる環境設計をするかが重要になります。
具体的には
自分の仕事のやり方や思想を押し付けない
自分の意見を言うだけでなく、相手の意見も必ず聞く
放置しない。自由と放置は異なる
といったことです。
人が組織を離れる理由の多くは
人間関係か環境
にあります。
そして、その不満のほとんどが
納得のいかない仕事のやり方や思想を押しつけられる
一方的な意見を言うだけで、こちらの意見は聞かない
といったような内容です。
これでは優秀な人材は集まりませんし、集まっても残りません。
もちろん完璧な組織などは世の中に存在しません。
扱う情報の内容によっては、働き手の自由を奪わざるを得ない場合もあります。
しかし、その理由の説明はきちんとするべきです。
適切な自由が与えられている環境では、人は組織を離れませんし、その結果として、人と組織の両輪で力をつけていくことができます。
まとめ
今回は
開発における制約と自由のバランスで考えていること
について記載しました。
まとめると
制約は必要悪だが、なるべくシンプルにして、一つ増やしたら一つ減らすことを考えるべき
自由を感じられる環境とは、一方的な思想の押し付けをせず、お互いの意見を言い合える環境を作ることである
ということです。
この記事では開発現場を想定して書きましたが、開発現場以外の他の仕事であっても、組織作りの基本的な考え方は同じです。
制約と自由のバランスをうまく管理し、生産性が高く、満足度の高い素晴らしい組織を作り上げてください。