「開発言語」を知らない設計者
いま勤めている会社の中で問題になっているのですが、最近の潮流としてターゲットとなる開発言語を知らない設計者が増えてきているという話題があります。酷い場合には、言語のみならずプラットフォームであるOSやネットワークの基礎すら知らない人というのも目にすることがあります。このあたりは「人材の空洞化・ドーナツ化」などとよく言われていることだと思います。
要件定義から概要設計の中において、言語を知らなくとも構わない部分が存在しますので、個人的にはOKだと思っています。ですが、今回のような点が話題にあがる環境ですと、言語に大きく依存する部分まで設計してしまおうという状態ではないでしょうか。要件定義をほとんど行わない状態で概要設計を行う、概要設計と詳細設計の区別がついていない、GUIのデザインだけでAPを実装させる（時間的な都合はわかるのですがね……。人のことは言えないですが）など、落ち着いて考えれば酷い状況を目にも耳にもすることがあります。
私の狭い視野の中にあってもこのような状態は目にすることが多いです。個人的な見解ですけれど、年齢・キャリア・役職が上がるにつれ、問題のある設計者の割合は多くなっているのではないでしょうか。ただし、一定以上の役職レベルを超えている方々というのは、問題のある設計者ではない方が多いですので除外できるとも思います。例えば、名の通っているような有名企業でマネージャ職以上に就いているような方々には、問題のある技術者というのは少ないと感じています（もちろん技術者としては問題があるが、管理職として高レベルな人も多いですね）。
ところが、地方中小零細企業では上記のような、能力に見合って役職に就いていると思える方というのが、なかなか……それほど……あまり……（ほとんど？）見当たりません。もちろん、私の見ている範囲が狭いという理由も多々あります。というよりもそれが殆どでしょう。私が思うほど、世の中問題のある技術者ばかりではないというのも承知しているところです。
かなり限定した領域での話題になってしまっているとは思います。
そのような狭く限定した環境かもしれませんが、このような問題のある設計者と一緒に仕事をすることになった場合、どのような事態になるでしょうか？
実際目にした話ですが、オフコン時代の経験が豊富で業種に対しての知識もかなり有している人と一緒に仕事をする機会がありました。ところがこの人は開発言語の知識がCOBOLのみ、データベースもよく知らない（ファイルと同じと思っている）、クラス云々ではなく構造化を知らないというタイプの人でした。さらに悪いことに、（ある程度でも）ちゃんとした仕様書というのを起こすことができずに画面デザインのみが着々と増え続けるような状態になっていったのです。テーブル設計というか、ER図なんてものもありません。要件を定義するようなこともなく、ユーザーからあげられた要望をほとんどそのまま受け入れてしまうため、「どこまでが要件で、どのような仕様となるか」、という線引きすらまともにできないほどプロジェクトが迷走してしまいました。気がつくと時間ばかりが過ぎ、個々のアプリケーションとしてはある程度の完成度までたどり着いたのですが、システム全体としてみるとまったくと言っていいほど連携が考えられておらず、システムと呼べる代物には体をなしていませんでした。
このような状態であっても、そのプロジェクトのマネージャは特に手を打とうとしませんでした。それは、この問題のある設計者が会社に対して、常にごまかす報告を続けていたからです。正に「見える化」をしなければならないプロジェクトの例としてとりあげられそうな状態ですね。上層部からすると、このプロジェクトは順調に進んでいるとしか見えていませんでした。
しかし、実際に納期が近づいて、ユーザーからもボチボチと受入試験の結果が上がってくるようになると、さすがに隠し通すことはできません。マネージャは報告と実態がかけ離れた状況だと感じ、改めて開発現場にヒアリングを行い、初めて事態の深刻さに気付いたようでした。ちゃんと仕様としてまとまっていないから常に口頭による作業指示となる、議事録もドキュメントとして残っていないからユーザーの言いなりになる、どこまでがやらなければならないことかということもわからない、でも時間ばかりが迫ってくるからとりあえず実装する人はがんばれよ、といった状況ですね。実装側にかかっていた負担、プレッシャーは相当なものだったと思います。
状況を把握したマネージャが打った手はこうでした。
「その設計者をプロジェクトから外すことは今までの経緯もあるのでできないが、設計からは外す」
すべての業務からその人を外すというのは、対外的な問題もあるのでできない事なのですが、少なくとも物づくりからは外れることとなったのです。代わりに引き継いだのはその人より若い人で、業務の知識は少ないのですが、オープン系の知識をある程度身につけていた人でした。その後は、その人を中心に実装側が協力し、できる限りシステムとしての形を整え、なんとか納品、検収までこぎつけることができたという話です。
この例は「開発言語を知らないから」という点だけが問題で起きた訳ではなく、もっと複合的に問題があったために発生した例です。ですが、開発言語を知らないために詳細設計を行うことができなかったという事実はあるのではないでしょうか。最初に「全てではないが」と書いたのはこの部分にあたります。さすがに詳細設計となると、開発言語を知らなければ設計というものはできないと思えます。
そのあたりも踏まえて個人的な見解としては、
- 言語に関わる内容が多いレイヤはNG（詳細設計はもってのほか）
- 言語に依存する前であれば「まだ」OK（要件定義や概要設計ぐらいが限度？）
と考えています。できる限り開発言語は知っていてほしい、とは思いますが、実際にそれを望むことは非常に難しいと感じています。自分が努力するのはまだ易しいですが、他人に努力させるというのは非常に難しいからです。
個人的にこの件で危機感を持ってもらいたいのは「上流」と呼ばれる仕事をする方達です。規模の大きい企業なら分業体制を取ってやりくりすることも可能でしょうが、中小～零細企業に勤める私のようなSEこそ危機感を持つべきだと思います。
冗談ではなく、仕事がなくなりますよ？ 今までの経験で得たもので、いまも役に立つものはどれくらいありますか？ あまり使えるものがない……と思った人は、これから増やすよう心がけましょう。今までやってきたことをこれからもやるだけです。できないわけがありません。
「年齢が……」ですとか、「そういうのは上がやる事じゃない」と言うのはただの言い訳です。もしそれでも言い続けるのならば、その代償としてあなたの仕事はなくなるという事を覚えておいてください。
反対に「下流」と呼ばれる仕事をする方達に考えてもらいたいのは、「だからといって他人はそうそう変わらない」という点です。もちろん変わる人もいます。でも変わらない人もいるのです。ならば、そのような方達と一緒に仕事をするにはどうすればよいのか。「○○さんは今の技術を知らないから一緒に仕事ができません」、それでは社会人として失格です。環境に文句を言うことは誰でもできるのです。重要なのはその環境下でどれだけ質の高い仕事を行えるか、ということだと私は思っています。
上流をサポートするように動いてみるのもいいでしょう。もしくはもっと大胆に上流の人の仕事を肩代わりしてしまってもいいくらいだと思います。そうすることにより、幅広く自分が仕事に関わることができ、なおかつ精神衛生上も負担が少ないとなると、メリットの方が多くないですか？ 少しずつでもできる領域を増やすことは、会社としても社員に求めていることの1つです。
では、もし肩代わりして失敗した場合は？
……そのような場合は、素直に上の人間を頼ってしまいましょう。権限を持つ上の人間は同時に責任もついてまわるのですから。
コメント
インドリ
ボクの場合は、ITって何？というレベルの自称IT会社から丸投げされて、システムを納品したら料金を支払ってくれないというケースが何度もありました。
世間は看板だけで判断しがちなので、本当に何も知らないAnd知るつもりもない自称IT会社がエンドユーザに甘やかされて存在する場合が多々あります。
Ahf
コメントありがとうございます。
エンドユーザに甘やかされて存在するIT企業というのは厄介な存在ですよね。料金を支払ってくれないというのは厄介を通り越していますが・・・。
取引実績があるとか、大手SIerと開発実績があるとかそういう付加要素だけに目がいってしまうのも困りものです。このあたりで本当にその会社や社員の能力を示すことができる何かがあれば、事態は変わっていくと思えるのです。
そうすれば一企業だけでなく業界全体で意識が高まり、もっと切磋琢磨する状態になることができるかな、と考えています。
sam
実は、アプリケーション開発現場だけでなく、ネットワークインテグレーション（いわゆる、ルーター・スイッチと呼ばれるものの設計・導入）の現場でも、同じような現象は起きています。機器現物を触らずに、設計の要件定義から、プロジェクトマネジメントに関与している人材が増殖しています。これがアウトソーシング化による効果なのか、副作用なのか断定は難しいですが、確実にエンジニアを経験せずに、上流工程に携わる人材が増えていますね。人材不足が、こういう面でも現れていると見るべきでしょうか？
須田 機一
ただ、給料を貰うためだけに、会社に所属してるのでは
インドリ
Ahfさんのコメントを読んで私なりに考えたのですが、上流／下流で仕事が分断され、変化する環境に対応できないのも要因の一つとしてあるのかもしれませんね。
本来は常に両方の仕事をしていないと腕がなまりますよね・・・
Ahf
samさんコメントありがとうございます。
私はハード系の設計などはかなりうとかったので、ソフト系と同じような話題が出ているというのは驚きでした。ハードソフト問わずに同じ問題が出てきているのであれば、本当にIT業界の根底にある問題なのかも知れませんね。
私の個人的な考えとしては、人材不足と教育不足、この二つが複雑に絡み合っているのではないかと思っています。
Ahf
須田さんコメントありがとうございます。
給与を貰うためだけに会社に所属する、それも一つのスタイルなので否定はしませんが業界で働く人間としては少々残念に思えてしまいます。
給与を得るためだけに働く、というのはとても精神的に大変だと思うのですよ。よほど精神力のタフネスさがなければできないなぁ、と思っています。
Ahf
インドリさん更にコメントありがとうございます。
上流と下流という考え方自体は学術（でいいのかな）として考えると、理に適っていると思えます。言葉のイメージだとは思うのですが、上流下流といっても上流から下流に流れていくのではなく、上流も下流も平行して流れていくような形が今のIT業界には求められているのかも知れません。
片方にだけ精通してやっていけるのは一部の企業に勤めている方だけだと思うのですよね。少なくとも私がいる様な地方都市ではそれではやっていくことは非常に難しい状況です。常に両方をこなせるように、というのを胸に頑張っていきたいものです。
白影
プログラマーの低迷には、言語自体にも問題ありです。
++,#,.net･･･複雑にしすぎです。
クラス・構造化･･･
要はプログラマー本来の能力を使わずに楽にプログラムしているから弱体化が起きるのではないでしょうか。
与えられたものでしかプログラミングが出来ない人が多くなりすぎたのでしょう。
プログラムツール＝オフィスツール
に、なっていませんか？
クラスや構造化を知らなくても良いプログラムは出来ます。
プログラムという物の本質を見失っていませんか？
貴方の作ったプログラムシステム最小要件を必要以上に引き上げてはいませんか？
プログラマーとして必要なことは新しい技術を沢山覚えるかではなくて自分の能力を最大限に生かす発想力と調べる能力です。
言語というのはプログラムを作る為の物であり言語によってプログラムの優劣を決めるものでは有りません。
くれぐれも本質というものを間違えないようにしてください。
最新のハードウエア技術に助けられて肥大化しているプログラムには、そろそろ卒業してネットブックなど少ない資源で快適に動くプログラムを考えましょう。
老婆心ながら初めてプログラムという物に触ってから三十数年の間に気になったことをコメントさせていただきました。
Ahf
白影さんコメントありがとうございます。
私と異なる考え方をコメントしていただけるのは非常にありがたく思います。
私は開発言語に優劣があるとは考えていません。開発言語はあくまでも目的を達成するための道具であり、あるのは「やろうとする内容に対して向いているかどうか」だと考えています。今回書かせていただいた例が言語に優劣があるように受け取られたのでしたら、大変申し訳ないと思います。
今回私が取り上げたかったのは、何かしらの開発言語を利用して開発するにもかかわらずその言語自身を知らない設計者が増えている、という点です。違う例としてはJava「だけ」を熟知した人がCOBOLの詳細設計を行っても大変だよ、というところでしょうか。特定の言語にフォーカスした内容として書いたつもりはありませんでした。
後私としては肥大化したAPというのはあまり好ましいとは思っていませんが、できることをやらない、というのも一技術者として好ましいとは思っていません。このあたりはケースバイケース、その案件の規模ですとかユーザーの要件ですとかから考えるべきかと思います。
「プログラマーとして必要な事」は私も近い意見です。私は新しい技術は知っている必要があっても必ず使うものではない、と思います。
・・・個人的にはネットブックでの業務ソリューションは是非手がけてみたいと思っていますよ。できればネットブックとモバイルで。
としろう
私も「人材の空洞化・ドーナツ化」は良く感じますね。
設計などは、やはり道具の良い所悪い所に、作り方の定石等をしっていなければ
昨今の複雑だが安く短納期という案件を満たす要件定義～設計をこなせない。
人月単価しか見ずに、本来の開発者の能力は生産性が簡単に数倍レベルで差が有るのに単価は数倍もない場合が多く、単価が下のほうは烏合の衆という特性を理解していないんでしょうね。
会社レベルも含めて上流下流で分割して全体最適が図れない状態で囚人のジレンマ状態かと。
ちなみに言語自体を問題にしている方がおられますが
複雑にしすぎということはありません。
使いこなせない人を使うのが間違いなのです。
クラスに構造化、大変便利で楽に質の高いプログラムを作れるようになったのです。
先の開発言語を知らない設計者の問題と同じく
対象をわかった気になって、勝手な思い込みで使う事こそに問題が有るのです。
いけないのは、その使えない人に「使わせるGOサインを出す人」です。
実際使われる人の意識（知らない場合に取るべき対応）も、問題が有るのですがね。
この業界では軽視しすぎなんですよ。
誰でも出来ると思うからこう使えない人に使わせるのでしょう。
ココを変えない限り上も下も地獄のままデスマーチが繰り返されるのです。
Ahf
としろうさんコメントありがとうございます。
技術者の扱いとして人月による単価を用いていると、どうしても能力によるレベル分けなどは行えない（行いにくい）状況があるかと思います。また能力により金額を分けるというのも会社としては簡単に行えないかと思います。このあたりの事情は込み入ってますよね。実力主義に向かない風土であるというの一因でしょうか。
誰でもできる、と思われている節は確かにあると思います。今でもプロジェクトが苦しい状況に陥った際に「PGを増やせばいい」という考え方が根強く残っているのがその一つでしょうか。実体としてはそんなこともないのですけどね。
個人的には「PGが経験を積むとSEになる」、というのと同じくらいどうにか考え方を改めて欲しいと思う点です。
ハムレット
こんにちわ。
読ませて頂き気になったので、仕事中なのですがコメントさせていただきます。
経験談の中で、COBOL しか知らない技術者の方を例に出していましたが、この
場合、「開発言語を COBOL しか知らない」からではなく、「ちゃんとした設
計技法」を知らない事が問題ではないのでしょうか。
個人的に、システム設計にはプログラムやコンピュータの基礎知識は必要です
が、それ以上システム設計固有の技術・技法を知らない、深めない技術者の方
がはるかに多いように思えます。大まかに言えば、要件定義は Reason of the Why を、基本設計は What To を, 詳細設計は How To を定義、記述するものだ
と考えています。 少なくともこの違いの意味を理解して、それぞれのフェーズ
で一体何をアウトプットにすべきかを理解して欲しいと思うこと多いですね。
開発言語や実装技術しか知らない、興味のない技術者はどうしても思考が How
To に偏りがちのように思えます。少なくとも「ソースコードが最良の設計書」
と言う人もいると思いますが、ソースは結果的に as is でしかないとおもうの
ですがね。
Ahf
ハムレットさんコメントありがとうございます。
ご指摘の通り設計技法を知らない、という点も原因の一つだと思います。今回の場合はそれに加えて開発に用いる言語も知らなかったという複合的な事柄が原因かと感じています。
設計技法を知らない深めない技術者というのは私も多いと思っています。
特にAPの開発経験が豊富＝設計ができる、という微妙な勘違いを持っている方が多いように見受けられます。SEとしての技術は、PGを続けて得たもの以外にも必要なものが多いと思っているのですが・・・。
特に要件定義においては別領域の技法が必要だと思います。ただ業界の中においてもあまりそういう風潮がないのが何ともいえないところですね。だから問題プロジェクトの数が減らないとさえ思えますから。
shela
対象となっている開発言語で、何が出来るかということを設計者が知っていることが前提で、開発言語を知らなくても設計は出来る、というのはあるかと思います。
COBOL以外全く知らない設計者がASP.NETの設計が出来るとは思えませんし、当然ながら、組み込み、パッケージ、Web等の用いられ方の違いによっても考え方は大きく変わります。
結局のところ、自分が思うのは、各設計フェーズにおいてそのフェーズの担当者が他のフェーズの設計のことを全く意識しないというのは絶対にあり得ないはずで、担当者の経験が不足しているなら自力で覚えるか、有識者の意見を求めるべきだ、ということですかね。
期間に余裕がないプロジェクトが多いことは承知していますが、独善的にならず、他人の意見を「これは考慮すべき価値のあるものだ」と捉えられるだけの気持ちの余裕だけは失いたくないものです。
Ahf
shelaさんコメントありがとうございます。
案件の分野によって大きく設計も変化しますので、shelaさんの言われる通りだと思います。Ｖ字モデルだなんだと言われてはいますが、なかなか他のフェーズをしっかりと意識した技術者は、まだまだ数が不足しているかなと私は思っています。
有識者の意見を求めるとか、努力するとかそういう方向に向いてくれている方が多くなればいいですよね。
締めに言われている言葉は大切ですよね。私もその言葉を忘れないように努力していきたいと思います。