地方エンジニアが感じる地方・中小企業での悩み

手段と目的と

»

 エンジニアに限った話ではありませんが、ある領域に関連するスキル群は膨大な種類があり、すべてを身に付けることはできません。

 プログラミングを行う部分に限定したとしても、その多さは多岐にわたります。また、特定領域に限定されたスキルというのもありますが、広範囲に関わるスキルもあり、どれをどう身に付けていくのがよいか、考えるだけでも大変なことではないでしょうか。

 個人的な考え方としては「一点集中」を好んでいるというのもあり、何か1つ特定の領域に長けることを目指していたいのですが、実際に業務をこなすことを考えると、それはあまり好ましいことではありません。

 非常に高度なプログラミングスキルがあったとしても、案件をこなすためには他にも多くのスキルが必要となります。

 それは例えば、キーマンとなる人たちとの折衝であったり、プロジェクト全体を視野にいれつつスケジュールの調整であったり、メンバーが多くなれば、その中でも調整を行わなければならないでしょう。このように「開発する」と一言で言っても、その状況によっては求められるスキル、必要となるスキルは大きく変化します。

 また同じスキルの種類であっても、状況によって必要となるレベルも変化します。1人~数人でこなす案件で必要なレベルと、数十人からそれ以上の案件で求められるレベルは異なりますし、その性質も変わってきます。

 少人数向きな案件でのスキル・レベルで、大人数の案件を同じように行おうとしても、うまくいくことは少ないですし、反対に大人数の案件でのスキルを少人数の案件でそのまま発揮しようとしても、うまくいきにくいでしょう。

 例えば、スピード感が求められる案件で、よく言えばしっかりとしたSIer的手法を用いてもうまくいきません。そしてその逆のケースとして、しっかりとした方式を求める相手に対してスピード感を感じさせるような方式で臨んだとしても、これはまたうまくいきません。

 特に、最近はSIer的手法を軽視する風潮がありますが、その多くは「向かない領域に適用しようとしている」のが根本の原因で、決して手法自体が悪いことではないと思います。プログラミング言語についても同様で、ある言語向きの手法を別の言語にもそのまま適用しようとしてうまくいかないケースを、例として用いていることが見受けられます。

 これらを見ていると、どうにも「万能な手法」を求めているように思えてなりません。どのような案件でも「このとおりやればうまくいく」、どのような言語でも「こう開発すればうまくいく」――こうした度を越した願いや希望が、ここ最近の特定分野への批判などへ繋がっているのではないでしょうか。

 今まで培ったノウハウをそのまま利用できればそれに越したことはありません。ですが、それは決して叶わぬ願いです。時代が進み今よりももっと汎用的に利用できる言語やプラットフォームが出てくれば話は変わりますが、まだまだそこに到達できるほど成熟してもいません。

 特に、IT分野はこの傾向が強いと感じます。

 クラウドの世界がようやく利用しやすくなり、多くの場面で活用されるようになりましたが、その世界にオンプレミスなルールを持ち込んだところで、土台が異なりますし、環境も異なるのですから、うまくいかないでしょう。

 前提となる条件に適した方法を用いなければ、存在する多くのメリットを打ち消してしまいます。少しのデメリットのために多くのメリットを打ち消すのは、非常にもったいないことだと思います。

 本来であれば、目的のために手法を選択するのが正しいやり方なのですが、気が付くと「手法ありき」で進めてしまっていませんか。今までの経験上こう進めるのが適しているはず、こういう管理を行うのが必要なはず、と「~であるはず」といったあまり根拠のない考えから、疑問を持たずに推し進めようとしている場面を多く生み出してしまっているようにも思えます。

 「銀の弾丸などない」――頭の中では、こう理解している人がほとんどだと思います。

 ですが、現実になると、どうしても銀の弾丸を求めてしまう人が多く、それうまく進まない案件が生み出されてきているのではないでしょうか。わかってはいるけどもつい、このような気持ちで日々の業務と向き合われている方が、恐らくはこの業界に限らずどの界隈でも大多数なのだとも思います。

 今までやってきたことを無にして、とまでは言いませんが、初心に還り、いま直面している状況に対して何が有用なのか、どのような方法であれば効果が高そうかと、改めて考えてみることも重要ではないでしょうか。

 それを繰り返すことによって、ゆっくりとかもしれませんが、あなたを取り巻く状況が変化していくかもしれません。

Comment(5)

コメント

ここ数年間、このコーナーでは、特定の言語、特定の技術に固執した人たちのコメントが、大陸間弾道ミサイルのように飛び交っています。高い技術を持っている人ほど、自分の得意分野の土俵で戦いたがるものかもしれません。

「今までやってきたことを無にして、今何が有用か改めて考えてみる」

Afhさんの意見は立派なものであり、多くのエンジニアが耳を傾ける価値があると思います。

プログラムで飯を食っていく場合、もっとも重要なのは、お客の求めるものが「完成」できることですよね。
そして、それが商売としては「目的」になるわけですがー
自分の理解できない「手段」では「目的」を達成できないので、その「手段」を否定したりもしますね。
これはセンスの無さから生まれるわけですがー
先入観から間違った理解のもとに、「手段」の使い方を間違っている場合にも似たような状況になりますね。

深く1つの技術に使っている人ほど、先入観は強くなりがちですが、センスがあれば、他の技術の本質を見て、
自分のものにするのも早かったりします。
逆に広く浅くの人は、先入観はないのでしょうが、技術の本質を見るのは難しいですね、浅いんですから(^^;
本を沢山読んで、理解できていると錯覚している場合は、そうなりやすいですね。
知識があることと、使えることは別なんですが・・・
プログラムの世界だと、現場に居た人じゃないと、その差はわからないかもしれませんね。

基本的に新しい技術は、なんらかの利点があるから生まれるわけで、その利点を理解できなければ、良いものに見えないわけです。
利点を見つけられないってのは、センスの無さでしょうね。
例えば、私は自分のセンスの無さから、ラムダ式やtupleを便利だと感じられません。
逆に便利だと感じられるようになれば、センスが鍛えられたということだと思うわけですがー
内容からすると、自分の仕事では利用される頻度が低いもののような気がするので、よほど面白いサンプルに遭遇しない限り、
私が、この手のセンスを得るチャンスは少なそうですw

クラスに関しても、何が便利か最初はわからなかったですねぇ。
「構造体に関数いれてなにが便利なの?」ってのが初期の疑問だったわけですがー
あるとき、動物の鳴き声サンプルをみたときに、世界が広がったんですねぇ、「あぁ、そういう発想もあるのか」っと。
これを「ポリモーフィズム」と呼ぶと知るまでには、かなりの時間がかかりましたがw

「目的」と「手段」の優先度が逆になっている例で、もっとも多いのは、「○○だから××できない」ってパターンかな。
これは、「○○じゃなければ、××できるかもしれない」に繋がればいいんだけど、そこで終わる場合も多いわけでー
1つ1つは小さなことでも、累積すると、簡単に「手段」のほうが「目的」よりも優先されてしまい、
「手段」のために「目的」を変えるという駄目パターンが生まれるわけです。
「目的」の本質を変えなければ有効だったりしますが、1つを許すとズルズルといってしまう罠がw

アラファイブ

昨日「素数夜話」という本を読んだのですが、メンバ2つの複素数やメンバ4つの四元数でも
数学的にはものすごい複雑で芳醇だそうです。

クラスや構造体やレコードはそれこそ何十元数である訳で、人間にうまく扱えるはずが無い、
あるいは元の数が多すぎて逆に複雑さが無くなる(トリビアな構造しか残らない)とかある
のかも知れません。
なにか今までやってきた事に制限を加えると、なにか出るのかも知れません。

ただ、フレームワークなんかその例かも知れませんが、制限の加え方が変で、
どうも困っていない所を助けてくれて、困っている所を余計ひどくする傾向があります。
(「DB技術者は貴重で、アプリ技術者はすぐ調達できる」ので、DBを隠蔽するとか)

もちろん、何がどうであっても、メンバ1つのSTATICのみにするというのは、どう考えても
行き過ぎです。

技術セットのどれか一つを覚えるのすら大変なのに、
いくつも覚えてその中から適切なものを選ばないといけない。

どうしても自分が詳しくないツールの得意分野は、
必要ないと思う傾向が出てきてしまいますし。
適切なものを適切に選ぶには、すべてに詳しくなくてはなりません。

プログラマーとしての技術を覚えるのは大変なものですね。
人ひとりの一生で覚えきれるものなのか、自信がなくなってきます。

確立していると信じていたものが実は違う、認識がずれているというのは、よくある話。WBSを引き直す前に、タスクの再構成からしなくてはならない場合もあります。

コメントを投稿する