第24話 マネージャの憂うつ
今年ももう2カ月が過ぎようとしています。早いですね（年だから？）。こちらのコラムは更新自体が久しぶり過ぎて、「はじめまして」と言っても通用するんじゃないかとさえ思います。
あ、そんな中でもちょこちょこ古い記事にコメントをくださってありがとうございます。返信はできませんでしたが、よかったらまたよろしくお願いします（あんまり前のだと覚えていなくて返事をしないことの方が多いです）。
近況ですが、仕事自体はそんなに忙しいわけではありません（ヒマではありませんが）。ネタもそれなりにあるのですが、プライベートがちょっと忙しくて、なかなかこちらのコラムまで手が回りませんでした。よそで執筆してたりしますが、こちらは仕事でした（会社外ですが）。もっとも、ITやエンジニアの類ではないので、特に宣伝などはしません（興味ないでしょうし）。
■されどPM
仕事上では私はPMなのですが、エンジニアライフのコラムを読んでいると、PMはどちらかと言えばエンジニアの「敵」扱いされていることが多い気がします（フィクション含む）。まぁ、それなりに経験だとか年齢が離れているというせいもあってか、PMに上から頭ごなしに何か言われれば、そう感じてしまうこともあるとは思います。個人的には、上司なんてそんなもんだと思っていますが、私の若いころを考えてみれば、その気持ちは十分理解できます。
私もいろいろなPMと仕事をしましたが、どちらかと言えば、神経質な雰囲気を漂わせる人が多かったと感じます。特に、プロジェクトが遅れていると、非常にピリピリムードになって、話し掛けられない感じとか。ただ、時々すごく大ざっぱ（に見えた）な人もいました。いつも「何とかなるか」って笑ってた人や、見た目や話し方が居酒屋の大将っぽかった人もいました。ただ、不思議なことに、神経質な人よりはそうでないPMの方が、案外スムーズにプロジェクトが進行しているように思います。
私のように「成りゆき」でPMになる人はあまりいないと思います。エンジニアでたたき上げでPMっていうのも、おそらく少ないと思います（いるとは思いますが）。特に大企業なんかはそうですが、基本的に「将来はPM候補だ」と思われる新人が入ってくると、少しだけプログラミングを経験し、そこから少しずつ設計をして経験を積み、徐々にPMになるための教育なんか受けて……というのが多いと思います。会社の規模が大きいと、キャリアパスの形成がしっかりとしています。
エンジニアとして就職した人は、PMのような管理職じゃなく、SEやリーダーとして、できれば現場でずっとプログラミングに携わっていたいという人が多いのかもしれません。私の同僚でも、現役エンジニアにこだわって転職した人が何人もいますし。
私も、できれば毎日楽しくプログラミングしていられれば良かったなぁ、と思っているクチですが、まぁそこはサラリーマンの宿命で（家族もいるし）、そうそう拒否も退職もできないので、自分なりにマネジメントしてます。
今回は、私の実体験を通して、PMの大変さを少しでも理解してもらえればと思います（誤解されてしまう可能性も否定できませんが）。
■権限と責任
PMは通常「プロジェクトマネージャ」を指しますが、私の会社はSIerではなくソフトハウスなので、プロジェクトというよりは製品単位でマネージャが存在します。そういう意味では「プロダクトマネージャ（製品管理者）」と言った方がピンと来るのですが、まぁ、やること自体はそんなに変わりません（おそらく）。
SIerと違うのは、特定の顧客（ターゲット）がいないことです。そのため、実装する機能に対する要望は、営業（販売店）を通したお客様の意見や、既存ユーザーの要望やクレームがメインとなります。
うちの会社の場合、PMの権限はかなり強いです。新製品の企画を出すこともありますが、会社から決められる事は基本的に「ソフトウェアの種類とターゲット」だけです。種類とは例えば「ワープロ」や「表計算」みたいな感じです。ターゲットは個人か企業か開発ツールかなどです。それ以外についてはほぼPMが決定します。具体的には機能やプラットフォーム（とは言ってもほぼWindowsですが）、値段、スケジュールなどです。中堅以上のSIerと異なり、メンバーはまず10名以下です。他の製品も絡んでくることはありますが、1人で管理するにはまぁ、問題ないレベルだと思います。
開発言語（環境）もほぼ自由です。極端な話、Excelのマクロ（VBA）だって構いません。C/C++だろうが、VBだろうが、Javaだろうが、どれでも特におとがめはないですが、あまり変なものだとツッコミは入ります。上司（役員）に必要性みたいなものを説明できないとさすがに却下されますが、そういうことはまれです。
機能に関しては、初期バージョンはゼロベースから、バージョンアップ時はお客様の意見や営業の要望などです。時には上司から命令に近いものもありますが（他社で同じようなソフトがあった場合、そちらに実装されている目玉みたいな機能は入れろとよく言われます）、無理なものは無理なので、できそうなものをチョイスしながら決定します。この辺はSIerよりもかなり自由なので、結構気楽だと思います。
こういう環境だと、一見ストレスがないように見えませんか？
いやいや、権限があるということは、それに比例して「責任」が生じます。重大なバグの発生やリリース日が予定より遅延したりすると当然、責任を取ります。場合によってはいくらか罰金を給与（賞与）から引かれます。もっとも、逆にかなり予想より売り上げが上がると金一封がもらえます。売れないと営業からかなり突き上げられますし（モノが良くないと言われる）、売り上げ計画も立てるのですが、それが未達成だとやっぱり小言を言われます（さすがに罰金はないですが）。
SIerのPMとは規模も役割も若干違うとは思いますが、そうは言ってもやはり権限と責任がそれなりにあることは間違いないと思います。
■誰が悪い？
私のプロジェクトではまずないですが、プロジェクトが遅延した場合、誰が悪いと思いますか？ 実際の作業では、どこかが何らかの理由で遅れるのですが、責任という意味では当事者ではなくPMにあります。
PMはプロジェクトを円滑に進めるためにマネジメントする立場だからで、本来は遅れそうな部分を事前に見つけてリカバリ（あるいはリカバリを考える）を求められる立場です。時には不可抗力なこともあるでしょうが、大概が人災なので、日々の管理は大切だと思います。
ただ、PMも人間なので、遅れているメンバーに対しては正直、「ちゃんとやれや！（怒）」と心の中で責任転嫁していることが多いと思います（それぐらいは許して）。中には本当に責任転嫁しちゃう人もいますが、それはPMとしては失格です。
■基本は信用しない
どこかのプロ野球チームの監督も言っていた気がしますが、私はプロジェクトメンバーに関しては「信頼はしても信用はしない」です。当然、仕事上の話であって、人間的に信用しないわけではないです。
世の中にはいろいろなプロジェクト管理の手法や考え方があります。当然、私も本ぐらいは読んでいますし（教育は受けたことがないですが）、スケジュールもフェイズを区切って、プロジェクト管理ツールも使用しています。でも、それでプロジェクトが順調に進むなら苦労はしません。机上論だけではおそらくダメだと思います。
メンバーは定期的に進捗報告しますが、私は基本的にそれをナナメに読んで、あまり信用しません。むしろ毎日メンバーが出勤する前に前日にコミットされたソースやその差分なんかをチェックします。これがおそらく、一番確実だと思うからです。
メンバーのソースで気になるところやあまり進んでいないと、必ず朝のうちに直接話を聞きます。この時、スケジュールありきで話をするのではなく、エンジニア目線で話をすると、意外と納得してくれます。あとは、ソースレベルでチェックしていることが浸透すると、いい加減なコードや進捗報告を書かなくなります。逆に、私の書いたコード（前にも書きましたが、人的都合で兼業PMなので設計もプログラミングもテストも参加しています）も他の人がチェックしているので、時々突っ込まれたりします。
「信用しない」というのは言い過ぎかもしれませんが、仕事なので、ある程度緊張感を持ってやることは必要だと考えてます。なぁなぁでもなく、ピリピリでもなく、ある程度「管理」しているということを認識してもらえるように常に考えています。
■役割を考える
私はSE、PG、テスターという一般的な分け方は今どきナンセンスだと思っています。ウォーターフォールがどうとかアジャイルがどうとかではないのですが、フェイズごとに役割を割り当てると、エンジニアはなかなか全体が見えにくくなってしまいます。そのため、私のプロジェクトでは程度の差はあれ、基本的に1人が1つのモジュールに対して設計・実装・テストを行うように割り振ります（ただし、最終的な結合・総合テストはまた違う人を割り当てることはありますが）。
そうすると、エンジニアのスキルが、ある程度平均化していきます。自分で設計や実装するからと言って好き勝手すると、他のところでも影響が出る可能性があるので、他のエンジニアからチェックが入ったり、他の人のソースを参考にしたりするようになります。
■無駄なことはしない、させない
仕様書って、どの程度作ってますか？ SIerとかだと、仕様書は納品物の1つなので、状況によっては「お金をもらう」ための仕様書（＝あんまり役に立たない、取りあえずこういう設計したという証拠みたいなもの）が結構あると思います。
最初はいいのですが、プロジェクトが段々大詰めになってトラブルとか遅延とか出てくると、仕様書は段々メンテナンスされなくなっていくことも多いと思います。私も経験上、「後々役に立たない仕様書だなぁ」と思ったことは何度もありました。
私のプロジェクトの場合、基本的に「1機能：1～2ページ」が基本です。画面遷移などは、なかなかそれで収まらないことも多いですが、あんまり細かいことまでは記述しない場合が多いです。仕様書で、ある程度の動作や機能が把握できれば、後はソースコードを追う方が早いので、そこが基本線です。
もっとも、ソフトハウスだからこそできると思うのですが、分厚いドキュメント作っても、後から見るのもメンテナンスするのも大変なので結局、細かい変更はプログラムだけで完結させることも多々あります。それが積み重なると、だんだん仕様書の意味がなくなってしまうので、それだけは避けようと考えています。全員が他人のソースコードを追うクセがついているので、コメントの書き方も意外とうまいです。多過ぎず、少な過ぎず、です。
ドキュメントに時間を費やすより、プログラムを作って考える時間を増やした方が最終的には早いですし、何かあると結局プログラムを追いかけた方が効率が良いです。使われなくなる（使えない）ドキュメントを作るなら作らない方がマシだと、私は考えています（それじゃまずいので適当に自分でメンテナンスはしますが）。
■意外と気を使ってマス
スケジュールはあってなきもの、なんて感じで、実際は予定どおりにいかないことも多いです。ですが、基本的にメンバーに責任を押し付けたりはしないようにしています。予定どおりにいかないと分かれば、負荷分散するようにして（そういう時はたいてい私自身がフォローしていますが）、怒ったり責めたりせず（時々、すごく腹が立つこともありますが）なるべく優しくするように気を付けています（今どきは怒鳴ってもあんまり効果なさそうですし）。
あと、なるべく残業や休日出勤はさせないようにします。そもそもダラダラやってたら、能率だって集中力だって続くわけないですし。だったらオンタイムに集中して、終わったら帰った方が絶対にいいです。エンジニアの中には、残業や休出が自慢みたいな人もいますが、そんなの「私は時間内で仕事が終われない無能です」と言っているようなものです。それだからか、うちのメンバーは昼休み以外ほとんど休憩しません。そして定時後、1時間以内にはほぼ全員帰宅します。
ちなみに私は率先して定時に帰ります（その分、早く出社しますが）。上司や先輩がいたらやっぱり帰りづらいでしょ？ それを言い訳にされるのもイヤなので、会議やお客様との約束がなければさっさと帰ります。
プロジェクトってなかなか理屈だけではうまくマネジメントできないなぁ、といつも感じます。計画や手法、管理よりも、しょせんメンバーが協力してくれないと絶対にうまくいかないので、なるべく気持ちよく仕事を進めてもらえるよう考えています。
とは言っても、やっぱりPMってうざいんだろうなぁ……（涙）。
何かの縁があって私のプロジェクトに入った場合は、快く協力してください。
コメント
ハムレット
はじめまして。
にゃん太郎さん>仕様書って、どの程度作ってますか？
とりあえず、SIer ですと、プログラムとして正しく動くかと云う基準と、作ったプログラムが役に立つか、と云う２つの基準があるので、そういう意味で仕様書は必要だと思います。
確かにメンテナンスが難しいので、あくまで開発開始時にお互い納得して決めたシステムの在り方程度の意味で良いかなと思います。
多分、途中でメンテナンスするのはナンセンスで、検収・納品後に実情に合わせて修正するか。（マニュアル作成のついでに）更改時に関連する部分だけメンテナンスするかって感じでしょうか。
個人的にはSIの場合は仕様書よりも分析図の方が価値のあるドキュメントだと思っています。（客先のAS IS を明確にすると云う意味で）ただシステム分析をちゃんと出来るSEって少ないんですよね。プログラマとはまた違った視点を要求されるからでしょうか。どちらかといえば結合テスト、統合テストの設計に似通っているかもしれません。
にゃん太郎さん> あと、なるべく残業や休日出勤はさせないようにします。そもそもダラダラやってたら、能率だって集中力だって続くわけないですし。
にゃん太郎さん> ちなみに私は率先して定時に帰ります。
何と羨ましいことか。・・・・
にゃん太郎
ハムレットさん、コメントありがとうございます。
> 多分、途中でメンテナンスするのはナンセンスで、検収・納品後に実情に合わせて
> 修正するか。
これは難しい問題だと思います。漏れなく後から確認出来るかがポイントだと思いますが、私自身はドキュメントに修正を入れてからプログラムを修正します。メンバーには共用フォルダを用意しておき、そこに各自の名前のテキストファイルを作らせておき、修正時にメモを残すように指導しています。
SIerでないソフトハウスなのでそこは比較的自由だから出来るんだとも思いますが。なかなか現場によっては難しいでしょうね。それは分かります。
> 何と羨ましいことか。
まぁ、確かに客先常駐だとお客様の目もありますからね。どこでも、という訳にはいきませんでしょうね（私も経験はあります）。ただ、そういう時でも私はあんまり残業はしてませんでしたが（笑）
インドリ
お久しぶりです。私も同意見です。
この問題の根源は、言葉にあるかと思います。
英語のmanageは、「物事、特に困難を伴う事を何とか...する」という意味であり、そこから派生して色々な意味を持ちます。
しかし日本のマネージは、「責任者あるいは支配者」だけであり、そこから多くの組織的誤りが生じているかと思います。
私はアジャイルを推進している事もあり、よく「管理者はどうすればいいのか？」と聞かれます。
その時私は本来の英語の意味から「プロジェクトを開発者に何とかしてもらえるように環境の整備をする人と思えばいい」と答えています。
日本の管理者は、実現不可能な完璧なシステムを求めて責任者として口うるさくするしかない事が多いです。
しかし、英語の本来の意味をよく考えれば、その様な狭い視野ではなく広い世界があります。
それを理解すれば、PMも開発者も楽になります。
狭い範囲でしか「管理」を考えていないから苦しむのだと私は考えています。
マネージャは和製英語と日本の環境的組織構造の犠牲者だと思います。
にゃん太郎
インドリさん、コメントありがとうございます。
おっしゃる通りで、人だけを管理してもなかなかうまく進まないと思います。自分のやり方を押し通したり、進捗の遅れだけを気にしたりしても相手は人間なのでいつも自分の思う通りになるとは限りません（って言うか、ならない事の方が多い）円滑に進めたいなら、実際の作業内容をきちんと把握して注意するなら感情論ではなく、論理立てて一緒になって問題解決を考えるべきです。
マネージャなんて、エンジニアをおだてながら気持ちよく仕事が出来るように最小限の干渉と最大限の意見の尊重をしていけば割合うまく行きますし、時にはケンカ腰で議論すればそれなりにガス抜きになると思います。大切なのは「やらされている感」ではなく、「自分からやっている感」になるように仕向ける事です。自分がイライラして雰囲気を悪くしても何の得にも足しにもなりません。
まぁ、そうそううまく行けば苦労しなんでしょうが心がけだけは忘れないようにいつも気を付けてます。
みながわけんじ
前回のにゃん太郎さんの辛口コラム、好きでした。
今回のコラムはにゃん太郎さんらしくなく、「朝来てメンバーのソースの差分をチェックする」・・・せこいことやってるのかあ・・・なんて思っちゃいました。当然わたしもソフトウェアハウスの管理者ならば、そのくらいやるかな？？？それは確実なんですが、自分は若い時代、気分が載ってるときに一気にやって、そうでないときは、コメント入れたり、醜いコードを書きなおしていました。結局はメンバーに公正な評価をし、今の時代ですと、それなりに評価に基づいて査定するような会社の体制、仕組みが整っていることが重要だと思います。
OS/2 は３人ぐらいで作ったOSだという話もありますし、WindowsNTはPM自らカーネルを書いたという話もあります。LINUXのトーバルトもしかりで、世界でトップのプロダクトというものは、近代日本のプロジェクト体制というよりも、毛利元就の「3本の矢」のような上も下もない賢人のチームワークで生産されているような気がします。
仕様書ですが、社内SEは業務アプリケーションを扱うことがほとんどのケースで、さらにRDBMSを使うのがほとんどなケースです。これは外部業者委託で開発する場合も内製開発する場合も同じです。
●仕様書がなくてもいいんじゃないの？というケースはデータベースの項目名が会社で使っている業務用語そのままの場合。
●仕様書がいるのは、R/3のABAPプログラムで、パッケージであるから、テーブル仕様や項目名が社内で使っている業務用語と違うケースです。何万というテーブルがある大規模なものですから、プログラムの仕様書にどのテーブルのどの項目を抽出しているか書いてもらわないと保守不可能になります。
にゃん太郎さんは、開発効率がいいフレームワークというものに対し、自由なコーディングできなくなるという観点で嫌悪感があるみたいですが、少人数の開発体制のほうが管理が楽なので、そのようなフレームワークを使うとか作るとかは考えないのですか？ フレームワークを使って開発効率を上げる部分と、自由なコーディングをするために、フレームワークを使わない部分が混在しているハイブリッド型の開発など、いろいろ手はあると思いますが・・・
最後に、にゃん太郎さんの会社では、コードを見れば仕様はわかるそうですが、UML書いてますか？ １０行の共通ロジックを書くのに、staticメソッドを使う人と、クラスのコンストラクタにロジックを書いてメンバー変数で結果を返す人がいると思います。どうしたらいいんでしょうかねえ・・・
にゃん太郎
みながわけんじさん、コメントありがとうございます。
本人は辛口って意識はないんですけどねぇ。
> 「朝来てメンバーのソースの差分をチェックする」・・・せこいことやってるのかあ・・・
> なんて思っちゃいました。
まぁ、責任がありますからね。どうやって進捗具合をチェックするかを考えた場合、現状のウチではこれが多分確実なので。せこかろうがなんだろうが、デスマーチになったり品質が悪かったりリリース日が遅延したりして責任取らされるよりはマシです。これはこの立場じゃないとわかりづらいと思いますが。
> 結局はメンバーに公正な評価をし、今の時代ですと、それなりに評価に基づいて査定する
> ような会社の体制、仕組みが整っていることが重要だと思います。
次のコラムのネタなのですが、会社なんて公正な評価は基本的にしないと思ってます。まぁ、何を持って公正かっていうのも実はあいまいですが。私が経営者だった時もそうですが、エンジニア（技術者）をスキルありきで評価しても実は業務はなかなかうまく回りません。ある程度は考慮しますが、評価の基準なんて技術者でも事務でも営業でも基本的には同じです（これが良いか悪いかは別問題ですよ）
> 開発効率がいいフレームワークというものに対し、自由なコーディングできなくなると
> いう観点で嫌悪感があるみたいですが
嫌悪感は別にないですよ。使ってないかと言われれば使ってますし。今の時代、全然使わずにっていうのも難しいでしょうし、便利なのは理解しています。ただ、中身が見えないのは気持ち悪いっていうのがあるだけです。ソフトウェアのブラックボックスは基本的に信用できないので、トラブルがあった時にどこが悪いか調べるにはある程度中身を知っていないと時間がかかるしなぁ...っていうだけです。個人的にはそれでよく嬉々として（おおげさ？）使えるなぁと思うだけです。作っているソフトウェアの都合上、フレームワークを自作してもなかなか使いまわしが利かないので作ることはマレです（せいぜい共通ライブラリぐらい）
> どうしたらいいんでしょうかねえ・・・
コンシュマー向けのソフトウェアというのは実は機能や速度が優先なので、ソースがキレイかどうかは二の次なんです。ライブラリやフレームワークを使って遅かったら直接ハードウェアを叩くことも考えます。サービスやドライバを作ることも結構あるので、そこはSIerや社内SEとは多分違うところです。
ただ、技術的には新旧問わないので、何が良くて何がダメなのかっていうのはなくその時々でベストなら問題ないと思ってます。問題なければStaticでも何でも構いませんが（グローバル変数だけはやめてとは思いますが）どうしても必要なら私はコーディング規約で縛るようにしてチェックするようにしています。
「なんだ、これ？」っていうようなコードでも動く事が多々あるのでソフトウェアはそこが面白いとは思いますが、仕事では困りもんですかね。
みながわけんじ
にゃん太郎さんご回答ありがとうございます。
私も開発を業者に発注したことがありますが、進捗が見えないので、各モジュールごとに想定ステップ数と現状のステップ数を先方のプロジェクトマネージャに報告してもらいたいなあ・・・なんて思ったことがありましたが、世界で一番大手さんで強気なマネージャさんだったので、そんなこと言ったら、ステップ数報告のために要した管理工数を追加費用として要求される可能性もあるのでやめました（笑）
また他の業者さんで、作業進捗について聞いたところ「デバッグ中」ということで、「デバッグ中というのは進捗が一番目に見えにくいので、なんとか進捗がわかりやすい形で報告して欲しい」という不満の要望を述べたことがあります。
.NET FRAMEWOK という言葉で、フレームワークとクラスライブラリが、ごっちゃの意味に捉えられていますが、私はグーグルで「フレームワークとクラスライブラリの違い」について調べたことがあります。クラスライブラリは、ライブラリのオブジェクトを使って、その周りにユーザーがコードを記述するもので、フレームワークは用意されたテンプレートの中にユーザーがコードを記述するもので、ユーザーがやることは反対なんだという説明でした。
フレームワークを作っているなんていうと、開発ツールを作っているか、オーバーライドできる関数を用意しておき、あとでカスタマイズするような設計をしているのかな？なんて勘違いするので、その辺の用語は適切にしたほうがいいんじゃないでしょうか？にゃん太郎さんのようなかたは、すごいオブジェクト指向技術を使っているだろうなあなんて思ってましたけど、意外に私でも納得がいくような技術なんで、なんか安心してしまいました。
「三本の矢」については、ノーコメントでしたが、にゃん太郎さんがPMという職業上しかたがないと思います。しかし「ソフトウェア開発に幸せな未来があるのか」という観点からすると、確かに幸せをつかむものは非常に少ないかもしれませんが、「若い青年が良い友を得てJapanese Dreamを実現させたい」という夢を持ってもらうことも重要だと思います。
現実はそうはうまくいかないというのが、にゃん太郎さんの意見だと思いますし、わたしもそうです！と思ってますが、なかには才能がある青年もいると思うので、トーバルトや「まつもと」さんに続くような方が出てきてほしいです。「ソフトウェア開発に幸せな未来は、管理社会の日本ではありえない」という結論では悲しすぎる。
にゃん太郎
みながわけんじさん、コメントありがとうございます。
> 「三本の矢」については、ノーコメントでしたが、
まぁ、ウチもPM（私）が普通にコード書いている（PMがメンバーに対してコードレビューしているのはなかなかないと思います）ので、レベルは別にして似たようなもんだと思ってます。自分の中では管理する部分と開発する部分はまた別なので、開発の打ち合わせをする時（進捗とかではなく）は上から話をしないようにしています。
うちの場合、外注したら工数と見積で納品日を設定しますので、納品日に来なければいろいろツッコミますが、途中で進捗を尋ねる事は少ないです（聞いても正直いう事は少ないです）結局、品質面で手を入れる事も多いので、手直しさせるかこちらで手直しして値切るかです。知った担当者以外はそれこそ信頼も信用もしていないので、品質面はあまり良くない事を想定して外注します。まぁ、これは会社によっていろいろ事情があるでしょうが。
> .NET FRAMEWOK という言葉で、フレームワークとクラスライブラリが、ごっちゃの意味に
> 捉えられていますが
最近は以前に比べて、あんまりライブラリって聞かないような気がします。個人的にはあんまり言葉に気を取られないようにしてます。使おうかな、って考える場合、気にはなるのでいろいろ調べはしますが、どっちがどっちっていう事は敢えてツッコまないようにしてます。
> すごいオブジェクト指向技術を使っているだろうなあなんて思ってましたけど
私も20年以上やってますからね。どちらかと言えば「GOTO」でガリガリと力技？でコード書く方が好きです。オブジェクト指向が嫌いとか良い悪いとは思ってなく、今どきの開発では理にかなっていると思います。ですから、開発の時にメンバーなどと打ち合わせをした時に例えば「GOTO」でガリガリ書いた方が効率も品質も絶対に良い、となればそっちを採用します（あくまでも例えです）
> 「若い青年が良い友を得てJapanese Dreamを実現させたい」という夢を持ってもらうこと
> も重要だと思います。
それは賛成ですよ。ただ、何の疑問もなくググってコピペで動けば良し、って言うのはあかんやろ、と思うだけです（コピペが悪いんじゃないんです...あくまでも「何の疑問もなく」が問題なだけです）でも、デスマーチな現実だけ突きつけられるとそりゃ「このままでやっていけるか？」と感じてしまってもしょうがない気はします。まぁ、これは構造的な問題の方が大きいでしょうが。
> なかには才能がある青年もいると思うので、トーバルトや「まつもと」さんに続くような
> 方が出てきてほしいです。
ただ、才能のある人があんまり画期的なものを作って簡単に工数が減らせて品質が良いものを作っちゃったら（作れるようになったら）それはそれで業界にとっては良くてもエンジニアにとっては幸か不幸か分からないですが。エンジニアのスキルが向上してもそれがエンジニアの待遇改善につながらないところが業界構造的に不幸だと思ってます。その辺の話もまぁ、おいおい考えてますので、またその時にも意見を頂ければと思います。