ソフトウェア開発プロフェッショナル
著者： スティーブ・マコネル, 松原 友夫, 山浦 恒央
タイトル： ソフトウエア開発プロフェッショナル
----
「プロセス指向」と、「実力主義」という二つの組織的な開発スタイルを対比させると面白いものが見える。プロセス指向の開発は、綿密に計画を立て、きちんと定義したプロセスを適用し、時間を有効に使い、ソフトウェア開発でのベスト・プラクティスをうまく利用することで効率を上げる。この開発スタイルのプロジェクトが成功するのは、常に、開発プロセスを改善しているためだ。最初は効率が悪くても、プロセス改善を常に意識していれば、回数を重ねるに従い、効率が上がる。
一方、実力主義による開発には、「スーパー・プログラマ指向開発」とか、「個人能力増強型」開発など、いろんな名前がついている。実力主義開発の特徴は、現時点でかき集められる人員中、一番優秀なプログラマを選び、この日までに死んでもやると約束させ、好き放題できる権限を与え、極限までヤル気を出させ、プロジェクトが完了するまで、週に60、80、100時間も働かせることだ。
（途中略）
ソフトウェアの研究者の間でよく起きる議論として、プロセス指向がよいか、各個人に権限を与える方がよいか（すなわち、「実力主義の開発方法がよいか）がある。この2方式が背反すると考えるのは正しくない。プロセス指向は効率的だし、開発担当者へ権限委譲する方式も理にかなっている。二つが共存しても、何の問題もない。
----
いままでのソフトウェア開発論では、方法論で全て解決するとは思わないが、俗人的なままではまずいのではないか、という主張がわりと多かったように思う。特に会社ではプログラマ個人の能力に依存するのは問題があるという意識が強かったのでは無いだろうか。
この本によると、やり方次第で理に適いもするし、リスクが高くなるばっかりになる場合もある、と至極真っ当な話が書いてある。わざわざ、意識の高い能力のある新人を型にはめるよりも、適材適所で最大限に能力の発揮できる仕事を任せた方がいい、という話である。
もっとも、それはあくまでも人材の使い方であり、たまたまうまくいくようなモデルでは会社が続かない。この本の後半では、組織的に人材を育成するにはどうすればいいかということを、実例を挙げて説明している。
いろいろな必要なスキルについて定義しているのだが、興味深かったのは、知識がない段階から、入門者の段階にステップアップするのに必要な条件として、「文献を読む」ということが大半を占めていたことだ。
まずは基礎的な知識は、文献から学ぶのが効率的であるということだ。絶対的に知識が不足していては、コミュニケーションもおぼつかない。ただ、日頃からあまり本を読んでいない人にとっては、ただ本を渡されてもなかなか読めないだろう。
ましてや会社で８時間も１０時間もプログラムを組んだ後で、帰ってから本を読めと言われてもなかなか時間がとれない。ここはいっそのこと、本当に会社が教育する気があるのであれば、毎日１時間ぐらいは社員教育用に時間を割いて、本を読む時間を強制的に作るぐらいでもいいのかもしれない。
どの社員になんの文献を読ませるか、というところが社員教育の要である。ただ本を渡しても、だらだら読むだけでは意味がないので、１時間なら１時間で１冊を読ませる訓練をさせるのが大事だ。
どこがポイントでどこがどうでもいい部分なのか、コツを掴めば後は勝手に本を読んで成長していくだろう。アウトプットだけではなく、インプットもスケジュールに組み込むぐらいの気持ちでいれば、いざというときに技術力不足でデスマーチということが避けれるかもしれない。
日々学習しつづけないといけないよ、という話でした。
タイトル： ソフトウエア開発プロフェッショナル
----
「プロセス指向」と、「実力主義」という二つの組織的な開発スタイルを対比させると面白いものが見える。プロセス指向の開発は、綿密に計画を立て、きちんと定義したプロセスを適用し、時間を有効に使い、ソフトウェア開発でのベスト・プラクティスをうまく利用することで効率を上げる。この開発スタイルのプロジェクトが成功するのは、常に、開発プロセスを改善しているためだ。最初は効率が悪くても、プロセス改善を常に意識していれば、回数を重ねるに従い、効率が上がる。
一方、実力主義による開発には、「スーパー・プログラマ指向開発」とか、「個人能力増強型」開発など、いろんな名前がついている。実力主義開発の特徴は、現時点でかき集められる人員中、一番優秀なプログラマを選び、この日までに死んでもやると約束させ、好き放題できる権限を与え、極限までヤル気を出させ、プロジェクトが完了するまで、週に60、80、100時間も働かせることだ。
（途中略）
ソフトウェアの研究者の間でよく起きる議論として、プロセス指向がよいか、各個人に権限を与える方がよいか（すなわち、「実力主義の開発方法がよいか）がある。この2方式が背反すると考えるのは正しくない。プロセス指向は効率的だし、開発担当者へ権限委譲する方式も理にかなっている。二つが共存しても、何の問題もない。
----
いままでのソフトウェア開発論では、方法論で全て解決するとは思わないが、俗人的なままではまずいのではないか、という主張がわりと多かったように思う。特に会社ではプログラマ個人の能力に依存するのは問題があるという意識が強かったのでは無いだろうか。
この本によると、やり方次第で理に適いもするし、リスクが高くなるばっかりになる場合もある、と至極真っ当な話が書いてある。わざわざ、意識の高い能力のある新人を型にはめるよりも、適材適所で最大限に能力の発揮できる仕事を任せた方がいい、という話である。
もっとも、それはあくまでも人材の使い方であり、たまたまうまくいくようなモデルでは会社が続かない。この本の後半では、組織的に人材を育成するにはどうすればいいかということを、実例を挙げて説明している。
いろいろな必要なスキルについて定義しているのだが、興味深かったのは、知識がない段階から、入門者の段階にステップアップするのに必要な条件として、「文献を読む」ということが大半を占めていたことだ。
まずは基礎的な知識は、文献から学ぶのが効率的であるということだ。絶対的に知識が不足していては、コミュニケーションもおぼつかない。ただ、日頃からあまり本を読んでいない人にとっては、ただ本を渡されてもなかなか読めないだろう。
ましてや会社で８時間も１０時間もプログラムを組んだ後で、帰ってから本を読めと言われてもなかなか時間がとれない。ここはいっそのこと、本当に会社が教育する気があるのであれば、毎日１時間ぐらいは社員教育用に時間を割いて、本を読む時間を強制的に作るぐらいでもいいのかもしれない。
どの社員になんの文献を読ませるか、というところが社員教育の要である。ただ本を渡しても、だらだら読むだけでは意味がないので、１時間なら１時間で１冊を読ませる訓練をさせるのが大事だ。
どこがポイントでどこがどうでもいい部分なのか、コツを掴めば後は勝手に本を読んで成長していくだろう。アウトプットだけではなく、インプットもスケジュールに組み込むぐらいの気持ちでいれば、いざというときに技術力不足でデスマーチということが避けれるかもしれない。
日々学習しつづけないといけないよ、という話でした。
ポートフォリオ的スケジューリング
株というか投資の世界では、ポートフォリオという言葉がある。非常に適当に説明すると、多面的に株とか国債とか外貨とか現金とかをバランスよく取り混ぜて、全体のリスクを分散させて安定的に資産を管理しましょうということだ。
昨日の続きになるが、１つのプロジェクトだけで考えた場合、スケジュールの遅延リスクを回避しようとすると、そのプロジェクトにバッファを設けないといけないということになる。
ただリスクというのはどれもこれもが具現化するわけではないので、全部をスケジュールに組み込むのは現実的な解とは言えない。そこで上記のポートフォリオをソフトウェア開発のスケジュールに適用できないかどうか考えてみる。
要するに、複数のプロジェクトをポートフォリオとして構築し、ポートフォリオ内でリスクを管理するという手法である。１つ１つのプロジェクトは少しずつバッファを持たせておいて、もしもの時には、プロジェクト間でリソースとバッファを流動させることで対応するのである。
１つのプロジェクトを１つのチームで行うより、３つのプロジェクトを３つのチームで行った方が、バッファ分のオーバーヘッドが少なくなり、競争力が増すという考え方である。
ここだけ見ると当たり前のように思われるかもしれないが、ソフトウェア開発プロジェクトというのはは、えてして同じ会社でもプロジェクト間のリソースの共有化というのが少ない。終わったら別のところに入るというのはあっても、途中でヘルプに入るというのはよっぽどの場合に限られる。
それを、会社レベルでもう少し流動的にリソース（モノ、人、金）を動かすことができれば、スケジュールの遅延がなくなるのではないだろうかと思う。
そのためには、各プロジェクトの納期が少しずつずれるようにコントロールする交渉力と、スタッフのスキルが分散しないように少なくとも同じ言語で似たようなフレームワークが使える仕事を取ってくる営業力が必要だ。
つまるところ、１つでっかい仕事がきたから、わーいと言ってみんなで開発するというようなお子様チックな会社ではだめだということだ。継続的な営業力、技術に裏付けされた見積力、納期に間に合わせる開発力、仕様や納期や金額の交渉力と、組織の力を最大限に発揮できるスタッフを集めないといけない。
ソフトウェアを開発するだけで大儲け、と思っていたが、世の中そんなに簡単ではないようだ。相手が理解してくれたらなぁと嘆くのではなくて、自社の力を向上させて、相手に心から納得させられるような、そんな組織を目指していかないと、疲労とストレスでやってられなくなる。
プログラマというのは生涯現役でもやっていける職業だと思うので、もう少し職業の中身を充実させていければいいなぁということで。
昨日の続きになるが、１つのプロジェクトだけで考えた場合、スケジュールの遅延リスクを回避しようとすると、そのプロジェクトにバッファを設けないといけないということになる。
ただリスクというのはどれもこれもが具現化するわけではないので、全部をスケジュールに組み込むのは現実的な解とは言えない。そこで上記のポートフォリオをソフトウェア開発のスケジュールに適用できないかどうか考えてみる。
要するに、複数のプロジェクトをポートフォリオとして構築し、ポートフォリオ内でリスクを管理するという手法である。１つ１つのプロジェクトは少しずつバッファを持たせておいて、もしもの時には、プロジェクト間でリソースとバッファを流動させることで対応するのである。
１つのプロジェクトを１つのチームで行うより、３つのプロジェクトを３つのチームで行った方が、バッファ分のオーバーヘッドが少なくなり、競争力が増すという考え方である。
ここだけ見ると当たり前のように思われるかもしれないが、ソフトウェア開発プロジェクトというのはは、えてして同じ会社でもプロジェクト間のリソースの共有化というのが少ない。終わったら別のところに入るというのはあっても、途中でヘルプに入るというのはよっぽどの場合に限られる。
それを、会社レベルでもう少し流動的にリソース（モノ、人、金）を動かすことができれば、スケジュールの遅延がなくなるのではないだろうかと思う。
そのためには、各プロジェクトの納期が少しずつずれるようにコントロールする交渉力と、スタッフのスキルが分散しないように少なくとも同じ言語で似たようなフレームワークが使える仕事を取ってくる営業力が必要だ。
つまるところ、１つでっかい仕事がきたから、わーいと言ってみんなで開発するというようなお子様チックな会社ではだめだということだ。継続的な営業力、技術に裏付けされた見積力、納期に間に合わせる開発力、仕様や納期や金額の交渉力と、組織の力を最大限に発揮できるスタッフを集めないといけない。
ソフトウェアを開発するだけで大儲け、と思っていたが、世の中そんなに簡単ではないようだ。相手が理解してくれたらなぁと嘆くのではなくて、自社の力を向上させて、相手に心から納得させられるような、そんな組織を目指していかないと、疲労とストレスでやってられなくなる。
プログラマというのは生涯現役でもやっていける職業だと思うので、もう少し職業の中身を充実させていければいいなぁということで。
スケジュールの遅延をなくす気があるか？
コミットメントは約束するということ。ソフトウェア開発なら、プログラマが「この日までには必ず仕上げます」と約束するわけだ。
ただ、趣味とは違い仕事の場合、「この日」が余裕のある日かというとそんなことはなくて、大概の場合ぎりぎりなのである。なぜぎりぎりなのかというと、ぎりぎり間に合うと思われる規模に仕様を落とし込むからである。
しかし、ぎりぎり間に合う見積りが正確かというとそんなことはなく、だいたいスケジュールは後ろに伸びていく。伸びていくが納期が決まっているため、夜間と土日が埋まっていくといういつものパターンにはまるのである。
それならぎりぎり感をなくして、バッファ（余裕）分を加算してスケジュールすればいいと思うかもしれないが、顧客からの期待が圧力（プレッシャー）となり、余裕を省いて約束してしまうことがある。
また、バッファを入れれば大丈夫かというと、そのうち顧客も学習してくるので、バッファを削りにかかる。もう一声ではないが、お互いに手の内がわかるとろくなことがないといういい例だ。顧客が削らなくても社内の上司や経営者が削ることもあるのだ。
かくしてバッファは削られ、ぎりぎりのスケジュールが敷かれると、デスマーチとまではいかないが、残業続きということになる。そして疲弊する。35歳定年説も案外このあたりに問題があるのかもしれない。
一番の原因は何か？ バッファ（余裕）という言葉が主因のような気がする。余裕ではないのだが、余裕＝無駄に見えるのでいらないと思われてしまう。何かいい言葉はないのだろうか。言葉１つでソフトウェア開発が大きく変わるのかもしれない。
どうも余裕があるとサボるとか、余裕を使い果たすのは悪とか、そう考えてしまうのかもしれない。国の予算のメタファーが使えそうだ。ということは予算のうまい運用の仕方を模倣すれば、ソフトウェア開発のスケジュールにも使えるかもしれない。
ぎりぎりと思っているところが実は全然ぎりぎりではなくて、ちょっと余裕のあるぐらいが本当のぎりぎりなのだ、という認識でスケジュールを引かないとだめだ。自戒の意味もこめて。
ただ、趣味とは違い仕事の場合、「この日」が余裕のある日かというとそんなことはなくて、大概の場合ぎりぎりなのである。なぜぎりぎりなのかというと、ぎりぎり間に合うと思われる規模に仕様を落とし込むからである。
しかし、ぎりぎり間に合う見積りが正確かというとそんなことはなく、だいたいスケジュールは後ろに伸びていく。伸びていくが納期が決まっているため、夜間と土日が埋まっていくといういつものパターンにはまるのである。
それならぎりぎり感をなくして、バッファ（余裕）分を加算してスケジュールすればいいと思うかもしれないが、顧客からの期待が圧力（プレッシャー）となり、余裕を省いて約束してしまうことがある。
また、バッファを入れれば大丈夫かというと、そのうち顧客も学習してくるので、バッファを削りにかかる。もう一声ではないが、お互いに手の内がわかるとろくなことがないといういい例だ。顧客が削らなくても社内の上司や経営者が削ることもあるのだ。
かくしてバッファは削られ、ぎりぎりのスケジュールが敷かれると、デスマーチとまではいかないが、残業続きということになる。そして疲弊する。35歳定年説も案外このあたりに問題があるのかもしれない。
一番の原因は何か？ バッファ（余裕）という言葉が主因のような気がする。余裕ではないのだが、余裕＝無駄に見えるのでいらないと思われてしまう。何かいい言葉はないのだろうか。言葉１つでソフトウェア開発が大きく変わるのかもしれない。
どうも余裕があるとサボるとか、余裕を使い果たすのは悪とか、そう考えてしまうのかもしれない。国の予算のメタファーが使えそうだ。ということは予算のうまい運用の仕方を模倣すれば、ソフトウェア開発のスケジュールにも使えるかもしれない。
ぎりぎりと思っているところが実は全然ぎりぎりではなくて、ちょっと余裕のあるぐらいが本当のぎりぎりなのだ、という認識でスケジュールを引かないとだめだ。自戒の意味もこめて。
プログラマは社長とのホットラインを確立しておこう
プログラマは、ソフトウェア開発における最終的な責任をなぜか任されることが多い。実際には何も言われないし、本来責任を取る権限はないはずなのだが、プログラムにバグがあると昼夜問わず連絡が来て怒られる。世の中はとかく理不尽である。
そんな弱い立場に追い込まれるプログラマは、会社から見ると飯の種である。プログラムがソフトウェアを作らない限り会社に利益が出ないのだから、経営陣から見るとちゃんとソフトウェアを作るプログラマは確保しておきたい人材なのだ。
ただ、確保しておきたいという話と、内容を理解しているかという話は全然別で、社長ができることは社内の雰囲気とプログラマの顔色を見て判断しているだけ、もしくは部長とかに確認するのだが、部長もわかってなかったりすると、「大丈夫です」としかいえない。
要するに危機的状況が判断できるのは、何を隠そう、プログラムを作っているチームの中だけ、もしくはプログラマだけ、ということは普通にありえる話だ。
そんな状況下においては、下から危険を伝えていけないといけないわけだが、組織的に下からの声は一番上にはなかなか届きにくい。途中で上司が掴みっぱなしにするからだ。
上司が社長や取締役に説明しようとしても、質問に対して答えられないのでうやむやにしようとすることも考えられる。そもそもちゃんと質問に答えられる上司なら、危機的状況かどうかもわかっているので、危機的状況になっても手を打たない時点で、上司に何かを伝えても仕方が無いことを理解しよう。
さて、どうすればいいのだろうか。このままではプロジェクトは破綻しそうで、デスマーチは嫌だ。上司は人も金もないけどなんとかしてくれと言っている。そんな時に、社長に直談判できるホットラインがあれば、とりあえず現場がどういう状況かは伝えられる。
といっても、社長が人を増やしてくれたり納期を延ばしてくれるわけではない。社長が出来るのは社内の人を動かしたり、顧客とのトップ交渉したりということだ。一旦問題を一番上にあげることで、問題をチーム内から社内の問題にスケールアップさせることが大事なのだ。
このホットラインは、使い方を誤るとただの「狼少年回線」になる可能性もあるので注意する必要がある。伝家の宝刀としていつでも使えるようにして、使わないのが理想的な姿なわけで。
そんな弱い立場に追い込まれるプログラマは、会社から見ると飯の種である。プログラムがソフトウェアを作らない限り会社に利益が出ないのだから、経営陣から見るとちゃんとソフトウェアを作るプログラマは確保しておきたい人材なのだ。
ただ、確保しておきたいという話と、内容を理解しているかという話は全然別で、社長ができることは社内の雰囲気とプログラマの顔色を見て判断しているだけ、もしくは部長とかに確認するのだが、部長もわかってなかったりすると、「大丈夫です」としかいえない。
要するに危機的状況が判断できるのは、何を隠そう、プログラムを作っているチームの中だけ、もしくはプログラマだけ、ということは普通にありえる話だ。
そんな状況下においては、下から危険を伝えていけないといけないわけだが、組織的に下からの声は一番上にはなかなか届きにくい。途中で上司が掴みっぱなしにするからだ。
上司が社長や取締役に説明しようとしても、質問に対して答えられないのでうやむやにしようとすることも考えられる。そもそもちゃんと質問に答えられる上司なら、危機的状況かどうかもわかっているので、危機的状況になっても手を打たない時点で、上司に何かを伝えても仕方が無いことを理解しよう。
さて、どうすればいいのだろうか。このままではプロジェクトは破綻しそうで、デスマーチは嫌だ。上司は人も金もないけどなんとかしてくれと言っている。そんな時に、社長に直談判できるホットラインがあれば、とりあえず現場がどういう状況かは伝えられる。
といっても、社長が人を増やしてくれたり納期を延ばしてくれるわけではない。社長が出来るのは社内の人を動かしたり、顧客とのトップ交渉したりということだ。一旦問題を一番上にあげることで、問題をチーム内から社内の問題にスケールアップさせることが大事なのだ。
このホットラインは、使い方を誤るとただの「狼少年回線」になる可能性もあるので注意する必要がある。伝家の宝刀としていつでも使えるようにして、使わないのが理想的な姿なわけで。
デスマーチを減らそうとすると仕事そのものが減る矛盾
デスマーチプロジェクトは、突発的に発生する場合もあるし、最初からデスマーチになる確率がかなり高そうだと思われる場合もある。
前者はまだ言い訳できる余地がある（誰かが突然病気になったとか）が、後者は引き受ける時点で無理を承知で受けているケースが多いため、前提条件が何も変わってないのであれば、引き受けた側でどうにかする以外にない。
今回は後者のケースについてとりあげる。なぜ無理っぽい案件を引き受ける会社があるのかというと、大きく分けて
１．顧客と関係強化
２．スタッフに空きがあるため仕事を入れたい
３．無理だと思っていない
の３つぐらいに分類できそうだ。
１は、他の案件を受けている手前受けざるを得ないとか、新しく取引がしたいから少しきついかもしれないけど引き受けるという場合である。
２は、開発案件が終了して、スタッフが空いたという状態で、何か仕事がないですかという時に、少々赤字でもいいからスタッフを遊ばせておくよりはましといって引き受ける場合である。
３は、優秀なスタッフがいるからあいつに任せれば安心だろうとか、新しく優秀なスタッフを探してきたらなんとかなるだろうという思い込みで引き受ける場合である。
１、２は最初の読みが正しければ、スタッフは少し忙しく、少し赤字ぐらいの状態で難を逃れる事が出来るかもしれないが、ちょっとしたトラブルですぐにデスマーチに突入しそうである。
３については、予算と納期だけ決まって、後からスタッフをあてがうということで、成功するか失敗するかはわりと運任せである。いいスタッフがいればいいが、通常であればひどいデスマーチになることが予想される。
上記のような仕事の受け方では、デスマーチになるであろうことはわかるわけだが、かといって仕事を受けないとどうなるかというと、他の仕事を探すしかないわけだが、探している間は給料を貰えない、というわけにもいかない。
自分の所属する会社がデスマーチに陥りそうな仕事は全部拒否しても、どこかの会社（もしくは個人）が受けてしまうので、期間が延びたり、金額があがったりということもカルテルでも結ばない限りないだろう。デスマーチな仕事を回避していると仕事がなくなっていくのである。
要は顧客主体な仕事をしている限り、デスマーチな仕事を受けざるを得ない状態になりやすいし、デスマーチになると余計資金繰りが悪化するという悪循環にはまっていく。
そうならないようにするために、会社は人だけ派遣してプロジェクトに関与しない方向に向かっていくという選択肢を取るわけだが、派遣される側の人にとっては、派遣先がデスマーチの場合も当然あるわけで・・。
今日の結論：デスマーチが回避できるかどうかは、会社の戦略によるところが大きい。デスマーチな選択をしがちな会社に入ったら、その後相当の努力と運がないと回避できそうにない。そんな苦労をするぐらいなら、入る会社を慎重に選択する方がよい。どこに入ってもなんとかなる、というのは幻想だと思う。
前者はまだ言い訳できる余地がある（誰かが突然病気になったとか）が、後者は引き受ける時点で無理を承知で受けているケースが多いため、前提条件が何も変わってないのであれば、引き受けた側でどうにかする以外にない。
今回は後者のケースについてとりあげる。なぜ無理っぽい案件を引き受ける会社があるのかというと、大きく分けて
１．顧客と関係強化
２．スタッフに空きがあるため仕事を入れたい
３．無理だと思っていない
の３つぐらいに分類できそうだ。
１は、他の案件を受けている手前受けざるを得ないとか、新しく取引がしたいから少しきついかもしれないけど引き受けるという場合である。
２は、開発案件が終了して、スタッフが空いたという状態で、何か仕事がないですかという時に、少々赤字でもいいからスタッフを遊ばせておくよりはましといって引き受ける場合である。
３は、優秀なスタッフがいるからあいつに任せれば安心だろうとか、新しく優秀なスタッフを探してきたらなんとかなるだろうという思い込みで引き受ける場合である。
１、２は最初の読みが正しければ、スタッフは少し忙しく、少し赤字ぐらいの状態で難を逃れる事が出来るかもしれないが、ちょっとしたトラブルですぐにデスマーチに突入しそうである。
３については、予算と納期だけ決まって、後からスタッフをあてがうということで、成功するか失敗するかはわりと運任せである。いいスタッフがいればいいが、通常であればひどいデスマーチになることが予想される。
上記のような仕事の受け方では、デスマーチになるであろうことはわかるわけだが、かといって仕事を受けないとどうなるかというと、他の仕事を探すしかないわけだが、探している間は給料を貰えない、というわけにもいかない。
自分の所属する会社がデスマーチに陥りそうな仕事は全部拒否しても、どこかの会社（もしくは個人）が受けてしまうので、期間が延びたり、金額があがったりということもカルテルでも結ばない限りないだろう。デスマーチな仕事を回避していると仕事がなくなっていくのである。
要は顧客主体な仕事をしている限り、デスマーチな仕事を受けざるを得ない状態になりやすいし、デスマーチになると余計資金繰りが悪化するという悪循環にはまっていく。
そうならないようにするために、会社は人だけ派遣してプロジェクトに関与しない方向に向かっていくという選択肢を取るわけだが、派遣される側の人にとっては、派遣先がデスマーチの場合も当然あるわけで・・。
今日の結論：デスマーチが回避できるかどうかは、会社の戦略によるところが大きい。デスマーチな選択をしがちな会社に入ったら、その後相当の努力と運がないと回避できそうにない。そんな苦労をするぐらいなら、入る会社を慎重に選択する方がよい。どこに入ってもなんとかなる、というのは幻想だと思う。
ソフトウェア開発はアイデア出しの連続
著者： 高橋 誠
タイトル： アイデアが面白いほど出てくる本―これだけは身につけたい16の手法
---
問題解決には、基本として４つの手順・ステップがあります。「問題設定」、「問題把握」、「課題決定」、「課題解決」の４つです。
問題設定とは、何が問題なのかを明確にして絞り込むことです。次に問題把握とは、問題に関係するさまざまな情報を集めて、問題点を探し出して、解決するべき問題点では何が重要かを絞り込むことです。そして課題決定とは、絞り込んだ重要な問題点を元に解決すべき課題を決めること。最後の課題解決とは、さまざまなアイデアを出して課題の解決を考える。それが４つのステップです。
---
アイデアを引っ張り出してまとめる、というのはソフトウェアを開発するにおいて、避けては通れない話である。あるアイデアが劇的な速度向上を生んだり、劇的なコスト削減に結びつくこともある。言われたことだけをこなすという意識では、なかなか生き残れない。
もちろん、プログラムを実際に組む時ではなくて、もっと前の企画段階から設計段階までの各段階において、多種多様なアイデアが必要になるのである。逆に言うと、世の中に出回っているソフトウェアを追い抜くために、アイデアを出して、類似ソフトウェアを出し抜く必要がある。
そして、このアイデア出しという概念は、ソフトウェア開発をする会社には決定的に欠けているといっても過言では無い。ソフトウェア開発会社は提案力が弱いとかいろいろ書かれていることがあるが、それもそのはず、仕事を割り当てられたSEやプログラマが、過去の経験や思いつきで提案しているというような状態だからだ。
チームでまとまって、この本にあるような方法論を使ってアイデアを引っ張り出すということを行うと、仕様の抜けも減るし、より高度な提案も可能になるかもしれない。１人ではなかなか思いつかないようなことがチームなら出てきやすい。出てきやすくするための方法論でもある。
また、コミュニケーションツールとしても当然利用可能である。開発における疑問点や問題点も、どう質問したらいいかわからない場合等に、発言を引っ張り出すような使い方も効果的だ。
職業柄、コミュニケーション下手というか、なかなか仕事上の質問もできないというような人も多いのだが、どうコミュニケーションを取るか、というのもアイデア出しの方法論で解決できるのではないだろうか。
こういうのはあんまり学校で習わないので、慣れてない人は最初は思いっきり戸惑うかもしれないが、慣れてくると脳みそが活性化してくるだろう。いろいろ試してみると、チーム全体のレベルアップが簡単に出来るかもしれない。変にセミナーとかに出席させるより、費用対効果が高そうである。
タイトル： アイデアが面白いほど出てくる本―これだけは身につけたい16の手法
---
問題解決には、基本として４つの手順・ステップがあります。「問題設定」、「問題把握」、「課題決定」、「課題解決」の４つです。
問題設定とは、何が問題なのかを明確にして絞り込むことです。次に問題把握とは、問題に関係するさまざまな情報を集めて、問題点を探し出して、解決するべき問題点では何が重要かを絞り込むことです。そして課題決定とは、絞り込んだ重要な問題点を元に解決すべき課題を決めること。最後の課題解決とは、さまざまなアイデアを出して課題の解決を考える。それが４つのステップです。
---
アイデアを引っ張り出してまとめる、というのはソフトウェアを開発するにおいて、避けては通れない話である。あるアイデアが劇的な速度向上を生んだり、劇的なコスト削減に結びつくこともある。言われたことだけをこなすという意識では、なかなか生き残れない。
もちろん、プログラムを実際に組む時ではなくて、もっと前の企画段階から設計段階までの各段階において、多種多様なアイデアが必要になるのである。逆に言うと、世の中に出回っているソフトウェアを追い抜くために、アイデアを出して、類似ソフトウェアを出し抜く必要がある。
そして、このアイデア出しという概念は、ソフトウェア開発をする会社には決定的に欠けているといっても過言では無い。ソフトウェア開発会社は提案力が弱いとかいろいろ書かれていることがあるが、それもそのはず、仕事を割り当てられたSEやプログラマが、過去の経験や思いつきで提案しているというような状態だからだ。
チームでまとまって、この本にあるような方法論を使ってアイデアを引っ張り出すということを行うと、仕様の抜けも減るし、より高度な提案も可能になるかもしれない。１人ではなかなか思いつかないようなことがチームなら出てきやすい。出てきやすくするための方法論でもある。
また、コミュニケーションツールとしても当然利用可能である。開発における疑問点や問題点も、どう質問したらいいかわからない場合等に、発言を引っ張り出すような使い方も効果的だ。
職業柄、コミュニケーション下手というか、なかなか仕事上の質問もできないというような人も多いのだが、どうコミュニケーションを取るか、というのもアイデア出しの方法論で解決できるのではないだろうか。
こういうのはあんまり学校で習わないので、慣れてない人は最初は思いっきり戸惑うかもしれないが、慣れてくると脳みそが活性化してくるだろう。いろいろ試してみると、チーム全体のレベルアップが簡単に出来るかもしれない。変にセミナーとかに出席させるより、費用対効果が高そうである。
ソフトウェア開発業界では括りが粗すぎる
ソフトウェアとは、仕事で使うと限定すると、ほとんどがコンピュータと人がコミュニケーションするための道具であるといえよう。ソフトウェアはコミュニケーションツールなのだ、とここでは言い切ってしまおう。
人と人は会話する。同じ言語で同じ地方にいれば、間に通訳を挟まなくてもまぁだいたいコミュニケーションが取れるだろう。言語が違えば通訳を雇うことになるが、当然のことながら、両者の言語を専門に扱う人が必要になる。
日本語を扱う医者と中国語を扱う医者が会話をする場合、日本語と中国語の通訳ができて、医学の専門用語を知っている人が必要になるということだ。
ソフトウェアは、人とコンピュータをコミュニケーションさせるツールであると冒頭で述べたが、コミュニケーションを円滑に行うためには、同じようにその人（会社）の業務を知っていて、コンピュータをコントロールするための言語が知らないと話にならない。
しかし、ソフトウェア開発業界というのは、コンピュータ用の言語には詳しいが、業務知識の方はさっぱりというお寒い状態でもなんとかなっているのが現状である。
なぜそうなるのかというと、「ソフトウェア開発業界」といつまでも一括りだからである。業種が違えばソフトウェア開発内容も全く異なる。仕様の漏れがなくならないのは、業種によるノウハウの蓄積も何もなく、別の会社がまた１から考えるからである。
違うことをやっているのに、ソフトウェア開発というグルーピングですませてしまっていることが大問題なのだ。ソフトウェア開発会社毎に何かの業種に特化する必要はないが、せめて業種毎にノウハウを共有できる体制にしないと、よりよいものをより安く提供することはないだろう。
今はどの会社がどの業種に強いのかすら、誰もわからない。わからないから大手ベンダーに相談してしまい、大手ベンダーでは自社で対応できないと、下請けに出すしかない。そんな業界構造は21世紀には似合わない。
人と人は会話する。同じ言語で同じ地方にいれば、間に通訳を挟まなくてもまぁだいたいコミュニケーションが取れるだろう。言語が違えば通訳を雇うことになるが、当然のことながら、両者の言語を専門に扱う人が必要になる。
日本語を扱う医者と中国語を扱う医者が会話をする場合、日本語と中国語の通訳ができて、医学の専門用語を知っている人が必要になるということだ。
ソフトウェアは、人とコンピュータをコミュニケーションさせるツールであると冒頭で述べたが、コミュニケーションを円滑に行うためには、同じようにその人（会社）の業務を知っていて、コンピュータをコントロールするための言語が知らないと話にならない。
しかし、ソフトウェア開発業界というのは、コンピュータ用の言語には詳しいが、業務知識の方はさっぱりというお寒い状態でもなんとかなっているのが現状である。
なぜそうなるのかというと、「ソフトウェア開発業界」といつまでも一括りだからである。業種が違えばソフトウェア開発内容も全く異なる。仕様の漏れがなくならないのは、業種によるノウハウの蓄積も何もなく、別の会社がまた１から考えるからである。
違うことをやっているのに、ソフトウェア開発というグルーピングですませてしまっていることが大問題なのだ。ソフトウェア開発会社毎に何かの業種に特化する必要はないが、せめて業種毎にノウハウを共有できる体制にしないと、よりよいものをより安く提供することはないだろう。
今はどの会社がどの業種に強いのかすら、誰もわからない。わからないから大手ベンダーに相談してしまい、大手ベンダーでは自社で対応できないと、下請けに出すしかない。そんな業界構造は21世紀には似合わない。
仕様書にやらないことを書かないから後で喧嘩になる
どんなソフトウェアを作るのか、を紙にしたものが仕様書である。一般的には顧客がソフトウェア開発会社側に示すものが仕様書であるが、現実的に中小企業では顧客側が書くことはほとんどなく、ソフトウェア開発会社側が仕様書を書くところから参加している。
要は自分で作るものを自分で決めているわけだが、仕様書作成過程において、顧客と何を作るかについて延々と話し合う事になる。この時点（まだ何を作るのかすら決まってない時点）で、予算と納期が決まっている事がよくある。
予算と納期が決まっているということは、仕様を作成する段階で、仕様から落とす項目が当然出てくる。「今回はこの機能はやめておきましょう」とかなんとか言って、顧客も「予算的に無理ということであれば、稼働してから考えましょう」と同意する。
ところが、予算と納期に合わせていい感じに仕様が決まり、いざ開発となって中盤から終盤に差し掛かった頃、急に顧客の偉い人が「この機能が足りないと使い物にならない」とか言い始めるのである。
ここで、「仕様書に書いてないじゃないですか！」と言っても、「この機能は必須である。仕様書から抜け落ちているのはそちらの不備である」とか言いかねない。さすがにそこまで責任転嫁するところはないと思いたいが、少なくとも顧客側は不満に思うだろう。不満はそのうち別の所で爆発したりするので無いに越した事は無い。
問題は、落とした項目について営業担当者レベルでは同意していても、仕様書には一切「今回やらないこと」として記載されていないということだ。書いてあっても機能追加になりそうな気もするが、その場合は顧客側の責任ということで、金額と納期の交渉は出来るだろう。
やらないことを書いたほうがいいと言うと、膨大になるから無理という議論になりそうだが、そうでもない。予算と時間があれば追加したい機能一覧と思えば、書きやすいのではないだろうか。
そういう意味では、最初から予算と時間に合わせて仕様を決める前に、一回り大きな仕様を用意して、そのうちこの部分を今回のシステム化範囲とする、としたほうが後々の仕事にも繋がるのではないだろうか。
書いてあることを全部満たすようにソフトウェアを作るという前提だと、とにかく俎上に載せたものは全部作らなければならないという感覚に陥りやすくなってしまう。
顧客も最後になって、今言わないともう作ってもらえない！と思うと機能を追加したくなるので、そういう心理に追い込まないことが結果的に予算も納期も守れることに繋がるのではないかと思う。
技術的に遜色ないなら、あとは心理戦である。同じ作るならどういうアプローチにすれば効果的かを考えていかないと、無駄に損をしてしまう。仕事を円滑にするためのパターンというのが、プログラマにはもっと必要なのかもしれない。
要は自分で作るものを自分で決めているわけだが、仕様書作成過程において、顧客と何を作るかについて延々と話し合う事になる。この時点（まだ何を作るのかすら決まってない時点）で、予算と納期が決まっている事がよくある。
予算と納期が決まっているということは、仕様を作成する段階で、仕様から落とす項目が当然出てくる。「今回はこの機能はやめておきましょう」とかなんとか言って、顧客も「予算的に無理ということであれば、稼働してから考えましょう」と同意する。
ところが、予算と納期に合わせていい感じに仕様が決まり、いざ開発となって中盤から終盤に差し掛かった頃、急に顧客の偉い人が「この機能が足りないと使い物にならない」とか言い始めるのである。
ここで、「仕様書に書いてないじゃないですか！」と言っても、「この機能は必須である。仕様書から抜け落ちているのはそちらの不備である」とか言いかねない。さすがにそこまで責任転嫁するところはないと思いたいが、少なくとも顧客側は不満に思うだろう。不満はそのうち別の所で爆発したりするので無いに越した事は無い。
問題は、落とした項目について営業担当者レベルでは同意していても、仕様書には一切「今回やらないこと」として記載されていないということだ。書いてあっても機能追加になりそうな気もするが、その場合は顧客側の責任ということで、金額と納期の交渉は出来るだろう。
やらないことを書いたほうがいいと言うと、膨大になるから無理という議論になりそうだが、そうでもない。予算と時間があれば追加したい機能一覧と思えば、書きやすいのではないだろうか。
そういう意味では、最初から予算と時間に合わせて仕様を決める前に、一回り大きな仕様を用意して、そのうちこの部分を今回のシステム化範囲とする、としたほうが後々の仕事にも繋がるのではないだろうか。
書いてあることを全部満たすようにソフトウェアを作るという前提だと、とにかく俎上に載せたものは全部作らなければならないという感覚に陥りやすくなってしまう。
顧客も最後になって、今言わないともう作ってもらえない！と思うと機能を追加したくなるので、そういう心理に追い込まないことが結果的に予算も納期も守れることに繋がるのではないかと思う。
技術的に遜色ないなら、あとは心理戦である。同じ作るならどういうアプローチにすれば効果的かを考えていかないと、無駄に損をしてしまう。仕事を円滑にするためのパターンというのが、プログラマにはもっと必要なのかもしれない。
プログラムが設計書だとすると設計という工程はプログラミングになるはずだが？
最近のソフトウェア開発業界の風潮で、プログラムは設計書であり、プログラミングは設計工程という考え方がある。
今までは、プログラマがブルーカラー、いわゆる製造業でいうところのライン作業者みたいなイメージが蔓延していた。製造工程なんだから、部品を作り上げるまでの時間は的確に見積もれるし、完成までのスケジュールも把握できるという考え方だ。
プログラミング作業は製造工程だとすると、その上に設計工程が存在するはずである。ソフトウェア開発には、一般的にプログラム開発チームと設計チームが分かれていて、設計チームが設計書（非プログラム）を書き上げてプログラマに渡すのである。
ここでハードウェアの世界を見ると、ハードウェアでは設計者とライン作業者は完全に分断されている。設計者が設計書を書いて、工場に渡す（正確には直接ではないが）というのが一般的なのだと思う。
設計書（図）というものは、その通り作れば確実に動くという状態になっているはずのものである。なぜ矛盾がないと言えるかというと、実際に作って試したり、実際に作れない場合はミニチュアを作ったりして、試すからである。実際に作って試して問題なく動くことがわかってから、設計書を作るのである。
それでもハードウェアの場合、実物の部品というのは精度の誤差が積み重なって動かなかったりする。電子部品の場合は部品の質にばらつきがあることもある。それを最後のテストでチェックするということになる。
ところが、ソフトウェアは大きく異なる。プログラマに渡される設計書というのは、精度の差こそあれ矛盾無く記述されているということはない。なぜか？
逆説的に言えば、プログラムが最終的な設計書なので、プログラム以外の設計書が矛盾無く書かれていることはありえないということになる。矛盾がない非プログラムな設計書は、自動でプログラムに変換可能である。
さて、非プログラムな設計書は曖昧（何かが欠けているか矛盾がある）だとすると、ソフトウェアにおける非プログラマである設計者の存在とはなんなのだろうか。
プログラムはわからくても、設計はできるというような話をたまに耳にするが、設計という言葉の定義が少し異なるのだろう。最終的な設計書はプログラムだとすると、プログラムを見て検証しない限り、設計上正しいかどうかは解らないはずだが、それを無視してテストに頼っていたのが現状ではないだろうか。
ソフトウェア開発における設計者とプログラマの分離の弊害を指摘したのが、XPやスクラム等のアジャイル開発手法である。設計者という曖昧な存在を排除して、プログラマが設計してプログラマがプログラムを書くという、いたってシンプルな考え方だ。
ソフトウェア開発業界は、他業界のモデルをそのまま引っ張ってくるのではなくて、もう少しソフトウェアの持つ特性を意識した開発モデルを考えないといけないのではないだろうか。
今までは、プログラマがブルーカラー、いわゆる製造業でいうところのライン作業者みたいなイメージが蔓延していた。製造工程なんだから、部品を作り上げるまでの時間は的確に見積もれるし、完成までのスケジュールも把握できるという考え方だ。
プログラミング作業は製造工程だとすると、その上に設計工程が存在するはずである。ソフトウェア開発には、一般的にプログラム開発チームと設計チームが分かれていて、設計チームが設計書（非プログラム）を書き上げてプログラマに渡すのである。
ここでハードウェアの世界を見ると、ハードウェアでは設計者とライン作業者は完全に分断されている。設計者が設計書を書いて、工場に渡す（正確には直接ではないが）というのが一般的なのだと思う。
設計書（図）というものは、その通り作れば確実に動くという状態になっているはずのものである。なぜ矛盾がないと言えるかというと、実際に作って試したり、実際に作れない場合はミニチュアを作ったりして、試すからである。実際に作って試して問題なく動くことがわかってから、設計書を作るのである。
それでもハードウェアの場合、実物の部品というのは精度の誤差が積み重なって動かなかったりする。電子部品の場合は部品の質にばらつきがあることもある。それを最後のテストでチェックするということになる。
ところが、ソフトウェアは大きく異なる。プログラマに渡される設計書というのは、精度の差こそあれ矛盾無く記述されているということはない。なぜか？
逆説的に言えば、プログラムが最終的な設計書なので、プログラム以外の設計書が矛盾無く書かれていることはありえないということになる。矛盾がない非プログラムな設計書は、自動でプログラムに変換可能である。
さて、非プログラムな設計書は曖昧（何かが欠けているか矛盾がある）だとすると、ソフトウェアにおける非プログラマである設計者の存在とはなんなのだろうか。
プログラムはわからくても、設計はできるというような話をたまに耳にするが、設計という言葉の定義が少し異なるのだろう。最終的な設計書はプログラムだとすると、プログラムを見て検証しない限り、設計上正しいかどうかは解らないはずだが、それを無視してテストに頼っていたのが現状ではないだろうか。
ソフトウェア開発における設計者とプログラマの分離の弊害を指摘したのが、XPやスクラム等のアジャイル開発手法である。設計者という曖昧な存在を排除して、プログラマが設計してプログラマがプログラムを書くという、いたってシンプルな考え方だ。
ソフトウェア開発業界は、他業界のモデルをそのまま引っ張ってくるのではなくて、もう少しソフトウェアの持つ特性を意識した開発モデルを考えないといけないのではないだろうか。
ソフトウェア開発会社の生きる道
PM見習いの読書日記 ソフトウェアの値段 より
--
ただ、ソフトウェア開発専業のベンダーとしては、
・誠実に仕事をすることを約束して、かかった分の費用を請求する（人月清算ってことですね）
・あいまいな仕様書からの見積もり精度を高めて、一括で受注する
という選択肢しか残らないのかな？
--
ソフトウェア開発専業ベンダーというのは、営業や企画やマーケティングを他社に依存した会社のことだとすると、会社としては売るための仕組みが備わっていないので、口コミや誰か（ほとんど社長）のトップセールスで仕事を取ってくるような場合がほとんどではないだろうか。
とすると、いくら高尚なことを口にしようとも、やりたくない仕事でも引き受けざるを得ない。得意分野だけで勝負したくても、そもそも仕事選べないのであれば、毎回業務も異なり客も異なり開発言語も異なりコスト見積の算出方法も相手に合わせて用意する必要があるということだ。
そのような状態では、会社としての特徴はもちようがない。ソフトウェア開発業界が俗人的で、仕事は会社ではなくて人につくとなるのも当然の結果である。会社としての特徴を持つということはどの仕事を受けてどの仕事を断るのかはっきりさせるということだ。
なので、アジャイル的にかかった分だけのコストを請求していいのかどうか、という以前に、どうやって仕事取って来るのか、営業をどうするのか、である。営業をどうするのかを決めるには、どこに集中するのかである。
「Javaできます」は「英語できます」と同じぐらい、顧客から見ると意味が無くて、それは個人のスキルの宣伝でしかない。そんな宣伝をしている会社は、「弊社の社員をお貸ししますので使ってやってください」と暗に言っているということだ。
顧客は何を望むのか？「どうやったら利益がでるか（経費が減るか／売上が増えるか）」である。そのために「御社のこの部分をこうするとこれくらい利益がでます（経費が減ります／売上が増えます）」と言える何かが会社にないといけない。
そして、顧客に提案した内容の一部分がソフトウェアなのである。自ら提案するから、自分の会社の得意分野で勝負できて、開発言語も自前で選択でき、最適化することが可能なのである。ここまでこないと技術がコストダウンに結びつかない。
ソフトウェア開発会社は、顧客の仕様に合わせて作り、最終的に顧客の著作物となってしまう仕事ばかりしているのではないか。お金を貰っても自社には何も残らない仕事ばかりしてきていないだろうか。
プログラマは誰の金で仕事をしているのかわからなくなるのである。受託開発ならほとんどが顧客の金である。自社で働いているのではなく、顧客の会社で働いているようなものである。
会社は少しの間儲かるが、プログラマの磨り減り具合を考えると、本当にそのやりかたでいいのかどうかは疑問である。本当にいい仕事をしようと思ったら、自社にプログラム資産が蓄積されていき、どんどん仕事の質をあげていけるような、そんな状態にしないと、この先続けていくのは難しいのではないだろうか。
プログラマのやったことが蓄積されていき、その中からまた新しいものが生まれていく、というような好循環になってこそ、コストダウンにつながり、ソフトウェア開発専業会社として社会に貢献できるのではないかなという気がする。
--
ただ、ソフトウェア開発専業のベンダーとしては、
・誠実に仕事をすることを約束して、かかった分の費用を請求する（人月清算ってことですね）
・あいまいな仕様書からの見積もり精度を高めて、一括で受注する
という選択肢しか残らないのかな？
--
ソフトウェア開発専業ベンダーというのは、営業や企画やマーケティングを他社に依存した会社のことだとすると、会社としては売るための仕組みが備わっていないので、口コミや誰か（ほとんど社長）のトップセールスで仕事を取ってくるような場合がほとんどではないだろうか。
とすると、いくら高尚なことを口にしようとも、やりたくない仕事でも引き受けざるを得ない。得意分野だけで勝負したくても、そもそも仕事選べないのであれば、毎回業務も異なり客も異なり開発言語も異なりコスト見積の算出方法も相手に合わせて用意する必要があるということだ。
そのような状態では、会社としての特徴はもちようがない。ソフトウェア開発業界が俗人的で、仕事は会社ではなくて人につくとなるのも当然の結果である。会社としての特徴を持つということはどの仕事を受けてどの仕事を断るのかはっきりさせるということだ。
なので、アジャイル的にかかった分だけのコストを請求していいのかどうか、という以前に、どうやって仕事取って来るのか、営業をどうするのか、である。営業をどうするのかを決めるには、どこに集中するのかである。
「Javaできます」は「英語できます」と同じぐらい、顧客から見ると意味が無くて、それは個人のスキルの宣伝でしかない。そんな宣伝をしている会社は、「弊社の社員をお貸ししますので使ってやってください」と暗に言っているということだ。
顧客は何を望むのか？「どうやったら利益がでるか（経費が減るか／売上が増えるか）」である。そのために「御社のこの部分をこうするとこれくらい利益がでます（経費が減ります／売上が増えます）」と言える何かが会社にないといけない。
そして、顧客に提案した内容の一部分がソフトウェアなのである。自ら提案するから、自分の会社の得意分野で勝負できて、開発言語も自前で選択でき、最適化することが可能なのである。ここまでこないと技術がコストダウンに結びつかない。
ソフトウェア開発会社は、顧客の仕様に合わせて作り、最終的に顧客の著作物となってしまう仕事ばかりしているのではないか。お金を貰っても自社には何も残らない仕事ばかりしてきていないだろうか。
プログラマは誰の金で仕事をしているのかわからなくなるのである。受託開発ならほとんどが顧客の金である。自社で働いているのではなく、顧客の会社で働いているようなものである。
会社は少しの間儲かるが、プログラマの磨り減り具合を考えると、本当にそのやりかたでいいのかどうかは疑問である。本当にいい仕事をしようと思ったら、自社にプログラム資産が蓄積されていき、どんどん仕事の質をあげていけるような、そんな状態にしないと、この先続けていくのは難しいのではないだろうか。
プログラマのやったことが蓄積されていき、その中からまた新しいものが生まれていく、というような好循環になってこそ、コストダウンにつながり、ソフトウェア開発専業会社として社会に貢献できるのではないかなという気がする。