本記事の主張とターゲット
- SEは業務で改善活動を行う
- SEは改善活動を情報工学の観点で行う
- 管理職は改善活動を会計学の観点で評価する
- SEも会計学の知識を有する必要がある
本記事は、業務改善が上手くできない若手SEをターゲットにしています。
はしがき
このタイトルを読みアクセスしていただいたということは、多かれ少なかれ業務に対して悩みがあり、その悩みには会社指示で行っている改善活動が含まれるのだと見受けられます。
今月の業務を思い返してみてください。課長が改善しろと指示をしてきたから、忙しい開発業務の合間を縫って改善ツールを作ってあげたというのに、
- 「活動ありきで本当に問題視されていることが解決できていない」
- 「現状分析が薄く説得力がない」
- 「効果が少なすぎるため活動のコストに見合わない」
など、管理職には心が無いと言われる理由が詰まった言葉を聞くことになり、すでに納期間際で心が弱っている身としては、泣きっ面に蜂という状態なわけです。
しかし、いくら待っていても現状のままです。この状況を打開するのはあなた。いつだって自分から行動しなければ何も変わらないのです。
本記事では、何故上司は私たちの改善活動に対して評価してくれないのかを会計学の観点から考えるとともに、対策の一例を紹介することを目的としています。
こちらの記事は、プログラミング技術などのテクノロジー系とは関係がありませんが、Qiitaガイドラインの今後同じようなことを学んだり、悩んだりするエンジニアが使う時間を減らし、エンジニアの成長や生産性をスピードアップさせることを目指します。に沿い、エンジニアが行う改善活動で、悩む時間を短縮する狙いとなっています。
SEが業務改善に取り組む際の課題
SEってS/Wの開発業務のみをやる仕事だと思っていました――
SEとして働く中で、会社から「業務改善」や「品質改善」を求められることは少なくありません。これらの改善活動の多くは、いわゆる上層部判断によって実施が決められることになります。
何故なら、会社経営者は会計学や経営学の観点より会社を管理しており、このような学問では継続的に改善活動をすることが企業存続に必要とされているからです。そのため、現代の企業で採用されている業務モデルには、これらの改善活動が組み込まれています。
しかし、我々は情報工学や情報科学を専攻してきているため、会計学や経営学に関する背景や目的を理解していません。上司の言う改善活動とは、会計学の観点による改善活動を指している一方で、指示されたSE側が情報工学の観点による改善活動を行ったところで、双方の認識に相違があることは自明です。
本記事では、この認識の相違を課題として定義し、SE側からどのようなアプローチができるかを考えることを目的とします。
方法として、会計学の歴史的背景や基礎を知ることで、会社から何を求められていてどんな活動が評価されるかを知り、日々の改善活動に役立つ知識を身に着けることを目指します。
(頑張って改善活動してるのに評価されないのは悲しいので)
会計学とは
戦いに勝つためには敵を知る必要がある――
会計学と聞くと、融通が利かないし数字ばかりで難しそうなイメージですが、その本質は企業や組織の経済活動を記録し、分類し、それを基に経営方針や売上目標などの意思決定をサポートする学問になります。
企業は様々な部署で様々な活動をしていますが、それぞれの部署で独自に分析していては会社全体としての分析ができません。そのため、すべての企業活動を何らかの共通単位に換算し、それを基に全体的な分析を行いたいと考えるのが自然です。その、何らかの共通単位に「カネ」を選んだものが会計学になります。
現代企業の会計は主に2つの分類ができます。
財務会計
-
目的
株主や金融機関など外部の利害関係者に対して、企業の財務状況や業績を報告すること。 -
特徴
いわゆる企業IR情報などがそれにあたります(株式投資をする方や就活生の方なら見たことあるかも)。法律で様式が定められており、そのルールに沿った資料を作成しなくてはならないことが特徴です。主に過去のデータに基づいて財務諸表を作成します。財務会計の研究分野では制度やあるべき論の内容になることが多いです。
管理会計
- 目的
経営管理者に対して、会計情報の提供により組織戦略などの意思決定を支援すること。 - 特徴
外部の人間が企業の管理会計データを見ることは少ないです(見られないことが大半)のであまり知られていません。管理会計にルールは無く、目的が達成できるのであれば特に資料や手法に指定はないです。主に、会計データを加工して作成した会計情報を経営者に提供することで、予算管理や原価計算、業績評価などの支援を行います。近年では品質や環境への影響なども評価対象とする傾向にあります。
今回のテーマである業務改善は管理会計に基づく改善活動と定義しており、財務会計の内容は本記事では取り扱わないこととします。
会計学の歴史
会計学は産業革命中である約200年ほど前に発展しており、紀元前から存在する哲学や数学、物理学などと比べると非常に歴史の浅い学問になります。
そのため、まだまだ改善の余地がある学問と言えます。
起源
会計の基本概念は、ルネサンス期にルカ・パチョーリという方が提唱した「複式簿記」です。簿記の資格試験を受けたことがある方ですと想像しやすいですが、いわゆる損益計算書や貸借対照表などです。複式簿記はお金の出入りや資産の状態をまとめた表となっており、一目で赤字か黒字かが分かります。日本へは明治の文明開化に合わせて西洋の文化とともに来日し、取り入れられてきました。
産業革命
産業革命は会計学にとっての大きな転換期となります。というのも、蒸気機関の発明により、人の流れが増大したり製品の大量生産が可能となったことにより、企業の規模も大きくなりました。規模が大きくなると、お金の管理が困難になります。家族経営などで小さな商いを営んでいる場合は、管理をしなくても直感的にお金の流れが分かりますが、規模が大きくなるにつれて一見すると不透明な部分が出てきてしまい、適切なお金の管理が必要になりました。
また、人が増えたことによりサボタージュ(サボる人)や作業の個人差が目立ち、作業手順の管理なども必要になりました。
この時期に、経営者たちは、効率的な運営と収益性を高めるために会計手法を発展させました。例えば、工程の標準化を行う「科学的管理法」や製品の原価を計算する「直接原価計算」という手法が生まれ、製品ごとのコストを正確に把握することが可能になりました。本記事の後半では、会計学の基礎である科学的管理法の説明を行います。
20世紀以降
細かいことは割愛しますが、製造業のさらなる発展や世界恐慌などにより、コスト管理や予算管理といった管理会計の技法が整備され、経営効率化を目的とする方法が確立されました。管理会計の特色上、外部にその詳細情報が出ることは少なく、学会の研究が先行しすぎて実際の企業とにおいて温度差のある時期がありましたが、最近では現場に寄り添った研究が行われる傾向にあります。また、会計学はアメリカで発展していましたが、日本でもトヨタ生産方式(TPS)の発展に伴い、直接お金に関係する範囲を超えた品質管理や生産性向上の分野でも活用されるようになりました。
科学的管理法と業務標準化
改善活動はデータがものを言う――
本記事の本題です。
歴史のセクションで挙げたように、会計学は紆余曲折あって現代の形になっていますが、その手法が本当に最適なのかはまだ不明です。しかし、産業革命期に確立した手法は200年分の検証がありますので、だいたい最適だと言えるでしょう。
よって、昨今の管理会計では現状の把握+改善活動が基本となります。管理会計を効果的に活用するためには、まず業務を標準化することが重要です。管理会計は自由なので、標準化の方法は何でもいいのですが、最初期にフレデリック・テイラーという方が提唱した「科学的管理法」を使って標準化を行ってみましょう。
科学的管理法の概要
-
定義
作業や業務を科学的に分析し、どの工程にどれほど時間がかかるのかを割り出します。その工程に対し最適な方法を導き出すことで、効率と生産性を最大化する管理手法になります。 -
目的
当時の非効率的な作業習慣(サボったり、作業のやり方が独自手法になってしまっていたり)を改善することを目的としていました。
この手法を使うことで作業効率を最大化し、コストを最小化する狙いがあります。 -
問題点
実は、この手法ではSEの作業を標準化することは難しいです。それもそのはずで、当時は製造業がメインでしたので、製品を作成する際の作業工程はほぼ決まっていました。しかし、SEは仕様検討や設計検討、既存システムの把握、さらには仕様変更などもあり、標準化は一筋縄でいきません。でも頑張ってください。標準化をしないと、改善活動に対する評価ができません。評価ができないということは、その改善活動が使えるかを上司が判断できないということになり、あなたへ酷評が下されます。なので、ここは頑張ってください。正直なところ、精度が悪くてもいいです。業務改善はPDCAを回すことが重要なので、失敗には寛大です。極端な例ですが、大事なのはサイクルを重ねる上で、評価ができる形で目標を立てているかとなり、回数を重ねるごとに少しでも改善されれば問題はないのです。
それでは、具体的に例を挙げてみます。S/W開発の内部設計を例に、業務を標準化してみます。以下はGPT 4oによる標準化ですが、実際の業務ではもっと多いかもしれません。なるべく細かく標準化することがコツです。何故なら、改善活動の評価をする際に、どの工程のどの作業が何時間削減できたのかということが分かりやすくなるからです。仮に効果が少なかったとしても、上司は具体的なアドバイスができるため、関数設計をする時のように1項目1機能くらいのつもりで標準化してください。
GPT 4oによる内部設計の標準化
内部設計書作成プロセスの標準化
1. 準備フェーズ
-
外部設計書の確認
- 受け取った外部設計書の内容を熟読し、全体像を把握する。
- 不明点や矛盾点をリストアップする。
- ドキュメントのフォーマットや要件仕様のスタイルを確認する。
-
必要なリソースの確認
- 使用するテンプレート（内部設計書のフォーマット）を準備する。
- 関連資料（技術仕様書、過去の設計書、コーディング規約など）を揃える。
- 必要に応じてチームメンバーや関係者と打ち合わせのスケジュールを設定。
2. 要件の詳細化
-
機能ごとの詳細設計項目を洗い出す
- 外部設計書の機能要件を分割し、各機能の内部構造を洗い出す。
- 各機能に対応するモジュールやクラスをリストアップする。
-
制約条件の確認
- 性能要件や運用要件を詳細化し、設計に影響を与える条件をリストアップする。
- 外部インターフェースの詳細仕様を確認する。
-
システム全体の設計方針を明確化
- モジュール間の依存関係を明確にする。
- 設計上のトレードオフや設計基準をチーム内で合意する。
3. 詳細設計作業
-
モジュールごとの設計
- 各モジュールの処理手順をフローチャートまたは擬似コードで作成する。
- 入力データと出力データの仕様を明確化する。
- データ構造やデータベース設計を記述する（例：ER図の作成）。
-
エラーハンドリングの設計
- 各モジュールで想定されるエラーをリストアップする。
- エラー発生時の処理内容（リトライ、ログ出力、通知など）を定義する。
-
パフォーマンス要件の組み込み
- 各モジュールの処理時間やリソース消費の目標値を設定する。
- ボトルネックとなりそうな処理を事前に特定し、最適化案を検討する。
4. 設計書の作成とレビュー
-
内部設計書の作成
- 標準テンプレートに基づいて、設計内容を体系的に記述する。
- 各章に必要な項目（概要、目的、機能説明、インターフェース仕様など）を網羅する。
-
レビュー用資料の準備
- 内部設計書をレビュー用のフォーマットに変換する（要約やチェックリストを付加する）。
- チーム内でレビューを依頼し、フィードバックを収集する。
-
レビュー結果の反映
- レビューコメントをもとに設計書を修正し、最終版を確定する。
5. ドキュメント管理
-
バージョン管理
- 設計書をリポジトリに登録し、バージョンを管理する。
- レビュー履歴や修正履歴を適切に記録する。
-
共有と引き継ぎ
- 設計書を関係者に共有し、チーム内で引き継ぎに必要な説明を行う。
- 内部設計書の目次や重要な仕様箇所を簡潔に説明するドキュメントを作成する。
上記の時間が割り出せたら、あとはあなたの改善ツールによって、どの項目が何時間削減できたかを結果としてまとめて、上司へ報告しましょう。
業務改善を行うにあたり、管理会計の考えが基となっており、この手法から外れることは、上長からのツッコミ(なんでその手法を取った？)が入ることを意味します。逆に言うと、この手法で分析してしまえば「基本に忠実ですね」と優しい言葉をかけてもらえる可能性が高いです。
まとめと次回予告
- 会計学の一ジャンルである管理会計の解説を行った
- 管理会計を意識した改善活動の一手法を紹介した
次回は、管理会計の一分野である「責任会計」に焦点を当て、会社から求められる改善活動を従業員個人としてはどのように考えるべきかについて解説したいです。
補足
この記事に書いた内容は正しい箇所もあり誤っている箇所もあるはずです。
管理会計に決まりはありませんので、例えば標準化方法に科学的管理法を用いなければならない理由はありません。
現代ですと、例えばAIによる作業風景の映像解析によってSEに特化した標準化ができたりするかもしれません。
ここらへんは自由なので、記事を読んでくれた方の中で良い方法を知っているよという方がいれば、教えていただきたいです。