Avar

コストカットによる収益改善は一時的なものである。
経営者はコスト(支出)よりも、利益(収入)を優先すべきであると考える。

「コストカッター」として一躍有名になったのは、とある自動車会社のCEOである。
日本人経営者がやらなかったリストラや徹底的なコストカットにより、確かに会社をV字回復に導いたことは事実である。
極めて個人的な意見だが、コストカットは本当に経営者が行うべきものであるか疑問である。
それはコストカットの以下のような特徴があるからだ。
 (1) 対外要因が無い。(自分達の努力だけで利益が増える)
 (2) コストカットを実施したことによるデメリットをあまり感じない。
 (3) 比較的簡単に実施可能。
 (4) 一時的に成果が上がる。
特筆すべきは、「(3) 比較的簡単に実施可能」であり、誰にでもできることだからだ。

あなたが小学生だった頃のことを思い出してほしい。
あなたは親から貰った小遣いが少なくて困ったことは無いだろうか?
その時あなたはどうしただろうか?恐らく買いたいおもちゃや駄菓子を我慢したことだろう。
この場合、収入(小遣い)は決まっているのだから、支出が少なくなるようにやりくりするしかない。実に単純である。

会社等でのコストカットもスケールは異なるものの、原理は小遣いと変わらない。
経営者は一般社員よりも責任も重いが、多くの給与も貰っている。
自分のような凡人からすれば、高度な経営戦略が立てられる能力を有する人であることは疑う余地も無い。
そのような高度なレベルの人が小学生が思い付くようなレベルでの経営をして欲しくないと思っている。

では、経営者は何を行うべきか?
それは収益を増やすことを考えれば良いのだ。
何故なら末端社員では、収益を上げるような方法論は見えず権限も無い。
一方で経営者は会社全体が見えており、新しいことを行う権限を有している。

もちろん経営者視点でしかできないコストカットがあるかもしれないが、
コストカットには限界があるが、収益拡大は青天井である。
是非とも経営者諸氏には、下(コストカット)ではなく、上(収益)を視て頂きたいと切に願う。

プログラマーとスーパープログラマー

プログラマーには、普通プログラマーの3倍の早さで組める人がいる。
この人を「スーパープログラマー」と呼ぶ。
なお、私自身は普通プログラマーである。

個人的な環境下での経験だが、バリバリの開発系の会社で働いていた時にスーパープログラマーだと思ったのは、およそ20年間で約2人である。それだけスーパープログラマーは少ない。
「約2人」としたのは、スーパープログラマーには明確な定義が無いためだ。
なお、マネジメント中心の会社では、当然ながらスーパープログラマーとの遭遇率はゼロである。

そして”3倍早い”は、「とあるアニメに出てくる赤い彗星をもじってる」と思われるかもしれないが、一応の根拠はある。(本人から直接聞いた訳では無いため、推測が入る。)
まず、スーパープログラマーは、プログラムの完成形を素早く頭の中に完璧なイメージとして描いている。
だからスーパープログラマーの作業は、頭の中のイメージ通り「プログラムを組む(1.0)」これに尽きる。
※カッコ内は論理的な作業工数を表す。

一方普通のプログラマーも頭の中にある程度のイメージはあるものの、そこまで明確ではない。
そのため、プログラミングは大抵以下のような作業となる。
「プログラムを組む(1.0)」→「不満な箇所を削除する(0.5)」→「考える(0.5)」→「再度プログラムを組む(1.0)」

上記の作業工数を比較すると、以下のようになる。
・スーパープログラマー:1.0
・普通プログラマー:1.0 + 0.5 + 0.5 + 1.0 = 3.0
やや強引な根拠であるが、普通プログラマーは3倍の工数を使うことになる。

プログラミングには、以下の要素を持ってプログラムしている。
(1) 完成時にどうなっているか
(2) 個別の関数(メソッド)のインターフェース
(3) 各関数(メソッド)間のつながり
(4) ある程度の拡張性
(5) プログラムを組む
スーパープログラマーは、頭の回転が早く、プログラムにも精通しているため、
上記(1)~(4)までの完成イメージ言い換えれば、「論理プログラム」の確定までが早い。
要するに「天才肌」なのだ。
なので、もしもスーパープログラマーと遭遇しても「真似してやってみよう」などとは思わないことだ。
プログラミング上達のコツは、「自分のペースで地道にやる」のが一番の近道だからである。

3614468765

プロジェクト管理において、達成目標は3つある。
(1) 品質(Quality)
(2) コスト(Cost)※
(3) 納期(Delivery)
これらはその頭文字を取って、一般的に”QCD”と呼ばれる。
※コストについては、会社によって異なる呼び方(例:予算)をする場合もある。
上記3つの要素を厳守できれば、(個人的にはそう思わないが、少なくとも会社側からは)「プロジェクト成功」とみなされる。

しかし、現実はそんな簡単に達成できないのがプロジェクト管理の難しさである。
もしもプロジェクトが最大限努力したもののデスマーチ状態に陥り、上記3項目の達成が
困難であることが確定した場合、どの項目を優先すべきだろうか?
筆者の考える優先順位は以下の通りだ。
(高) 品質(Quality)
(中) 納期(Delivery)
(低) コスト(Cost)

以下にその根拠を述べる。

6014928531

(517) 284-6125

以前私が従事したプロジェクトにおいて、品質会計を採用していた。
品質会計とは、NECの開発現場で考案された品質管理手法であり、「品質会計」はNECの登録商標になっている。
概要を簡単に言うと以下のようなものである。
・ステップ数当たりのバグ件数を予想(想定)しておき、実際のステップ数とバグ抽出数(実績)との比較を行う。
・バグの傾向等により、更に対策が必要であるか、あるいは妥当であるかを判定する。
※予想(想定)のバグ件数は、過去のプロジェクト等から、ある一定精度の数値が前提となる。

この手法により品質を担保しようとする考え方である。
逆に言えば、想定バグ件数に対して、発見バグ件数が著しく乖離している場合、未知のバグが潜在している可能性があり、品質についても十分ではない可能性がある。
なお、対象となるのは、プログラムだけではなく、設計書も含む。
いわば、バグ傾向に基づいた品質の見える化である。

上に書いたように品質会計では、設計書とプログラムに対して、同様の手法を用いているが、
プログラム(コーディング)部分だけは、更に追加考慮すべきではないかと使用した際に思ったことがある。
それが「機能密度(機能数によるプログラム密度)」である。

では、何故「機能密度」が必要か?
その理由は、やや極端かもしれないが、以下のようなケースを想定してみよう。
・100ステップ当たりのバグ発生件数を1.5件とした場合(開発言語:Java)
(A) 800ステップ→想定バグ12件(上級プログラマーによるコーディング)
(B) 600ステップ→想定バグ9件(初級プログラマーによるコーディング)

上記の場合で、(A)の方が想定バグ件数より多く出たとしよう。
その場合、上級プログラマーがヘボなのかというと、単純にそうとは言い切れない。
それぞれのプログラムに対して、機能数を追加してみよう。
(A) 10機能、800ステップ→想定バグ12件、実績バグ24件(上級プログラマーによるコーディング)
(B) 3機能、600ステップ→想定バグ 9件、実績バグ 9件(初級プログラマーによるコーディング)
読者諸君から「いくら初級と上級でも機能数とステップ数でここまで差はつかねーよ」という声が聞こえてきそうだ。
だがしかし、データテーブルの使い方や、オブジェクト指向及びデザインパターン等を駆使するか否かでステップ数には圧倒的な差が出るのだ。(C言語や低級言語であれば、ここまで差はつかない)

よく見ると、(A)と(B)では、1機能当たりのステップ数が異なっている。
同じプロジェクト内であれば、ここまで差が付くことは無いかもしれないが、
プログラムというのは設計書と比較すると、成果物としての差が出易いのである。
機能密度を加味し、100ステップ当たりのバグ件数を計算すると、以下の通り(B)の方がバグ混入密度が高いことが分かる。
(A) (80ステップ/機能、実績バグ24件)→(24÷80)×100=30.0(上級プログラマーによるコーディング)
(B) (20ステップ/機能、実績バグ 9件)→( 9÷20)×100=45.0(初級プログラマーによるコーディング)

上記の例を鑑みて、プログラムに関する品質会計には、「機能数によるプログラム密度」も考慮した方が良いかと思う。

プログラミングを「製造」という呼び方について

開発工程において、プログラミングを”製造フェーズ”または”製造工程”と呼ぶことがある。
個人的には、プログラミングを「製造」と呼ぶことに違和感と不快感を覚える。
プログラミングは「無」から「有」を生み出す創造的なものであるはずだ。
それでは何と呼ぶべきか。私個人は基本的に「実装」と呼んでいる。
※基本的にと枕詞が付いているのは、プロジェクト内の工程名称として用語定義されている場合があり、
 渋々使わざるを得ないからである。

”製造”の本来の意味は「原料に手を加えて製品にすること」である。
しかしアプリケーション開発においては「設計書の通りに作る」という意味合いが
多分に含まれているように思える。
確かに仕様書(設計書)通りに作るという意味合いでは、合っていると言えないこともない。

しかしながら大抵の仕様書(設計書)には、「どのように実装するか?」は書かれておらず、
実装担当のプログラマーに委ねられる。
また、得てして仕様書(設計書)は変更される。
その仕様変更まで(ある程度)予見しながら、柔軟に対応できるように実装している。
ここまで考慮して作成したプログラムは本当に「製造」という言葉が相応しいだろうか?

ひょっとすると、私以外の技術者諸君は「製造」と「実装」という言葉に対して、
「そんなものは、単に言葉(呼び方)が違うだけで意味は同じだ!」
という人もいると思うが、たかが言葉されど言葉である。
技術者として試行錯誤したプログラムには、自信と誇りを持って「実装」または「コーディング」と呼んでもらいたいと私は切に願う。

SEの種類(職業SEと技術SE)

SE(プログラマー含む)は、大きく「職業SE」と「技術SE」の二つに分類できる。
但し、人によってどちら寄りかのバランスは異なる。
特に職業SEは、PCが普及した昨今、SE全体での比率として急増している。
昔(PC黎明期)にも居たとは思うが、希少な存在であったと推測する。
逆に言えば、SEという職業が市民権を得たということだろう。
さて、各SEの特徴は、私個人の経験を踏まえると、以下の通りである。

職業SE 観点 技術SE
この世に数多存在する職種から、SEを選択した。 職種の選択動機 コンピュータ好きが高じて、その延長としてSEという職種を選択した。
コンピュータに関する知識は乏しい。 初期の技術知識 コンピュータに関する知識は豊富。
(ソフトウェアからハードウェアまで)
目標に対して真っ直ぐ突き進む
(目的は仕事の完遂、技術はその手段)
仕事への取り組み 技術スキル習得を優先する。
(目的は技術の習得、仕事は技術実践の場)
社交的な人が比較的多い。
考え方が柔軟。
性 格 内向的な人が多い。
凝り性または完璧主義。
大企業IT系向き
(型にハマった仕事)
適合する作業環境 ベンチャーIT系向き
(型にハマらない、新規性の強いもの)
評価は高い。 仕事上の評価 評価は低い。
コード量は多いものの、作業時間は比較的短い。 生産性(コード量) コード量は少ないが、作業時間が掛かる。
他のメンバーを巻き込んで問題解決に当たる。 問題発生時の対応 自分で抱え込む傾向にある。
― 備 考 プライドが高い傾向にある。

この記事は、どちらかを肯定または否定するためのものではない。
例えるなら「絵」に似ているだろう。
職業SEは「漫画」であり、必要最低限の線で、短期間に多くの絵を描く必要がる。
一方の技術SEは「絵画」であり、1枚の絵に対して魂と技術をつぎ込み、自分自身を表現するのだ。
つまり「絵」の特性に応じて、最適な表現方法(描き方)は異なる。
そういう意味で、どちらのSEもそれぞれに正しい。
なお、私自身は「技術SE」に偏っていると自覚している。

707-530-6056

IT技術スキルに関して、熟練度を以下の7段階(レベル0~6)に定義する。
主としてプログラミングに関する理解度を対象とする。
また、レベル上位はレベル下位の基準を包括する。

レベル 俗称または別名 基準
0 赤ちゃん 知識の無い状態。技術そのものの存在を知らない。
1 頭でっかち 技術の存在を知っている。
概要は分かるが、実装は行えない。
2 初心者(入門者) サンプルコードやインターネットを用いて、簡単な実装が可能。
知識は都度インターネット検索、書籍に頼る。
3 門下生(修行者) 既存のコードを基にして、仕様通り(必要最低限)にコードが書ける。
知識は主要な命令またはコマンドに偏っている。
4 師範(指南役) 主要な命令を用いて、自力で1からコードが書ける。
また他人のコードから問題点を指摘できる。
その技術特有の知識を理解できる。
5 達人 技術の特性を理解した最適(※)な実装が可能。
※最適とは、実行速度の向上、コード量の軽減を表す。
知識は全ての命令を網羅しており、その技術に関する講演・執筆が可能。
6 神 技術の端々まで熟知している。
また、命令の機能拡張や創出、言語仕様の策定等、その技術の根幹に多大な影響を与える存在。