質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Python 3.x

Python 3はPythonプログラミング言語の最新バージョンであり、2008年12月3日にリリースされました。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

Q&A

6回答

6641閲覧

バックエンドシステムをPHPからPythonに書き換えることの可否

astoria17

総合スコア12

Python 3.x

Python 3はPythonプログラミング言語の最新バージョンであり、2008年12月3日にリリースされました。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

2グッド

2クリップ

投稿2016/10/28 03:11

B2C向けのコミュニティシステム(会員登録、掲示板投稿、マイページ、決済機能、商品のレコメンデ―ション機能、スケジュール調整機能等あり)を、PHP言語をバックエンドとして構築しています。サイトはWire Frameベースで合計200ページほどのそれなりに規模の大きなもので、フロントエンドからバックエンドまで一括で1000万円ほどかけて半年近く前から業者に委託しており、70%ほどが完成しています。

当初予定と比べて企画が色々と広がってしまい、英語化と海外エンジニアの活用を将来的に想定して、使用言語をPython(3.0)に丸ごと移行したいと考えています。まだサイトは完成前ですが、リリース前に丸ごとPythonに変換することは現実的でしょうか。リリースするとより予算がかかってしまうような気がするので、もしよければアドバイスを頂けると非常に助かります。

LLman, pack👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答6

0

PHP言語をバックエンドとして構築しています。
1000万円ほどかけて半年近く前から業者に委託しており、70%ほどが完成しています。
リリース前に丸ごとPythonに変換することは現実的でしょうか。

たしかに最近では、欧米を中心にPythonが国際的な主流になっています。
Java、JavaScript、C系言語の次くらいにメジャーな言語です。
機械学習系ライブラリの充実ぶりが、流行の要因のひとつです。

また、PHPはかなり行き当たりばったりに仕様拡張してきました。
たとえば、PHP5から(本格的な)オブジェクト指向の仕組みが追加されました。

しかし、最初から純粋オブジェクト指向で設計されている
RubyやPythonの方がOOPで自然に書ける、というのが実感です。

そこでは「すべてがオブジェクト」の世界です。元々はSmalltalkが元祖ですが。
関数型プログラミングにしても、Lispの流れを汲むので、やはり自然に書けます。

私自身も、(すでにC言語などは習得していましたが)
Webプログラミングは、まずはとっつきやすいPHPから入り、
OOPが得意なRubyに移り、最近ではPythonも触っている、という流れです。

ですから、質問者=発注者の方が、そのように考えるお気持ちも分かります。


しかし、7割完成時点から切り替えるのは非現実的だと思います。
もし私が発注者の立場だったら、PHPで完成させてしまいます。

変更のタイミングが遅過ぎで、ビジネス的に変更可能な時期を逸しています。
次の新サービスをPythonで書けば良いのではないでしょうか?

PHPも国際的な言語なので、海外の技術者はいます。
欧米中心のPythonと比較して、日本も含めたアジアに多いですが。

PHPのサービスで開発コストを回収しておき、
他と比較できる運用経験も残しておいた方が、
Pythonの新サービスにも良い影響を与えると思います。

中途半端に今変えてしまうと、単純に一千万円のコストだけが残ります。
もし、タダでパッと書き換えられる想定なら、それこそ非現実的です。

それに、開発効率、運用効率、実行速度、人件費、などの比較もできません。
技術面だけでなく営業面でも、収益を上げるノウハウを得てからでないと、
ムダな設計をしてしまう面があると思います。要は経験を次に活かせません。

ビジネスとしては、言語は手段であって目的ではありません。
ユーザにサービスを提供することで、利益を得るというのが最終的な目的です。


もしかしたら、レコメンド部分に最新技術を投入することで、
機械学習に強いPythonが生きる側面もあるかもしれません。

ただかりに最悪、今から作り直す場合でも、
マイクロサービスの考え方を取り入れた設計で、
PHPのメインシステムとは別にPythonで機械学習エンジンを作り、
データをやり取りする、といった方法も考えられます。

マイクロサービスは別言語のメンテがやや煩雑になりますが、
この場合、作ったPHPがムダにならないメリットが大きいです。

ただし、全面的な作り直しを回避できるだけで、ツギハギになるため、
仕様変更コストはやはり掛かるし、別に推奨したいわけでもありません。
どちらかというと、どうしても変更したい場合の苦肉の策です。

全面的な書き直しは、今のPHPでの開発が完全に頓挫していて、
どうにも進まないような失敗した状態でだけ検討します。


インターネットの初期には、「ネットスケープ」というブラウザもありましたよね。
それがMSのIEに負けたひとつの要因として、ソフトのバージョンアップ時に、
全面的な書き直しをしようとして、リリースが大幅に遅れたというのがあります。
今では「セカンドシステム症候群」と呼ばれるアンチパターン(失敗例)です。

まして、まだ始まってもいないサービスを書き換えるというのは、
意見の押しつけはしたくないものの、私はまったく推奨できません。
変更コストを上回る利益増の見込みがないなら、ビジネス的に悪手です。

ソフトの話だとピンと来ないかもしれないので、世間一般で通じる例で言えば、
料理が7割できた段階で、中華から洋風に変えようとか、
建物が7割建った段階で、木造からコンクリに変えようとか、
そんなの作り直しになりますし、確実に損しますよね。まずありえない感じです。

ただし、メインディッシュと別のデザートだけ洋風にできるし、
母屋とは別の離れの建物だけ木造、とかは現実にもありますよね。
マイクロサービスの話はこちらに相当します。これならまだしもアリかも。

以上、長文になりましたが、質問者の方や参考に見ている誰かに、
なるべく損をさせたくないという気持ちから、
仕様変更に慎重な立場からの意見を申し上げました。

投稿2016/10/28 21:00

LLman

総合スコア5592

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

astoria17

2016/10/30 01:55

コメントありがとうございました。仰る通りビジネスの視点が私には欠けていたように思います。無理に完璧を追い求めるあまり、技術で買って、ビジネスで負ける、という今の日本の経済の縮図のような事態にならぬように気を付けねばと思いました。PHPも利用シェアという点で、やはり今も充分協力なツールですよね。「セカンドシステム症候群」という視点も、とても参考になりました。
guest

0

自分も英語化と海外エンジニア活用を目的にPHPをPythonにするのは理由として正当だとは思いません。言語というよりなんのフレームワークを使っているのかが大事な可能性もあります。
なお、PHPをPythonに機械的に移行できるわけではないので、PHPで実装したときと、同じ程度の工数がかかるのではないかと予想します(フロントエンド部分が同じでいいならバックエンド部分の工数分)

確かに将来もっと機能が増えてからPythonに乗り換えるぐらいなら、今から作り変えたほうが安いのは間違いないと思いますが、作ったサービスが十分に収益を生むかどうかわからないのに、完璧なものにしてからリリースするという発想はあまりいいとは思いません。また、リリース時期も遅れることのリスクも考慮したほうがいいと思います。

あとは、お金と時間(リリース日)の政治的な問題だと思います...。

※自分は作り手側なので、あまりよくわかっていないで回答していますが、参考程度になれば幸いです。

投稿2016/10/28 04:12

編集2016/10/28 04:14
popobot

総合スコア6586

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

astoria17

2016/10/28 05:13

ありがとうございます。確かに無理にPythonにする必然性は薄いかもしれません。大変参考になります!!!
popobot

2016/10/28 07:39

自己資金なんですね...すご。ちなみにCakephpやLaravelなどのフレームワークは使っているんでしょうか?
astoria17

2016/10/28 12:07

お陰さまで手持ち資金はすっからかんになりました。笑 フレームワークは使っていないと思います!!
popobot

2016/10/28 12:35 編集

さらにすごいですね! なるほど...だったらどの言語を使うかより、フレームワークを使った方がよかったかもしれないですね。フレームワークは多言語化を簡単に実現する仕組みを持っていたり、Webサービスを作るための基本的なパーツが用意されています。エンジニアにとっても開発しやすい環境が整うので、とても大事な要素だと思います。 ※いまどき、一定レベル以上の業者だったら、フレームワークを使いそうな気もしますが...もしかしたら使っているのかもしれませんよ。こういったQAサイトではなく、知人とかで技術に詳しい方がいたら、そういった部分は相談できるといいですね。
astoria17

2016/10/28 12:50

ありがとうございます!!!確かにそうですね・・・ちょっと確認してみます!とても勉強になりました!!
astoria17

2016/10/30 01:44

すみません、どうやら独自フレームワークのようです!!
popobot

2016/10/30 02:48 編集

既成のフレームワークの方がよかったかもしれませんね。有名な既成のフレームワーク(CakephpやLaravelなど)だったら、それを使ったことあるエンジニアも結構いますし、わりとどのフレームワークも類似していることが多いので、結構開発しやすいです。また、フレームワーク自体も外部のエンジニアが機能追加していってくれるメリットもあります。 まぁ、独自のフレームワークの出来によっては、悪くない可能性もありますが
astoria17

2016/10/30 04:11

そうですね・・・汎用性のある既存のフレームワークがやはりよかったです。そこまで考えが及びませんでした。どういうフレームワークを使っているのかは、将来的に委託先を移行する可能性も含めて、どのコードが何を意味しているのか、個別に詳細に聞き込んでおきたい、と思います。今後開発を進める上でとても勉強になりました!本当にありがとうございます!!!
guest

0

英語化

多分国際化 (i18n)のことだと思うが PHP のフレームワークでも対応したものがあるためこれを理由に変えることは不可能かと

海外エンジニアの活用

PHP は日本国内発症のローカル言語ではなく海外発症の言語です。それなりに開発者もいます。

なので挙げられている点では押しが弱いです。
上が納得できる理由をでっちあげれるかがカギです。

投稿2016/10/28 03:39

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

astoria17

2016/10/28 05:14

PHPは世界でも通用しますね!よかったです。
guest

0

読む限り開発言語の変更はユーザ都合ではなさそうですね。
ならば一番気にすべきはユーザ影響でしょう。
納期、費用、品質etcユーザに迷惑をかけないなら、これまでの開発費用を棄ててまでやるメリットが会社にあるかないか、ですね。

仮にユーザ都合だとしても、普通なら要件定義や設計の甘さは責められると思います。
ユーザが非常識な変更要求をしているなら、正々堂々納期後ろ倒しと追加費用を請求して話を進めましょう。

いずれにしてもこのケースでは技術論は二の次です。やってやれない事はないんですから。
まずはユーザ対応です。
あと、チームメンバーともきちんと意思疏通しておかないと、会社ないしは質問者さんの判断能力や意思決定プロセスを疑われますよ。

投稿2016/10/28 05:10

ynakano

総合スコア1894

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

astoria17

2016/10/28 05:13

ありがとうございます。私が個人資金で発注しているのと、まだサイトがリリースしていないので、その点は大丈夫です。やはりかなりエネルギーがかかりそうですね!
guest

0

移行する場合の具体的な計画を立てましょう。

・今まで投資した1,000万円をどうするか
・移行にかかるコストをどう捻出するか

決済する人、場合によってはお金を出す人がOKであればいいのではないでしょうか。

現実的かどうかはあまり重要ではないです。

移行する前と移行する後でTCOでメリットがあればありなんじゃないでしょうか。

投稿2016/10/28 03:23

moonphase

総合スコア6621

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

astoria17

2016/10/28 05:14

お金は私の手持ち資金でやっています。今一度、Pros/Consを洗い出してみようと思います!
guest

0

##言語選択の葛藤

astoria17さんのおっしゃりたい事は、非常によく解ります。
なぜかといえば、そっくりそのまま、私個人の中で起こっている葛藤だからです。

5、6年程前でしょうか。当時は「勉強会」なるものが急速に盛り上がっている時でした。
私は、業務でSymfony(PHPのフレームワーク)を使用しておりました。

「海外では、Python」と言われ、「NASAやGoogleでは、Python」が決まり文句でした。
勉強会では、やはり「Ruby on Rails」が、一番イケてました(この言い方…)。
積極的に業務でというより、「まさにこれから」という感じでした。
私は、Rubyより「Pythonの方がカッコいい」と思っていたので、Pythonの勉強会に積極的に参加しておりました。

それに引き換え、当時もやはり、PHPと言えば…

もちろん、当時は「FacebookはPHP」が決まり文句でしたので、PHPも世界で使われています。
CakePHP(PHPのフレームワーク)もi18n(多言語化対応)が使えますので、重量級(一通りの機能が揃ってるという意味です)のフレームワークであれば、機能という意味では大差ないでしょう。

##レガシーコスト

その後、私個人が、業務でPythonに切り替えられたかと言えば、結局踏ん切りがつきませんでした。
今も、CakePHPを使ったりしています。

ただし、今もやはり、PHPと言えば…

多分、私の中では、PHPは現在進行形で、レガシーコスト(負の遺産)になりつつある所だと思います。

ここに来て、機械学習などの盛り上がりにより、日本でも一気にPythonがイケてる言語にのし上がってきましたね。
「キャズムを超える」なんて言葉も、今は恥ずかしいですかね。

##かかるコストについて

ここまでは、私個人の話です。

以下、ご質問の内容について、いくつか伺いたい点がございます。

  • astoria17さんご自身は、開発経験などはございますでしょうか?コンサル的な立場が長かったりするのでしょうか?

答えられる範囲で結構です。どういった知識をお持ちなのかが知りたくて。

  • そもそも、なぜPHPでスタートしたのか。astoria17さんの指定なのか。業者の指定なのか。

  • 他の方の回答にもありました、「フレームワーク」については、どのようになっているのか。

標準的に使われているフレームワークを使っているのか。スクラッチ開発のようなものなのか。

  • Pythonに切り替えるとして、同じ業者を使えるのか。別の業者を使うのか。

  • 仮に同じ業者を使うとして、その業者の規模はどの程度のものなのか。

ある程度、小さな規模の業者であれば、大部分を同じ担当者が引き継げる可能性があります。

一括で1000万円ほどかけて半年近く前から

この部分を見ると、大勢の担当者がいるようには見えない気もしますが。

極端な話、一人の担当者がいて、PHPとPythonの二刀流だとしましょう。

その一人の担当者が引き継げるとすれば、これまでの投資のうち、結構な部分は無駄になりません。
DB、フロント部分もそうですし、設計においても、自分が設計してるのですから。

仮に今使っているフレームワークがCakePHPとして、その担当者がDjango(Pythonのフレームワーク)に精通しているとすれば…

私自身の例を出した理由は、この部分です。
これまで、業務でCakePHPを利用してきました。イケてないなと思いながらも…

その傍ら、カッコいいと思っていたのでDjangoの勉強もしたりもしてました。
両者はともに、標準的かつ重量級のフレームワークですので、似ている所も多いです。

リリースするとより予算がかかってしまうような気がする

これは、間違いないと思います。

今現在、Ruby on Railsが、隆盛を極めたりもしていますね。エンジニアも多いですね。
「将来」を考えた時、イケてるイケてないは、本当に重要だと、私は思います。

なので、この質問を拝見した時、「応援したいな」と思った所が正直な所です。
自分自身への応援という意味も込めて。

##なぜ、Python3を選んだのか

私は、今現在の、海外の事情を調べた訳ではありませんので、詳しくは知りません。
astoria17さんが、Python3を候補として選んだ根拠などはありますでしょうか?
あまり難しく考えなくて結構です。

  • ご自身の経験から
  • 海外に知り合いがいて
  • 誰か詳しい人に聞いて

など、理由があれば、伺いたいです。

「NASAやGoogleでは、Python」が「WEB系にPythonが強い」を表している訳ではありません。
「Pythonは、研究、データ分析に強い」などと、言われたりします。

こちらは、一年程前の記事ですが。

【プログラミングは義務教育化すべきなのか?】という問題を考えてみた

イスラエルでは他国に先駆け、2000年より高校でのプログラミング教育を必修化していました。現在では義務教育で10歳からプログラミング(C++、Python)の授業が始まり、15歳まで教育は続きます。

最近、日本でも「学校でPythonを」という記事を、見たような気がしたのですが。
「おっ!」と思った記憶があるのですが、すみません、うろ覚えで見つけられませんでした。

##PHPを捨てる企業

すでに、ご存知かもしれませんが。

こちらの例は、全社を挙げて徐々にという感じなので、もちろん人材育成から何から何まで、時間をかけてという事例です。

Scala採用を決めて一年たった、CTOの雑感

投稿2016/10/28 09:20

編集2016/10/28 10:35
pack

総合スコア256

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

astoria17

2016/10/28 12:05

貴重なご回答ありがとうございます。洞察力に富んだコメントの数々、大変勉強になります!!!全く仰る通りと感じております。 私がPythonに関心を持ったのは、仕事上知り合う海外の知人でPython利用者が多かったからです。 GoogleでPythonを公式言語としていることはよく語られていました。 他には、 (1)PHPが言語特性上(HTMLの派生で完成度が低く)、最先端領域ではやや陳腐化しつつあること、 (2)Pythonは言語がシンプルかつルールがそれなりに厳しい(インデントなど)ので、 ディベロッパーによる品質のムラが生じにくいこと (3)このため、優秀な学術系の人材がPythonに行く傾向 があるということでした。 Python 3 は、やはり最新なのがベストかと思っています。 今は全く問題ないのですが、もしサービス利用者が増えた場合や海外でサービスを展開することを想定すると、 ディベロッパーによりムラが無いのは結構重要かなと思いました。 (何が書いてあるのかわからず引き継げずに丸ごと書き直すしかないという事態が一番困るので) 「「将来」を考えた時、イケてるイケてないは、本当に重要だと、私は思います。」 ありがとうございます。中規模のサービスであればPHPは最高に使いやすいかと思うので、一概には言えないと思いますが、ちょっと背伸びするならPythonなのかなと。 私はコンサルに近い職種で、まだまだ勉強中の身です。依頼先は、小規模な事業者の方ですね。 当初はそこまで深く考えていなかったのですが、開発を見るうちに楽しくなってきてしまい、これを海外でもサービスを展開してみたら面白いな、と思うようになり、考え始めてみました。
pack

2016/10/29 01:52 編集

この質問に巡り合えたのも、私自身が「背中を押してもらいたくて」というのが、あったかもしれないですね。 ここで、誰ぞの名言を持ってきて、astoria17さんへの励ましの言葉とするのもどうかと思うので、止めておきますが。 おっしゃっているPythonへの見解については、全く異論はありません。私も同意見です。 だからと言って、私も精通してるとも言えなので、何の保証にもなりませんが。 なので、Rubyより「Pythonの方がカッコいい」と思った理由を書いておきます。 1.ロゴがカッコいい。 宝石よりかは、絡み合う蛇ですよ。「蛇使い」なんて、カッコいいじゃないですか。 「蛇使い」という言葉は、特に使われたりはしませんが。 2.ヒーローがいる グイド・ヴァンロッサム氏(Python作者、神) アーロン・シュワルツ氏(web.py作者) など、すごいカッコいいなと思い、憧れのようなものがありました。詳しくは、wikipediaを見ていただければと。 アーロン・シュワルツは若くして亡くなってしまい、ショックでした。 悲しいかな、それがかえって『伝説』を創ってしまいましたが。 ドキュメント映画にもなりましたね。 Rubyでは、まつもとゆきひきさんが、やっぱりヒーローですね。 という感じです。まぁ、直観です。 以下は、当然、astoria17さんも検討されていると思いますし、状況を知らないので、参考とはならないと思いますが。 私も練習になると思って、考えてみました。 icchiiさんの方の回答も、拝見いたしました。 まずは、前提となる懸案事項として。 A.標準的なフレームワークを、本当に使っていないか 独自フレームワークなどという言い方もしますが、どれだけ独自の手法で設計、開発などを行っているか、やはり、詳しく聞き取り調査が必要かと思います。 おっしゃる通り 「何が書いてあるのかわからず引き継げずに丸ごと書き直すしかないという事態が一番困る」は確かに、そうですが。 PHPかPythonか、もありますが、icchiiさんのおっしゃるように、その如何に関わらず「フレームワーク」というのも、大きなキーになります。 B.別の業者に当てがあるか 日本国内で、当たろうと思うと、選択肢としてはぐっと狭まると思いますので、すぐに海外も視野に入れる事になったりですね。 逆に、日本ですでに十分、実績があるのであれば、信頼のおける技術レベルにあると言えるのではないかと。 > ちょっと背伸びするならPython とおっしゃるように、それだけの事に取り組んできた訳ですから。 PHPはピンキリですからね。Railsを利用した開発も、じきにピンキリになるのではないでしょうか。 いわゆる、python界隈と呼ばれるような、コミュニティ等も、以前の事ですが拝見し、そんな風に感じました。 回答でも書きましたが、海外の事情も、全く知りません。 ここの話は、astoria17さんの事ですので、海外の人脈もあるという事ですし、今の業者とのつながりなど、全く状況を知らない私がどうこう言っても仕方ないですが。 A、Bを踏まえ、実際、どう計画していくか。4パターンが考えられるかなと。 1.開発を中断。他の業者への引き継ぎへ移行。 2.開発を中断。同一業者でPythonへの切り替えを模索。 3.開発を継続。リリースまで踏み切る。フィードバックを得る。資金を貯めて、Pythonでのリプレースに備える。 4.開発を継続。リリースまで踏み切る。フィードバックを得て、同一業者、PHPのまま改良を続ける。 1番ですが。 現在の業者に見切りをつけて、他の業者でとなると、やはりコストはかなり大きくなります。 Aであった、独自設計となれば、なおさらです。標準的なフレームワークであれば、他の人が読むことは多少は、容易ですが。 Bもどうするかが重要ですね。技術レベルなど見極めも大切になります。 2番ですが。 これは、回答にも書きましたが、逆に夢物語でもあります。 すんなり、低コストで切り替えが出来るとすれば、早いうちに踏み切った方が、いいでしょう。 ただ、やはりなかなか甘くはないかなと。今の業者の技術レベル次第です。 3番、4番ですが。 icchiiさんもおっしゃるように 「完璧なものにしてからリリースするという発想はあまりいいとは思いません。」 の部分、私も同意見です。 とにかく、リリース後のフィードバックが大切だと思います。 まず市場で試してみるというスピード感は、絶対的な正義です。 改良の必要のないサービスなど、あり得ないのですから。 そこで懸念されるのが、4番の場合の、改良スピードです。 独自設計などで、規模が拡大していくと、どんどんスローダウンしていくのではないかと。 次々、やりたい事が出てきても、開発側が渋るようになってくるというのが、よくあるパターンです。 ここも、Aの結果によるところが大きいと思いますし、PHPで行き続ける事になるので、astoria17さんご自身が、どこかで後悔するのではないかと。 という感じで、3番あたりが、現実的な落としどころかなというのが、私の勝手な感想です。 フィードバックを貯め、改良項目を練り、その間にまた資金を貯め、Bを確実なものにできるよう、準備をする。 ざっとこんな感じで考えてみましたが、astoria17さんも他、こんな風に考えた、というのがございましたら、聞いてみたいというのもあります。 いろいろ勝手な事を書いて、かつ大変な長文となってしまい、失礼いたしました。 本当に、ただただ、サービスの成功を祈るばかりです。
pack

2016/10/29 00:47 編集

もう一つ、懸案事項として C.「70%」に、どれだけの信憑性があるのか プロトタイプのような形で、動く状態で、都度チェックできているか。 「開発を見るうちに楽しくなってきてしまい」とあるように、ある程度、見られているようですが。 これこそが、フィードバックですので、すでに投資分の回収は始まっていると言えます。 ただ口頭で、開発者が「70%くらいですね」というだけであれば、かなり疑わしいでしょう。 「もうすぐ着く」は、家を出たばかり。なんていう言葉もありますしね。 仮にそうでなくても、業者にも自分にも厳しく見て、実際は4割、5割という所かもしれません。 じゃあ残りを返金してもらえるかと言えば、そういうものではないでしょうから、裁判沙汰になるのかなど、また別の問題が出て来ます。 そう考えると、2番と3番の間に、ここでは2.5番としますが。 2.5. 開発を継続。試験運用。ユーザーテストを今から積極的に行い、フィードバックを得る。つまり、αテスト、βテストに留める。同時に他の業者への切り替えに動き出す。 Cですでに動くものを見られているとすれば、「とりあえず、これと同じものを。DB、画面設計などはこの設計書を参考に」という形は、規模にもよりますが、次の開発者からすれば、かなり楽になる部分はあります。 当然、新しいチームも、動いているものを見ながら、フィードバックを得られますし、現在の設計を反面教師にもできます。 多分、PHPのソースを渡しても、細かい所までは読まないでしょう。 もちろん、Bをどうするのかという課題はありますが。 もしかしたら、いい意味でビックリするくらいの見積もりが出てくるかもしれませんね。 αテスト、βテストに留める事で、最後の詰めをそこまで気にしなくてもよくなります。 開発においては、ここが大きいですからね。ブラッシュアップするための開発に力を入れられます。 「いいアイデア」は、αテストで得られる事が多いですしね。 実際どうなるかはわかりませんが、他の言語、他の業者などを検討する事、それぞれの開発手法を知る事、海外の開発事情を知る事、開発スピードなどの違いを感じる事、すでに得たフィードバック、そこから出てきたアイデア、それら全てが、astoria17さんにとっての、大きな資産ですから。 お金なんかとは、まったく意味合いが違います。
astoria17

2016/10/30 01:55 編集

色々なアドバイスありがとうございました!MOTHER2は私も遊び尽くしたので、懐かしいです。こんなインタビューがあったのですね。まさか開発に5年もかけていたとは思いませんでした。まだ日本経済が良好だった1990年代だからこそですね。 Pythonは、長期的な拡張可能性という目線と、短期的な投資資金回収の目線とのせめぎあいで、とても悩みますね。そして日本ではPython技術者が少ないというのも、躊躇してしまいます。 今のプロジェクトはこのまま進め、別案件としてやや高度な機能を中心にPythonベースで置き換えていくというのもありかもしれませんね。 packさんがご関心あればぜひ何かの機会に飲みに行きましょう!astoria17@gmail.comまでいつでもご連絡ください。
pack

2016/11/02 02:14

「ツギハギ」という言葉が出て来ましたが、逆にそれが一つの潮流でもあるんですよね。 ・REST ・APIエコノミー ・SaaS ・クラウド などなど。 また人件費だけで考えれば、安い地域でのオフショア開発もあり、何が正解かというのも、ますます無くなってきていますね。 まぁ知識だけで、ここであれこれ言っていても、しょうがないのですが。 インタビューの中にあった岩田さんの 「あの味は、1年で即席でつくったら出ないですよ。」 が印象的でした。 > packさんがご関心あればぜひ何かの機会に飲みに行きましょう! こんな風におっしゃっていただいて、光栄です。 ありがとうございます。 The Internet's Own Boy
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問