マルチスタック開発で意識している”視点の切り替え”-エンジニアS-

こんにちは。
フルスタックエンジニア兼、情報システム部長兼、執行役員のSです。
日によって肩書きが違うんじゃないかってぐらい立ち位置が変わるんですが、コード書いてるときだけは一貫して「職人モード」です。
今回はそんな僕が、Ruby・PHP・Python・JavaScriptと、いろんな言語&フレームワークをまたぐ中で意識している
**「視点の切り替え」**について、ラフに書いてみようと思います。
■どこから見て、なにを大事にするか”が変わる
マルチスタックの開発で一番大事なのって、
**「言語の書き方の違い」じゃなくて「考え方の切り替え」**だと思ってます。
その言語・そのフレームワークの“流儀”を尊重しないと、コードが浮いちゃうんですよね。
🟣 Ruby on Rails:物語のように読めるか?
Ruby on Railsを書くとき、真っ先に意識するのは**「自然に読めるか?」**という視点。
たとえば、真偽を返すメソッドはこんなふうに書きます。
———-
def published?
true
end
———–
「?」がついてるだけで「あ、これは true/false を返すやつだな」と一発で分かる。
こういう細かい文法のチューニング、“読み手の気持ち”に寄せてるのがRailsらしさです。
あと、Rubyは「全てがオブジェクト」。
nil.class すら NilClass って返るし、 1.to_s もできる。
そのおかげで、コードが“滑らか”につながっていくんですよね。
———–
user&.profile&.bio&.truncate(100)
———–
こういうコードが違和感なく読めるって、結構すごいことだと思うんです。
Railsでの視点は、
「このコード、人が読んで気持ちいいか?」
ってところにあります。
🟡Laravel:現場力が試される“明示性の世界”
PHP(Laravel)を書いているときは、視点がちょっと変わります。
———–
function is_published()
{
return true;
}
———–
はい、分かりやすい。
LaravelはRubyほど「自然に読めるか」ではなくより機械的に「何をやってるか」を明示的に書くのが基本です。
中身が見える安心感がある代わりに、開発チームごとの“ローカルルール”が表に出やすいのもLaravelあるある。
だから意識するのは、
**「この書き方、現場でメンテできる?読める?説明できる?」**という視点。
🔵Django:魔法のように動くけど、魔法すぎる世界
Djangoは、もう**「魔法」**って言い切っていいと思ってます。
———–
class Article:
def is_published(self):
return True
———–
このあたりまでは分かりやすいんですが……。
本番はビュークラスです。
・CreateView
・UpdateView
・DeleteView
・ListView
・DetailView
・FormView
などなど、用意されたViewクラスが多すぎる。
正直、「何も書いてないのに動いてる」感すごいです。
———–
class ArticleCreateView(CreateView):
model = Article
fields = [‘title’, ‘content’]
success_url = ‘/articles/’
———–
これだけでフォーム表示から登録完了まで全部やってくれる。
すごい、すごいけど…どこで何してるか分からなくなりがち。
なのでDjangoでは、
「この“魔法”、中で何やってるか追えてる?」
という視点をめちゃくちゃ意識します。
Djangoは設計思想が強くて、**“型にはまれば強いけど、外れると一気に不安定”**になるイメージ。
魔法に頼りすぎると、逆に自分が置いていかれることもあるので、付き合い方が大事です。
逆に魔法の中身を完全に理解していれば、設計段階で考慮することも可能なので、より効率的な開発が可能なのが良いところですね。
■最後に
日々多数の案件に関わっていると1日の間に何度も違う言語へ行き来することになります。
PHPの開発で「authentication!」という関数を定義しちゃったり、Rubyで「is_published」みたいな関数を定義しちゃったりで、混ざったりすることもあります。
マルチスタック開発をやっていると、毎回「視点のスイッチ」が求められますね。
コードの書き方を合わせるだけじゃなく、**“この技術では何を大切にするのが自然か?”**を理解することが、心地よい設計への近道です。

こんにちは。
フルスタックエンジニア兼、情報システム部長兼、執行役員のSです。
日によって肩書きが違うんじゃないかってぐらい立ち位置が変わるんですが、コード書いてるときだけは一貫して「職人モード」です。
今回はそんな僕が、Ruby・PHP・Python・JavaScriptと、いろんな言語&フレームワークをまたぐ中で意識している
**「視点の切り替え」**について、ラフに書いてみようと思います。
■どこから見て、なにを大事にするか”が変わる
マルチスタックの開発で一番大事なのって、
**「言語の書き方の違い」じゃなくて「考え方の切り替え」**だと思ってます。
その言語・そのフレームワークの“流儀”を尊重しないと、コードが浮いちゃうんですよね。
🟣 Ruby on Rails:物語のように読めるか?
Ruby on Railsを書くとき、真っ先に意識するのは**「自然に読めるか?」**という視点。
たとえば、真偽を返すメソッドはこんなふうに書きます。
———-
def published?
true
end
———–
「?」がついてるだけで「あ、これは true/false を返すやつだな」と一発で分かる。
こういう細かい文法のチューニング、“読み手の気持ち”に寄せてるのがRailsらしさです。
あと、Rubyは「全てがオブジェクト」。
nil.class すら NilClass って返るし、 1.to_s もできる。
そのおかげで、コードが“滑らか”につながっていくんですよね。
———–
user&.profile&.bio&.truncate(100)
———–
こういうコードが違和感なく読めるって、結構すごいことだと思うんです。
Railsでの視点は、
「このコード、人が読んで気持ちいいか?」
ってところにあります。
🟡Laravel:現場力が試される“明示性の世界”
PHP(Laravel)を書いているときは、視点がちょっと変わります。
———–
function is_published()
{
return true;
}
———–
はい、分かりやすい。
LaravelはRubyほど「自然に読めるか」ではなくより機械的に「何をやってるか」を明示的に書くのが基本です。
中身が見える安心感がある代わりに、開発チームごとの“ローカルルール”が表に出やすいのもLaravelあるある。
だから意識するのは、
**「この書き方、現場でメンテできる?読める?説明できる?」**という視点。
🔵Django:魔法のように動くけど、魔法すぎる世界
Djangoは、もう**「魔法」**って言い切っていいと思ってます。
———–
class Article:
def is_published(self):
return True
———–
このあたりまでは分かりやすいんですが……。
本番はビュークラスです。
・CreateView
・UpdateView
・DeleteView
・ListView
・DetailView
・FormView
などなど、用意されたViewクラスが多すぎる。
正直、「何も書いてないのに動いてる」感すごいです。
———–
class ArticleCreateView(CreateView):
model = Article
fields = [‘title’, ‘content’]
success_url = ‘/articles/’
———–
これだけでフォーム表示から登録完了まで全部やってくれる。
すごい、すごいけど…どこで何してるか分からなくなりがち。
なのでDjangoでは、
「この“魔法”、中で何やってるか追えてる?」
という視点をめちゃくちゃ意識します。
Djangoは設計思想が強くて、**“型にはまれば強いけど、外れると一気に不安定”**になるイメージ。
魔法に頼りすぎると、逆に自分が置いていかれることもあるので、付き合い方が大事です。
逆に魔法の中身を完全に理解していれば、設計段階で考慮することも可能なので、より効率的な開発が可能なのが良いところですね。
■最後に
日々多数の案件に関わっていると1日の間に何度も違う言語へ行き来することになります。
PHPの開発で「authentication!」という関数を定義しちゃったり、Rubyで「is_published」みたいな関数を定義しちゃったりで、混ざったりすることもあります。
マルチスタック開発をやっていると、毎回「視点のスイッチ」が求められますね。
コードの書き方を合わせるだけじゃなく、**“この技術では何を大切にするのが自然か?”**を理解することが、心地よい設計への近道です。