オブジェクト指向とコモンセンス
はぶにっき [Java]教えてとよろしくより
--
伝票はしゃべらないし飛ばないよ（ｗ 椅子は歩いたりしないよ。パッシブリソースとアクティブリソースの区分けをしないと、何でも生命持っちゃうから話がややこしくなるだけです。
--
ビール瓶とビールの例題で、ビール瓶クラスに「あといくらビールが入っているか問い合わせる機能」を追加しよう、なんてのは本で読んだ気がする。
このモノを主役としてしまう考え方は、オブジェクト指向ではわりと一般的のようだ。仮想的な部品が能動的に強調して動くということを考えると、エンジニア的になんとなくいい感じがする。
しかし、職場でチームでプログラムをしている時に果たして、顧客や上司やチームメンバに正しく気持ちが伝わっているか、と言われると甚だ疑問に思う。
プログラムというのものは、勝手にルールを決めてしまえば、何でもできてしまうため、ある程度現実世界に即した設計を心がけないと、いろんな人の概念が混ざってしまい、本質的に理解できないソフトウェアになりかねない。
その意味で、伝票は自分で計算するよりも、誰かに渡して計算してもらうような設計の方が万人にわかりやすい。少し冗長かもしれないが、顧客にも仕様を理解してもらいやすいほうが、後戻りも少なくなると考えられる。
これがゲームプログラムだったら、伝票が飛んだり、椅子が歩いたりしてもなんの問題もないわけだが。ソフトウェアの設計もTPOを考えないとだめだ、ということなのかもしれない。
--
伝票はしゃべらないし飛ばないよ（ｗ 椅子は歩いたりしないよ。パッシブリソースとアクティブリソースの区分けをしないと、何でも生命持っちゃうから話がややこしくなるだけです。
--
ビール瓶とビールの例題で、ビール瓶クラスに「あといくらビールが入っているか問い合わせる機能」を追加しよう、なんてのは本で読んだ気がする。
このモノを主役としてしまう考え方は、オブジェクト指向ではわりと一般的のようだ。仮想的な部品が能動的に強調して動くということを考えると、エンジニア的になんとなくいい感じがする。
しかし、職場でチームでプログラムをしている時に果たして、顧客や上司やチームメンバに正しく気持ちが伝わっているか、と言われると甚だ疑問に思う。
プログラムというのものは、勝手にルールを決めてしまえば、何でもできてしまうため、ある程度現実世界に即した設計を心がけないと、いろんな人の概念が混ざってしまい、本質的に理解できないソフトウェアになりかねない。
その意味で、伝票は自分で計算するよりも、誰かに渡して計算してもらうような設計の方が万人にわかりやすい。少し冗長かもしれないが、顧客にも仕様を理解してもらいやすいほうが、後戻りも少なくなると考えられる。
これがゲームプログラムだったら、伝票が飛んだり、椅子が歩いたりしてもなんの問題もないわけだが。ソフトウェアの設計もTPOを考えないとだめだ、ということなのかもしれない。
リバースデザイニング（Reverse Designing）
リバースエンジニアリングという言葉がある。ソフトウェアやハードウェアを分解して、中の仕組みを理解することである。
完成品から技術を盗むという意味もあるため、商品の説明書等にはリバースエンジニアリングは禁止と書かれていることも多い。しかし技術を学ぶためには避けて通れないし、ハードウェア業界では同業他社の製品を買ってきてはバラすのは日常茶飯事であると聞いている。
ソフトウェア業界では最近はオープンソース等のおかげで、プログラムの参考資料には事欠かなくなってきたが、問題はそれより上位の概念、いわゆるソフトウェアの仕様と言われるものについてである。
ソフトウェアはとにかく仕様が複雑になりがちである。適当な仕様からはプログラマまかせなソフトウェアが生成されるので、仕様はしっかりと作る必要がある。
しかし仕様をきっちり勉強する機会もなく、これが完全な仕様であるという仕様書というものも見たことがない。中途半端な仕様書と、完成後のプログラムから起こした自動生成ドキュメントというものばかりだ。
仕様書を書く技術というのは、実際に仕様書を書くことでしか見につかない。どうやれば仕様書を書く技術が身につくのか。やはり完成したソフトウェアから逆に仕様書を起こしてみるしか方法がないのではないか。それはリバースデザイニングとでも言うべきものかもしれない。
答えがあるものを使って練習するのは利に適っているといえるだろう。小規模なWEBサービスでも、仕様書にするとなるとなかなか骨が折れる。そもそもどこまでが仕様でどこからが設計なのか。画面仕様はどこまで決めるべきなのか。
それはどの部分を任せて、どの部分は制御したいのかによる。仕様書は答えが１つということはない。任せた部分については、任せたプログラマのセンスに期待することになる。一切を制御したい場合は仕様書なんてのは作らずに設計書を作るべきだろう。
そのあたりも考慮に入れて、仕様書を書く。書いた仕様書は実際に作らせてみる。出来上がったものと自分の思っていた製品イメージとの乖離が、仕様書の不備である。何回かフィードバックすると仕様書とはこうあるべきというパターンができあがるだろう。
プログラムを作るのは、知識と技術と慣れが必要だが、仕様書はソフトウェアの外側を見て書くものだ。誰でも出切るとは言わないが、少なくともソフトウェアを発注する側、仕様書を書く必要がある人は、書く訓練をしないとだめだ。
自分の描いているイメージをきちんと仕様として提示できるようになれば、ソフトウェア会社も最短で開発できる。お互いに最適な金額で仕事ができるようになるわけだ。これこそがWin-Winの関係なのではないだろうか。
完成品から技術を盗むという意味もあるため、商品の説明書等にはリバースエンジニアリングは禁止と書かれていることも多い。しかし技術を学ぶためには避けて通れないし、ハードウェア業界では同業他社の製品を買ってきてはバラすのは日常茶飯事であると聞いている。
ソフトウェア業界では最近はオープンソース等のおかげで、プログラムの参考資料には事欠かなくなってきたが、問題はそれより上位の概念、いわゆるソフトウェアの仕様と言われるものについてである。
ソフトウェアはとにかく仕様が複雑になりがちである。適当な仕様からはプログラマまかせなソフトウェアが生成されるので、仕様はしっかりと作る必要がある。
しかし仕様をきっちり勉強する機会もなく、これが完全な仕様であるという仕様書というものも見たことがない。中途半端な仕様書と、完成後のプログラムから起こした自動生成ドキュメントというものばかりだ。
仕様書を書く技術というのは、実際に仕様書を書くことでしか見につかない。どうやれば仕様書を書く技術が身につくのか。やはり完成したソフトウェアから逆に仕様書を起こしてみるしか方法がないのではないか。それはリバースデザイニングとでも言うべきものかもしれない。
答えがあるものを使って練習するのは利に適っているといえるだろう。小規模なWEBサービスでも、仕様書にするとなるとなかなか骨が折れる。そもそもどこまでが仕様でどこからが設計なのか。画面仕様はどこまで決めるべきなのか。
それはどの部分を任せて、どの部分は制御したいのかによる。仕様書は答えが１つということはない。任せた部分については、任せたプログラマのセンスに期待することになる。一切を制御したい場合は仕様書なんてのは作らずに設計書を作るべきだろう。
そのあたりも考慮に入れて、仕様書を書く。書いた仕様書は実際に作らせてみる。出来上がったものと自分の思っていた製品イメージとの乖離が、仕様書の不備である。何回かフィードバックすると仕様書とはこうあるべきというパターンができあがるだろう。
プログラムを作るのは、知識と技術と慣れが必要だが、仕様書はソフトウェアの外側を見て書くものだ。誰でも出切るとは言わないが、少なくともソフトウェアを発注する側、仕様書を書く必要がある人は、書く訓練をしないとだめだ。
自分の描いているイメージをきちんと仕様として提示できるようになれば、ソフトウェア会社も最短で開発できる。お互いに最適な金額で仕事ができるようになるわけだ。これこそがWin-Winの関係なのではないだろうか。
ソフトウェアでも触っていい部分と触ってはいけない部分はちゃんと管理しないと。
ソフトウェアは規模が大きくなると、当然のように多種多様な機能を持つようになる。多種多様な機能を持つからこそ大きくなるといえるかもしれない。
大企業になると基幹チーム、業務チームとかに分かれるらしいが、中小企業だとだいたい１プロジェクト１チームで開発を行うことになる。それでもソフトウェアの規模は結構な大きさになることもしばしばだ。
それなりの規模のソフトウェアは、全ての機能がお世話になる基幹部分と、それぞれの機能が個別に利用する部分とに大まかに分類できる。
問題は、期間部分も個別に利用する部分も、触ろうと思えば開発者の誰もが触れてしまうということだ。ここは大事だから修正する時は資格を持った人が必要とかそんなこともないことが多い。
我々が生きている社会に例えると、例えば家の中のブレーカーは勝手に上げたり下げたりするのに資格はいらないが、変電設備とかは触ろうと思ってもそう簡単に触れないような仕掛けになっているし、資格を持った人ではないと触れない。物理的にも社会的にも触れない仕組みが施されているわけだ。
ソフトウェアも、特にオブジェクト指向開発だと１つの部品をいろいろなところで利用しているケースが多いため、中途半端な変更は命取りになりかねない。そのために最近はテストファーストという概念も取り入れられ始めたが、まだまだ努力目標に過ぎない。テストはなくてもソフトウェアは動いてしまう。
作る上で、インターフェースだけ決めればいいということではなく、大事な部分は明確に分けた上で、触らせない工夫（ライブラリ化等）が必要だろう。あとは社内で資格制度でも作って、ライブラリを触れるのはシニアプログラマ以上とするとかやると、社内モチベーションがあがってよいかもしれない。
プログラマにもピンからキリまでいるので、開発内部でもフールプルーフ的な考え方を導入しておいた方が後戻りが少なそうだ。
大企業になると基幹チーム、業務チームとかに分かれるらしいが、中小企業だとだいたい１プロジェクト１チームで開発を行うことになる。それでもソフトウェアの規模は結構な大きさになることもしばしばだ。
それなりの規模のソフトウェアは、全ての機能がお世話になる基幹部分と、それぞれの機能が個別に利用する部分とに大まかに分類できる。
問題は、期間部分も個別に利用する部分も、触ろうと思えば開発者の誰もが触れてしまうということだ。ここは大事だから修正する時は資格を持った人が必要とかそんなこともないことが多い。
我々が生きている社会に例えると、例えば家の中のブレーカーは勝手に上げたり下げたりするのに資格はいらないが、変電設備とかは触ろうと思ってもそう簡単に触れないような仕掛けになっているし、資格を持った人ではないと触れない。物理的にも社会的にも触れない仕組みが施されているわけだ。
ソフトウェアも、特にオブジェクト指向開発だと１つの部品をいろいろなところで利用しているケースが多いため、中途半端な変更は命取りになりかねない。そのために最近はテストファーストという概念も取り入れられ始めたが、まだまだ努力目標に過ぎない。テストはなくてもソフトウェアは動いてしまう。
作る上で、インターフェースだけ決めればいいということではなく、大事な部分は明確に分けた上で、触らせない工夫（ライブラリ化等）が必要だろう。あとは社内で資格制度でも作って、ライブラリを触れるのはシニアプログラマ以上とするとかやると、社内モチベーションがあがってよいかもしれない。
プログラマにもピンからキリまでいるので、開発内部でもフールプルーフ的な考え方を導入しておいた方が後戻りが少なそうだ。
スケジュール駆動開発（Schedule-Driven Development）
ソフトウェア開発には、いろいろな開発モデルがあるわけだが、ウォーターフォール型、要するに最初に仕様を決めて開発→テストという流れの開発モデルの場合、基本的に納期が設定されているはずである。
一般的に納期というのは実際の仕様に依存するものではなく、予算と人材との兼ね合いで設定されることが多い。もしくは先に納期ありきで、金額は多少の融通が利く場合というのもある。
どちらにしても、何を作るかは大まかには決まっているが、詳細については後回しで、納期が先に決まるのである。この場合、納期から逆算されたスケジュールにソフトウェア開発プロジェクトの全てが依存する。
スケジュールに全てが依存するということは、何かを実現する際に「スケジュールに間に合うかどうか」が全てに優先される。ある意味、「スケジュール駆動開発（Schedule-Driven Development）」といえるだろう。
スケジュール駆動開発では、予定スケジュール内に予定工程が完了している必要がある。ということは、どれくらい時間がかかるか保障できないような計画は極力避けて、簡単で作業時間が計測可能で力技で量をこなせばなんとかなる計画の方が望ましい。
よって、スケジュール駆動開発をうまく行うには、時間がどのくらいかかるのかよくわからないことは入れてはいけない。プログラムが必要な部分についても、極力作る部分を減らして、ありものを探してきたり買ってきたりする方がよい。プログラムを作れば作るほど、スケジュール通りに終わる確率が下がっていく。
もっとも、一番時間がどのくらいかかるのかよくわからないのは、仕様を決める部分なのだが。仕様が計画時間より前に出てくることはあまり聞かないが、計画時間より遅れてでてくることもあまり聞かない。なぜか？
理由は簡単で、時間がないから後はお任せということになるのである。それなら時間かけずに最初からお任せにすればよさそうなものだし、任せた部分も後で文句を言うのだから始末に悪い。
仕様決定の工程は、できればソフトウェア開発スケジュールから独立させて、単体の仕様決定プロジェクトにした方がうまくいくだろう。その上でスケジュール駆動開発を行えば、スケジュール通りに物事が進むと思われる。
もっとも、プログラマにとってはたぶん面白くないプロジェクトになると思うが。
一般的に納期というのは実際の仕様に依存するものではなく、予算と人材との兼ね合いで設定されることが多い。もしくは先に納期ありきで、金額は多少の融通が利く場合というのもある。
どちらにしても、何を作るかは大まかには決まっているが、詳細については後回しで、納期が先に決まるのである。この場合、納期から逆算されたスケジュールにソフトウェア開発プロジェクトの全てが依存する。
スケジュールに全てが依存するということは、何かを実現する際に「スケジュールに間に合うかどうか」が全てに優先される。ある意味、「スケジュール駆動開発（Schedule-Driven Development）」といえるだろう。
スケジュール駆動開発では、予定スケジュール内に予定工程が完了している必要がある。ということは、どれくらい時間がかかるか保障できないような計画は極力避けて、簡単で作業時間が計測可能で力技で量をこなせばなんとかなる計画の方が望ましい。
よって、スケジュール駆動開発をうまく行うには、時間がどのくらいかかるのかよくわからないことは入れてはいけない。プログラムが必要な部分についても、極力作る部分を減らして、ありものを探してきたり買ってきたりする方がよい。プログラムを作れば作るほど、スケジュール通りに終わる確率が下がっていく。
もっとも、一番時間がどのくらいかかるのかよくわからないのは、仕様を決める部分なのだが。仕様が計画時間より前に出てくることはあまり聞かないが、計画時間より遅れてでてくることもあまり聞かない。なぜか？
理由は簡単で、時間がないから後はお任せということになるのである。それなら時間かけずに最初からお任せにすればよさそうなものだし、任せた部分も後で文句を言うのだから始末に悪い。
仕様決定の工程は、できればソフトウェア開発スケジュールから独立させて、単体の仕様決定プロジェクトにした方がうまくいくだろう。その上でスケジュール駆動開発を行えば、スケジュール通りに物事が進むと思われる。
もっとも、プログラマにとってはたぶん面白くないプロジェクトになると思うが。
プログラマが偉くならないとデスマーチは無くならない
少ない人数で徹夜続き、いわゆるデスマーチをもろにかぶるのは直接コードを書くプログラマである。仕様決定のスケジュールを延々引き伸ばした挙句、中途半端に決めて後は実装で対応、と言い残して去っていく上司はデスマーチには参加しない。
なぜプログラマは被害に遭いやすいのだろうか。会社に対して文句を言わずに指示通りに作ることをよしとしているからだろうか。立場的になぜか不利な立場に追い込まれているように見えるプログラマは結構多い。
しかし、プログラマは会社にべったり依存しているように見えるが、逆から見ると会社がプログラマに依存している。当然プログラマにはスキルが必要だが、あきらかに高度なスキルを持っているような人でも、デスマーチプロジェクトを淡々と（愚痴を言いながら）進めているケースもよくある。
プログラマはソフトウェア開発の要なので、デスマーチになりそう／なったからといって諦めてはいけない。上からの指示に言う通りに従うと赤字になったり体がおかしくなったりするということは、上からの指示が間違っているということである。
デスマーチ防止に役立つのは開発方法論ではなくて、組織力学である。上がダメならいくら下でがんばっても根本的な解決は難しい。ならば、どうするか。プログラマが偉くなるしかない。具体的には自分が組織の一段上にあがるのである。
上に立ちたくない、と思うプログラマは多いと思うが、少なくともデスマーチで体を壊すよりはましだと思う。デスマーチになるかどうかはプログラマが一番よくわかっているはずだ。ぜひ、偉くなって世の中からデスマーチを撲滅して頂きたい。
なぜプログラマは被害に遭いやすいのだろうか。会社に対して文句を言わずに指示通りに作ることをよしとしているからだろうか。立場的になぜか不利な立場に追い込まれているように見えるプログラマは結構多い。
しかし、プログラマは会社にべったり依存しているように見えるが、逆から見ると会社がプログラマに依存している。当然プログラマにはスキルが必要だが、あきらかに高度なスキルを持っているような人でも、デスマーチプロジェクトを淡々と（愚痴を言いながら）進めているケースもよくある。
プログラマはソフトウェア開発の要なので、デスマーチになりそう／なったからといって諦めてはいけない。上からの指示に言う通りに従うと赤字になったり体がおかしくなったりするということは、上からの指示が間違っているということである。
デスマーチ防止に役立つのは開発方法論ではなくて、組織力学である。上がダメならいくら下でがんばっても根本的な解決は難しい。ならば、どうするか。プログラマが偉くなるしかない。具体的には自分が組織の一段上にあがるのである。
上に立ちたくない、と思うプログラマは多いと思うが、少なくともデスマーチで体を壊すよりはましだと思う。デスマーチになるかどうかはプログラマが一番よくわかっているはずだ。ぜひ、偉くなって世の中からデスマーチを撲滅して頂きたい。
ドキュメントは冗長でないとわかりにくい
プログラマにはドキュメントを書くのが下手というか苦手な人が多い。苦手というのはちゃんと書いたつもりなのに、理解してもらえないということだ。
単純にドキュメントを書くには違うスキルが必要だから、と言ってしまえばそれまでだが、いったい何が違うのだろうか。
ちょっと考えてみると、プログラマはプログラミングが本業である。プログラミングは、なるべく冗長な部分を減らすような思考になる。そしてドキュメントをその考え方のままで書くと、冗長性の少ない、（プログラマにとって）素敵なドキュメントが出来上がる。
冗長性の少ないドキュメントは、関連性が最小限に押さえられていて、リファレンスとしては過不足ないにしても、読む側は取っ掛かりがなくて非常に辛い。
ある部分は冗長に記すことで読む人の記憶に焼き付けさせ、必要ない部分は思い切って省略することで読む人の注意を分散させないという強弱加減も、ドキュメント記述の上では大事な要素だ。
どこを重要とするか。どこを切り捨てるか。このあたりの取捨選択っぷりがドキュメントのよしあしを決めるのではないか。
プログラマが重要と思っている部分は、わりと技術寄りで高度で難しいけれど、本当にソフトウェアのことを知りたいと思っている人にとっては、どうでもいい部分である場合が結構ある。
なので、プログラマがドキュメントを書かないといけなくなったら、何が重要と思うか、プログラムを作っていない人に聞いてから書き始めるのがよいのではないかと思う。プロダクト作成には事前ヒアリングが大事ということだ。
単純にドキュメントを書くには違うスキルが必要だから、と言ってしまえばそれまでだが、いったい何が違うのだろうか。
ちょっと考えてみると、プログラマはプログラミングが本業である。プログラミングは、なるべく冗長な部分を減らすような思考になる。そしてドキュメントをその考え方のままで書くと、冗長性の少ない、（プログラマにとって）素敵なドキュメントが出来上がる。
冗長性の少ないドキュメントは、関連性が最小限に押さえられていて、リファレンスとしては過不足ないにしても、読む側は取っ掛かりがなくて非常に辛い。
ある部分は冗長に記すことで読む人の記憶に焼き付けさせ、必要ない部分は思い切って省略することで読む人の注意を分散させないという強弱加減も、ドキュメント記述の上では大事な要素だ。
どこを重要とするか。どこを切り捨てるか。このあたりの取捨選択っぷりがドキュメントのよしあしを決めるのではないか。
プログラマが重要と思っている部分は、わりと技術寄りで高度で難しいけれど、本当にソフトウェアのことを知りたいと思っている人にとっては、どうでもいい部分である場合が結構ある。
なので、プログラマがドキュメントを書かないといけなくなったら、何が重要と思うか、プログラムを作っていない人に聞いてから書き始めるのがよいのではないかと思う。プロダクト作成には事前ヒアリングが大事ということだ。
ソフトウェア開発の管理者がしなければいけない１番大事な仕事
ソフトウェア開発の管理者（マネージャ）は、小さい企業だとリーダが兼ねていることもあるが、ここでは開発仕様に対して権限を持っている人のことを指す。
ソフトウェア開発で利益を確保するために、管理者がしないといけない１番大事な仕事は、仕様管理である。チームのモチベーション維持も大事だが、そもそも何を作るかが変動しやすいソフトウェア開発においては、仕様管理を誤るとどうがんばっても利益が出なくなる。
仕様管理とは、突き詰めるとチーム内の作業量管理のことである。なので顧客からの仕様の追加変更要求に対しては、受け入れられるものと受け入れられないものをはっきりさせないといけない。ここが曖昧では管理者失格である。
顧客の要求はできるだけ受け入れるべきだ。なぜなら受け入れられない仕様に対しては、ある程度こちらの意見を聞き入れてもらいやすくなると考えられるからだ。そのためにも変更されがちな部分については、変更コストを減らす工夫が必要だ。
ソフトウェア開発の管理者の仕事は、上記のような折衝や工夫を行い、プロジェクトの利益を増やすことだと思う。何もしないだけだとまだましだが、勝手に自分の仕様を押し通すような管理者は要注意だ。
いい管理者の下にいい開発者が集まる、という好循環が作れるようになるとデスマーチプロジェクトも減ると思うのだが・・。開発者の教育も大事だが、管理者の教育も今のままではかなりまずい。
ソフトウェア開発で利益を確保するために、管理者がしないといけない１番大事な仕事は、仕様管理である。チームのモチベーション維持も大事だが、そもそも何を作るかが変動しやすいソフトウェア開発においては、仕様管理を誤るとどうがんばっても利益が出なくなる。
仕様管理とは、突き詰めるとチーム内の作業量管理のことである。なので顧客からの仕様の追加変更要求に対しては、受け入れられるものと受け入れられないものをはっきりさせないといけない。ここが曖昧では管理者失格である。
顧客の要求はできるだけ受け入れるべきだ。なぜなら受け入れられない仕様に対しては、ある程度こちらの意見を聞き入れてもらいやすくなると考えられるからだ。そのためにも変更されがちな部分については、変更コストを減らす工夫が必要だ。
ソフトウェア開発の管理者の仕事は、上記のような折衝や工夫を行い、プロジェクトの利益を増やすことだと思う。何もしないだけだとまだましだが、勝手に自分の仕様を押し通すような管理者は要注意だ。
いい管理者の下にいい開発者が集まる、という好循環が作れるようになるとデスマーチプロジェクトも減ると思うのだが・・。開発者の教育も大事だが、管理者の教育も今のままではかなりまずい。
プログラマには高速道路の先に何が見えるのか
インターネットの普及がもたらした学習の高速道路と大渋滞より
IT業界もすでに高速道路が整備されていて、その先に大渋滞が待っているというような書き方になっているように読めるが、高速道路はともかくその先の大渋滞なんて起こりようがない。プログラマは将棋棋士と違い、トップが１人という勝負の世界ではないからだ。
問題はその先だ。IT技術は一度押さえてしまうとそれで一生食えるというものではない。ハードウェアの進歩やコモディティ化、パラダイムシフトと共に、新しい技術が突然出てくる。こちら側に高速道路が整備されましたからどうぞという状態である。
がんばって高速道路を抜けて先にいたはずなのに、いつの間にか別の高速道路が出来ていて、後ろにいたはずの人達が先に駆け抜けていく。汎用機がパソコンになり、パソコンが携帯になり、まさにイノベーションのジレンマである。
そうなると、高速道路が整備されたとしても燃費の悪い車では大変だ。やっとのことで高速道路を抜けた人には、次の高速道路は進めない。燃費をよくするためにはどうすればいいのか。そもそも走りつづけないとだめなのか？
全員が技術を追いかけないといけないわけではない。必要な技術が手に入ったら後は別の軸でビジネスを興してしまうのがよいとも言える。走りつづけるにはやはり才能が必要なのだと思う。燃費のよさと走るスピードと高速道路の入り口を見つける能力はどれも才能だろう。
才能というのはあるから偉い、ないから偉くないというものではない。自分にどういう能力があるのか、何が得意なのかというのを早くから見極めることができれば、その後が楽だ。やりたくないことを無理してやらなくていいからだ。
その意味でプログラマに向いている人は高速道路に載って、早く次のステージに進んだ方がいい。そうではない人はさっさと諦めるのもまた１つの才能だと思う。
IT業界もすでに高速道路が整備されていて、その先に大渋滞が待っているというような書き方になっているように読めるが、高速道路はともかくその先の大渋滞なんて起こりようがない。プログラマは将棋棋士と違い、トップが１人という勝負の世界ではないからだ。
問題はその先だ。IT技術は一度押さえてしまうとそれで一生食えるというものではない。ハードウェアの進歩やコモディティ化、パラダイムシフトと共に、新しい技術が突然出てくる。こちら側に高速道路が整備されましたからどうぞという状態である。
がんばって高速道路を抜けて先にいたはずなのに、いつの間にか別の高速道路が出来ていて、後ろにいたはずの人達が先に駆け抜けていく。汎用機がパソコンになり、パソコンが携帯になり、まさにイノベーションのジレンマである。
そうなると、高速道路が整備されたとしても燃費の悪い車では大変だ。やっとのことで高速道路を抜けた人には、次の高速道路は進めない。燃費をよくするためにはどうすればいいのか。そもそも走りつづけないとだめなのか？
全員が技術を追いかけないといけないわけではない。必要な技術が手に入ったら後は別の軸でビジネスを興してしまうのがよいとも言える。走りつづけるにはやはり才能が必要なのだと思う。燃費のよさと走るスピードと高速道路の入り口を見つける能力はどれも才能だろう。
才能というのはあるから偉い、ないから偉くないというものではない。自分にどういう能力があるのか、何が得意なのかというのを早くから見極めることができれば、その後が楽だ。やりたくないことを無理してやらなくていいからだ。
その意味でプログラマに向いている人は高速道路に載って、早く次のステージに進んだ方がいい。そうではない人はさっさと諦めるのもまた１つの才能だと思う。
仕様の決まり方
ソフトウェア開発において、仕様は決めるものではなくて決まるものである。自分で勝手に決めてそれを仕様と言い張っても、誰かの一声でなかったことにされてしまう。
あまり日本だからという言い方は好きでは無いし、他の国の仕様の決めっぷりを見たことがないので比較しようがないが、特に非IT業界の顧客側の責任者に対しては、仕様の確定を求めてもあまり意味がないし、強硬な態度に出ても険悪な雰囲気になるだけで、あまり得にならない。
仕様が決まらないから先に進まないという愚痴は、言い訳にしか聞こえない。顧客も趣味に金を注ぎ込んでいるわけではないので、その仕様が決まらないと一歩も先に進まないなら、その重要度をきっちり資料やわかりやすい説明を用いて、全力で顧客を説得するのがこちら側の役割である。
それでも決まらないならたぶん顧客に興味のない部分かよくわからない部分なので、一番簡単なものを選択すればよいのである。最初は自分で決めるわけだが、顧客に「この方法でやります」と伝えるとそこで仕様が決まることになる。
決めたことは覆されるが、決まったことは覆されない。たまには覆されるかもしれないが、決まったことを変えるのはそれなりに代替手段が用意されるか、それなりの交渉の余地が生まれる。
要するに、ソフトウェア開発において土台となる仕様（変更されると根本的にまずい部分）についてはさっさと顧客との打ち合わせの場で決まりごとにしてしまう。変更したところでどうってことないところは、勝手に決めて進めておく。
顧客とコミュニケーションを取りつつ、どうやって開発を効率よく進めるか、というのは、この仕様の決めっぷりと決まりっぷりにかかっているといっても過言では無いだろう。
あまり日本だからという言い方は好きでは無いし、他の国の仕様の決めっぷりを見たことがないので比較しようがないが、特に非IT業界の顧客側の責任者に対しては、仕様の確定を求めてもあまり意味がないし、強硬な態度に出ても険悪な雰囲気になるだけで、あまり得にならない。
仕様が決まらないから先に進まないという愚痴は、言い訳にしか聞こえない。顧客も趣味に金を注ぎ込んでいるわけではないので、その仕様が決まらないと一歩も先に進まないなら、その重要度をきっちり資料やわかりやすい説明を用いて、全力で顧客を説得するのがこちら側の役割である。
それでも決まらないならたぶん顧客に興味のない部分かよくわからない部分なので、一番簡単なものを選択すればよいのである。最初は自分で決めるわけだが、顧客に「この方法でやります」と伝えるとそこで仕様が決まることになる。
決めたことは覆されるが、決まったことは覆されない。たまには覆されるかもしれないが、決まったことを変えるのはそれなりに代替手段が用意されるか、それなりの交渉の余地が生まれる。
要するに、ソフトウェア開発において土台となる仕様（変更されると根本的にまずい部分）についてはさっさと顧客との打ち合わせの場で決まりごとにしてしまう。変更したところでどうってことないところは、勝手に決めて進めておく。
顧客とコミュニケーションを取りつつ、どうやって開発を効率よく進めるか、というのは、この仕様の決めっぷりと決まりっぷりにかかっているといっても過言では無いだろう。
ソフトウェア業界で人が足りないという意味
ソフトウェア開発会社でそれなりに仕事をしているところは、すぐに人手が足りなくなる。そして求人しようにも求める人材のレベルが高すぎて、なかなか希望通りの人に出会わない。
そして、「人さえいればもっと儲かるのになぁ」と言いつつ日々を過ごしているのだ。聞くとあたりまえのようだが、市場にいない人を求めて彷徨うのは何かずれている気がする。
人が足りなくなるのは、仕事の依頼がある毎に人を割り当てるからに他ならない。毎回別々に人を割り当てないといけないのは、何を作るのかから考える必要があるからである。フルタイムでずーっとその仕事について考える人がいないと、必ずと言っていいほど間に合わないので人を張り付けざるをえない。
どの会社も似たような依頼はほとんど来ない。毎回違う業態、違う会社、違う内容の仕事を「IT」という名のもとに受け入れてしまう。仕事内容が違えば、作り方も、チェックすべきポイントも、精度も異なる。それらが異なるということは、仕事の進め方も当然異なる。
ここまで来ると、問題点はやはり仕事の受け方にあると言える。人さえいれば儲かるということは、会社のビジネスモデルは人と仕事を探してマッチングするということになる。ソフトウェア開発会社と呼ばれている会社のほとんどはこのビジネスモデルを採用しているのかもしれない。
開発に特化した会社というのは、仕事と会社をマッチングするビジネスモデルの会社と相互依存の関係にあるということになる。このビジネスモデルは階層構造になっている。
シンプルな構造は、
（依頼主[仕事]→受託会社）
という関係である。依頼主から仕事を請け負う会社が存在するという図式だ。
これが受託会社がマッチングビジネスモデルの会社の場合は、
（依頼主[仕事]→（受託会社[仕事]→孫受会社））
となる。
これをどんどん深くすると、
（依頼主[仕事]→（受託会社[仕事]→（孫受会社[仕事]→（曾孫受会社[仕事]→個人））））
となることがよくある。
この１番右の個人さえいれば、中の３社は仕事をしたことになる。これが「人さえいれば」という言葉になって現れるわけだ。
ここまで書いて、ようやく「人さえいればもっと儲かる」の違和感がすっきりした。ソフトウェア開発会社と思っていたので違和感があっただけで、マッチング（仲介）を本業とすると考えると、人さえ探し出せれば儲かる、というのは会社の本業をやればちゃんと儲かると言っているわけで、当たり前の話ということになる。
そういう会社は「人がいない」と嘆くのではなくて、日々人を探しつづけるのが仕事である。愚痴をこぼしてないで仕事しましょう。
そして、「人さえいればもっと儲かるのになぁ」と言いつつ日々を過ごしているのだ。聞くとあたりまえのようだが、市場にいない人を求めて彷徨うのは何かずれている気がする。
人が足りなくなるのは、仕事の依頼がある毎に人を割り当てるからに他ならない。毎回別々に人を割り当てないといけないのは、何を作るのかから考える必要があるからである。フルタイムでずーっとその仕事について考える人がいないと、必ずと言っていいほど間に合わないので人を張り付けざるをえない。
どの会社も似たような依頼はほとんど来ない。毎回違う業態、違う会社、違う内容の仕事を「IT」という名のもとに受け入れてしまう。仕事内容が違えば、作り方も、チェックすべきポイントも、精度も異なる。それらが異なるということは、仕事の進め方も当然異なる。
ここまで来ると、問題点はやはり仕事の受け方にあると言える。人さえいれば儲かるということは、会社のビジネスモデルは人と仕事を探してマッチングするということになる。ソフトウェア開発会社と呼ばれている会社のほとんどはこのビジネスモデルを採用しているのかもしれない。
開発に特化した会社というのは、仕事と会社をマッチングするビジネスモデルの会社と相互依存の関係にあるということになる。このビジネスモデルは階層構造になっている。
シンプルな構造は、
（依頼主[仕事]→受託会社）
という関係である。依頼主から仕事を請け負う会社が存在するという図式だ。
これが受託会社がマッチングビジネスモデルの会社の場合は、
（依頼主[仕事]→（受託会社[仕事]→孫受会社））
となる。
これをどんどん深くすると、
（依頼主[仕事]→（受託会社[仕事]→（孫受会社[仕事]→（曾孫受会社[仕事]→個人））））
となることがよくある。
この１番右の個人さえいれば、中の３社は仕事をしたことになる。これが「人さえいれば」という言葉になって現れるわけだ。
ここまで書いて、ようやく「人さえいればもっと儲かる」の違和感がすっきりした。ソフトウェア開発会社と思っていたので違和感があっただけで、マッチング（仲介）を本業とすると考えると、人さえ探し出せれば儲かる、というのは会社の本業をやればちゃんと儲かると言っているわけで、当たり前の話ということになる。
そういう会社は「人がいない」と嘆くのではなくて、日々人を探しつづけるのが仕事である。愚痴をこぼしてないで仕事しましょう。