gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

業務にシステムを合わせるのか? システムに業務を合わせるのか?

ふと何気につぶやいた程度の話だったのですが、思ったより膨らみそうなので、膨らませてみる(笑
いやまぁ結論は「程度問題」なんだろうなぁ、とは思いつつ。じゃぁ「どの程度」が「よい程度」なのか? ってのもあるので、このあたりは論考してみても面白いんじゃないかなぁ、と。


いつも以上に、っていうか多分今までになく「とっちらかったまま」書いてるので、文章に不安定なところや毒やその他諸々が含まれますので。
容量用法を適切にまもってお読みくださいませ。


直接的なネタとしては「Webアプリケーションフレームワーク」回り。まぁおいちゃんなんで、PHPの。
ただそこから少し「経営回り」のお話が絡んでくるので、そんな感じで色々なレイヤーをまぜこぜにしつつ。


直接的には、直近使ってるLaravel(5.5)が、そうで。
Ruby on Railsなんかでも聞こえてきて、それ以外のフレームワークだとFuelPHPなんかで感じて。………cakePHPは、がっぷり四つに組む前に魔改造してたから不明(笑
なにかってぇと「フレームワーク特有の縛りと固有のノウハウが結構面倒」。
もちろんこの辺はトレードオフなので、ってのはあるんだけど。


ん……少し暴言を吐くと「0からがっちょり(セキュリティ回り含めて)組める面子でそろえられるんなら、フレームワークを使わない」って選択肢が、脳内によぎる程度。
ちなみにその辺の観点からSlimが最近わりと気になっていて、今度がっぷりやってみる予定……ってのは、余談。
あと「テンプレートエンジン」は、なにか、は、大概使う。「シンプルな機能」だけなら、どのテンプレートエンジンでも「大体同じような機能を提供している」から、学習コスト低いし。
Twigが結構気になってるんだよなぁ、その辺としては。
もちろん「素のPHPをテンプレートエンジンに使う」でもよいんだけど、いくつかの観点から、テンプレートエンジンは使いたい事が多いかなぁ。「中にPHPコードが書けないようにする」的なギミックがあると個人的にはすげぇ嬉しかったりするんだが*1


話を戻すと。
上述は「0からがっちょり組める面子でそろえられるんなら」って前提なので、「そんなメンバーばかりではない」場合は、もちろんフレームワークを使って「提供された機能を使う」ほうが楽なケースも多々。
あと、「0からがっちょり組める面子でそろえられる」場合でも、認識合わせのルールはしっかり決めないとえらいこっちゃになるケースが多いように思われるので*2
事前にその辺の「取決め」は、大枠から細かい所まで意識合わせしないとひどい目に合う感じなので、その辺は注意。


ただまぁじゃぁ「フレームワークつかったらそんなことがなくなるのか」といえばそんなことは全然ないので。
フレームワークによって強制できる取決め」は、全体からみると割と控えめだったりするので、その辺も注意が必要ではあったりする。細かい見た目からもうちょっと致命的な記述方法まで、色々と問題が起きるしねぇ。
んでまぁこれがまた「フレームワーク使ってる"から"誰が書いてもコードが均一になる」とかいう信仰を持っている方も一定数いらっしゃるので、どっちがより深刻な事態になるのかなぁ? とか、思うところは色々。


個人的には「仕事で書いてるんならちゃんと人と足並みそろえようよ」と。
「好き勝手にコード書くのは、プライベートな趣味か、でなきゃせめて"自分が頭張ってる"時にして」って思うざます。


次。
んじゃまぁ「ある程度のルールが均一化できた」として。
次に立ちふさがるのが「フレームワーク的な制約」の諸々。端的には「素組みならさほど困らない実装」のいくつかが、フレームワークを使ったりすると「えらい事面倒」になったりする感じ。
この辺も「8割くらい*3フレームワークに従って楽が出来て浮いた工数」を「残り2割の奇異な要求で、がっつりと工数が食われる」とかいう状況になったりして、全体的なバランスがですね、えぇ。


もちろん「フレームワークのお作法をドン無視して」ってやり口もあるのですが、その場合大体は、割れ窓の法則に従って「全部が壊れていく」ので、フレームワーク使う旨味が減っていくので。
結果として「フレームワーク、使わなかったほうがよかったんぢゃね?」とかいう状況になって、それはそれでど〜なのかなぁ? と。多分選択肢としては「劣悪」な部類だと思う。


で、この辺になってくると気になる一つ目が「そのフレームワークの作り」と、次が「そのフレームワークに対する習熟度」。
ちなみにその観点で、Laravelは、作りとしては面白いんじゃないかなぁ、と思ったです。
「知らないと出来ない」の塊ではあるにしても、「知ってたら、ある程度介入出来る箇所も多い」ような印象は受けたので。
Zend Frameworkは「そもそも縛りがほぼない」から、この辺については楽だったなぁ………それ以前の問題が山積み過ぎて困ったけど。
CodeIgniterもその辺の縛りはシンプルだったような気がする……ただそれならSlimまでそぎ落としてほしいとか思うので、色々と難しいなぁ、とか思うのですが。


閑話休題


………こう考えてみると「フレームワークの縛りがギチギチで介入が難しい」ってのは、昔はあったんだけど、今は減ってきてるのかなぁ? って気は、する。気がするだけかもしれないけど。
ただ、上述のように「フレームワークそのものの処理に介入」できるようになるためには、フレームワークのつくりまでをある程度「熟知している」必要があると思われて。
端的には「新しい案件で使うからキャッチアップしませう」のレベルだと、ちょっと、そこまで踏み込むのは難しいんじゃないかなぁ、とか思ってみたり。


なんてのを色々と脳内で繰り広げていくと。
一つの疑問がふと脳内に横切るわけなんですね。


「どのフレームワークを使う?」以前に「フレームワーク、使う?」


いやまぁもちろん「対象フレームワークを熟知してから使う」ってのは、一つの真っ当な正解だとは思うのですが。
とはいえ、割とコロッコロ移り変わるフレームワークを、どこまで追いかけていくのかなぁ? と考えると、色々と思案のしどころ、ってのが一つ。
もう一つが「じゃぁ熟知するフレームワークにはどれを選択する?」って話にもなって。もちろん「今のトレンド」に合わせてもいいのですが、多分それ、5年持たないんじゃないかなぁ? と。
その辺を考えると「いずれにしても(フレームワークよりは)長期間使える知識としての"PHPそのもの"や"SQLそのもの"や"サーバ知識そのもの"を学習する」とかなんとか。まぁそこから先に踏み込むと「PHPよりは長期間使える知識としての"プログラミングそのもの"」とかになってきて玉ねぎの皮のようになっていくわけなのですが。


で……そこからさらに考えて。
おいちゃんの場合は「実案件」ベースなので。つまり実案件が「フレームワークの諸々の縛りに、何一つとしてはむかわないニーズのみ」であれば、問題の大半は解消できるんですよ*4
ただ、現実問題として、見ている案件は、大なり小なり「フレームワークのこの部分の縛りをど〜にかして業務に合わせてほしい」っていうニーズがあって。
「素直にフレームワークを使う」と迂回路を作るのに工数がめっさかかって、でなきゃ「フレームワークを熟知する」か「フレームワークを使ってる意味をなくすレベルで壊す」か、「フレームワークを使わない」か。
んで、もう一つ出てくるのが、「顧客の要求を捻じ曲げてご理解いただいてねじ伏せる説得する」っていうルートです。


ようやっとここで出てくるわけなんですね「業務にシステムを合わせるのか? システムに業務を合わせるのか?」ってお題。
Google検索で「業務にシステムを合わせる システムに業務を合わせる」なんかでも色々と出てくるんですが。
おいちゃんが見聞きしている論調としては「アメリカではシステムに業務を合わせるが、日本では業務にシステムを合わせようとするから失敗する」的なお話。


個人的には「ケースバイケース」だと思うですし、もうちょっと突っ込むと、根本的にまずいのは「業務フローを定期的に見直すルートが存在しない」事なんじゃないかなぁ? とは思うです。
一見無駄に見えるフローが「予想以上に無駄」な事もありますし B-p 、一方で「実はちゃんと意味があった」事象もあるので。正確には「ある事象を懸念してルールを策定して連絡して伝えたのにルールが無駄だと軽視された結果、懸念した事故が起きて面倒をこうむった」事とか、ま〜ま〜あります。
なので「無駄な業務」が「本当に無駄なの?」ってのは、しっかりと理由込みで継承していかにゃならんのではないかなぁ、と。
その上で「昔は重要だったけど今は無駄になった」なんてのもあると思うので、定期的に検証のループを回す、と。


んで、ちょうど大垣さんが、Facebookのほうで、ど真ん中な書き込みをしてくださってます。
https://www.facebook.com/michiaki.furusho/posts/1840530206021119?comment_id=1840546786019461&reply_comment_id=1841203432620463¬if_id=1521601974590136¬if_t=feed_comment&ref=notif

パッケージを入れると今の業務に合わなくなるので、どうでも良いことは全てパッケージに合わせる、が良いのは確かです。
問題はどうでも良くないことで、一言で言えば「競争力を維持するための業務」についてはカスタマイズも検討する方が良いと思います。でもそれ本当に競争力??という検証は常に必要だと思います。

多分、ここに尽きるんですよね。
おいちゃん的にポイントだと思っているのは
・どうでも良いことは全てパッケージに合わせる
・「競争力を維持するための業務」についてはカスタマイズも検討する
・でもそれ本当に競争力??という検証は常に必要
この辺。


んで……こっからは経営素人なおいちゃんの考え方、として。
「これ本当に競争力?」って、どうやって検証するのか、ってのが、おいちゃんには正直、よぉわからんです。
「KPI回せばいいじゃん」とか言われそうな気もするのですが、KPI界隈もいろいろあるっぽいですしねぇ。
「施策を打ったらKPIが上がった!」だけで満足するのは危険( https://tjo.hatenablog.com/entry/2013/06/17/190319 )」とか、こーゆー話、なんか割とありそうな気がして、色々。


………確か、どこかで「2要素が、相関なのか因果なのかを(ある程度)判断できる」方法とか、あったような記憶がかすかにうすぼんやりと。


話をシステムに戻しつつ。
システムを組むのって「業務を組む」事でもありつつ、「システム自身」のお話にもなるので、二重に出てくるお話なんですが。
フレームワークが持つ縛り」を、どれくらい許容してどれくらい許容しないのか? ってのは、まぁ、少なくともしばらくは、ず〜〜っと付きまとってくるお話なのかなぁ、と。
その辺も結局のところ
・どうでもよい事か?
・重要な箇所か?
ってあたりの考察が、定期的に必要なんだろうなぁ。
あとは「重要な箇所」が「なぜ重要なのか?」を、最低限、言語化できる事と、可能であれば、必要な人に伝える事。


んで。
個人的には、どちらかというと「フレームワークの縛りが業務と相反する、或いは露骨にリソースを食う」なら、フレームワークをカスタマイズするなり改修するなり改造するなり部分的に置き換えるなり使わないなり、って選択肢を選ぶことが多かったんだけど。
その辺を、今後、ど〜しようかねぇ? っという感じで。
フレームワークの縛りが業務と相反する」についてはお客様と要相談。問題は「露骨にリソースを食う」場合で、「許容できる業務」もあれば「許容が不可能な業務」もあるかなぁ、と思うので。
その辺も「業務の性質を考えながら」になるんだろうなぁ、とかとか。


まぁおそらく最終的には「プレタポルテにも対応できる、普段はレディ・メイド」になるんだろうなぁ、とは思いつつ、まぁまだ色々と煩悶している時期なので。
とりあえず、その煩悶をそのまま文章にしてみましたww


……多分、フレームワークを「がっつり熟知する」には、端的には「そのフレームワークに好意以上のものを持つ」あたりが一番のモチベーションになりそうなんだけど……今の所、あんま、ないしなぁ。
そーゆー意味で、Slimがちょっと気になってる感じ。次点は、現状だと割とCodeIgniter。案件で一度「壮絶なコード」を見たけど、あの壮絶さに、逆に可能性を感じたのでwww


なんて駄文を、つらつら。
広い世界で、なんか一人くらい、この文章が参考になってくれればよいかなぁ。

*1:テンプレートの中で「DBに接続してSQL発行する処理」とか、あんまり見たくない

*2:Zend Frameworkの案件でいくつか「壮絶なの」を見てるしなぁ……伝聞も実体験も込みで

*3:なんとない印象値。根拠なし

*4:いやまぁそれでも最後「なんか色々と無駄メモリ使ってるなぁ」とか思うところもなくはないのですが、その辺も「クラウドインスタンス増やす」で片付くしねぇ