第22話 生産性向上に見るエンジニアの矜持（後編）
前回はどちらかと言えば「お金」に主眼を置いて生産性について書いてみました。それは仕事である以上、避けて通れないのと、エンジニア側と経営者側で生産性の向上の考え方が異なることを示すために、あえて、そのようにアプローチをしてみました。
ただ、実際のソフトウェア開発でいわれる生産性は、「どれだけ効率よく目的のソフトウェアを完成させるか」という意味で使われることが普通だと思います。今回はそちらも含めて生産性の向上を考えてみたいと思います。
■いま一度、生産性を考える
生産性の向上を目指すのは「利益を上げる」ためというのは、おそらく誰しもが理解していると思います。同じソフトウェア開発でも趣味やオープンソース・フリーウェアのような作成することでは、収益の発生しないものでは、生産性の向上を考えることはまずありません。好きなものを好きなペースで好きにこだわることが第一だからです。フレームワークやライブラリを使うことはあるでしょうが、それは生産性が目的ではなく、こだわる必要がない部分だからであり、生産性はあくまでも経済活動が前提といえます。
生産性の向上は、基本的にエンジニア側と経営者側が同じ方向を目指していないとうまく行きません。同じ方向を向いて、生産性の向上を考えれば、それはお互い「幸せ」な生産性の向上になります。ところが、同じ方向に向かないと、それは「不幸な」生産性の向上に繋がります。
経済活動が前提となる以上、世の中の経済状況も関係してきますが、現状では総じて「不幸な」生産性の向上を行っているところが多いように感じます。これが最終的にエンジニアの質が低下していく要因の1つと考えられます。誰しも頑張れば認めて欲しいですし、ボランティアではないので生活することもできませんから。
■生産性の向上が図れないワケ
昔から情報処理業界は人材不足が深刻でした。人が多くても生産性は上がりませんが、少なくても当然、生産性は上がりません。今は人が足りないというよりは仕事が足りない状況にあるのでそういう話はあまりないのですが（むしろ派遣やフリーランスの人は余っている感じがします）、これを解消するためのアプローチは昔から考えられてきました。
1つはとにかくエンジニアを養成する、ということです。大学や専門学校、職業能力訓練校、それ以前の中学・高校まで、段階に応じて情報処理教育を行い、その中で適性のありそうな人を開拓します。これは現在でも行われていますが、学校教育だけではなかなか現場に対応したエンジニアを教育するのは無理なので、あくまで「基礎」的な教育を行います。全員とは行きませんが、段階を踏んで行うので現場で数年もすればそれなりのエンジニアになるでしょうが、学校で教育したからといって、そのままエンジニアになるのかといえばそうではありません。
そこで今度は「ソフトウェア開発」の敷居を低くすることが考えられました。つまり、専門的な知識が必要なエンジニアが足りないのなら、専門的な知識がなくても開発できるようにすればいいのでは、というアプローチの仕方です。今のように探せばどんなソフトウェアでもありそうな時代になったのはこのアプローチが成功しているといえます。
昔はパソコンでも「OS」を買うという発想がありませんでした。今ではアプリケーションやゲームを買えば対応OSがあると思いますが、昔はワープロにしろゲームにしろOS上で動作するのではなく、独自に動作していました。ですからパッケージには今のような対応OS（WindowsXPなど）が書いてあるのではなく、機種名が書いてありました。ソフトウェアを作るにはまず特定のハードウェアを理解しないとできないので、開発できるエンジニアが非常に限られていました。それをOSや開発ツールが吸収してしまい、徐々に開発するために必要な最低要件を減らすことができました。この流れは今でも続いており、最終的には誰でも簡単にできるようになると思います。
どちらかといえば、相反する2つのアプローチによりソフトウェアを「作る」ことに対しての問題はほぼ解消しているといえると思います。しかし、一方がスキルを身に付けさせる方法に対して、もう一方は、スキルがなくてもできるようにしたために、現場ではスキルの格差が生まれてしまいました。通常、スキルのある人が難しそうな部分を担当し、スキルの乏しい人が簡単な部分を担当します。
つまり、スキルのある人に負荷がかかることになります。これがまず生産性の向上が図れない理由の1つだと思います。良くあるのが、開発も終盤に入るとスキルの乏しい人から段々とヒマになっていきます。そうなるとテスト工程の準備や簡単な手伝いがメインとなり、なかなかスキルアップが期待できません。
以前に、スキルの乏しい若いメンバーに勉強も兼ねて難しい所を一部担当させたことがあります。最初はやる気を出していろいろ調べたり、聞いたり、サンプルを作ってみたようですが、基礎的な知識があまりないため進まず、本人はやって行けないと自信を失ってそのまま辞めてしまいました。いろいろヒントを出してもあまりピンと来ないようでした。このことがきっかけでエンジニアの教育についていろいろ考えるようになりました。
ソフトウェアのように、階層構造に分けて目で見えないロジックを考える仕事は、いきなりスキルが身に付くことも見るだけで盗むことも難しいでしょう。「学問に王道なし」とはよくいいますが、基礎から順番に積み上げて行かなければいずれ行き詰ってしまいます。それは業界にとっても会社にとっても、そしてエンジニアにとっても不幸なことです。
開発環境やフレームワーク、ライブラリが中途半端にエンジニアのスキル不足を補ってしまう現状が結果的にプロジェクト内でのバランスを崩し、せっかくの機能も生産性の向上につながらないと言えます。
■エンジニアに不幸な「生産性の向上」
経営側だけが自分の考えだけで生産性の向上を考えた場合、エンジニアにとっては不幸な結果になることが多いと思います。特に経営者がエンジニア出身ではなかったり、エンジニアを経営資源の1つとしてしか考えていない場合はそういう傾向になりやすいです。
経営者が「利益」を追求することは当たり前です。ボランティアではないですし、儲けがなければ会社を経営しても辛いだけです。社員の給料も売上（利益）があって初めて出せるのであって、そのために生産性を考えるのは何ら悪いことではありません。
会社経営を行う場合、長期的な目標と、目先の短期的な目標を立てるのが普通です。大企業で良く「経営五カ年計画」と言われるようなものを作るのはそれに当たります。ただし、企業規模が小さいと、あまり長期的に経営を考えることは少なく、目先のことで手一杯になる場合が多いです。ソフトウェアを開発する場合、ソフトハウスやSIerは基本的に開発が終わってから初めて利益（入金）になります。
SIに関しては工事進行基準の対象にもなったのでフェイズ単位での支払いもありますが、長期で展望するためには開発中も給与などの人件費は先払いになるため、それなりに資金が必要となります。中小のソフトウェア会社を名乗る会社に派遣業務が多いのは、これが関係してきます。自社開発だけで人件費が賄えない時は、派遣で毎月収入がある方が会社として経営しやすく、エンジニアの雇用も守れます。前回書いたように元々「特別な職業」という認識があったのでエンジニアの単価もそれなりに高かったのもあります。
利益を考えたら、ソフトハウスでは短期間でできるだけたくさんのソフトを販売して売り上げを上げることであり、SIerならたくさんのプロジェクトを短期間で納品することが一番といえます。（ここには営業は考慮していませんが）そのことから、利益を上げるには生産性の向上を常に求めることが必要となります。
経営者が生産性の向上を考えるのはあくまで「利益」優先です。エンジニアをないがしろにしているとはいいませんが（いないと生産活動ができないので）、エンジニア個々のスキルや負荷に関してはあまり考慮していません。
納期も基本的に顧客の希望が第一です。そのため、エンジニアに対しては負担を強いることになります。また、それでも足りない時はコストカットやリストラも視野に入ってきます。経営者からすれば給与を払っているのでスキルアップのために努力することは当然だと思っていますし、相手がある以上、多少厳しい納期でも相手の意見がまず第一だと思うでしょう。どんなに画期的な製品を作っても、「売れてなんぼ」です。
しかし、開発環境が高機能になったおかげで開発の敷居が下がり、それにより少し事情が変わってきました。ソフトウェア開発が一般的になった分、ユーザーもある程度ソフトウェアを作れるようになり、場合によっては少し踏み込んで話をしてくるので（これぐらいはできるハズだよね、みたいな）、感覚的には特別なものという認識があまりなくなりました。そのため、エンジニアに技術的なスキルを求めるのではなく、とにかく完成させることができるだけのスキルしか要求しなくなります。ですから、技術的な教育には費用も時間もかかるため、あまり関心がなくなります。
経営者はエンジニアが考えるよりはるかに厳しい立場です。決してふんぞり返っているだけではありません。最終的なクレームも損害もすべて背負うため、現場のデスマーチ以上に辛いと思います。エンジニアのスキルアップがどうでもよいわけではなく、利益を得るためのトレードオフになっているだけで、そこはエンジニアの良心に期待するしかないのもあります。わたしも経験ありますが、「もうちょっと分かってくれよ」と思ったことは何度もあります。
ただ、不幸なのはエンジニアが頑張っても利益が上がる保証がないのと、利益が上がってもなかなかエンジニアに恩恵が感じられないところです。エンジニアが苦しい思いをして生産性の向上に努力しても報われないと感じるため、それが続くと結局、スキルアップの努力は続かなくなりますし、さらなる努力を求められると退職も考えるようになります。
ここで社長のねぎらいがあるとか、利益が上がった場合は還元してくれるとか、ある程度目に見えて経営側も苦しいけど一緒に頑張ろうという姿勢が伝われば、エンジニアもそれなりに理解してくれると思います。しかし、口だけで利益がないから仕事が遅いとかいわれ、社長が高そうな車なんか乗っていたら、それはエンジニアにとって不幸でしかありません。
エンジニアもまずそれなりに会社の財務状況を把握した上でどうやって生産性を上げるのかを考えることがこれからは必要だと思いますし、経営側も財務状況をある程度公開した上でどれだけ利益があがればそれを還元できるかを明確にするべきです。お互い同じ目標に向かえるように経営側が仕向けてやれば、みんな頑張るでしょうし、それこそ「それにはまず技術が必要だ」と説けば社員も少しはスキルアップを考えると思います。
高度成長期はとっくに終焉し、ただ「みんなで頑張ろう！」というだけではもう誰も頑張れません。
■先輩エンジニアの役目
ハードウェアやソフトウェアの基礎技術はすでに確立されていて熟成されています。反面、応用技術は常に進化して、その流行り廃れは非常に早いです。昔は基礎技術から順番に追わないとソフトウェア開発はできませんでしたが、今は土台となるOSの開発環境と最低限のソフトウェア知識があれば事足りるようになりました。知識を「ゼロ」ベースから考えた場合、今の方がはるかにソフトウェアの生産性は上がっていると思います。職場では応用技術がメインのため、先輩から継承されるのはその職場で必要な応用技術がほとんどだと思います。
しかし、実際にプロジェクト全体としての生産性を上げるには基礎技術の習得と継承が必要だと思います。それは前回も書いた通り、トラブルがあった時の調査や、複雑な処理を実現したりするためです。基礎があっての応用は新たな応用に繋がりますが、基礎がない応用は、新たな応用にはなかなか繋がっていきません。
今のようにいろいろな情報が溢れていて、複雑なソフトウェア体系の中ではこれからエンジニアを目指す人が地味な基礎技術を習得するだけの理由を見つけるのは難しいと思います。それこそ先輩エンジニアはまず基礎技術を後輩に継承していくべきだと思います。それにより先輩エンジニアも忘れない様に再確認できます。
いろいろコメントもいただきましたが、わたしは何もすべてのブラックボックスの中身を知る必要もこじ開ける必要もないと思っていますし、生産性や採算に見合うなら使うことは間違っていないと思っています。商用製品であれば、開発元に対応してもらえばそれはそれで良いと思います。その上で、作れるなら作った方が……とは考えています。しかし、いざとなったらこじ開けてでも原因を探るぐらいの気概と何とか調べられる程度の基礎技術は必要だと思います。
直してもらうにしてもある程度「ここが悪い」といえなければ「仕様」といわれるかもしれません。その重要さが分かっているから、後輩の教育には基礎的なことを理解してもらえるように努力します。ひょっとしたら必要ないかも知れません。でも、いつか必要になった時に1つでも解決するための「武器」になればそれで良いのではないのでしょうか。エンジニアの矜持とはそこにあるような気がします。
■「当たり前」なことは1つだけ
生産性の向上はある意味、いままでもそしてこれからもエンドレスなテーマとして続いていくでしょう。多分、ゴールはないでしょうし、そのためのアプローチはこれからもいろいろな方面からあると思います。ひょっとしたら開発ツールすら必要になり、マウスで数回クリックするだけでアプリケーションが作れるようになるかも知れません。
エンジニアとしてこれからも飯を食っていこうと考えるなら、まず「当たり前」なことはほとんどないと考えましょう。会社も、仕事も、給料が出ることも、働く現場があることも、すべて自分以外の人が頑張っているから、今の自分があるのです。エンジニアにとってたった1つの「当たり前」とは「技術を常に磨くこと」、これだけです。
どんなに便利なツールを使っても、それを作るのはエンジニアですし、使うのもまたエンジニアです。便利さにあぐらをかかないで勉強することは必要ですし、その大切さを伝えるのもまたエンジニアの役目です。この継承がうまく行けば、おそらく開発現場の不均衡な負荷は減り、少しは明るい未来が見えて来ると思います。
生産性の向上は1人ひとりのエンジニアの自覚と矜持が一番効果的だと思います。わたし自身はこれからもそう思って自己研さんと後輩の指導をしていきたいと思っています。技術で語りあいができるのは、本物のエンジニアだけですから。
コメント
インドリ
こんばんは。にゃん太郎さん。
今回も読み応えがあるいいコラムでした。
読んでいて改めて思ったのが、以前にゃん太郎さんが言っていた意見「エンジニアは全てフリーになった方がいい」が正しい事です。
私もエンジニアに金銭感覚が点が気になっていました。
趣味でやるならいざ知らず、商売でやるからには利益が出なければなりません。
しかし、毎月決まったお金がもらえるせいなのか、向上心が無くそういった事に疑問すら抱かない人が居ます。
※全てのサラリーマンがそうだと言っているのではありません。
一方経営者もブラックボックス的に扱いすぎる人が居て気になっていました。
経営者は儲かる会社をつくるのが仕事なのにも関わらず、経営者の方も何も学ばない。
それどころか「経営者はITなんて知らなくてもいい」と言う人すらいて不思議だと感じておりました。
知らないもので大もうけできるほど商売は甘くありません。
これらの要因がこの業界を駄目にしたと言う気がしてなりません。
ですが性質の悪い事に、日本では看板さえあれば儲かるのもまた事実。
あくどい例をあげれば、何もせずに下請けに丸投げしている方が回転率が上がって儲かります。
これが非常に達が悪い。
この業界では生産性ではなく「称号」で報酬が決まっております。
ですから、性質の悪い人達は称号で飯を食い、称号を偽装する事を目指します。
称号や看板さえあれば、中身は問われないのだから酷いものです。
これを改善するには、エンジニアが経営層に行き、お客様に騙されている事と品質を鑑定するという発想を伝えるしかありません。
それには全員がフリーになる方が手っ取り早い。
そうすれば、自然と両方の考えが分かるようになります。
ですが、エンジニアが目覚めて行動しない限りこの業界の腐った構造は何も変わりません。
その為にもにゃん太郎さんの様な方がこうやって情報発信をする事を応援しております。
次回も楽しみにしております。
にゃん太郎
インドリさん、ありがとうございます。
今回のようなコラムの考え方って、経験しないとなかなか実感出来なくてエンジニア側から見ると賛否両論かな、って気がします。それでも際立つように今回も書いてみました。経営者が例えばインドリさんのようにフリーランスから起業すると、今回のコラムのような事についてはバランスが取れると思いますが（儲かるかどうかは別として）、バブル期以降のように「コンピューターは儲かるから」という考えだけで事業をすると儲けだけが最優先になるのでエンジニアには頑張っても還元されない状況が生まれてしまいます。そうなるともう愚痴しか出なくなります。
> この業界では生産性ではなく「称号」で報酬が決まっております。
今は称号も厳しいですが、能力や生産性はどちらかと言えば二の次ですね。生産性が低い場合はマイナスしても良い様な気もしますが、日本の法律上それは出来ないので他の方も書いていらっしゃいましたがだらだら残業した方が得というおかしな構造になります。
ご期待に添えるか分かりませんが、明るい未来を模索しながらもっと書いていきます。
インドリ
にゃん太郎さんおはようございます。
返信有難うございます。仰る通りだと思います。
今回はエンジニアの未来と関係あると思う事を思い出したので書きます。
マルチコア時代になり、並列処理が一般化してきていますので、今までの様にハードウェア様で誤魔化して儲ける事が出来なくなったと私は考えております。
理由は並列処理を上手く実装するには、ハードウェア・アセンブラ・メモリモデル（Javaで実装する場合Javaメモリモデル）・並列処理の技法・言語とライブラリに関する深い知識が必要とされていると考えているからです。
これらの知識をエンジニアが身につけるには、今の様な業界構造では駄目ですし、まともな製品を作れない会社が多くなると予想しております。
下手に配列処理に手を出すとデッドロックするのが関の山で、なんちゃって技術者ではデバッグ出来ないと思います。
まぁ、並列処理もTBBの様に抽象されるでしょうが、それでも今までの様に学習しないで儲かる時期は終わったと私は思います。
こういった事から少しはこの業界がましになると思うのですが、にゃん太郎さんはこの件についてどう思われますか？
gachao
はじめまして。
私も小さいソフトハウスで、経営、企画、開発、教育などに関わる立場にあり
今回のコラムには非常に共感致しました。
少し前の時代から、技術者は開発現場での仕事を通じて、自然とスキルアップが出来ないように
なっていると感じています。にゃん太郎さんのおっしゃる「サラリーマンエンジニア」化し、
スキルが無くても仕事が出来てしまう、という状態です。
(他者が作った成果物をコピーして、または書き換えて、仕事をしているエンジニアがとても多い)
こうした中、例えば詳細設計工程を一から行えるエンジニア、独自のアイデアを実装出来る
エンジニアは絶滅寸前です。
しかし、同じ状況の中でも伸びる者もいます。彼ら(彼女ら)に共通することは、
・担当タスクに対して目的や理由、経緯を理解していること
・扱う技術について、使い方だけでなく振る舞いを理解していること
があります。こうした勉強は慣れてくるとさほど生産性に影響を及ぼさずに
出来るようになります。むしろ中期的には生産性が高まります。
要するに、日常の仕事への取り組み方と、そこでの経験を知識にするための
ほんの少しの努力で、エンジニアのスキルは伸ばせると思っています。
さらに、
・会社としてのコンセプト・方向性が定まること
・技術向上が会社利益に貢献し、技術者の評価に反映されること
の2点が加わることで、良い循環が生まれることと思います。
それが難しいんだよ！というところですが、
ここがまさに会社(管理職)として為すべきことではないでしょうか。
会社も個人も、変わらなければならない時代、
逆に言うと変わることが出来れば、チャンスはまだまだめぐってくる！
と信じて頑張る、今日この頃です。
nt
全体的な論旨には賛同できるところもあるのですが、1点だけ。
> 経営者の優先事項はまず「利益確保」です。
私は、この考え方が間違っていると思います。企業経営の最終的な目的は、今風の言葉で言うところの "going concern" にあります。要するに、企業は「存続すること」を目的として経営すべき、ということです。利益は、企業が存続するための一つの要素にすぎません。もちろん、極めて重要な要素ではありますが。
例えば金銭的な側面で言うと、企業存続にとっては、短期的には利益よりもキャッシュフローの方が重要です。赤字でもキャッシュフローが回っていれば企業は立ち行きますし、黒字でもキャッシュフローが回らなければ倒産します。もっとも、日本の(特に中小企業の)ように多くの企業が運転資金を銀行からの借金で賄っているような状況では、赤字決算→貸し剥がし→キャッシュフローが回らなくなる、というパターンになるので、利益を出すこと＿だけ＿に目がいきがちになってしまうというのは、その通りでしょう。しかし、それは資本調達ルートを多様化する努力をしていないという意味で、経営者の怠慢でもあります。
そうは言っても、中長期的に見て利益の出ない企業にお金を出す人がいないのは当然なので、利益が重要なことを否定するものではありません。ただ、中長期的に見るなら、企業存続にとっては、他にも重要な要素は沢山あります。そのあたりは本エントリーで取り上げておられる通りで、例えば従業員を減らしてしまうと中長期的には(残った)従業員もやる気がなくなったり体を壊したりして、会社が立ち行かなくなります。またIT業界のような技術の変化が激しい世界では、教育に投資をしなければいずれ仕事は来なくなります。また利益を上げることに血眼になるあまり、ぼったくりのような商売をしたり違法な仕事に手を染めたりすれば、やはり会社はいずれ立ち行かなくなります。
「企業が存続すること」を目的とするなら、極論、「利益(ここでは人件費までを費用計上した後の残りを利益と呼ぶことにします)はトントン」でもいいのかもしれません。あるいは、技術の教育に必要な資源(お金と時間)から逆算して、利益のあるべき額を求めることになるのかもしれません。何が言いたいのかというと、要するに「利益」ではなく「存続」を目的関数とし、利益や教育や人件費などをそのパラメーターとして、最適な組み合わせを求めるのが、経営者の仕事であるということです。存続の一要素でしかない利益(しかも目先の利益)だけを追う経営者は、経営者としては落第だと思います。
生産性を上げる、という話も同じで、単に売上比のコストを下げるという利益しか念頭にない発想だと、いずれ会社は立ち行かなくなります。「会社が存続するためには」というより高い視点から、どのように生産性を上げるべきなのかを考えるほうが、思考の幅も広がり、従業員も納得しやすい方法に行き着けると思います。
エンジニア自身が自覚と矜持をもって自身の技術を磨くことは、自らの生き方の舵取りを(他人任せではなく)自分自身で行えるようにしておくという意味でも重要だし、価値のあることだと思います。しかし、生産性の向上を「エンジニアの自覚と矜持」だけに頼るような経営者は、間違いなく経営者失格でしょう。
nt
追伸。
> 基礎があっての応用は新たな応用に繋がりますが、基礎がない応用は、新たな応用にはなかなか繋がっていきません。
このお考えには、全面的に賛成です。OSや言語など、特定のプラットフォームに依存しない基礎的な知識こそ、最も重要だと思います。即効性がないので経営者側も技術者側もそこに投資するのをいやがりますが、一度身に付けたら幅広く応用が利くという点で、本当に最も価値があるのは基礎だというのが私の考えです。
にゃん太郎
生島さん、ありがとうございます。
生島さんもエンジニアであり社長ですよね。まぁ、正直「バランス良く」だと思うのですが、それが一番難しいんですよねぇ…コラムでも（笑）
にゃん太郎
インドリさん、ありがとうございます。
昔は「マルチCPU」ってありましたね（今でもありますが、サーバぐらいしか見ないので一般的でない、と言う意味において）あまり広がらなかったのはソフトウェアの作り方が非常に難しいからかな、と思います。普段はあまり意識しないのですが、ソフトウェアが「どのCPUで動いているか」を常に意識する必要があります。特に「デバイスドライバ」ではちゃんと管理しないとインドリさんのおっしゃる通りデッドロックの嵐です。（実は経験者）
マルチコアやハイパースレッドは「なるほど」と思うのですが、マルチスレッドと違いソフトウェア側で意識しなくても普通に動くのでアプローチは良いと思います。当然、マルチコアを意識したツールを使えばさらに効率よく動作しますが、現状ではそこまでの動きはあまりないですね。このあたりをきちんとやろうとするならインドリさんのおっしゃる並列処理を学ぶ必要はあるのですが、これだけ「マルチタスク」が一般的でも「同期」「非同期」の処理を設計するのが下手なエンジニアが多いので、ソフトウェア的なアプローチはしばらくはあまりないと思えます。
マルチコア化は処理速度アップとソフトウェアの特別な対応がなくても良いという利点がありますが、逆を返せばマルチCPUの反省？に立ってソフトウェアを当てにしない戦略とも読み取れるので個人的にはソフトウェア側からも効率よくマルチコアを生かすように考える必要はあると思います。
やっぱり基本だとは思うんですけどね。そこさえちゃんと埋めておけば容易に対応できると思うんですがそのあたりがないがしろになっていたり、動けばよしと考えるエンジニアや経営者が減れば業界として少しは明るくなると思います
にゃん太郎
gachaoさん、ありがとうございます。
おっしゃる通り、こんな中でも当然伸びる人はいます。これをきちんと育て上げる事が出来れば会社としても非常に将来は明るいのですが、先輩がこれに嫉妬したり、出来る事を良い事に便利屋にしてしまったらエンジニアが疲弊してしまい、業界から離れさせてしまう原因にもなり兼ねません。これが個人的にはツラいです。
私は先輩として後輩や部下が自分を踏み台にして伸びてもらう事が一番うれしいと思ってます。ずるい考えをすれば自分が頑張らなくても他の人で充分になって自分が楽になるからですが、自分だけが良いと考えると今は良いですが、先々いずれ引退した後に残したものがないとそこで終わってしまうと会社にも業界にも不幸だと思います。ですから、
> 会社も個人も、変わらなければならない時代、
> 逆に言うと変わることが出来れば、チャンスはまだまだめぐってくる！
> と信じて頑張る、今日この頃です。
と考えてくれる人がいるのはコラムを書いていて嬉しいです。
にゃん太郎
ntさん、ありがとうございます。
会社を経営していて一番頭が痛いのは「お金」だと思います。小さい会社だと喉から手が出るほど欲しいのは「安定的な利益」ですが、それは日本の銀行などはソフトウェア会社にはなかなか理解を示してくれないからです。私の場合は電話やインフラなどと組み合わせてやっていたので何とかなってましたが、ここが外国とは違うのかな、と思います。外国の投資家などは確かにシビアですが、ソフトウェアでもある程度アイデアが良ければ投資してくれます。
ま、コラムでは非常に極端な書き方をしましたが、私は経営者がエンジニアである必要はないと思っていますが、何も知らずに儲けだけを追いかけるやり方ではソフトウェア業界に関してはいずれ行き詰ると思ってます。「利益」と「技術」は両輪で考えるバランスを経営者がリーダーシップを持ってやってほしいと願っています。
しっぱ
こんにちは。しっぱと申します。
会社の利益と自己の技術（会社の資産でもありますが）の両天秤には被雇用者は常に踊らされ続け、経営者は常にその狭間で苦しみ続ける。。。。
嫌な負の連鎖ですよね。
いつかこれが断ち切られることを祈るばかりです。
ただ、
＞エンジニアにとってたった1つの「当たり前」とは「技術を常に磨くこと」、これだけです。
ここはちょっと疑問が残ります。
体験談を話すと長くなるのでものすごく極端な例を出すと
「技術や知識は高くて仕事が早く終わるので、自分の仕事が終ったら他人のことなんてどうでも良くて就業中でも寝てしまう。」
これってどうですか？
まあ、ヒューマンスキルっていうか極端な例なのでそれ以前の問題ですが。
以前これに近い方が実際にいたのでｗその方は仕事が終わると「休職」してましたｗあとで噂で株で生活していたとのことでしたが・・・。
有価証券のシステムＰＪだったので情報を取りやすかったんですね。。。
ただ、技術も業務知識も半端じゃなく高い方でした。
でも、私はこの方を認めたくはありません。
技術云々の前に仕事は一人でやるものではなく、チームでやることが多いのですからヒューマンスキルは必要だと思います。
逆もしかりで、技術がないのにおべんちゃらで仕事場で活動することもしたくありません。それは技術者でもＩＴ関係者でもありません。
まあ、ちょっと外れましたが、
生産性の向上というお題目の上で大事なことは「開発技術」だけでなく、「ヒューマンスキル」も必要なんじゃないかなと思いました。
技術がある人、うまく計画を管理出来る人、クライアントからうまくヒアリング出来る人、チェックがうまい人、職場の雰囲気を明るくしてくれる人。
どの人もそれぞれＰＪを運用していく上で必要かと思っています。
職場の雰囲気を明るくしてくれる人に関しては賛否両論あるかと思いますが、少なくとも私は雰囲気の良くない現場で働くより、忙しくても明るい現場の方が効率が上がります！
にゃん太郎
しっぱさん、ありがとうございます。
> ここはちょっと疑問が残ります。
しっぱさん、あまりに言葉の意味を読みすぎです（苦笑）
「エンジニア」としてなのでこれはこれで良いと思っています。だって「事務職」や例えば食品会社の営業職には必要ないものですから（代わりに違うスキルが必要ですけどね）でもヒューマンスキルはエンジニアに限らず営業だろうが事務職だろうがそれは「当たり前」だと考えているので今回はその事には触れていません。
ですから、
> 「技術や知識は高くて仕事が早く終わるので、自分の仕事が終ったら他人のこと
> なんてどうでも良くて就業中でも寝てしまう。」
これは職業エンジニアとしてどうかと言われればそりゃ「失格」です。コラムの中でも「技術さえ磨いて高ければ何でもよい」とも書いたつもりもないですし。コラムはすべてを包括して書く事は難しく、ましてや私のように「素人」には限界があります。そういう意味で毎回「なるべく絞って」「極端でもテーマを決めて」と考えています。出来ているかどうかは別ですが、ITメディアのスタッフの方のおかげで何とか「読める」ようにはなっていると思います。
生産性の向上はエンジニアの技術的な向上だけではなし得ません。でも、コラムではエンジニアはその事は常に考えて欲しい、という事が趣旨なのでご理解下さい。ヒューマンスキルは私から言えばエンジニアであるかどうかは関係なく社会人として「当たり前」だと思っています。ただ、今回のコラムにはあまり必要ないため、触れてません。
> 職場の雰囲気を明るくしてくれる人に関しては賛否両論あるかと思います
私は絶対必要だと思います（笑）
しっぱ
にゃん太郎様
お返事いただきましてありがとうございます。
いやいやちょっとズレすぎましたね＾＾；
ここのところ、社内ＳＥにどっぷりなせいか、コミュニケーションスキルが非常に疎かにされている環境なもので。。。。
社内ＳＥは名刺交換の機会すらないこともありますからねｗ
3年程いても名刺が1枚も減ってないとかザラです・・・
そのためか、技術に関しては評価項目もありますが、ヒューマンスキルやコミュニケーションスキルについては評価がされません。
と、まあ、こんな環境にいるため技術にどっぷりってのがちょっと引っかかってしまいました＾＾；
今読むと完全に個人的な内容ですねｗ
失礼いたしました。
あとむ
以前もコメント致しましたあとむ@フリーSEです。
いつも興味深く拝見しております。
私の先輩(40歳前後)が、同様のことをよく言っていたのを思い出します。
技術的な側面では、仰る通りOSSの流れもあり、充実した開発環境等がある為、
その技術の裏側まで知ることなく開発作業が出来てしまう部分が多いですね。
私も以前のwebアプリ開発の職場で、後続の人の為に開発環境をVMwareで用意し、
仮想OS上にLAMPP環境を構築したことがありました。
開発環境を構築する際、仮想OSとしてLinuxインストール、XAMPPインストール、
各種設定等を行いましたが、その作業は自分にとって非常に勉強になりました。
と同時に後続の人が上記作業を行う必要がないため、
組織としては効率的かもしれませんが、一方でその経験を奪うことにも
なり得るんだと少し複雑な心境になったことを思い出します。
ただ、開発環境が既にあることで、開発環境構築に手間をとられない分、
開発作業にすぐに専念できるようになったことも確かに事実ではあります。
私は結局のところ、効率化をして空いた時間を何に使うのか？
という点が(組織としても個人としても)非常に大切だと思っています。
時間的な制約が少ない状況では、以下のような分類が可能かもしれません。
・①ある技術を深堀りする人
・②別の技術に興味を示し試してみる人
・③技術を応用してどんなサービスができるか検討してみる人
・④サボる人(前向き/後向き含め)
仮に経営側の観点で考えてみる場合、各人の上記傾向性をよく考えて、
適材適所で人材を配置していくことが解決策として上げられると思います。
また個人的には、これまでの経験上①～④のせめぎあいは熾烈で、
一言に「適材適所」といっても上手くいかないケースの方が多いように思います。
これは、私としては日本の階層型請負体質が大きく影響しているのではと考えます。
→①～④の人はそれぞれ別会社/組織にいるケースが多いような気がします。
中小企業の立場から考えると、この階層型請負体質の枠組みの外で戦うことが必要で、
そのとき最も大切になってくるのが「どのように利益を上げるのか」、つまり
ビジネスモデルだと考えています。
ビジネスモデルが確立されていれば、中小企業であっても、少なくとも①～③の人が
それぞれの立場を尊重し合いながら魅力的な企業として存続できるのではと思います。
# 大企業並に組織が大きくなると④の人も受け入れることになる気がしますが…
にゃん太郎
しっぱさん、ありがとうございます。
> 社内ＳＥは名刺交換の機会すらないこともありますからねｗ
3年程いても名刺が1枚も減ってないとかザラです・・・
これは良く分かります。私は社内SEではなくてパッケージソフト開発なので、あまり特定のお客様と話をする事がありません。せいぜい質問とバグ報告のメールぐらいです（笑）アンケートや要望であまりに多いニーズだとそれに沿って追加したりしますが、それも基本的に「最大公約数」なのでまぁ、バグ報告以外は気楽ですけどね。でも、確かにその分コミュニケーションスキルはおろそかになりそうでコワいです。
にゃん太郎
あとむさん、ありがとうございます。
> と同時に後続の人が上記作業を行う必要がないため、
> 組織としては効率的かもしれませんが、一方でその経験を奪うことにも
> なり得るんだと少し複雑な心境になったことを思い出します。
これも「効率」の考え方にもよるのでしょうが、私はメンバーのスキルを見てわざわざ同じ事をやらせる事があります。同時にマニュアルを書かせます。そのマニュアルを今度はそのまた後輩に渡して同じ事をさせて今度はマニュアルをアップデートさせます。逆にそれなりのスキルや経験を持っている人にはすでにある環境をそのまま渡します。
> 私は結局のところ、効率化をして空いた時間を何に使うのか？
> という点が(組織としても個人としても)非常に大切だと思っています。
これはそうだと思います。結局、黙っていても自分で進んで行ける人は良いのですが、そうではない人には管理者としてはある程度「道筋」は付けてやる必要があると思っています。ですから、最初に書いた作業もいきなり環境を与えるのではなく自分で手順を追ってなるべく理解出来るように仕向けます。「急がば回れ」とは良く言ったもので、最初は非効率でもそのうち効率的に仕事が回ります。最近はあまりメンバーの新陳代謝がないので余計です。ただ、ある程度やってもダメだったら私は見切り付けてルーチンワークをメインにやらせてしまいますが。
組織的な「効率化」を考えた場合、管理者がメンバーをある程度スキルで選別した上でそれぞれ個別に「どういう作業をさせるか」を考える必要性があります。つまり、スキルや経験が充分であれば100%業務をやらせれば良いのですが、そうでない場合は業務50%、スキル向上カリキュラム50％と言うように考えます。ただ、勉強だけさせても応用が利かないのでツールを作らせたり、マニュアルや環境を作らせたりして不足しているであろうスキルを補わせるように仕向けます（その成果物もいずれ効率化に役立つし）
私の場合、それでどうしようもない部分は自分でやって補うようにしています。
志御
「第19話 フレームワークの甘いワナ」でもコメントさせていただきました志御です。
にゃん太郎さん、こんにちわ。
いろいろ書きたいことがあるのですが、簡単に。
「■「当たり前」なことは1つだけ」は非常に共感します。エンジニアは技術が使えて何ぼだと思います。
部下に指導をしている際、よく「鈴木イチロー」選手を引き合いに出します。あれだけの選手であっても、仕事以外でも常に練習をしているとか話します。
まあ、イチロー選手くらいお金が貰えれば…と返されることは多いのですが、卵が先か鶏が先かの問題で、エンジニアとして評価されるのが先か、お金もらって能力を発揮するのが先かとなります。
いずれにしても、最近のエンジニアはエンジニアの本分を忘れているなと、つくづく思います。
生産性については、「考え込む時間をなくすこと」が一番効果が高いことだと思っています。自分も、仕様がわかっていれば、プログラムに起こすことはそれほど時間が掛かりませんが（最速は２万ステップ程度を一日でコーディングしたことがありますが…）、仕様が良く分からず理解に苦しむときや、全く知らない技術や環境を使う際に、考える時間が長くなるので、当然生産性が低くなります。
生産性が低くなるのが嫌いなので、寝ているときと食事しているときと業務中以外は、知識をかき集めるのに邁進しています。
その甲斐あって、この業界で２３年ほどの経歴をもっていますが、他人が悩んでいることについて、フォローできないことはありません。
プログラムを書く際も（最近めっきり減りましたが）、最初に１～２時間、私用に基づいて頭のなかでシミュレートした後、ノンストップで一気に書き始めます。
Javaの場合だとEclipseがコーディングしながらコンパイルエラーも検知してくれるので、非常に効率よくコーディングできます。
もちろん、論理バグはいくつか出てくるので、テストは入念に行いますが、シミュレートしているので、原因を突き止めるのは難しくありません。
と言ったことを、部下に教えていますが、どうも着いてきてくれないのに困っています。かといって、その部下たちも普段の空いている時間に技術力向上のために何か取り組んでいるかと言うと、場合によってはパソコンすら持っていないと言う人までいる状況です。
かなり愚痴っぽくなりましたが、生産性の向上には、フレームワークなどとか言う前に、意識改革が最も重要なことではないかと思います。
いかがでしょうか？