と、言うわけで、面白いもんが出てきたのでつなぎに（笑）
何かっつーと、寨主が１０年前に書いた課長昇格時の論文です（爆）
シリーズで言うと、１～６辺りの登場人物が役員をしてた頃のもんです。
しかし、今読んでも良く書けてるな、とゆー自画自賛（笑）
もう一つ、この論文の半年後の部長昇格論文もあったんで、明日upします。
が、これって別に寨主の文才とか、マネージャとしての能力を自慢したいわけじゃなくて、こんなこと書かれちゃう会社の状況ってゆーか、役員たちの能力欠如の傍証として、エピソードの状況を把握してもらうには良さそうだと思ってね。
ちなみに、当時論文審査の後に役員面接審査があったんだけど、論文審査が通らないと面接には行けませんでした。
で、提出された論文は５人くらいの役員が読んで、コメントとランクを付けるんだけど、審査後に大体上司がこっそり見せてくれるってのが慣例になってました。
で、これも部長論文も似たような感じだったけど、銀行出身の経理役員は大絶賛してくれてて、創業役員は「何を言ってるか判らん」とか「難しすぎる」とかのコメントが付いて評価が低いと（爆）
つか、書いてることって当たり前のことだけで、大したこと書いてないじゃん（笑）
ま、一応「論文」なんで、国文出身の寨主としては、「論文」を書いたわけですが、技術者出身の役員たちには”論文調”が難しかったか、そもそも”経営”に関わる話が難しかったらしい(^_^;;;
見りゃ判りますが、長文です。
-------------------------------------------------------------------------
論題に基づき、ＸＸＸＸＸＸＸＸ部における問題点を技術・教育・運営の各観点から考察し、それぞれに対する実現可能な解決策を論述する。以下、内容の一部は既に部として実施中のものもあるが、それについては予め了承願いたい。
一章 技術的観点
技術的観点から観た問題は以下の二点に集約される。
一点は技術者の専門性の低下、二点目はプロジェクト管理技術の欠如である。
一 技術者の専門性の低下
まず業界全般で技術の一般範囲が広くなっていることからくる技術者の専門性の低下であるが、現在の業界動向を俯瞰するとオープンシステム化の波は留まるところを知らず、Ｃ／Ｓからインターネットへと形を変えながら進行している。これらの技術は将に日進月歩で幅を広げつつある。
この事象は、開発の現場に習得すべき技術分野の限り無い拡大を生む母体となっている。
かつて、我々の時代には現在の技術の根本となる技術が一般的かつ狭い範囲で存在し、市販の書籍も少なかったこともあり、必要に迫られてではあるが自力で技術を習得せざるを得ない場面も多かった。
このような経験をしてきたものにとっては、現在の進歩した技術もより具体的な構造イメージとして捉えることが比較的容易であるが、今を出発点とする技術者にとっては個々の技術の構造からの理解は難しいようである。
開発を行う上で、そこまでの理解は不要であると言う意見もあるとは思うが、実際の開発ではそこまで理解していれば発生しないトラブルも事実として存在するし、そのような技術力があって初めてより有利な契約交渉も可能であると言えよう。
現在の規模の当社では、品質が良いだけでは当然のこととして他社との差別化の対象とはなりえず、専門性、言い換えればより高い技術力のみがただ一つの武器となり得る。
しかし、敢えて述べるまでもなく、個人としてのスキルで賄え得る範囲には自ずと限界があり、ましてや経験年数の少ない技術者にとってはこれは大きな精神的圧迫となっていることは事実である。最近の退職者の中においてもこれを理由とするものもいたほどであり、このような技術者の発生を防ぎ社員の定着率を向上させることは、部の、強いては経営の根幹に関わることで忽せにはできない。
これらの経営的な課題は、方や技術者に技術的な向上を求め、方や技術的に負荷をかけないと言う一見相反するものであるため、解決方法は一つしか有り得ない。
結論的には、この解決方法は至って簡単で、現在ＸＸＸＸＸＸＸＸ部において試行中であるが、各技術分野の分散習得である。現状では、全ての技術者に全ての技術分野を均等に、且つ深く極めることを求めるために広く浅くなる傾向にあり、プレッシャーとなっている。これをグループ化した技術者単位に特定の技術分野のみを絞り込んで習得させることによって、上記の問題を解決するものである。技術
者によっては、ある分野の習得が十分であれば、別分野へ技術力を伸ばすと言うように段階を踏んだスキルアップを図ることも可能であるし、部として見れば新規プロジェクト発足時に必要なスキルに従って、各グループから技術者をアサインすることで、副次的に要員管理の効率化を促す。
但し、最終的にそこまで持って行くには時間もかかることであり、即効薬的にそこまでの効果は得られるものではない。
二 プロジェクト管理技術の欠如
一で述べたようなオープンシステム化の流れには、一部マスコミ及びメインフレーム各社の唄い文句で安、早の二文字が付きまとう。
ソフトウェア製造業は基本的に知識集約的な仕事であって、技術革新による生産性の向上がマスコミが喧伝するように画期的には起こり得ない。（確かに一部工程では労働集約的作業を伴うので、１００％否定する訳ではないが）
寧ろ、かつてのように全てを１ベンダで統一できた頃のシステムに比較すれば、製品間のインタフェースの違いや製品組み合わせの多様化から難易度は上がっている。当然、調査等の実際の開発以外で費消される工数も増加することとなる。
しかし、エンドユーザは前述の造られた常識が前提となっているため、ここ数年のシステムは工期・工数共に以前に比べ縮小傾向にある。
このような状況下での開発を行う場合、各技術者の技術力も然る事ながら、それらの技術者を取りまとめ、プロジェクトの問題点を把握補正し、維持運営していくためのプロジェクト管理技術の優劣がプロジェクトの成否の鍵を握ることとなる。
社内及び社外のプロジェクトを観ても、品質的利益的に失敗と思われるプロジェクトではこの問題が散見できる。
開発を行っていた技術者がリーダとなった場合、最初に訪れる戸惑いは何をどうすればよいか判らないと言う類のものが多く、プロジェクト管理を知らないことがその要因となっている。
プロジェクト管理は本来技法であり、リーダの資質とは無関係であるため、あるパターンのポイントさえ押さえていれば、問題を最小限で食い止め軌道修正することも可能で、大きな失敗にはならないものである。
現状では、ＸＸＸＸＸＸＸＸＸ部においてはプロジェクト管理のためのツールとしての各種フォーマットの規定はされているが、残念ながらそれを使って行う方法論が確定されていない。各社では、ＩＳＯ９０００に準拠した管理要綱等を制定しているところもあるが、これらはプロジェクト管理の集大成である。
当社でも全社の統一のプロジェクト管理方法の制定が望まれるが、これらの制定には時間も工数もノウハウも必要であるので、大上段に振りかぶらず少しづつ部内での統一を行うことが現実的であろう。
このように方法論をルール化し、各プロジェクト運営において遵守させ定型業務のように実施させること、つまり具体的なマニュアルを提供して実行を義務化しいくことが、この問題に対する最も簡単な解決策である。
二章 教育的観点
教育的観点からＸＸＸＸＸＸＸＸＸ部を眺めた場合、問題は教育の内容や方法ではなく、教育を受ける側の意識にある。逆に言えば、これは教育を行う我々側の、部下に対する動機付けが十分ではないことの証しであろう。
一章でも述べたようにＸＸＸＸＸＸＸＸＸ部では、既に教育方法として技術の分散習得を採用しているが（ユニット制と称する）、内容的にはＵＮＩＸ・ＤＢ・クライアントＯＳの三分野に部員を配し、それぞれのノウハウを業務とは別個に習得していくもので、運営は各ユニットに所属する課長代理クラスを中心に委ねられている。
これらの活動はまだ初に就いたばかりではあるが、現時点で観ても部員の参加意識が受動的であるように見受けられる。このシステムの導入時の本義は、各自に動機付けを行った上でそれぞれが主体的に技術の習得に励むための基盤を設けることであった。が、新人は別としてもそれ以外までもが教えてもらうと言うスタンスになりつつある。これはこのシステムの運営が各自の業務等の都合によって間欠的になった場合、自主的な努力が行われなくなる可能性を秘めている。
比較的若い世代の社員と話していて感じることは、上昇志向が少ないこととプライドが高いこと、それと自分自身に枠をはめて自分から出て来ないことである。無論、全ての社員がそうである訳ではないが傾向として否めないところであろう。指導教育のターゲットを考える時、これは外せないポイントである。
易きに流れるのは人の常であって、善悪というよりそれが本性であると言う前提に立てば、これに対する指導方法には一顧を要する。
つまり、業務命令として一方的に指示することでは意識改革には繋がらず、反感を買うか萎縮させてしまうこととなり、目的が達せられない懸念がある。
私論では、仏教で言う方便なのかも知れないが、自身の技術力を高めることは会社への利益をもたらし、それで初めて自分の増収と言う形で戻って来ることを理解させることである。誰しもより良い生活を送りたいし、自分のことであれば主体的にならざるを得ない。酷な意見であることは重々承知してはいても、現実解を求めるならば上記の答えが導き出される。
言わば、飴と鞭の論理だが、会社を公器と考えるならば自分がそれに参加している実感を持たせること、現実的に給与・賞与の形で評価することと合わせて行わなければ難しいと考える。
この指導と実績に対する評価の考え方は、今回の改定された人事評定方式と主旨を同じくしており、新人事評定方式の運用が正しく行われれば問題を解決するかも知れないが、誤解を恐れずに言わせてもらえば今回の改定自体が若干付け焼き刃的な感が拭えなかったので、開発本部との密な連携を行った上で評価される側からも理解できる透明な評価方法の提示が必要なのではなかろうか。
三章 運営的観点
ソフトウェア開発におけるプロジェクトの単位でも原価管理を行うことが一般的であるが、オープンシステム部というより、当社全体の雰囲気としてその考え方が希薄なように思えてならない。
更に言うなら、収益に対する意識が低いのではないかと感じる場合が希にある。
聞くところによれば、当社ではプロジェクト単位の予実管理は主に工数単位で行われていて、収益ベースの管理は部に対して一意に決められた原価率で全プロジェクト一律に行われていると言う。
この形で管理を行うとすれば、社内的には契約時に原価見積を行い、利益率の最低限度等の基準を設けることが必要ではないかと思うが、現在の見積は工数見積のみで原価見積は行っていないし、利益率云々という話は聞いたことがない。
当社の契約形態では、契約単価は当社のテーブルではなく、顧客のテーブルに従っていて、なおかつ同一顧客でもプロジェクト毎に単価が変わることがしばしばある。
このような状況で工数ベースの管理を行っていれば、同一の契約工数を同一の実績工数で上げたとしても掛かる原価が同じであるため、利益に差異が生ずるのは当然である。
また、管理単位が工数であるため、誰が何時間残業を行ったとしても工数的には１人月の計上しかされないので、見掛けと実績の原価の違いも発生する。
「原価率」での管理について言えば、上記でも判るように売上に対する原価率で算出される金額は実際の原価とはなんら関係がないため、「売上に対して使用しても良い金額のパーセンテージ」でしかない。目標原価率と言うことなのであろうか。原価見積を前提に売価の決定を行っていないのに、目標原価率で成績を判断するのは、釈然としない。
前年度の決算報告において、増収減益との話があったが、「入るを図って出づるを制す」の基本が忘れられ、「入る」にばかり気を取られてこれらのことが等閑にされていることが、根底にあるのではなかろうか。
結局は、最初に述べたような状況を作り出しているのはそのような環境であって、一般の会社の管理職が持ち得るような、初歩的な経営に対する意識を持っていなくても管理職が勤まるような状況が、その元凶ではなかろうか。
当社がより発展していくためには、現在のように管理職が高級ＳＥであるだけではなく、どうしてもそれぞれのセクションに対しての経営意識を持つことが必要であると信ずる。
このような状態に対して意識改革を行う一つの案として、見積を含めたプロジェクト管理に現在の工数ベースのプロジェクト管理だけでなく、収益ベースのプロジェクト管理も合わせて実施するよう義務付けるのはどうであろうか。
ここで言うのは、何も財務諸表のような詳細且つ正確なものを指す訳ではなく、もっと簡素なものでよい。そして、意図はあくまで意識を持たせるためであるので、いきなりそれを評価と連動させないことである。例としてあげるならば、
・社員各ランク毎の全社共通の標準原価を設定する。
・各協力会社毎の単価テーブルを提供する。
・当社としての適正利益率を設定する。
・見積作成時は概算原価を算出し、利益率を上乗せしたものを作成した後、現在の工数見積と顧客毎
の単価テーブルから採算ラインを検討して、提示金額を決定する。
・要員計画に従い、契約工数を開発期間に分配し、各月毎の原価及び売上配分を行う。
・月毎に確定した実績の原価と上記を使用して、収支の予実管理を行う。
というようなものである。この程度の管理であれば、基本的に開発に直接参与していない管理職であれば実現可能ではないだろうか。
多少の誤差は出るとしても、このような管理を行っていれば、予算に対してその時の状況から今後どのような施策を行うべきか、どの程度の新規契約が必要か等の判断材料にはなるであろう。
四章 総論
他社を経験した目で見ると、当社は良い社風を持っていると思う。比較的オープンであるし、技術的にも一級とは言わないまでもかなり高いレベルにあり、上昇志向もある。
ただ、数年間離れて戻って来て見て思うのは、以前よりもそれが組織としてではなんて、個人に依存する割合が高くなってきていることである。これは具体的にどうと言うことではなく、直感的なものなので非常に説明しにくいのではあるが、そのように感じられる。
２０周年を迎えて、そろそろ曲がり角に来ているとも言えなくはないが、良い社風をもう一度組織の体質として取り戻したいものである。
散漫ではあるが、これを当論文の総論として代えさせていただく。
何かっつーと、寨主が１０年前に書いた課長昇格時の論文です（爆）
シリーズで言うと、１～６辺りの登場人物が役員をしてた頃のもんです。
しかし、今読んでも良く書けてるな、とゆー自画自賛（笑）
もう一つ、この論文の半年後の部長昇格論文もあったんで、明日upします。
が、これって別に寨主の文才とか、マネージャとしての能力を自慢したいわけじゃなくて、こんなこと書かれちゃう会社の状況ってゆーか、役員たちの能力欠如の傍証として、エピソードの状況を把握してもらうには良さそうだと思ってね。
ちなみに、当時論文審査の後に役員面接審査があったんだけど、論文審査が通らないと面接には行けませんでした。
で、提出された論文は５人くらいの役員が読んで、コメントとランクを付けるんだけど、審査後に大体上司がこっそり見せてくれるってのが慣例になってました。
で、これも部長論文も似たような感じだったけど、銀行出身の経理役員は大絶賛してくれてて、創業役員は「何を言ってるか判らん」とか「難しすぎる」とかのコメントが付いて評価が低いと（爆）
つか、書いてることって当たり前のことだけで、大したこと書いてないじゃん（笑）
ま、一応「論文」なんで、国文出身の寨主としては、「論文」を書いたわけですが、技術者出身の役員たちには”論文調”が難しかったか、そもそも”経営”に関わる話が難しかったらしい(^_^;;;
見りゃ判りますが、長文です。
-------------------------------------------------------------------------
論題に基づき、ＸＸＸＸＸＸＸＸ部における問題点を技術・教育・運営の各観点から考察し、それぞれに対する実現可能な解決策を論述する。以下、内容の一部は既に部として実施中のものもあるが、それについては予め了承願いたい。
一章 技術的観点
技術的観点から観た問題は以下の二点に集約される。
一点は技術者の専門性の低下、二点目はプロジェクト管理技術の欠如である。
一 技術者の専門性の低下
まず業界全般で技術の一般範囲が広くなっていることからくる技術者の専門性の低下であるが、現在の業界動向を俯瞰するとオープンシステム化の波は留まるところを知らず、Ｃ／Ｓからインターネットへと形を変えながら進行している。これらの技術は将に日進月歩で幅を広げつつある。
この事象は、開発の現場に習得すべき技術分野の限り無い拡大を生む母体となっている。
かつて、我々の時代には現在の技術の根本となる技術が一般的かつ狭い範囲で存在し、市販の書籍も少なかったこともあり、必要に迫られてではあるが自力で技術を習得せざるを得ない場面も多かった。
このような経験をしてきたものにとっては、現在の進歩した技術もより具体的な構造イメージとして捉えることが比較的容易であるが、今を出発点とする技術者にとっては個々の技術の構造からの理解は難しいようである。
開発を行う上で、そこまでの理解は不要であると言う意見もあるとは思うが、実際の開発ではそこまで理解していれば発生しないトラブルも事実として存在するし、そのような技術力があって初めてより有利な契約交渉も可能であると言えよう。
現在の規模の当社では、品質が良いだけでは当然のこととして他社との差別化の対象とはなりえず、専門性、言い換えればより高い技術力のみがただ一つの武器となり得る。
しかし、敢えて述べるまでもなく、個人としてのスキルで賄え得る範囲には自ずと限界があり、ましてや経験年数の少ない技術者にとってはこれは大きな精神的圧迫となっていることは事実である。最近の退職者の中においてもこれを理由とするものもいたほどであり、このような技術者の発生を防ぎ社員の定着率を向上させることは、部の、強いては経営の根幹に関わることで忽せにはできない。
これらの経営的な課題は、方や技術者に技術的な向上を求め、方や技術的に負荷をかけないと言う一見相反するものであるため、解決方法は一つしか有り得ない。
結論的には、この解決方法は至って簡単で、現在ＸＸＸＸＸＸＸＸ部において試行中であるが、各技術分野の分散習得である。現状では、全ての技術者に全ての技術分野を均等に、且つ深く極めることを求めるために広く浅くなる傾向にあり、プレッシャーとなっている。これをグループ化した技術者単位に特定の技術分野のみを絞り込んで習得させることによって、上記の問題を解決するものである。技術
者によっては、ある分野の習得が十分であれば、別分野へ技術力を伸ばすと言うように段階を踏んだスキルアップを図ることも可能であるし、部として見れば新規プロジェクト発足時に必要なスキルに従って、各グループから技術者をアサインすることで、副次的に要員管理の効率化を促す。
但し、最終的にそこまで持って行くには時間もかかることであり、即効薬的にそこまでの効果は得られるものではない。
二 プロジェクト管理技術の欠如
一で述べたようなオープンシステム化の流れには、一部マスコミ及びメインフレーム各社の唄い文句で安、早の二文字が付きまとう。
ソフトウェア製造業は基本的に知識集約的な仕事であって、技術革新による生産性の向上がマスコミが喧伝するように画期的には起こり得ない。（確かに一部工程では労働集約的作業を伴うので、１００％否定する訳ではないが）
寧ろ、かつてのように全てを１ベンダで統一できた頃のシステムに比較すれば、製品間のインタフェースの違いや製品組み合わせの多様化から難易度は上がっている。当然、調査等の実際の開発以外で費消される工数も増加することとなる。
しかし、エンドユーザは前述の造られた常識が前提となっているため、ここ数年のシステムは工期・工数共に以前に比べ縮小傾向にある。
このような状況下での開発を行う場合、各技術者の技術力も然る事ながら、それらの技術者を取りまとめ、プロジェクトの問題点を把握補正し、維持運営していくためのプロジェクト管理技術の優劣がプロジェクトの成否の鍵を握ることとなる。
社内及び社外のプロジェクトを観ても、品質的利益的に失敗と思われるプロジェクトではこの問題が散見できる。
開発を行っていた技術者がリーダとなった場合、最初に訪れる戸惑いは何をどうすればよいか判らないと言う類のものが多く、プロジェクト管理を知らないことがその要因となっている。
プロジェクト管理は本来技法であり、リーダの資質とは無関係であるため、あるパターンのポイントさえ押さえていれば、問題を最小限で食い止め軌道修正することも可能で、大きな失敗にはならないものである。
現状では、ＸＸＸＸＸＸＸＸＸ部においてはプロジェクト管理のためのツールとしての各種フォーマットの規定はされているが、残念ながらそれを使って行う方法論が確定されていない。各社では、ＩＳＯ９０００に準拠した管理要綱等を制定しているところもあるが、これらはプロジェクト管理の集大成である。
当社でも全社の統一のプロジェクト管理方法の制定が望まれるが、これらの制定には時間も工数もノウハウも必要であるので、大上段に振りかぶらず少しづつ部内での統一を行うことが現実的であろう。
このように方法論をルール化し、各プロジェクト運営において遵守させ定型業務のように実施させること、つまり具体的なマニュアルを提供して実行を義務化しいくことが、この問題に対する最も簡単な解決策である。
二章 教育的観点
教育的観点からＸＸＸＸＸＸＸＸＸ部を眺めた場合、問題は教育の内容や方法ではなく、教育を受ける側の意識にある。逆に言えば、これは教育を行う我々側の、部下に対する動機付けが十分ではないことの証しであろう。
一章でも述べたようにＸＸＸＸＸＸＸＸＸ部では、既に教育方法として技術の分散習得を採用しているが（ユニット制と称する）、内容的にはＵＮＩＸ・ＤＢ・クライアントＯＳの三分野に部員を配し、それぞれのノウハウを業務とは別個に習得していくもので、運営は各ユニットに所属する課長代理クラスを中心に委ねられている。
これらの活動はまだ初に就いたばかりではあるが、現時点で観ても部員の参加意識が受動的であるように見受けられる。このシステムの導入時の本義は、各自に動機付けを行った上でそれぞれが主体的に技術の習得に励むための基盤を設けることであった。が、新人は別としてもそれ以外までもが教えてもらうと言うスタンスになりつつある。これはこのシステムの運営が各自の業務等の都合によって間欠的になった場合、自主的な努力が行われなくなる可能性を秘めている。
比較的若い世代の社員と話していて感じることは、上昇志向が少ないこととプライドが高いこと、それと自分自身に枠をはめて自分から出て来ないことである。無論、全ての社員がそうである訳ではないが傾向として否めないところであろう。指導教育のターゲットを考える時、これは外せないポイントである。
易きに流れるのは人の常であって、善悪というよりそれが本性であると言う前提に立てば、これに対する指導方法には一顧を要する。
つまり、業務命令として一方的に指示することでは意識改革には繋がらず、反感を買うか萎縮させてしまうこととなり、目的が達せられない懸念がある。
私論では、仏教で言う方便なのかも知れないが、自身の技術力を高めることは会社への利益をもたらし、それで初めて自分の増収と言う形で戻って来ることを理解させることである。誰しもより良い生活を送りたいし、自分のことであれば主体的にならざるを得ない。酷な意見であることは重々承知してはいても、現実解を求めるならば上記の答えが導き出される。
言わば、飴と鞭の論理だが、会社を公器と考えるならば自分がそれに参加している実感を持たせること、現実的に給与・賞与の形で評価することと合わせて行わなければ難しいと考える。
この指導と実績に対する評価の考え方は、今回の改定された人事評定方式と主旨を同じくしており、新人事評定方式の運用が正しく行われれば問題を解決するかも知れないが、誤解を恐れずに言わせてもらえば今回の改定自体が若干付け焼き刃的な感が拭えなかったので、開発本部との密な連携を行った上で評価される側からも理解できる透明な評価方法の提示が必要なのではなかろうか。
三章 運営的観点
ソフトウェア開発におけるプロジェクトの単位でも原価管理を行うことが一般的であるが、オープンシステム部というより、当社全体の雰囲気としてその考え方が希薄なように思えてならない。
更に言うなら、収益に対する意識が低いのではないかと感じる場合が希にある。
聞くところによれば、当社ではプロジェクト単位の予実管理は主に工数単位で行われていて、収益ベースの管理は部に対して一意に決められた原価率で全プロジェクト一律に行われていると言う。
この形で管理を行うとすれば、社内的には契約時に原価見積を行い、利益率の最低限度等の基準を設けることが必要ではないかと思うが、現在の見積は工数見積のみで原価見積は行っていないし、利益率云々という話は聞いたことがない。
当社の契約形態では、契約単価は当社のテーブルではなく、顧客のテーブルに従っていて、なおかつ同一顧客でもプロジェクト毎に単価が変わることがしばしばある。
このような状況で工数ベースの管理を行っていれば、同一の契約工数を同一の実績工数で上げたとしても掛かる原価が同じであるため、利益に差異が生ずるのは当然である。
また、管理単位が工数であるため、誰が何時間残業を行ったとしても工数的には１人月の計上しかされないので、見掛けと実績の原価の違いも発生する。
「原価率」での管理について言えば、上記でも判るように売上に対する原価率で算出される金額は実際の原価とはなんら関係がないため、「売上に対して使用しても良い金額のパーセンテージ」でしかない。目標原価率と言うことなのであろうか。原価見積を前提に売価の決定を行っていないのに、目標原価率で成績を判断するのは、釈然としない。
前年度の決算報告において、増収減益との話があったが、「入るを図って出づるを制す」の基本が忘れられ、「入る」にばかり気を取られてこれらのことが等閑にされていることが、根底にあるのではなかろうか。
結局は、最初に述べたような状況を作り出しているのはそのような環境であって、一般の会社の管理職が持ち得るような、初歩的な経営に対する意識を持っていなくても管理職が勤まるような状況が、その元凶ではなかろうか。
当社がより発展していくためには、現在のように管理職が高級ＳＥであるだけではなく、どうしてもそれぞれのセクションに対しての経営意識を持つことが必要であると信ずる。
このような状態に対して意識改革を行う一つの案として、見積を含めたプロジェクト管理に現在の工数ベースのプロジェクト管理だけでなく、収益ベースのプロジェクト管理も合わせて実施するよう義務付けるのはどうであろうか。
ここで言うのは、何も財務諸表のような詳細且つ正確なものを指す訳ではなく、もっと簡素なものでよい。そして、意図はあくまで意識を持たせるためであるので、いきなりそれを評価と連動させないことである。例としてあげるならば、
・社員各ランク毎の全社共通の標準原価を設定する。
・各協力会社毎の単価テーブルを提供する。
・当社としての適正利益率を設定する。
・見積作成時は概算原価を算出し、利益率を上乗せしたものを作成した後、現在の工数見積と顧客毎
の単価テーブルから採算ラインを検討して、提示金額を決定する。
・要員計画に従い、契約工数を開発期間に分配し、各月毎の原価及び売上配分を行う。
・月毎に確定した実績の原価と上記を使用して、収支の予実管理を行う。
というようなものである。この程度の管理であれば、基本的に開発に直接参与していない管理職であれば実現可能ではないだろうか。
多少の誤差は出るとしても、このような管理を行っていれば、予算に対してその時の状況から今後どのような施策を行うべきか、どの程度の新規契約が必要か等の判断材料にはなるであろう。
四章 総論
他社を経験した目で見ると、当社は良い社風を持っていると思う。比較的オープンであるし、技術的にも一級とは言わないまでもかなり高いレベルにあり、上昇志向もある。
ただ、数年間離れて戻って来て見て思うのは、以前よりもそれが組織としてではなんて、個人に依存する割合が高くなってきていることである。これは具体的にどうと言うことではなく、直感的なものなので非常に説明しにくいのではあるが、そのように感じられる。
２０周年を迎えて、そろそろ曲がり角に来ているとも言えなくはないが、良い社風をもう一度組織の体質として取り戻したいものである。
散漫ではあるが、これを当論文の総論として代えさせていただく。