7/1付けでR3にJoinした山田 雄一です。
入社エントリを書いてよ～と社内から要望があったので書いてみますが、果たしておもしろいのだろうか などと思っています。
そもそもなぜこの会社に入ろうと思ったのか
前々職ではSIを15年弱、受諾開発が主でいろいろな案件をやっていたのですが、一般的な受諾開発というのはどうしても「金の切れ目が縁の切れ目」みたいな所があり、システム導入をしたはいいものの導入して安定運用した後は、しばらくすると保守もコストだよね なんて話になりがちです。
結果、そのエンドユーザ様がどうなったのかは正直よくわからない… なんて事が普通にありまして、その点に釈然としない物を感じたのと、その業務スタイルに飽きてしまった事もあって転職しました。(実はそのころに某ETLツールを担いでいた関係で、データ連携先としてkintoneはちょっとだけ触っていたし、実はエンドユーザサポートもそのETLツールのエキスパートとしてはちょっとだけやってた)
前職ではそういった「金の切れ目が縁の切れ目」がない世界（伴走的なスタイル）を求めて社内SE（システム内製したがる会社の）としてJoinしたのですが、まあいろいろとシステムに社内のひずみを全部乗っけるようなマネジメント（マネジメント？）だったのでアレだなぁと思っていたところに今回話を頂いて… という経緯だったりします。
なので、入社動機としては「エンドユーザと妥当性のある形で伴走するスタイルでIT業務がしたかったから」というのが理由の大きなところになります。
1つ目の理由としては ね。（2つ目がある そしてくっそ長いので気になる人だけお付き合い下さい。）
実は面接の時に言ってなかった理由がある
あまり誰にも細かく聞かれなかったので言ってなかったんですが、もう1ついいなーと思っていた大きな理由があります。(R3がというよりはkintoneエコシステム全体としての話が半分、伴走サービスが半分ぐらいの話になるのですが。)
ここら辺の思ってることを説明するには私のエンジニアとしての技術全体に対する技術観というのが伝わらないとよくわからないと思いますので、そこを簡単にまず説明させてください。
モジュール化に伴うとある現象について
まず大前提としまして、エンジニアリングを横断的に見たときにおけるエンジニアリングの一般測の一つに「一つの技術分野で起きた変化は、他の技術分野においてもどこかのタイミングで同様に発生する」という普遍性があると言われています。
過去にこういった技術イノベーションが技術分野を超えて起きた例でいいますと、、
・電子回路(真空管)で発達した信頼性工学により、1つ壊れてもシステム全体が壊れないようなシステム設計が戦後発達し、大抵のミッションクリティカルな分野で並列システムが採用され一般化した（らしい）
※参考：ja(jst.go.jp)
・機械設計や電子回路設計では一般的だったコンピュータシミュレーションをベースにした設計、シミュレーションがその他の設計分野でも大抵のケースで一般化した
※私の父が実は電子回路設計のエキスパート(高周波ノイズ対策特化の人だった)でそんなことを言っていた
また、例えばITに似た技術分野でいうと、エレクトロニクス(電子工学)関連の分野があり、たとえば電子回路設計の分野では素子や回路の集積化 というアプローチが継続的に行われてきています。
具体的な例も挙げてみましょう。たとえば簡単なラジオ（今では１００均で売っているような安価なもの）の設計実装を例にすると
- 素子単体を回路上で組み合わせて行う回路設計、実装
- ICをを回路上で組み合わせて行う回路設計、実装
- １チップICによる実装
という変遷を辿っているようです。また実際に上記の回路設計の粒度が今と比べてだいぶんシンプルであった１９８０年代ぐらいまでは家電などが故障した際には中を開いて故障したパーツを換装し、直した例がけっこうあったという話を伺っています。
これがいわゆる所の「モジュール化」という概念になります。
さて、この「モジュール化」ですが、楽になるように見えるのですが良いことばかり…というわけでもありません。（ITにおけるモジュール化はソフトウェアの内部構造の見通しが良くなるので基本的には歓迎されがちなのですが。）
例えばある製品が
(入力)→[モジュールA]→[モジュールB]→[モジュールC]→(出力)
といった構成になっていた時に、モジュールとしてはそれぞれ単体では上手く動いているが、全体としてみたときにモジュールが意図しない形で干渉しあってうまく動かない なんて事が起きるケースがあります。
※そういったケースではモジュールとモジュールの間に干渉を緩和するような調整を入れたりするわけです。
ITとそれ以外をつなぐという概念について
もう一つ、言及しておかないといけない概念があります。昨今はあんまり聞かなくなりましたが、ITの世界には「グルー言語」と呼ばれるものがあります。初めて聞かれる方にはなんのこっちゃ という感じがあるかもしれませんが、要は紙をはっつけたりするノリ(Glue)に例えて、システムをシステムを接合するような使い方をするプログラム言語を指す言葉です。一昔前にWeb系システムの開発で使われたPerl言語などはもともとこのグルー言語としての役目を期待されて開発された…(はずです。本にも記載があったはずですが実家に置きっぱなしなので確認ができていない)
※参考：グルー言語 - Wikipedia
手触りの良いＵＩや機能を足せるという筋の良さ
最近はスクリプト言語を直接使ってシステム間をつなぐ というケースも随分減ったような気がする(手触りの良いETLツールとかありますしね。)のですが、ＩＴシステムにおけるインターフェースというのはそういったシステム対システムだけでなく、人に対しての接続点も重要です。ただし、前述の「モジュール化に伴うとある現象」にも記載しましたが、システムと他との接続点というのは意外に狙った通りにスマートにつながってくれない なんて側面があったりします。
実際、パッケージソフトやWebサービスのUIって、上手く使うのがしんどかったり手になじまなかったり、はたまた現場の業務フローに合わなかったり という話が起きがちですよね。
こういった話は、従来のITシステムの利活用ケースでは人がシステムに無理やり合わせに行かないとダメで、結構しんどかった所であったような気がしています。
ですが、kintoneエコシステムやカスタマインを上手く使うことで、既存の基幹システムに大きな影響を与える事なく、データエントリーやデータ利活用機能を気軽に足してＩＴを上手く使い、手早く改善プロセスを回せるのは非常に筋が良いな…と思って見ていたのですが、今回R3にジョインさせて頂きましたので、そういった点から皆様のお手伝いができれば良いなと思っています。
