企業経営ってこうあるべきだと思うんです
ここでは私が６年エンジニア（リーダー）として働き、方向性の違いで来月卒業する会社に向けて、会社としてこう変わっていけば良くなると思うことについて書いていきます。
長期的な利益を追求する
最も基本的なことです。
プロジェクト単体の3年、５年、１０年後の利益 = 成長が試算できたなら、積極的にチーム全体に共有した方がいいと思います。それがチームの目標となり、その現場に居る理由になります。
利益が出ているのかすら分からず、機能追加、障害対応、リプレイスの連続ばかりだと、単純に昇給のタイミングが見えませんし、その仕事の重要性も分かりません。
商品の将来云々よりも、メンバーとしてこんなにやりがいの無いことはありません。
せめて、苦しい作業ばかりさせられている人材には「ありがとう」の一言が欲しいところですが、その「ありがとう」は明るい将来を約束するものであるべきです。
ブランディングを徹底し、意味のないことはやらない
アイデアを形にするだけでは売れる商品は作れません。
それは趣味の方がよくやる「作ってみた」と同じで、ユーザーから対価を得るには全く失礼な商品であり、今時の企業が販売する製品の基準には達しません。
アイデアが見つかったら、様々なユーザー視点に立ってシミュレーションし、商品コンセプトをしっかり固めましょう。
ブランディングはスローガンのようなものを考える作業ではなく、要件定義そのものであり、マーケティング、利益とコスト、内部のワークフローまで織り込んだ、サービスを運営するための設計書です。
そのコンセプトが要求するものは徹底して研究開発し、そのコンセプトの外にあるものは一切機能追加する必要はありません。
安易な機能追加で一時的な利益を見込むくらいなら、ユーザー・エクスペリエンス（UX）の向上に尽力すべきです。
小さなサービスの組み合わせで会社を形成する
単純に、どんなに優れた人材でも一人のエンジニアが60個ものリポジトリ（サーバー）を管理できるわけがありません。
弊社のリソースはだいたい丸こげ状態で、新規の方にさっと投げられるものが一切ありません。
近年のオープンソースに依存するソフトウェアは毎年、いや常に日々更新される最新バージョンに対応した状態を保つ必要があり、セキュリティアップデートは頻繁になされ、また単純にパッケージのアップデートをするだけだと、廃止されたインターフェースにより機能が動作しなくなることは普通にあります。
そのため責任のない新規の方に古いリポジトリを投げることは本来あってはならないことなのです。
こういった問題から、マイクロサービスとは決してコード設計の話だけではなく、企業としてのあり方を定義するものだと最近よく思います。
「この機能を追加したら契約してくれるお客さんが居る」そう言って安易に機能追加されて行った結果がうちの製品なんだと思います。
決して営業が安易な考えで動いている訳ではないことは理解していますし、できるだけ提案に応えようと尽力してきました。
そういうこともあり、全て単機能にバラして作成し、バラで売っていたらなと常々思います。
それなら別サイトで小さなサービスとして運用ができたんです。
小さな単位で製品を企画し、小さな単位で利益を考えていれば見えること
個々の機能の成果が見えやすく、評価がしやすい。
必要な人材の数が把握しやすい。
欠員が出ても人材の補充にそこまで苦労しなくていい。
機能の成長が見えやすく、予算増強または削減、サービス停止が考えやすい。
必要なログの収集方法も見えてくる。
リポジトリが小さくなり１、２人のプロジェクトとして理想的なサイズ感。
個人の持ち込み企画としても、ブランディング、会計管理、実装まで全て任せられるサイズ感。
フロントを別々のサブドメインで小さく作れる。
完全に独立したサービスとして作成でき、廃棄もしやすい。
内部のAPI連携は特に難しいことではない。
フレームワークのアップグレードやリニューアルも個別に対応できる。
個々の資料がコンパクトになる。
巨大なモノリシックなサービスにしないことは私はとても合理的で良いことだと思っています。
巨大な製品というのは、巨大な資金に支えられたプロジェクトにしか成し得ないものだとすら思います。
しかしこれは会社自体がソフトウェア開発企業として問題を理解し、そういう方針で歩んでもらわなければ実現できることではありません。
例として、会計管理のfreeが提唱するスモールビジネスもそういったソフトウェア開発の問題解決を含むフレームワークだと予想でき、実際にfreeのサイトは機能毎にサイトが別れています。
現状のエンジニアに運用サポートは居ない
先に述べたとうり、現状の弊社エンジニアの業務は膨大です。
1日に何件も調査依頼や問い合わせ対応をさせられると業務が回りません。
丸一日コードが書けず、チャットばかりしている日もよくあります。
「運用」というポジションがあるのであれば、運用は製品について全て理解し、仕様書を読んで作業できないと仕事になりません。
「この機能ってどうなってるんですか？」別に聞かれれば答えますが、本来は運用側で仕様書から調べてWikiを作って頂きたいのが本音ですし、知らないでいい事とも思いません。
しかし、現状は運用のポジションが本来の仕事をできる環境にないのが事実です。
それは製品の運用フローについてしっかりと考えられていないため、運用が作業できるよう資料整備し、データを確認、操作できるようAdminが設計されていないためであり、現状は全てエンジニアがプログラミングを通して確認するしかない状態です。
それが当たり前になっているため、運用が顧客の望みを考えることに終止し、運用としての環境作りを考えなくなっています。
だから日常的に多くのチャットが飛び交うんです。
運用側もそのどうしようもない現状に自担打を踏んでいますが、Adminから運用できるよう一つずつプロジェクトを立てましょうというのが一つの回答になります。
手っ取り早くAWSコンソールに入れば閲覧・操作できるものもありますが、NoSQLのDBに関してはまず必要な情報の検索ができないはずです。
私はそのために何度もAdminのリプレイス、機能追加を強行してきましたが、「製品開発が優先」と判断されて全て半端な所で頓挫しています。
しかし絶対にトータルではアドバンテージの高い開発だと思います。
エンジニアと運用のポジションをしっかり機能させるためにも、運用ツールの開発については真剣に取り組むべきです。
この記事が気に入ったらサポートをしてみませんか？