ソフトウェアの複数の視点
株式会社株式スタイルの後藤秀典です。
この番組では、エンジニアリングチームで起きている問題について、
技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、今後ソフトウェアエンジニアに求められるマインドセット、です。
どっちかというと、僕自身がこういうマインドセットを皆さん持ってくれたらいいな、というような願望の話だったりもするんですけれども。
その願望に加えて、僕がソフトウェアをどう見ているのか、というようなところも、
あれこれ話してみたいと思っていますので、
もしかすると皆さんのヒントに色々なるんじゃないのかなと思っていたりします。
エンジニアリングマネージャーの問題集。
今日はですね、エンジニアに今後求められるマインドセットというか、
色々僕がどういう風にソフトウェア開発というのを見ているのか、みたいなお話をしようかなと思っています。
最初にですね、まずソフトウェア開発というのかな。
この辺り、設計方法論みたいなものとか色々あるんですが、
そういうのとは別に個人個人が、ソフトウェアエンジニアが、
ソフトウェア作りだったりソフトウェアっていうのをどういう世界観で捉えているのか、
これを僕はソフトウェア観、観というのは観察の観なんですけれども、世界観みたいなやつですね。
ソフトウェア観っていう風に僕の中では呼んでいて、あんまり出てこない、見かけない用語だと思うんですけど、
そういうソフトウェア観っていうのを僕は一体持っていると思っています。
まず僕が今の時点でどんなソフトウェア観を持っているのかというところからお話してみたいと思います。
最初に言ってしまうと、僕はソフトウェアっていうのは、
まず3つの視点で考えられるべきだという風に思っていて、
ものすごくソフトウェアの中の話っていうよりは大きく捉えた時なんですけれども、
当たり前の話かもしれないんですが、1つはユーザー、ソフトウェアを使う人ですね。
もう1つはソフトウェアを書く人、これはだからプログラマーです。
聞いている皆さんはどっちかというとプログラマーであることが多いかなと思っています。
その2つとは別にもう1つの視点として、
ソフトウェアっていうのはほとんどの場合コンピューターの上で動作するものかなと思いますので、
このコンピューターというのもソフトウェアを考える時に大事な要素かと思っているので、
僕としてはこの3つですね、ユーザーとプログラマーとコンピューター、
この視点でもってソフトウェアを捉えるっていうのがバランスよくソフトウェアを見ることにつながるかなと思っています。
とはいえこの3つの視点というんですかね、登場人物が平等なのかというとちょっと違うというか、
当然この3つが全く同じ役割で登場させているわけでもありません。
やっぱり目的に対して作られるっていうところから、
その目的というのはやっぱりユーザーのために何らかの処理をするというか、
アウトプットを出すというかね、
いうために存在しているのがソフトウェアだと思うので、
何においてもまずユーザーというのが第一でしょうというふうに思っています。
どういう環境で動くのかっていうのもソフトウェアを作るときには色々要素として考慮しなきゃいけないので、
コンピューターというのは出てきますし、
プログラマーというのはその2つに対して、
そのソフトウェアを何ですかね、
作る人ですよね。
作る人として存在してますと。
こういう関係性です。
で、なんかこの見方からじゃあ、
プログラマーのイメージ
なんかどういう話ができるのかということなんですけれども、
ソフトウェアの設計みたいな話をするときにも、
この3つの見方っていうのは大事かなと僕の中では考えています。
で、
ソフトウェアは本来ユーザーのために存在するんですけれども、
エンジニアたちの、
聞いてる皆さんはそうじゃないかもしれませんが、
SNSってよく見かける議論というか、
目立ってる、シェアされてる記事だとかいうもので、
多くのものはプログラマーのためのノウハウというか、
プログラマーのための設計の話っていうものが多いのかなと思っています。
例えば設計方法論だとか、ソースコードをどううまく書くのか。
これは技術的不採用、填材するとかそういう話もそうだし、
いろんなクラウドの上で動かしますみたいな。
これはある種ちょっとコンピューターサイドの要素も出てきますけれども、
どちらかというと作る人、プログラマーのため、
もしくはプログラマーが集まった集団、
組織のためにソフトウェアをどう設計するのか、
どういうソフトウェアであるべきなのか、
みたいな話をしているものがほとんどかと思っていて、
逆に言うと当然かもしれないんですが、
ユーザーのためにどういう設計しましたっていう話って、
あんまり見かけないんですよね。
それってどっちかというとプロダクトのための、
プロダクト設計の話っていうふうに皆さんは思うかもしれませんけれども、
決してそういう棲み分けでもないはずなんですよね。
皆さん大好きかもしれませんが、
ドメイン駆動設計なんかの話で言うと、
ソフトウェアの中に作り込んだモデル自体が、
ユーザーに対する価値を生み出す原生になるんだ、
みたいなそういう考え方でもあったりするので、
そうするとユーザーのための設計っていう要素の話が、
もっともっとソフトウェアの設計の話として出てきてもいいような気がするんですが、
それぞれの会社でやってることでシェアできる程度が違ったりもするので、
そういった都合でなかなか世に出てこないという側面もあるのかなと思うんですが、
ちょっとそのあたりの話は置いといて、
この三つの視点というやつですね、
ユーザーとコンピューター、プログラマーみたいな視点が、
設計みたいな話をするときにも、
誰向けの話なんですかっていうのを整理するときに役に立つのかなと思っています。
かつ多くの議論って割とプログラマー向け、
作る人たち向けの設計の話になっちゃってるのかなという気もしています。
これは時代の流れというか、
より持続的に組織的にソフトウェアを扱っていかなくちゃいけないっていう、
時代にもなってきてるっていうところを反映してるだけなのかもしれないですよね。
よりどううまく一つのソフトウェア、一つじゃないかもしれませんが、
ソフトウェアを作っていくのかっていうところに、
価値があるというんですかね。
必要性が高まっているという側面もあると思うので、
そういった議論が増えていること自体を悪いと言ってるわけではないんですけども、
客観的に見るとそういう形になっているなというところです。
今の3つの視点、ユーザー視点、コンピューター視点、プログラマー視点みたいなもので、
ソフトウェアを捉えましょうというところと、
ちょっと違う観点なんですが、
今、僕がソフトウェアを、ソフトウェア作りをどう見てるのかっていう話をしてるんですけれども、
一つ付け加えておきたい、僕の見方っていうのがあって、
ソフトウェアって、だいたいソースコードを書くじゃないですか。
ソースコードを書いたら何かが動くみたいなものだというふうに、
簡単に言うと説明できるので、
ある種、ソフトウェアっていうのはソースコードですというか、
もちろんコンパイルしたりするんで、
完全にソースコード自体がソフトウェアっていうふうには言えないっていうふうに厳密には思うかもしれませんが、
ざっくり言うと、やっぱりソースコードの集まりっていうか、
それを指して、それがソフトウェアです。
動いてるものはちょっと違うところにデプロイされた実態かもしれませんが、
とはいえやっぱりソースコードがソフトウェアですっていうような、
暗黙的な理解っていうんですかね。
そういうのは一定多くの方が持ってるんじゃないのかなと思っています。
ちょっと言い方のニュアンスの差はあると。
僕はですね、それ自体はあんまり否定するものではないんですけれども、
ただソフトウェアっていうものを指したときに、
ソースコード以上に大事な要素があると思ってるんです。
それは何かっていうと、先ほどの3つの要素で言うと、
プログラマーサイドのことになるんですが、
プログラマーの脳の中に作られたソフトウェアのイメージっていうんですかね。
抽象的な言葉になっちゃうんですけれども、
その部分もソフトウェアそのものっていうよりはソフトウェア作りに、
ものすごく大きな影響を及ぼす要素、パーツかなと思っています。
僕が思っているソフトウェア作りっていうのは、
まずプログラマー、当然何を作るかとかが決まってる前提だとすると、
何を作るのかっていうことに対して、
プログラマーがまず頭の中に作りたいもの自体を理解し、
その作りたいものに対して、
これはソースコードと結構インテラクティブにグルグルするところかもしれませんが、
それは言ったまきにおいては、プログラマーの頭の中に
ソフトウェアとしてどういう形で作るのかっていうようなところを、
いろんな形もソースコードの文字を頭の中に浮かべる人もいるかもしれませんし、
そうじゃない抽象的な図形的な表現みたいなもので思い浮かべる人もいるかもしれませんが、
いずれにしても結構プログラマーの脳の中には、
作るソフトウェアシステムの何らかのイメージですね、
っていうのがまず結構ちゃんと作られると思うんですよ。
そのイメージを持ってソースコードを書いていくっていうことをしてると思っています。
何が言いたいかっていうと、
この脳の中にある程度像を描いて、それを形にしていくっていうところの、
脳の中に描くっていう活動の比重っていうんですかね。
これがものすごく高い仕事だというか、
他の活動と比べて脳の中に描かなきゃいけないものの量というか重要さというかが非常に大きいと思っています。
ソフトウェア作りの特徴
ここにソフトウェア作りの特徴があると思っています。
極端な比較で言うと、マニュアルを見てやれるような仕事っていうのもあるわけじゃないですか。
そこに書いてある通りにやればできるような仕事っていうのもある中で、
ソフトウェア作りっていうのは決してマニュアルを読めばできるようなことではないというふうに思ってるわけです。
そうではなくて、作りたいものに対してどう作るのかっていうのを、
プログラマー自身がものすごくいろんな周辺知識の理解とともに頭の中に作り上げて、
さらにそれをソースコードっていう形に落とし込んでいくっていうような活動なんですよね。
この頭の中に描くっていうところが若干話がそれると、
特にチームで仕事をしたりするときに、
描いてるものってなかなか同じにならないので、
これをどう同じ認識にさせるのかっていうところに時間というかコストを使わなきゃいけなかったりしますし、
もしくは組織で長期間運営していくみたいなときに、
その頭の中にあるような理解をどうやって引き継いでいくのかというところも問題になったりしますよね。
ドキュメンテーションすれば一定程度は引き継げますけれども、やっぱりそれがちゃんと引き継いだ人、
公認者みたいな人が前任者と同じ程度でソフトウェアを扱うためには、
その引き継いだ人の頭の中に前任者と同程度の、
ソフトウェア作りと建築の比較
たぶんドキュメントには書ききれていないような、だったりドキュメントを読み取った上で頭の中に構成される、
ちょっと違った形のシステムの像っていうんですかね。
そういうものがちゃんと作られないと、
十分にシステムをメンテナンスできない、扱えないということでもあったりするので。
同じような話を何度もしてますが、結構脳というか脳内に作られるイメージ、それをどう作るのかっていうのが
大きなウェイトを占めているっていうのがソフトウェア作りの特徴だという話ですね。
なので最初に言った3つと、それから脳の中のイメージっていうのが大きな割合を占める、
大きなウェイトを占めるっていうのが僕のソフトウェア感、ソフトウェア作り感っていうんですかね、っていう話です。
もしかすると、何て言うかな、勘違いとまでは言わないんですけれども、
多くの皆さんが陥りがちだなっていうところに、
ちょっと注意した方がいいよねっていう話を2つぐらいしたいと思っていて、
これは建築だったりアートだったり、ソフトウェア作りに割と
何て言うのかな、例えば過去の偉大な先輩方がインスパイアされて、
良いソフトウェアの作り方っていうのはこういうふうですみたいなことをやって来られたりしてきているものだったりするんですが、
それらについて僕がどう考えているのかっていう話をちょっとしたいと思っています。
まず建築ですが、当然建築っていうのはソフトウェアなんかよりもよっぽど歴史のあるインダストリーで、
良い建築というものはどういうことなのかっていうのが、
いろいろな方面で取り組まれているものだったりしますよね。
当然ソフトウェア作りっていうのが複雑化していく過程で、
建築っていうところからインスパイアされたというか輸入されたというか、
持ってきたやり方だったり考え方、コンセプトっていうのが結構たくさんあるものだったりするっていうのは、
ソフトウェア作りに関わったことがある方なら多くご存じのところかと思っています。
これ何回か前のポッドキャストでも話したと思う、
ドメイン駆動設計のときかな、思うんですが、
とはいえソフトウェア作りっていうところも急速に複雑化して大規模化していくだったり、
作れるもの自体が変わってきているっていう中で、
元々建築の世界から持ってきて良い作り方の指針として使われてきていたようなものが、
今の時代となってはもしかしたら結構ずれていたり、
邪魔になってたりだとかするものもあるのかなと思っています。
これってもちろん今でも聞く部分もあると思うんですが、
大事なところは何て言うんだろう、
やっぱり最近の特に自社プロダクトとかですかね、
そういうところで求められるソフトウェア開発、
作っているソフトウェアの特性と建築で求められる特性っていうんですかね、
建築物自体の特性っていうのがあって、
それをどう作るのかっていうのが建築の設計というか手法というかの話で、
これを比べたときに似た部分もあるけれども、
違いがより大きくなってきているのかなと、
僕自身は考えていまして、
その違いの最も大きなものが、
やっぱり環境の変化にどれだけ適応しなきゃいけないのかっていうこと、
適応しなきゃいけないのかっていうか、
環境の変化の影響がどれくらい大きく作用するのかってことですかね。
建築も当然環境の変化っていうのはあり得るんで、
物理的にこの世の中に存在している以上、
何らか環境は変化しますけれども、
じゃあ何ですかね、
百年単位とかそういう単位で見ると、
もうわかんないです、気候が大きく変動しましたとか、
地形みたいなものが変わりましたとか、
そういったところで、
建築物の大きな構造を変えなくちゃいけないっていうことはあるかもしれませんけれども、
じゃあそれが何か5年とか3年とかの単位であるかっていうと、
そういう世界じゃないですよね。
建築物に対する環境の変化ってそこまでのタイムラインで発生するものじゃないですね。
もちろん建築物の一個一個の部屋の中とかフロアの中とか、
そういう視点で見たら、
トレンドに合わせた何でしょうね、
マイナーチェンジみたいなものは当然あると思うんですけれども、
全体的な変更みたいな観点でいったときには、
そこまでじゃない世界に今はなってるかなというところがあります。
それを前提に考え方が作られてる。
基本的な構造はより長い間維持できたほうがいいとか、
多分そういうふうになってると思うんですよね。
それに対してソフトウェアの世界って、
もともとはやっぱり10年単位とか20年単位で動くような
ビジネスソフトウェアを作るっていうところから出発してると思うんですよね。
そういう世界であれば長いこと同じ共通構造で使っていけるっていうことが、
一番合理的だというか価値があるっていうふうに、
建築と共通したような作り方っていうのがはまってたとは思うんですけれども、
今でもそういった作り方、考え方が求められるソフトウェアも
当然あると思うんですけれども、
一方で環境変化っていうんですかね。
これはいろんな意味での環境変化ですね。
ビジネス環境が各社各社変わるし、
経済状況みたいなものにも当然左右されやすいというか、
物理的に建築物のようにドーンと立ってればいいっていう、
建築物を卑下してるわけじゃないんですけれども、
そういうものと違って、やっぱり一個一個の会社と密接に結びついて存在してるっていうところがあるので、
その会社の意気地に、ビジネスの状況とかに左右されて環境変わっちゃいます。
というところでもあったり、インターネットや使われるデバイスだとか、
そういった環境っていうのもどんどん変わりますよね。
っていうふうに、そもそも環境の変化っていうのがめちゃくちゃ大きいですと、
かつ早いですと、その中で生き残っていかなくちゃいけないっていうのが
ソフトウェアに求められていることだとするので、
長いこと同じ構造のままっていうことの価値が、
客観的に見ると、そこまで大きくなくなっているんじゃないのかなと思ったりもするわけですよ。
より環境に合わせて変わっていけるようなソフトウェアというか、
そういう作り方っていうんですかね。
そういうところが必要なのかなと思ったりもしてるので、長くなっちゃったんですけれども、
建築とソフトウェアを比べたときに、
そういう環境変化とその変化の時間軸とか影響の大きさみたいなところがかなり違うので、
その違いを意識してソフトウェアっていうのを見たり、
その設計コンセプトみたいなものとの向き合い方を変えたりだとか、
するのがいいのかなっていうのが、まず建築に対して僕が思っていることです。
ソフトウェア作りとアートの比較
建築はそこまでなんですけれども、もう一つ触れておきたいのが、
アートっていうんですかね。クリエイティブっていうんですかね。
的な側面もソフトウェア作りというか、コードを書くっていう活動っていうんですかね。
にはあると思っていて、
そういうところ、インダストリーというか、そちらの活動からインスパイアされた色々なコンセプトだったりっていうのも、
ソフトウェア作りの中に入ってきていると思っています。
これ、僕自身もたくさんコードを書いていた人間なので、
コードを書くだったり、ソフトウェアを作るっていうの自体がめちゃくちゃ楽しいっていうのは、
今でも当然思っています。
ソフトウェア自体、自分の考えたものを形にするっていうのが楽しいだったりだとか、
コードの書き方っていうか、それってある種、自己表現みたいなところでもあったりするので、
ささいな、どこかの開業の仕方みたいなところから、
名前の付け方だったり、クラスの構成の仕方とかですよね。
あらゆるものが表現みたいなところなので、
その表現自体をいい感じにするっていうことが、まず楽しいんですよ。
それ自体、僕はまず、ものすごく自分の現体験として持っているので、
だからソフトウェアのバックグラウンドを持っているっていうことでもあったりするんですけれども、
ただ、こういうクリエイティブな側面っていうのって、
昨今求められているソフトウェア開発には、
なんというのかな、あんまりそぐわないのかなと客観的には思っているところがあります。
例えば、メンテナンスしやすいソースコードにしていきましょうみたいな話一つをとっても、
メンテナンスしやすいっていうのは、自分一人でやる場合もありますが、
多くの場合は組織の中でより俗人化しない状態で、
かつ簡単に触れる必要な変更っていうのを加えやすい状態ってことなんですけれども、
そういう状態にソフトウェア、ソースコードを持っていこうとすると、
先ほど触れたような自己表現みたいなものを、
基本的には、なんていうのかな、否定するというか、
より合理的に多くの人が理解しやすく変更しやすい構造っていうところに、
ある種機械的に合わせにいくような、
そういうプログラミングという割合の方が大きいというか、
ほぼほぼそれなんじゃないのかなと思っているところがあります。
もしかすると、これ聞いている皆さんは、
そんなソフトウェア開発は嫌だというふうに感じる方もいるんじゃないのかなと思うわけですよ。
ただやっぱり求められていることっていうのは、そういうことだろうなと客観的には僕は思っています。
なので、この部分ちょっと短いんですけれども、
ソフトウェアエンジニアとしてのマインドセット
僕のソフトウェア感、ソフトウェア作り感っていうと、付け加えて今2つのことを話したんですが、
建築だったりアートだったりっていうところが、
もともとはそういう要素が結構あった活動かなと、
ソフトウェア作りっていうのはそういう活動だったと思うんですけれども、
今の時点でよりソフトウェアを作るプロフェッショナルとしてソフトウェアをどう見てるかっていったときには、
この2つとは一定ちゃんと距離を置いて、
それらとは今必要なソフトウェア作りっていうのは違うんだっていうような考え方を持つことも大事かなと思っています。
これらを踏まえて、ソフトウェアエンジニアとしてのマインドセットみたいなのって、
こういうふうに持っておくのがいいんじゃないかみたいなのを最後にお話ししようと思います。
大事なのは本当に今どんなソフトウェア作りが求められているのか。
これは裏を返すと、自分が取り組んでいる組織だったりソフトウェアそのもの、チームとかね。
何が問題になっているのか。いくつかの問題があって何が一番重要な問題なのかとか、
そういうのを見極めて、それを解決するソフトウェア作りっていうのはどういうことなのか。
これは他のインダストリーでこうやってるからとかそういうことじゃなくて、
自分の会社であればこれが求められているからこういう作り方をするんだと。
そういうふうに自分自身の頭で目の前にあるものをきちんと向き合って見つめて、
それに対して必要なソフトウェア作りっていうのを導けるっていうことが大事なのかなと思っていて。
その時に、僕であれば三つの視点でソフトウェアを見ましょうみたいな、
何らかのソフトウェア感みたいなのを軸にしながら、
必要なソフトウェア作りっていうのはこうだよねみたいなのを考えるっていうことをしたりするので、
ソフトウェアエンジニアのあるべき姿
聞いている皆さんも何らかソフトウェアっていうのはこういうものだよねっていう、
ソフトウェア感を持ってるんじゃないのかなと思うので、
それを少し言語化してみるとか、
そういうことをしておくとより借りてきた知識とかそういうものに頼らずに、
自分の頭であるべき姿っていうのを導きやすくなるのかなと思っています。
加えて言うならば、今後こうなったらいいなっていう、
僕の願望みたいなところでもあるんですけれども、
例えば一時期マイクロサービス化みたいなことがすごいもてはやされて、
いろんな会社さんだったり大小さまざまな会社チームで、
マイクロサービス化みたいなのを取り組まれた時期があって、
僕もその輪の中にいた一人ではあるんですが、
そこからの回帰というか反省というか、
今はどちらかというと何が何でもマイクロサービス化するっていうことではなく、
よりマイクロサービス化に対して慎重になろうだったり、
今必要なものはマイクロサービス化そのものではなくて、
ソフトウェアがよりある種メンテナンスしやすい状態というんですかね、
モジュール化みたいなのが適切になされていれば目的に対して十分だよねみたいな、
そういったソフトウェア設計ですね、プログラマー向けの設計なんですけれども、
話の宣伝みたいなのがあったかなと思っていて、
何を言いたいかというと、
そういったトレンドみたいなところに対して自分がどう考えるのかっていうのもやっぱり大事だと思っていて、
トレンドに乗るっていうことが少なくとも常に正解ではまずないわけで、
繰り返しになりますけれども、今自分が取り組んでいる問題というか、
会社の中で何が必要なのかっていうのをきちんと見極められることが必要で、
そのためにはですね、一番大事なこととして、
よくあるのが、
例えばソフトウェア開発自体のスピードっていうんですかね、
とにかく作ってリリースするみたいなことをやると品質が犠牲になったりだとか、
メンテナンス性が悪くなるだとか、これはもうよく言われることですよね。
ある種、常識のようにこれを聞いているソフトウェアエンジニア、
エンジニアマネージャーの皆さんは思っているところがあると思うんですが、
僕自身はここに考え方、そのマインドセットのチェンジが、
我々ソフトウェアエンジニアサイドに必要なのかなと思ってるんですよ。
それなぜかというと、
例えばもう01のスタートアップみたいなところで、
作ったものが当たるかどうか分からないと。
当たらなかったら、もうそれ捨てて別のことやりますと。
いったものづくりをするときに、メンテナンス性っていらないじゃないですか。
いらないと思うんですよ。
そこでメンテナンス性があって、リリースするのに
リファクタリングしなきゃいけないとか、テストコードを書かなきゃいけないとか言っていて、
リリースが1ヶ月遅くなりますとかって、ビジネス的に致命的だったりするんですよね。
ここは聞いていらっしゃる方の中には、なかなか納得いかない方もいるとは思うんですけれども、
でもやっぱり僕は、そういった会社が今何が必要なのかっていうところも理解して、
それに合わせた作り方ができるっていうところまで含めて、
今後のソフトウェアエンジニアのあるべき姿なんじゃないかと思ってるんですよ。
なので、例えば今だと、モジュラーモノリスみたいなのでやれば一定スケールしても大丈夫とか、
ユニットテストみたいなのを最初から書いておけば、技術的塞いが大きくならなくていいんですよとかいう話があって、
逆に経営者とかがそういう知識を仕入れて、そういう作り方を背負って気を利かせていってくる場面も何ならあるんじゃないかと思ってるんですけれども、
それに対してノーと言えるぐらいのソフトウェアエンジニアが、僕は何なら今後は必要なんじゃないかと思っています。
つまりビジネスが成功するために、今本当に求められている作り方っていうのを、
ソフトウェアの見方と考え方
世のトレンドだったり、モダンとか言われてるみたいなこととは別に、きちんと自分の中で判断し、
それを実行できるっていうところまで含めて、ソフトウェアエンジニアのあるべき姿だと思っていて、
当然それはフェーズによって、とにかく最速でリリースできる作り方が必要な時もあれば、
一定チームで機能追加もどんどんしながらメンテナンスもしていくっていうことが大事な時期もあるし、
もっと大きな組織になって、役割分担しながら作っていかなくちゃいけないようなフェーズもあると。
それぞれそういうフェーズに合わせて何が必要なのかっていうのを、自分たちで考えて見出して、
その姿に持っていけるっていうところまで含めて、そういった柔軟性っていうんですかね。
そういうそれぞれ全部ひっくるめてソフトウェアだよというようなソフトウェアの見方をできるような、
そういったソフトウェアエンジニアっていうのが今後求められるんじゃないのかなと思っています。
というわけで今日は僕のソフトウェア感、ソフトウェア作り感みたいなことと、
そこから紐を付けてエンジニアとしてどういうふうに考えたらいいのかねみたいな話をしました。
このソフトウェア感みたいなことって、多分本とかにもそういう言葉ってあんまり出てこないだろうし、
改めて考えるみたいな機会ってそんなに持たれてないんじゃないのかなとも思ったりするんですが、
ソフトウェアエンジニアとして、というかソフトウェアっていうのを軸足にして今後生きていこうとしてる方にとっては、
ここにしっかりとした考え方を持っておくことって、よりプロフェッショナルに振る舞う上では大事なことなのかなと、
僕は強く思ってますので、聞いてくださった方はこれを機会にヒントに、
何か自分なりのソフトウェア感っていうのを考えてみるっていうのもいいんじゃないのかなと思っています。
さてこの番組では感想や質問リクエストなどお待ちしております。
番組詳細欄にあるリンクよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。
EMはアルファベット問題集は漢字でお願いします。
そしてAppleポートキャストやSpotifyのポートキャストではレビューもできますので、
こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社株区スタイルCOO兼CTOの後藤秀典でした。
