こんにちは、エスワイシステム関東の中平です。
ソフトウェア開発において、 コードレビュー は欠かせないプロセスです。
開発者が書いたコードをそのままリリースすれば、 「仕様ミス」や「バグ」、「パフォーマンス問題」 などが発生し、
最悪の場合、システム全体が崩壊することすらあり得ます。
そのため、 「他のエンジニアがチェックし、品質を担保する」 という仕組みが組み込まれています。
この概念は、ソフトウェア開発において 「コードレビュー・品質管理」 として知られていますが、
専門的には 「ソフトウェア品質保証（Software Quality Assurance, SQA）」 という領域に属します。
実は、これと全く同じことが、 「私のブログの承認フロー」 でも起きています。
承認フローは「コードレビュー」だ！
私は毎日ブログを書いている。
しかし、その記事が 即座に世に出るわけではない。
1. インターン生I君の校正
→ コードで言えば「静的解析ツール」。誤字脱字のチェック、論理の一貫性を確認し、明らかにミスと思われる部分を修正する。
→ また、写真や図を乗せたりする。
2. Oさんの承認
→ 「CI/CD の本番リリース前の最終レビュー」。企業ページのブログ記事として適切か？ 誤解を招く内容ではないか？ などといったブランドイメージを守るための最終チェックが行われる。
つまり、私が書いた記事は 「Pull Request を出してレビュー待ち」 の状態になるのだ。
|
コードレビュー （ソフトウェア開発）
|
承認フロー （ブログ記事）
|
レビューで否認されることもある
これまでに、私の書いたブログ記事は 5回 却下された。
理由は、 「企業として発信するのにそぐわない内容である」 とのこと。
例えば、
- 「なぜ私は焼肉を食べると爆速で仕事が進むのか？」
- 「仕事のモチベーションを上げるためにはガチャを回すべきだ」
などの記事が Reject（PRクローズ） されたわけだ。
個人的には、どちらの記事も 「根拠ある理論に基づいた高度な考察」 だったつもりだが、
「企業ページのブログ記事」という観点では「仕様に適合していない」との判断であったようだ。
「レビューは面倒だが、最終的な品質を守る」
コードレビューを受けるエンジニアは 「俺の書いたコードを信用してくれ！」 と思うものだ。
しかし、そこを 「いや、チェックがあるからこそ品質が守られる」 と考えることが重要になる。
これはブログの承認フローでも同じこと。
私は否認されると 「くそっ…！」 と思うこともあるが、
「この仕組みがあるから、最終的なブログのクオリティが保証される」 という安心感もある。
ソフトウェア開発も、ブログの承認フローも、 「レビューというプロセスを経て品質を上げる」 という意味では本質的に同じなのだ。
レビューと承認フローがあるからこそ、強いプロダクト（コンテンツ）が生まれる
ソフトウェア開発の世界では、 「コードレビューなしでの本番リリースは事故の元」 と言われる。
そして、 ブログもレビューなしで公開すれば、事故が起きるかもしれない。
だからこそ、私は今日も、レビューされることを前提にブログを書く。
次こそは、I君とOさんに「Approve」をもらえるように。
著者情報
中平 裕貴（Yuki Nakahira）
株式会社エスワイシステム 関東事業本部
関東第2事業部 3SEシステム6部 事業部長代理
『技術 × 事業戦略 × 組織運営をつなぐ実務家』
エンジニアとしての技術的な知見を持ちながら、営業・事業運営・HR・組織マネジメントの視点も持つ実務家。
エンジニア、グループ会社経営、営業を経験し、技術とビジネスの両方を理解した「橋渡し役」として事業推進に携わる。
技術と組織運営をつなぎ、主体的なチームを育て、人々が「WONT TO」で動ける社会を目指す。
🛠 技術領域
アプリ開発、クラウド、データ分析、AI、
📈 事業・営業経験
SI事業の拡大、プロジェクトマネジメント、アジャイル
🏗 組織マネジメント
リーダー育成、組織改革、チームビルディング
📩 お問い合わせ・お仕事のご相談はこちらから↓
