受託開発は客から見ると投資である
IT Pro 不透明なソフト開発の価格，解決への第一歩は“相場”を示すこと
から
--
では，こうした数値が実際にソフトの適正価格を判断する指標になり得るのかを，少し考えたい。データの分析結果で明らかにされるのは，ソフトの規模に対する平均工数，平均不具合数，平均納期などである。調査が十分なサンプル数を集めれられば，ある程度の指標になると思う。
--
引用のような方法で適正価格が得られるかどうかは、正直ばらつきが大きすぎるし、顧客側が開発工程のどの期間に仕様を確定したのかとか最後にちゃぶ台返しをしたのかとかで、工数や期間は著しく変わってくるため、無意味なように思う。
後からソフトウェアを見て、これならいくらですね、と言うのはそれほど難しくない。仕様が決まっているソフトウェアならわりと正確な見積が出せるだろう。それで見積が出るから、他の同程度の規模（規模の軸も不明だが）のソフトウェアが似たような金額で納品できるかというと、そんなことはない。
なぜうまくいかないのかというと、仕様（契約）を満たしているかどうかの判定に、顧客の主観が大きなウェイトを占めているということがあげられる。顧客が完成したソフトウェアを見てから駄目出しをしているようでは、コストがいくらあっても足りない。
仕様の煮詰めが甘いだけといわれるかもしれないが、顧客もうまく説明できないようなものを作る際に、見ないとイメージできないという場合も多々ある。モックやプロトタイプを作りながらイメージを固めて、こつこつソフトウェアを構築していく場合の見積は、後からソフトウェアを見ても当然わからない。
よって、ソフトウェアの値段の相場という概念がそもそも間違いであるように思う。会社にとってソフトウェアを利用することで、経費が削減される／より儲けることができるという場合に、投資としてソフトウェアを発注するのであって、その際に投資金額も費用対効果で決めるわけである。先に予算ありきであり、ソフトウェアありきではない。
当然、その予算にはどのようなソフトウェアを作るべきかという企画段階からの予算も含まれる。ソフトウェア単体の値段の相場を出すことに何か意味はあるのだろうか。
他社が導入したからうちも、そしてそのソフトウェアはいくらなのかというような考え方では、SIベンダーにいいようにされるだけなので、辞めておいた方がよいだろう。相場を決めて得をするのは当然SIベンダーなのだから。
から
--
では，こうした数値が実際にソフトの適正価格を判断する指標になり得るのかを，少し考えたい。データの分析結果で明らかにされるのは，ソフトの規模に対する平均工数，平均不具合数，平均納期などである。調査が十分なサンプル数を集めれられば，ある程度の指標になると思う。
--
引用のような方法で適正価格が得られるかどうかは、正直ばらつきが大きすぎるし、顧客側が開発工程のどの期間に仕様を確定したのかとか最後にちゃぶ台返しをしたのかとかで、工数や期間は著しく変わってくるため、無意味なように思う。
後からソフトウェアを見て、これならいくらですね、と言うのはそれほど難しくない。仕様が決まっているソフトウェアならわりと正確な見積が出せるだろう。それで見積が出るから、他の同程度の規模（規模の軸も不明だが）のソフトウェアが似たような金額で納品できるかというと、そんなことはない。
なぜうまくいかないのかというと、仕様（契約）を満たしているかどうかの判定に、顧客の主観が大きなウェイトを占めているということがあげられる。顧客が完成したソフトウェアを見てから駄目出しをしているようでは、コストがいくらあっても足りない。
仕様の煮詰めが甘いだけといわれるかもしれないが、顧客もうまく説明できないようなものを作る際に、見ないとイメージできないという場合も多々ある。モックやプロトタイプを作りながらイメージを固めて、こつこつソフトウェアを構築していく場合の見積は、後からソフトウェアを見ても当然わからない。
よって、ソフトウェアの値段の相場という概念がそもそも間違いであるように思う。会社にとってソフトウェアを利用することで、経費が削減される／より儲けることができるという場合に、投資としてソフトウェアを発注するのであって、その際に投資金額も費用対効果で決めるわけである。先に予算ありきであり、ソフトウェアありきではない。
当然、その予算にはどのようなソフトウェアを作るべきかという企画段階からの予算も含まれる。ソフトウェア単体の値段の相場を出すことに何か意味はあるのだろうか。
他社が導入したからうちも、そしてそのソフトウェアはいくらなのかというような考え方では、SIベンダーにいいようにされるだけなので、辞めておいた方がよいだろう。相場を決めて得をするのは当然SIベンダーなのだから。
弛緩と集中
著者： 山本 真司
タイトル： 30歳からの成長戦略 「ほんとうの仕事術」を学ぼうより
--
ある先輩が語ってくれたことがある。その先輩は二十代に弛緩→集中の習慣をつけたという。その先輩は大学卒業後、外資系の大手銀行に就職した。その銀行では、夏休みは三週間と決められていた。日本人の先輩は、そんな非常識な長さの夏休みは取れないと上司に申し出たらしい。その上司（外人）が答えた。「我が社では休みを三週間取らないと首である」と。先輩は驚いて聞いた。「なぜですか？」と。その答えがふるっている。「休みの最初の一週間は疲れを取るだけで終わる。二週間目に英気が養われる。三週間目に仕事をしたくなる。そこまで休んではじめて、凄まじい集中力で仕事できるようになるもんだ。」と。
--
情報産業は８時間毎日こつこつ働けばいいというものではない、と頭でわかっていたが、こうストレートに表現する上司には当然ながら出会ったことがない。
集中力が大事だ大事だ大事だと、念仏のように皆語っているが、逆に弛緩（休息）について語る人はほとんど見かけない。なぜだろうか。弛緩＝さぼりという認識がまだまだ根強いからだろうか。
脳を酷使するということについて、経験がないということなのかもしれない。改善しないといけないのはまず労働基準法だろうと思うが。
（参考）
--
労働基準法 第4章 第34条
使用者は、労働時間が6時間を超える場合においては少くとも45分、8時間を超える場合においては少くとも1時間の休憩時間を労働時間の途中に与えなければならない。
--
本当にソフトウェアに対して責任を持たせるのであれば、昼寝しようが何しようがどうでもいいように思うが、契約社員や派遣社員は時間による契約がほとんどであり、正社員もそれに引きずられてしまうのである。
いい加減に、時間による契約はやめるべきだと思うのだが、わかりやすい指標がないという理由からかなくなる気配すら感じない。弛緩ということを考慮すると、とても時間契約なんてできそうにない。
効率を上げるという目標を掲げるのであれば、集中させるための弛緩についても気を配るべきであろう。今年のキーワードは、弛緩と集中でどうだろうか。まずは昼寝からである。昼ご飯食べた後は眠いので、寝るところから開始しよう。
映画とプログラミング
あけましておめでとうございます。
今年もよろしくお願い致します。
---------
くろねこ亭－ハウルの動く城のページより
ハウルの動く城についてのインタビュー中の宮崎監督のコメント。
宮：スタッフと討議して映画を作るのは不可能です。僕は「こういうふうにします」としかできません。
この言葉を見て、まだ世の中にないものを作るという行為は、討議とか会議とかで決めるものではないのだと実感した。
見えないものをどうにかして形にする、このどうにかする部分は積み上げではなかなか作り出せない。個人の発想や直感に頼る部分が多い、俗人的な部分であるが、俗人性を排除してしまっては、世の中にまだない新しいものを作り上げることはできないと思う。
システム設計も、コアとなる部分はやはり何人かで決めるというよりは、１人がきちっと決めた方が上手くいくことが多い。逆に言うとある程度設計できるような人が１人以上いないようなプロジェクトは初めから危なそうということでもあるが。
オープンソースなプロジェクトでも、企業内の開発プロジェクトでもそうだと思うが、最初からチームでどのように作るかを話合うということをやってもうまくいかないのである。
ベースなりフレームワークなりがある場合はまた違うだろうが、何もないところから全員であぁだこうだいうよりは、まずは個人を走らせてみるのが大事ではないだろうか。
余裕があれば、２～３人をそれぞれ別々に走らせて、プロトタイプ開発をさせてもいいかもしれない。無駄と思われるかもしれないが、同じ仕様で違った生成物を見て、違うアイディアからお互いに触発されるだろう。
チーム開発は、個人のアイディアを平均化させすぎてしまう傾向にあるように思うので、もう少し俗人性をいい方向に発揮させてみることも考えてもいいのではないだろうか。
もっとも、評価する人間が価値を評価できなければまったく意味がないのだが。
今年もよろしくお願い致します。
---------
くろねこ亭－ハウルの動く城のページより
ハウルの動く城についてのインタビュー中の宮崎監督のコメント。
宮：スタッフと討議して映画を作るのは不可能です。僕は「こういうふうにします」としかできません。
この言葉を見て、まだ世の中にないものを作るという行為は、討議とか会議とかで決めるものではないのだと実感した。
見えないものをどうにかして形にする、このどうにかする部分は積み上げではなかなか作り出せない。個人の発想や直感に頼る部分が多い、俗人的な部分であるが、俗人性を排除してしまっては、世の中にまだない新しいものを作り上げることはできないと思う。
システム設計も、コアとなる部分はやはり何人かで決めるというよりは、１人がきちっと決めた方が上手くいくことが多い。逆に言うとある程度設計できるような人が１人以上いないようなプロジェクトは初めから危なそうということでもあるが。
オープンソースなプロジェクトでも、企業内の開発プロジェクトでもそうだと思うが、最初からチームでどのように作るかを話合うということをやってもうまくいかないのである。
ベースなりフレームワークなりがある場合はまた違うだろうが、何もないところから全員であぁだこうだいうよりは、まずは個人を走らせてみるのが大事ではないだろうか。
余裕があれば、２～３人をそれぞれ別々に走らせて、プロトタイプ開発をさせてもいいかもしれない。無駄と思われるかもしれないが、同じ仕様で違った生成物を見て、違うアイディアからお互いに触発されるだろう。
チーム開発は、個人のアイディアを平均化させすぎてしまう傾向にあるように思うので、もう少し俗人性をいい方向に発揮させてみることも考えてもいいのではないだろうか。
もっとも、評価する人間が価値を評価できなければまったく意味がないのだが。
IF文を極力減らすと見晴らしのいいプログラムになる
プログラムの中は分岐の塊である。入り口が１つしかないのに、いろいろなことをさせようとするため、当然のように枝分かれしていく。
ところがこの枝分かれというのがプログラマ泣かせで、たまにしか通らない部分があったりすると、そこにバグがあった場合に発見が遅れたり、バグが出ても再現しずらかったりする。
なので、ツールを利用して、自動的に全分岐を辿って、バグを発見したり、絶対到達しない分岐を発見したり、ということも場合によっては可能なのだが、どこでも利用できるわけではないし、やはり複雑な分岐になるとバグの温床になりやすい。
そもそも、分岐をいっぱい作っておいて、ツールを使って全部チェックするという考え方は穴掘って埋めるという感じでなんとなく無駄が多い。もう少しいい方法はないだろうか。
１つに、分岐を出来るだけ入り口に近い側に持っていって、後は一本道にするという方法である。フォークタイプというか、付け根のところで分かれた後は、最後まで他と交わらずに処理を行う方法をとることで、分岐処理は分岐処理として集中できるため、プログラムの管理も行いやすい。
もう１つ、デザインパターンのTemplate Methodパターンや、Strategyパターン等、振る舞いを切り替える仕組みと、最近話題のDependency Injection パターンを組み合わせることで、ある入力に対して使用するクラスが一意に決まるような作りにすることが可能だ。
どちらの場合にも、複雑に絡み合わないような設計にすることによって、テストの組み合わせが減るので工数削減につながる。流れが決まるということは、ドキュメントが書きやすいということでもある。
プログラムの流れをシンプルにすることで、保守性も拡張性も高めることができるだろう。IF文だけではなくて、クラスの継承も複雑さを生む原因になっているので、継承も出来るだけ排除して、よりシンプルな設計にするのが後々のためにもよいのではないだろうか。
ところがこの枝分かれというのがプログラマ泣かせで、たまにしか通らない部分があったりすると、そこにバグがあった場合に発見が遅れたり、バグが出ても再現しずらかったりする。
なので、ツールを利用して、自動的に全分岐を辿って、バグを発見したり、絶対到達しない分岐を発見したり、ということも場合によっては可能なのだが、どこでも利用できるわけではないし、やはり複雑な分岐になるとバグの温床になりやすい。
そもそも、分岐をいっぱい作っておいて、ツールを使って全部チェックするという考え方は穴掘って埋めるという感じでなんとなく無駄が多い。もう少しいい方法はないだろうか。
１つに、分岐を出来るだけ入り口に近い側に持っていって、後は一本道にするという方法である。フォークタイプというか、付け根のところで分かれた後は、最後まで他と交わらずに処理を行う方法をとることで、分岐処理は分岐処理として集中できるため、プログラムの管理も行いやすい。
もう１つ、デザインパターンのTemplate Methodパターンや、Strategyパターン等、振る舞いを切り替える仕組みと、最近話題のDependency Injection パターンを組み合わせることで、ある入力に対して使用するクラスが一意に決まるような作りにすることが可能だ。
どちらの場合にも、複雑に絡み合わないような設計にすることによって、テストの組み合わせが減るので工数削減につながる。流れが決まるということは、ドキュメントが書きやすいということでもある。
プログラムの流れをシンプルにすることで、保守性も拡張性も高めることができるだろう。IF文だけではなくて、クラスの継承も複雑さを生む原因になっているので、継承も出来るだけ排除して、よりシンプルな設計にするのが後々のためにもよいのではないだろうか。
他人のルールで仕事をすると面白くない
プログラマは依頼（要求）に従って動く事が多いため、何かと受身になりがちである。何が来ても大丈夫なようにスキルを身に付ける、という発想はいいのだが、ある意味他力本願というか、仕事は他人任せとなってしまう。
毎回他人のルールで仕事をしていると、無駄なことも苦手なことも許容する羽目になる。無理な仕事で燃え尽きたり、犯罪の片棒を担がされたりすることもあるかもしれない。
似たような仕事は２度こないというのは、ソフトウェア開発の現場においてはよくある話だが、宣伝もしてないのに別の人から似たような仕事を頼まれる方がおかしい。
自分の得意分野の仕事ができるようにするためには、社内社外を問わず営業してまわるか、誰かに頼んで営業してもらうしかない。こういう仕事なら他社よりアドバンテージがあるので、安く早くできますというのは自分の売りになる。
自分を売り込むというよりは、自分を知ってもらうということが大事だ。誇大広告をする必要はないが、必要以上に謙遜していてはいつまでたっても本当の能力が伝わらない。
結局のところ、プログラマは得意分野を生かそうと思ったら、コミュニケーションスキルが必須ということだ。ちゃんと仕事をするということより前に、どうやって得意分野を生かせるような仕事を取るか、を考えて実行したほうが、よりいい仕事ができるのではないだろうか。
毎回他人のルールで仕事をしていると、無駄なことも苦手なことも許容する羽目になる。無理な仕事で燃え尽きたり、犯罪の片棒を担がされたりすることもあるかもしれない。
似たような仕事は２度こないというのは、ソフトウェア開発の現場においてはよくある話だが、宣伝もしてないのに別の人から似たような仕事を頼まれる方がおかしい。
自分の得意分野の仕事ができるようにするためには、社内社外を問わず営業してまわるか、誰かに頼んで営業してもらうしかない。こういう仕事なら他社よりアドバンテージがあるので、安く早くできますというのは自分の売りになる。
自分を売り込むというよりは、自分を知ってもらうということが大事だ。誇大広告をする必要はないが、必要以上に謙遜していてはいつまでたっても本当の能力が伝わらない。
結局のところ、プログラマは得意分野を生かそうと思ったら、コミュニケーションスキルが必須ということだ。ちゃんと仕事をするということより前に、どうやって得意分野を生かせるような仕事を取るか、を考えて実行したほうが、よりいい仕事ができるのではないだろうか。
プログラミングの教育はもっと実戦的に。
新人教育やら配置転換教育やら学校の教育やらで、プログラミングそのものを教育する機会は結構多い。ただ、いつまでたっても全網羅型の教育から抜けてないように思う。
マルチスレッドなプログラミングなんて、最初から教える必要があるのだろうか。知識として知っておく必要があるという意見もありそうだが、少しかじったぐらいで本番で利用できる知識でもないので、あえて教えないという選択もありだろう。
網羅的なのを批判する理由としては、英単語といっしょで、網羅的に覚えても頭に残りにくい（忘れやすい）ということがあげられる。ソフトウェアを作るためにプログラミングを教育するのであれば、教育が終わった際に仕事の１つでも任せられるようにならないと、教育時間が勿体無い。
実戦的な教育とは、要するに修了と同時に何かができるようになっている、ある意味訓練に近いものである。型にはめるとも言えるかもしれない。
プログラミング教育は、わりと「プログラムとは何ができるのか」というコンピュータ側の視点で教育することが多いわけだが、ある意味数学の計算問題といっしょで、計算問題はこなせるが文章題になると、どうやって解決すればいいか解らないという話になってしまう。
そうではなくて「この仕様を実装するには何をすればいいか」という目標に対して、順序立てて解説するような実際の仕事の一部分を切り出したような教育を延々繰り返すほうがよいように思う。
この場合、なぜそうする必要があるのかを理解しないままになってしまうこともあるだろうが、目的が「仕事をこなすこと」にあるのだとすれば、それはそれでいいのではないだろうか。後から理解がついてくればなおよしである。
ある意味、プログラマのマニュアル化とも言える。底が浅いので多様な案件で使えないと思われるかもしれないが、１日中どうでもいいようなところで考え込むプログラマは実際問題かなり多い。
出来ることと出来ない事の把握、新しいことへ挑戦させる際の教育、そしてそのフィードバックを繰り返す事でしか、プログラマは成長していかない気がするのだが。
今はまだプログラマ自身の自主的な学習に頼っているが、根本的に教えられる人がいないから、教わる事が出来ない悪循環が業界内を蝕んでいる。プロジェクトに合わせて教育マニュアルを作り、それをクリアしたものからプロジェクトに参加していく、という流れにならないものかなと。
ついでに、教育マニュアル作成専門会社とかが出てくると世の中素敵になりそうだ。
マルチスレッドなプログラミングなんて、最初から教える必要があるのだろうか。知識として知っておく必要があるという意見もありそうだが、少しかじったぐらいで本番で利用できる知識でもないので、あえて教えないという選択もありだろう。
網羅的なのを批判する理由としては、英単語といっしょで、網羅的に覚えても頭に残りにくい（忘れやすい）ということがあげられる。ソフトウェアを作るためにプログラミングを教育するのであれば、教育が終わった際に仕事の１つでも任せられるようにならないと、教育時間が勿体無い。
実戦的な教育とは、要するに修了と同時に何かができるようになっている、ある意味訓練に近いものである。型にはめるとも言えるかもしれない。
プログラミング教育は、わりと「プログラムとは何ができるのか」というコンピュータ側の視点で教育することが多いわけだが、ある意味数学の計算問題といっしょで、計算問題はこなせるが文章題になると、どうやって解決すればいいか解らないという話になってしまう。
そうではなくて「この仕様を実装するには何をすればいいか」という目標に対して、順序立てて解説するような実際の仕事の一部分を切り出したような教育を延々繰り返すほうがよいように思う。
この場合、なぜそうする必要があるのかを理解しないままになってしまうこともあるだろうが、目的が「仕事をこなすこと」にあるのだとすれば、それはそれでいいのではないだろうか。後から理解がついてくればなおよしである。
ある意味、プログラマのマニュアル化とも言える。底が浅いので多様な案件で使えないと思われるかもしれないが、１日中どうでもいいようなところで考え込むプログラマは実際問題かなり多い。
出来ることと出来ない事の把握、新しいことへ挑戦させる際の教育、そしてそのフィードバックを繰り返す事でしか、プログラマは成長していかない気がするのだが。
今はまだプログラマ自身の自主的な学習に頼っているが、根本的に教えられる人がいないから、教わる事が出来ない悪循環が業界内を蝕んでいる。プロジェクトに合わせて教育マニュアルを作り、それをクリアしたものからプロジェクトに参加していく、という流れにならないものかなと。
ついでに、教育マニュアル作成専門会社とかが出てくると世の中素敵になりそうだ。
成功失敗より、頑張る頑張らないで評価されるプログラマ
PM見習いの読書日記 銀の弾丸より
--
自分が結局「やれないかどうかは、やってみないとわからないでしょ」的な意見に負ける人間なのでこう思いました。
--
根性論ここに極まれりのようにも見えるが、実はこの発言は「失敗してもいいからやってみろ」としか聞こえない。上司が責任を取ってくれるのだから、社内の開発チームはできるところまでやるという選択肢しかない。
そもそも、この場合、開発者側にコミットする余地がないのである。一歩間違うと無責任な現場だが、そこは日本人技術者の悲しい性で、主体的に責任を果たそうとしてデスマーチへの道を辿る。
この会話の前後の問答を想定すると、
開発者「このプロジェクトは納期までに絶対間に合いませんよ！」
上司「やる前から出来ないと言っていたら、出来るものも出来なくなるだろう！」
開発者「といっても、まだ仕様も決まってないのに、無茶ですよ！」
上司「出来ない言い訳なんて、いくらでも出てくるんだ。死ぬ気でやってから言え！ 嫌ならお前が営業に行って来い！」
開発者「・・・。」
という感じだろうか。上司の最後の単語は開発者のモチベーションを極限まで低下させる。
IT業界の一部の組織の風潮として、「がんばる／がんばらない」と「成功／失敗」の２軸があった場合、（がんばる－成功）と（がんばる－失敗）の場合は社内も顧客も「よく頑張った！」となることが多い。（がんばる－失敗）は、とりあえず完成までどこからともなくお金が出続ける。
（がんばらない－成功）は、顧客にいい顔をされないことが多い。ぼったくり状態のように思われてしまう。それでなくても単価がよく見えないので、次の仕事は来ないか、来ても単価を下げられる可能性がある。なので、少なくともがんばる振りは大事だ。
（がんばらない－失敗）は大変である。いや、どうなるのかは怖くて試していない。たぶん、次の日からはIT業界にいられないかもしれない。少なくとも職場からはいなくならないと、目線が冷たそうなことだけはわかる。
と考えると、実は「成功／失敗」の軸は一部の組織から見るとどうでもよくて、いかに頑張ってやったかが評価されているということになる。
なぜなら一部の組織ではソフトウェア自身を評価できないので、どれくらいまじめに取り組んでいるかでしか評価できないからだ。顧客側はなおさら外側からしかわからないので、評価の基準はやはり頑張ったかどうかにならざるを得ないところが多いのではないか。
最初の引用に戻るが、「やったら出来るかもしれないんだからやれ」と言われたら、気合を入れてやってみるのも１つの手である。成功したら大成功で、失敗しても当たり前のプロジェクトというのは、別の視点から見ると挑戦のしがいがあるとも言える。
顧客に対しては失礼かもしれないが、この場合は顧客に対する責任は上司におしつけてしまってよいだろう。回りまわって会社に影響を与える可能性もあるが、会社を辞める気がないならそこまで気にしても仕方がない。
--
自分が結局「やれないかどうかは、やってみないとわからないでしょ」的な意見に負ける人間なのでこう思いました。
--
根性論ここに極まれりのようにも見えるが、実はこの発言は「失敗してもいいからやってみろ」としか聞こえない。上司が責任を取ってくれるのだから、社内の開発チームはできるところまでやるという選択肢しかない。
そもそも、この場合、開発者側にコミットする余地がないのである。一歩間違うと無責任な現場だが、そこは日本人技術者の悲しい性で、主体的に責任を果たそうとしてデスマーチへの道を辿る。
この会話の前後の問答を想定すると、
開発者「このプロジェクトは納期までに絶対間に合いませんよ！」
上司「やる前から出来ないと言っていたら、出来るものも出来なくなるだろう！」
開発者「といっても、まだ仕様も決まってないのに、無茶ですよ！」
上司「出来ない言い訳なんて、いくらでも出てくるんだ。死ぬ気でやってから言え！ 嫌ならお前が営業に行って来い！」
開発者「・・・。」
という感じだろうか。上司の最後の単語は開発者のモチベーションを極限まで低下させる。
IT業界の一部の組織の風潮として、「がんばる／がんばらない」と「成功／失敗」の２軸があった場合、（がんばる－成功）と（がんばる－失敗）の場合は社内も顧客も「よく頑張った！」となることが多い。（がんばる－失敗）は、とりあえず完成までどこからともなくお金が出続ける。
（がんばらない－成功）は、顧客にいい顔をされないことが多い。ぼったくり状態のように思われてしまう。それでなくても単価がよく見えないので、次の仕事は来ないか、来ても単価を下げられる可能性がある。なので、少なくともがんばる振りは大事だ。
（がんばらない－失敗）は大変である。いや、どうなるのかは怖くて試していない。たぶん、次の日からはIT業界にいられないかもしれない。少なくとも職場からはいなくならないと、目線が冷たそうなことだけはわかる。
と考えると、実は「成功／失敗」の軸は一部の組織から見るとどうでもよくて、いかに頑張ってやったかが評価されているということになる。
なぜなら一部の組織ではソフトウェア自身を評価できないので、どれくらいまじめに取り組んでいるかでしか評価できないからだ。顧客側はなおさら外側からしかわからないので、評価の基準はやはり頑張ったかどうかにならざるを得ないところが多いのではないか。
最初の引用に戻るが、「やったら出来るかもしれないんだからやれ」と言われたら、気合を入れてやってみるのも１つの手である。成功したら大成功で、失敗しても当たり前のプロジェクトというのは、別の視点から見ると挑戦のしがいがあるとも言える。
顧客に対しては失礼かもしれないが、この場合は顧客に対する責任は上司におしつけてしまってよいだろう。回りまわって会社に影響を与える可能性もあるが、会社を辞める気がないならそこまで気にしても仕方がない。
作った途端に忘れるのが優秀なプログラマ
優秀なプログラマは大規模なソフトウェアも作れる。普通のプログラマはある程度の規模以上のプログラムを作ると破綻してしまう。この違いはなんだろうか。
小規模なプログラムが作れる人は、大規模なプログラムも作れそうである。仕組みは何も違いがないし、建築物みたいに大きいと自重で沈むとかそんなことを考える必要がないからだ。
根本的な違いは、全体を把握しているかどうかである。普通のプログラマは、自分の理解できる規模を超えると、途端に前に進めなくなる。この関数はなんだったかなと思い出し直しては開発し、また忘れて、ということを繰り返すからである。
それなりに記憶力のある人は、ある程度の規模までは自力でプログラミングできてしまうため、大規模な案件を任せたら火があがるという罠があったりする。
優秀なプログラマは記憶力が抜群にいいから大規模でも問題ないのだろうと思われるかもしれないがそうではない。優秀なプログラマはプログラムの中で何が大事で何が大事でないかをよく知っている。そのため、自分で作ったプログラムも作った時点で忘れてしまうことが出来る。要するにモジュール化、ライブラリ化が上手ということだ。
中のロジックは作っている時は一生懸命考えているが、作り終わった後は、入力に対して結果がどうなるかだけ覚えていれば、中身は綺麗さっぱり忘れてしまう。
バグがあれば直すことになるが、その時は他人が作ったプログラムを見るのと同じ過程を辿ることになる。以前作ったけど覚えていないという状況はいかにも駄目プログラマのようだが、実際は忘れてしまえるからこそ大規模なプログラムのコントロールができるのだ。
ある意味、仕掛中なのか、もう終わったのかということである。何度も何度も同じプログラムの手直しをしているという状況は、ずっと仕掛中だということだ。手を入れなくてすむ場所と触りつづける場所を分離して、手を入れなくてすむ場所については、完全に切り出して終わらせてしまうことができるかどうかが、優秀かどうかの境目ということなのかもしれない。
忘れる以上は、その後バグなんて出している場合ではない。そのために忘れる前にテストである。もう一生そのプログラムに触らないつもりでテストしないと、忘れたくてもそう簡単に忘れられない。
優秀なプログラマは本当に必要な箇所だけを意識して、それ以外は忘れる。理屈で考えるととても当たり前のように見えてなかなか難しい。それが出来るようになれば、一人前のプログラマといえるのではないだろうか。
小規模なプログラムが作れる人は、大規模なプログラムも作れそうである。仕組みは何も違いがないし、建築物みたいに大きいと自重で沈むとかそんなことを考える必要がないからだ。
根本的な違いは、全体を把握しているかどうかである。普通のプログラマは、自分の理解できる規模を超えると、途端に前に進めなくなる。この関数はなんだったかなと思い出し直しては開発し、また忘れて、ということを繰り返すからである。
それなりに記憶力のある人は、ある程度の規模までは自力でプログラミングできてしまうため、大規模な案件を任せたら火があがるという罠があったりする。
優秀なプログラマは記憶力が抜群にいいから大規模でも問題ないのだろうと思われるかもしれないがそうではない。優秀なプログラマはプログラムの中で何が大事で何が大事でないかをよく知っている。そのため、自分で作ったプログラムも作った時点で忘れてしまうことが出来る。要するにモジュール化、ライブラリ化が上手ということだ。
中のロジックは作っている時は一生懸命考えているが、作り終わった後は、入力に対して結果がどうなるかだけ覚えていれば、中身は綺麗さっぱり忘れてしまう。
バグがあれば直すことになるが、その時は他人が作ったプログラムを見るのと同じ過程を辿ることになる。以前作ったけど覚えていないという状況はいかにも駄目プログラマのようだが、実際は忘れてしまえるからこそ大規模なプログラムのコントロールができるのだ。
ある意味、仕掛中なのか、もう終わったのかということである。何度も何度も同じプログラムの手直しをしているという状況は、ずっと仕掛中だということだ。手を入れなくてすむ場所と触りつづける場所を分離して、手を入れなくてすむ場所については、完全に切り出して終わらせてしまうことができるかどうかが、優秀かどうかの境目ということなのかもしれない。
忘れる以上は、その後バグなんて出している場合ではない。そのために忘れる前にテストである。もう一生そのプログラムに触らないつもりでテストしないと、忘れたくてもそう簡単に忘れられない。
優秀なプログラマは本当に必要な箇所だけを意識して、それ以外は忘れる。理屈で考えるととても当たり前のように見えてなかなか難しい。それが出来るようになれば、一人前のプログラマといえるのではないだろうか。
ソフトウェア開発プロジェクトにメインプログラマという位置付けはあるか？
ソフトウェア開発プロジェクト、特に業務系の開発プロジェクトでは、あまりメインプログラマという肩書きは聞かない。リーダ格の人はいるが、プログラム作成工程の中では、作業は全員並列という感じである。
これがゲーム業界になると、少し前まではメインプログラマ、ツールプログラマ、サウンドプログラマという具合に、ソフトウェア毎に一人で開発するのが基本だった。
何が言いたいかというと、業務系のソフトウェア開発って、１つのプログラムに対して割り当てるプログラマの数が多すぎやしませんか、ということだ。当然規模や納期にも左右される問題だが、ソースコードに触る人の数が増えると、当然品質にばらつきが出るし、何をやっているのか良く解らない部分が増える。
ソフトウェア開発工程において、プログラマは少数でいいと思っている。サブプロセスにあまり分割できないのであれば１人か２人でいいはずだ。メインプログラマを決めて、プログラムについてはその人に任せよう。後は、ソフトウェア開発をサポートするための人員に力を注ぐべきである。
実際には、サーバの環境を整備したり、ドキュメントを整備したり、データを作成したり検証したり、テストをしたり、ソフトウェアに関してプログラムを作る以外にやらないといけない作業は相当ある。
逆に言うと、プログラマはプログラムを作る以外の工程に仕事が出せるような実装にすることで、プログラマ個人にかかる負荷が分散され、プロジェクト全体として、投入できる人材の幅が広がることに繋がる。
少々の規模のソフトウェアについても、開発時に大量のプログラマを集めるのではなくて、優秀な一握りのプログラマ以外は、プログラム以外の作業でソフトウェア開発に貢献させるべきだろう。
そうすれば、たぶん優秀なプログラマが徹夜で他のプログラマのバグを修正したりということもなくなると思う。もっとも、優秀なプログラマってどうやって見つけるのか、という問題はいつまでたっても残るわけだが。
これがゲーム業界になると、少し前まではメインプログラマ、ツールプログラマ、サウンドプログラマという具合に、ソフトウェア毎に一人で開発するのが基本だった。
何が言いたいかというと、業務系のソフトウェア開発って、１つのプログラムに対して割り当てるプログラマの数が多すぎやしませんか、ということだ。当然規模や納期にも左右される問題だが、ソースコードに触る人の数が増えると、当然品質にばらつきが出るし、何をやっているのか良く解らない部分が増える。
ソフトウェア開発工程において、プログラマは少数でいいと思っている。サブプロセスにあまり分割できないのであれば１人か２人でいいはずだ。メインプログラマを決めて、プログラムについてはその人に任せよう。後は、ソフトウェア開発をサポートするための人員に力を注ぐべきである。
実際には、サーバの環境を整備したり、ドキュメントを整備したり、データを作成したり検証したり、テストをしたり、ソフトウェアに関してプログラムを作る以外にやらないといけない作業は相当ある。
逆に言うと、プログラマはプログラムを作る以外の工程に仕事が出せるような実装にすることで、プログラマ個人にかかる負荷が分散され、プロジェクト全体として、投入できる人材の幅が広がることに繋がる。
少々の規模のソフトウェアについても、開発時に大量のプログラマを集めるのではなくて、優秀な一握りのプログラマ以外は、プログラム以外の作業でソフトウェア開発に貢献させるべきだろう。
そうすれば、たぶん優秀なプログラマが徹夜で他のプログラマのバグを修正したりということもなくなると思う。もっとも、優秀なプログラマってどうやって見つけるのか、という問題はいつまでたっても残るわけだが。
簡単なものほど再生産されやすく見えない工数の無駄となる
年月日の検証（うるう年例外含む）とか、CSVファイルの読み書きとか、まぁどこにでもありそうで、以前作った記憶があるかもしれないが、探すのがめんどくさいというような理由で再生産してしまうことがよくある。
もしかすると、同じチーム内で同じプロダクト内でも、全く同じことをしているプログラムを別々の人が個別に書いていることもあるかもしれない。
複雑でやっかいな部分というのは、わりと皆で意識を共有しやすいのだが、簡単でたまに使うような部分は、その都度探すか作るかということが多い。
ソフトウェア開発において、コミュニケーション不足という言葉がよく聞かれるが、その代表例としてコード（機能）の重複がある。なぜ重複するのかというと、隣の人に聞かずにインターネットや文献をまずあたるからである。
隣の人にまず聞けばよさそうに思うが、どうもチーム内コミュニケーションと雑談を混同する人がいるからか、自分の知らないことを他の人に聞くのが嫌なのか、忙しそうにしているところに割り込むより自分で解決した方が早いと思うからか、基本的に聞かないというのが主流だ。
悩む人は丸１日でも悩みつづけることがある。そういう業界の風習を変えようということで、最近はペアプログラミングという考え方が出てきた。ずーっとペアでプログラミングというのはある意味極端だが、コミュニケーションをとりつづけるのと、黙々作業をし続けるの中間ぐらいを目指すのがいいように思う。
具体的には、３０分刻みで作業をわけて、間に会話を挟むとか。メリハリがついていいかもしれない。ソフトウェア開発もまだまだ試行錯誤が大事ということで。
もしかすると、同じチーム内で同じプロダクト内でも、全く同じことをしているプログラムを別々の人が個別に書いていることもあるかもしれない。
複雑でやっかいな部分というのは、わりと皆で意識を共有しやすいのだが、簡単でたまに使うような部分は、その都度探すか作るかということが多い。
ソフトウェア開発において、コミュニケーション不足という言葉がよく聞かれるが、その代表例としてコード（機能）の重複がある。なぜ重複するのかというと、隣の人に聞かずにインターネットや文献をまずあたるからである。
隣の人にまず聞けばよさそうに思うが、どうもチーム内コミュニケーションと雑談を混同する人がいるからか、自分の知らないことを他の人に聞くのが嫌なのか、忙しそうにしているところに割り込むより自分で解決した方が早いと思うからか、基本的に聞かないというのが主流だ。
悩む人は丸１日でも悩みつづけることがある。そういう業界の風習を変えようということで、最近はペアプログラミングという考え方が出てきた。ずーっとペアでプログラミングというのはある意味極端だが、コミュニケーションをとりつづけるのと、黙々作業をし続けるの中間ぐらいを目指すのがいいように思う。
具体的には、３０分刻みで作業をわけて、間に会話を挟むとか。メリハリがついていいかもしれない。ソフトウェア開発もまだまだ試行錯誤が大事ということで。