とあるIT屋の独白

ITや経営について主に書きます

日本のITとモノについて考えてみる

日本のソフトウェア産業は海外に比べると遅れをとってると、けっこう前から言われていることではあります。下記の記事にあるとおり、ハードが主流だった時代は日本はまぁまぁ良い位置にいたのに、なぜソフトウェアとなるとダメになるのかというのは、けっこう面白い考察です。そこには、日本人の特性であったりソフトウェア産業の成り立ちだったり、諸々の要因が考えられるのですが、今回はそんなことを書いてみたいと思います。

qiita.com


元々、日本には下記の記事にある通り、「モノには魂が宿る」という考え方があります。例えば、日本刀とか茶碗なんかは分かりやすいですが、職人が手間暇かけて渾身の一作を作るみたいな雰囲気です。ビジネスというよりは、どちらかというと芸術家のほうが雰囲気的には近いと思っていて、いかに良いものを作るかという自己実現的な領域で職人なんかは仕事しているのかなと感じます。

business.nikkei.com

 

そんな文化を持つ日本のソフトウェア開発は下記の記事にある通り、「製造業」に近い特性を持っていると言えます。つまり、高い品質を志向して、そのソフトウェアが完璧に動くといったことが追求されてきています。ただ、アメリカはその発想とは違っていてソフトウェアは「ビジネスの道具」です。なので、決められたものを完璧というよりは、いかにビジネスとして成り立つ形にしていくかという発想なので、そもそもの出発点は違うかなと感じています。

blog.goo.ne.jp


そして、なぜ日本では製造業の考え方がソフトウェア開発の出発点になっているかというと、元々ソフトウェアがハードウェアの付随品としての位置付けだったからというふうに私は感じています。昔はメインフレームという大きなハードウェアがあって、そのハードウェアの上で動くソフトウェアという考え方な気がします。だから、ITベンダーに発注するときユーザ側は「コンピュータ」というハードを買っているのであって、ソフトウェアを買っているという意識が無かったように思います。

gendai.ismedia.jp

 

ただ、それは昔の話であるにもかかわらず、いまだにソフトウェアはハードウェアの付属品としての位置付けで丸っとITベンダーに発注、という考え方から長い間脱せていないと私は考えています。だから、ビジネス環境やエンドユーザの反応に応じてソフトウェアをアップデートし続けるということに遅れて、ソフトウェアビジネスの主導権をアメリカや中国に奪われてしまったと感じます。
しかし、今の段階で日本が巻き返せないのかというと、そうでもないと私は考えています。ビジネスの道具としてのソフトウェアを追求していたアメリカですが、一方で下記の記事にある通り、それはどうなのよという意見も上がってきています。

itnews.org


今後、ソフトウェアの世界でも「本当に良いもの」が求められてくるフェーズにきているのではないでしょうか。もちろんビジネスも大事ですが、それに加えて「完成度の高さ」や「洗練さ」の重要性も上がってくると考えています。だから、アメリカの手法を真似するだけでなく、独自の哲学や文化的要素を取り入れ、より良いソフトウェアを昇華していくような取り組みが大事になってくると思います。ユーザの目が肥えている中で、いかに良いものを出していくかという日本人の強みを活かしたソフトウェア開発の新しい形が、今後の日本が追い求める一つの姿なのではと私は感じます。

レールに乗ることについて考えてみる

人生のターニングポイントってふと考える時はないでしょうか。過去を振り返ったらあの時がターニングポイントかなと思われなくもないのですが、長く生きてると人それぞれなのかな思います。私は今まで生きてきた中でもそれっぽいのもある気がしますが、まだ明確にこれというのも無い気がしています。
若い時にやりたいことが見つかって、それを続けてこれればそれは幸せなことだと思いますが、そうじゃない人もいると思います。かくいう私は中学・高校・大学と特にやりたいこともなく、かなり適当に過ごしてしまったので、やはり後悔は無くは無いかなという感じです。学生時代はこれといって、何かに打ち込んだ時間を過ごしてはいなかったかなと思います。
もちろん、やりたいことが無いのであれば勉強なんかせずに、まずはやりたいことを探せ、という意見もあるとは思います。ただ、個人的にはやりたいことがなくても、とりあえず勉強して進学するというのも悪い選択ではないと考えています。下記の記事のように、まずはレールにのってみて、ある程度まともと言われてる道を歩くのは今後の人生において無駄にはならないと感じています。

takope.net


社会人になってからの私は、どちらかといえばレールから外れてしまった方かなと思っています。同年代で会社の役職に就いたり、起業したり、私よりも年収もらってる人は、ごまんといると思います。もし仮に私が以前勤めていた会社を辞めずに勤め続けていたら、レールに乗れている状態だったかもしれません。
社会人になってから大きなターニンングポイントのようなものは無い気はしていますが、少しずつですが自分のやりたいことが見えてきた感覚があって、数回転職したのもこのやりたいことを優先したからかな、とは今思うと感じます。下記の記事にあるように、人生のターニングポイントは40歳代が多いという人が多く、もしかしたらまだまだ転換点はあるかもしれませんが。

shuchi.php.co.jp


一方で、この変化が激しい現代で今までレールに乗り続けられたから今後も大丈夫、という保証はどこにもありません。大企業でも平気でリストラを行う時代です。自分がレールから外れる恐怖みたいなのは持ってる人も多いと思います。私も今は会社員ですが、いつか会社が潰れるかもしれないし、自分がクビになるかもしれない、というのは頭の片隅にあります。で、その恐怖に打ち勝つには、自分がやりたいことをやれてるという実感だと私は考えています。今やりたいことが少しでもやれていれば、たとえ今の場所にいられなくなっても次探そうという気持ちも出てくるし、やりたいことはがんばれるし、続けていこうという姿勢になると思います。
ただ、次の場所に行こうとする時は、どうしてもある程度「レールに乗っていた」事実が求められてしまうことが多いです。レールに乗っていたことは、将来において選択肢を広げる手段になると思います。だから、今やりたいことが無い人でも、拙速に無理してやりたいことを見つけようとせず、レールに乗るという選択を取るのも全然悪くないと思います。いざ、やりたいことが見えてきて人生のターニングポイントと思われるものが来た時に、乗っていた経験は必ず価値になると私は考えています。

話が通じないということに感じること

自分の話が通じない、と感じるときは多くの人が経験していることかなと思います。そういうお前は人から何か言われて話が通じるのか、と言われると正直自信がないです。では、この「話が通じない」という現象はどのような時に起きるのか、というのを少し考えてみたいと思います。
まずは一般論として、話が通じない人にみられる特報が以下の記事にまとめられています。自分が正しいといった思い込みや、感情的になるといった点は、けっこう納得できる部分もあるかなと思います。

the5seconds.com

 

さて、話が通じないといっても、こちらが言うことが100%全く通じないということはけっこう稀であって、たいていは「通じない部分がある」ということが多いと思います。それは人によって思考のタイプが異なることも一因していると感じています。下記の記事のように、「ゴール指向問題解決型」と「プロセス指向共感型」で、各々の思考の仕方が違う場合、最終的な結論については同じになるケースでも、そのプロセスにおいて通じない部分が発生する頻度が高くなる気がします。

studyhacker.net


もちろん、タイプが違うだけで通じないことが発生するのではなくて、お互いの思考プロセスがある程度認識できていれば「話が通じない」ということは少なくなるように感じます。
一方で、こういった話をする行為自体を諦めてしまうという選択肢もあると思います。例えば100%全く通じない相手が現れて、こっちが何話しても聞いてくれないという状況に陥った場合は、諦める選択もありだと思っています。そのような場合は思考プロセス以前の問題で、信頼関係が崩れてしまっているので。
親子関係において、例えば子供が全く親の言うことを聞いてくれないと言うこともあると思います。反抗期と一言で言えばそれまでなのですが、その反抗期になるきっかけみたいなのがあると個人的には感じてます。そもそも、親がちゃんと子供の言うことを聞いたり、信用をしてんのかってのが大事だと思ってて、それがどれだけ出来たのかは後々にひびいてくる気がします。

toyokeizai.net

 

ただ、一方で今思うと、この信頼関係はお互いの背景を理解することでも、生まれてくる気がします。その人の背景が分からないと信用するの難しいと感じてしまうこともあるし、言ってることも表面上は理解してるように見せてはいるけど、しっかり理解はしてないようになってしまうこともあると思います。親子関係でも、子供が親から離れていくと、段々とその思考プロセスの背景が読みにくくなるといったことも出てくることもあるでしょう。
背景を理解するようにすれば自ずと信頼関係も醸成されるのではと考えています。逆もまた然りで、背景をしっかり理解出来ていなくても、とりあえずその人の言葉を信頼し続けることで、何となく背景も見えてきたりすることもあります。結論としては、その人の背景を理解することと信頼関係を築くことは相互に関連してると私は思っていて、どういうアプローチをとるにせよ、人と話を通じさせる上でこの2つを意識する必要はあると感じます。

モバイルのUIデザイン

Webのページをスマホで見ることも当たり前になっていて、多くのページもスマホに合わせたレイアウトにしてると思います。スマホのデザインは個人的にはPCよりも難しいと思っていて、限られた画面の中で何を表示させるべきか、より工夫しないといけないと感じます。かく言う私は、PCのビジネス向けのアプリを今まで仕事では中心に開発していたこともあり、一画面にかなりの情報を詰め込んでしまいがちです。
色々なサイトを見ていると、スマホのUIデザインもけっこうパターン化されている感もあります。以下のサイトで色々な例を紹介しているページがのせられているのですが、例えば同じ業種であったりするとデザインも似てくる感じはします。

www.kerenor.jp

 

下記の記事によると、従来のUIの考え方では「大きな要素や明るい要素に人の視線が向けられるだけでなく、そこに長くとどまる」とのことだったそう。ただ、モバイルのUIにおいては、「視線は探索や閲覧の起点として、左上隅に流れる」であったり、「テキストが重要な役割を果たし、ユーザーはモバイルアプリケーションのテキスト要素に注目する傾向」があるそう。たしかに、上述で紹介されてるサイトの例でも、テキストの見せ方は工夫されてる感じは見受けられます。

www.atmarkit.co.jp

 

テキストの使い方については、以下のNetflixの記事が参考になります。コンテンツとタイトルを別で管理してるようで、以前見たタイトルの内容とは別のものが出るそう。また、ユーザーが経験する段階に応じて、説明なども出し分けている見たいです。
こういったユーザー飽きさせない仕組みを、テキストを上手く使って表現してます。

note.com

 

ローコードの有用性についてあらためて考えてみる

昨年に私のブログで、ローコードについて取り上げてみました。この記事では、ローコードとは何かというのと、従来のコード生成ツールとの違いと思われる点を挙げてみました。

toaruit.hatenablog.com


ちなみに、ノーコードとローコードの違いは、ざっくりソースコードを直で書くことが有るか無いかの違いなので、本質的にはやりたいことは同じと考えます。ので今回の記事でも、記載は「ローコード」に統一したいと思います。が、参照とする記事についてはノーコードと表記しているものもありますので、予めご了承ください。
さて、ローコード開発のメリットの大きなところは、非エンジニアであっても開発ができる点です。下記の記事のようにあえて開発の間口を広げるために、ローコード開発を採用するといった手段もあります。

www.atmarkit.co.jp

 

個人的には、ローコードツールを使うこと自体は肯定的で、短期間で簡単にシステムが作れるなら、エンジニアであっても積極的に採用すべきと考えています。また、けっこう言われるようなプログラミングの仕事がなくなるというのは、まだまだ先の話で、当分はローコードツールで実現できないような内容はプログラミングでの実装が必要と思います。下記の記事にあるようなWordPressの例など分かりやすいと思いますが、WordPressがここまで普及したからといってエンジニアの仕事が減っているということは現状ないかと思います。

tane.tech

 

ローコードツールを使えば生産性が上がる、という考えは現状はあまり正しくなく、「適切な用途で使えば生産性が上がる」が正しいと考えています。下記に挙げている「OutSystems」というツールの例で、「DBと密結合」、「周辺ツールが充実していない」、「IDEが弱い」等々の課題が挙げられていて、ローコードツールを導入するにもエンジニアの視点で使い物になるかの精査がまだまだ必要と思います。

qiita.com

 

下記の記事で例えられている通り、「RPGツクール」的なところが、ローコードツールの現在位置ではないでしょうか。RPGツクールであっても、お作法的なところが大事だし、何も知らない人がいきなり作れと言われても厳しいものがあると思います。もちろん、RPGツクールのほうがプログラミングを一から勉強するよりも学習コストは低いわけですが、その分できることも限られてくるわけです。学習コストと作りたいものを天秤にかけてどういった手段が果たして適切かという吟味をした上で、ツールの導入をすべきであると感じます。ローコードツールを入れれば簡単にシステムを作れるという単純な話では、まだまだないのかなという感触です。

mizchi.dev

ITの多重下請け構造について考えてみる

少し前に話題になった、GitHubに業務ソースコードをアップしてしまった件、掘り下げると色々な要因が考えられると思います。もちろん、アップしたエンジニアが悪いのは言うまでもないのですが、そのエンジニアを取り巻く環境がなかなかに今の日本のIT業界の悪き構造のような感じがして、個人的には興味深く感じています。下記の記事で、徳丸さんが言うように、多重下請け構造という部分だけが問題ではなく、リテラシー教育であったりであったりとか、もちろん端末側で制限をかけるといったセキュリティ対応の不十分さも考えられると思います。

www.itmedia.co.jp


ただ、やはり多重下請け構造という問題はかなり根深いと思っていて、この構造が続く限り今回と同じ事象ではないにしろ、大きなインシデントが起きるのではないかと思っています。ということで多重下請け構造に関して今回は私見を書いてみたいと思います。
まず、IT業界の多重下請け構造ってどんなのかというのが、下記の記事にまとめられています。ITの案件で大規模なものになっていくと、元請けの会社だけで対応するのが難しくなってきます。そこで元請けがまた下請けに出していくのですが、それが多重になると3次請け4次受けといった話も珍しくはないかと思います。

setenshoku.jp

 

で、当然働く人の単価も上に上がればあがるほど、高くなる構造になっています。したがって下位の階層で仕事をやってる人が、どんなに優秀でもどんなに成果を出しても、上位の階層の単価を超えることはほぼ無いでしょう。
また、多重下請けの大きな問題の一つが、中抜き業者の存在です。こういった業者は自社のエンジニアで対応させず、右から左へ案件を流してマージンだけ抜いていきます。もちろん、中抜き業者の信用で案件が取れてる側面はあるのですが、これが横行してしまうと実対応を行うエンジニアの単価がいつまでたっても上がらないといったことにもつながります。
では、なぜこういった多重下請け構造が成り立つかというと、古くからあるSIerビジネスが一つの要因として挙げられると考えています。SIerは顧客のITに関する対応をまるっと請け負う形で、ビジネスを行ってきました。もちろん、ITがまだ一般的でない頃はこれでもいいのですが、これだけITが身近になった今でも、まだこのビジネスが成り立っています。つまりITのことがよく分からないユーザが、とりあえず大手のSIerにまるっと投げて、SIerはそれを下請けに出して案件数をこなし利益を稼ぐ構図です。

note.com

 

では、なんでこのSIerのビジネスが成り立つかというと、ユーザ側の企業がITに関する価値を精査できず、言われるままに高い費用を支払ってきたから、と私は感じます。もちろん、ユーザ側の企業も自分達でITの部隊を揃えるような動きはあります。ただ、直近はSIerビジネスが成り立ってしまうくらいには、まだユーザ側のIT力が高くないというところが現状でしょう。
全部が全部ユーザ企業が、システム構築をしなきゃいけないということではありません。外部のエンジニアのリソースを使う必要性は絶対に出てくるでしょう。ただ、そこで「丸投げ」するか、ちゃんと自社で中身を把握するかで、かなり違ってくると思います。ITがビジネスで重要になっているからこそ、ソースコードは重要な資産であると私は考えています。また、そのソースコードを生み出すエンジニアは重要な存在です。GitHubでコードが流出したケースでいくと、コードはちゃんとユーザ企業がレビューしたか、そのコードについて信頼できる人に開発してもらったのか、エンジニアに対して使用感などフィードバックしたか。こういった心がけが、「自分の価値が分からない」といったエンジニアの不安をやわらげ、業務コードをオープンなところに上げなくても自分の価値がなんとなく感じられる状況を作れるのではないでしょうか。

UEMとは何か

セキュリティ関連のニュースを見ると、時々「UEM」という単語を見かけるときがあります。UEMは「Unified Endpoint Management」の頭文字をとったもので、日本語に訳すと統合エンドポイント管理となります。これだけだといまいちピンとこないと思うので、少し調べてみました。
コロナの影響にあって、自宅などでノートPCやスマホを使っての仕事も、珍しくなくなってきてます。ただ、同時に各地に点在するデバイスを管理しなければいけなくなって、そのときの端末管理のためのツールがUEMになります。下記の記事にある通り、ツールを使ってOSやアプリケーションのインストールや、端末状態の把握が行えます。

cybersecurity-jp.com

 

実際の機能の詳細は、MobileIronという会社が提供してるサービスが参考になります。機能がけっこうあって、ユーザの連携やアプリを企業用・個人用に分けるといったことも、できるそうです。

www.hitachi-solutions.co.jp

 

UEMは基本的に多機能で、下記の記事にあるMDMやMANなどの機能を統合したものとなります。自社にとってそこまで必要かというのはあって、どういう製品を選べばよいかというのはけっこう混沌としてるみたいです。

note.com