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

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

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

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

Q&A

解決済

7回答

3033閲覧

社内のエンジニアの人数が増え、システムが大規模になって来た時に次に何を学べばいいのか

KazutakaShimizu

総合スコア157

PHP

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

6グッド

18クリップ

投稿2017/02/16 02:10

私は小さなベンチャー企業を経営しているものです。
もともと起業当初はチームにエンジニアがおらず、自分でPHPを独学して現在webサービスを運営しております。
最近サービスの方も徐々に大きくなってきたので、資金調達をしてエンジニアを増やそうと思っています。

今まではとにかく実装すること、それもなるべく早く実装することばかりを気にしてプログラミングを勉強してきたのですが、人が増えチームになったときにコードの可読性やメンテナンスのしやすさなど今まで意識してなかったことを意識する必要があるのかなと考えております。

そこで人数が増え、サービスが大きくなってきた時にはこういうことを意識したり勉強した方がいいよ、またできればそれが学べるサイトや本などがあればご紹介いただけないでしょうか。

何卒よろしくお願いいたします。

Yuki-Naka, zico_teratail, kanbeworks, M-Kajiwara, musix55, SASAHARA👍を押しています

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

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

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

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

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

guest

回答7

0

ベストアンサー

エンジニアとしては、質問者さんのような方が経営者側であると嬉しいですね。
お役に立てるかは分かりませんが、エンジニアの責任者サイドとして覚えるべき事をまとめてみました。
完璧を目指すと長い道のりになると思いますので、ご自身で覚える or エンジニア第一号を妥協せず高スキルな人間を採用して構築してもらう…あたりの判断はお願いします。


コードの品質の統一

独学…ですか。Webサービスを構築する際、フレームワークは利用されていますか?
もし利用していない場合、新メンバーが2〜3人のチームになるまではに是非覚えて乗り換えておきたいところです。

フレームワークすら使ってないオレオレWebサービスは、大抵コードもぐちゃぐちゃなので死ぬほど読みづらい糞プロジェクトなのが一般的です。
おれっちの最強プログラミングスキルならばフレームワークなどの軟弱なものは要らん…
というので無ければ、何かしらのWebブレームワークは必須と考えて良いでしょう。
(温故知新、フレームワークの戦い方や概念を知れば、フレームワーク無しで空で書く場合でも出来ることの幅が広がったり、深みが出ますからね)

そしてPHPのフレームワークは大抵コーディング規約(PSR等)を内包しています。
各地ではもう古臭いとか言われるCakePHPですらこの辺はある程度整っているので、一定の評価はされます。


GitHubやBitbucket流の運用方法はどうでしょうか?
もしプルリクを使ってなければ覚えましょう。
更に…もしGitを使っていないのであればGitはモダンなエンジニアの義務です。絶対に抑えましょう。

以下は私の職場を参考にした一例です。

  • masterブランチは本番環境で動作しているコードと等価
  • developmentブランチをmasterブランチを元に作成
  • 各作業者はdevelopmentブランチから新しいブランチを作成して作業
  • 作業完了後、作業者は自分のブランチ名をそのままPushする
  • ホスティングサービスの管理画面にログインして、developpmentブランチに対してプルリクエストを出す
  • リーダー(≒質問者さん)へプルリクエストの承認依頼がメール通知等で飛ぶ
  • リーダーは自身のアカウントでコミット対象のコードをレビューする
  • 承認された場合、管理画面のマージボタンクリックでdevelopmentブランチへ勝手に取り込まれる
  • 本番環境への更新はdevelopmentからmasterにプルリクを出すなどして取り込む

メンテナンスのしやすさ

絶対にXamppやMampを使っている作業者が出ないようにしましょう。
あれは新しいバージョンを使いたがるのと、コロコロ変わる仕様、ドキュメントの乏しさ、外部拡張機能の導入の困難さから「僕の環境では再現しませんでした。」現象が頻発します。
「甘ったれんじゃねえ!」と怒るも無駄で、結局バグ出した人にパソコン貸してもらって作業するという非効率極まりない解決方法になるので、絶対にこれは避けたいところです。

最低限Vagrant、余力があればDockerを覚えましょう。
1台で何とか出来る範囲内であればdockerとdocker-composeを抑えておけば自由自在にサーバーを立ち上げる事が可能になります。

その後、サービスが大きくなりすぎてロードバランサーで負荷分散というフェイズに至った場合、KubernetesやFleet(CoreOS)を利用しましょう。

投稿2017/02/16 03:53

miyabi-sun

総合スコア21158

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

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

miyabi-sun

2017/02/17 01:53

質問履歴にはsymfonyのタグの質問が多く見受けられるので、 フレームワークの導入という第一段階はクリアですね。 既存のコードは下記のルールを全て守っていますか? symfonyでやるなら下記に従い、今後ジョインしてくる全てのエンジニアに従わせましょう http://docs.symfony.gr.jp/symfony2/contributing/code/standards.html さもないとソースコードは直ぐ様バラバラのぐちゃぐちゃになり、プロジェクトが空中分解します 出来るエンジニアはその辺を把握しているので快く引き受けてくれると思います。
KazutakaShimizu

2017/02/19 05:29

ご回答ありがとうございます。 おお、こんなにたくさんアドバイスいただけるとは思ってなかったので感動しております・・・。 おっしゃる通り現在はsymfonyをつかってサービスを作っておりますが、フレームワークに規約が内胞されてるとはしりませんでした。ちょっと後ほど詳しく見させていただきます。 バージョン管理は現在gitを使い、bitbucketも使っております。 ただプルリクは全く使っておりませんし、外部のエンジニアさんと一緒に開発するときも変更をレビューするようなことはしてないですね・・・。 mamp、がっつり使っております・・・。「僕の環境では再現しませんでした。」現象、めちゃめちゃ出ております・・・。 dockerもvargrantも全く存じ上げておりませんでした。 世の中にはこんな便利なものがあるのですね。驚いております。
guest

0

複数人での開発を管理するツールの導入して、コミュニケーションを取れるようにしてからやり方を煮詰めて行ったほうがいいかもしれないですね。
・git等のバージョン管理ツール
・Slack等のコミュニケーションツール
・Redmine等のタスク管理ツール

投稿2017/02/16 03:19

yona

総合スコア18155

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

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

KazutakaShimizu

2017/02/19 05:30

ご回答ありがとうございます。 そうですよね、コミュニケーション周りのツールは大事ですよね。 現在はgit、slack、バックログを使っているのですが、ちょっとこのあたりも考え直してみます。
guest

0

  • コーディング規約を提示すること
  • チームにその規約を(強制的に)守らせる手段を用意すること。(教育、ドキュメントや構文チェックツールなど)
  • コードレビューの仕組み

を考える必要があるのではないかなと思います。

投稿2017/02/16 02:15

編集2017/02/16 02:16
yamato_hikawa

総合スコア2092

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

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

0

技術的なことは他の凄腕回答者さんたちに譲るとして、全く別の角度から・・・

人が増えて最も大切なことは、技術よりまず先にマネジメントや人心掌握術とかではないでしょうか?

コーディング規約も大事だけど、ワークライフバランスや福利厚生はもっと大事だと思います。
エンジニアも人間なのでね。

サービスのリリース直前などは年に数日くらい残業や長時間勤務になってしまう場合も仕方ないかもしれません。
しかし残業や長時間勤務が日常的になってきたらそれはマネジメントが無能だという証拠です。

あと『人を動かす』とか、そのあたりの名著を読んでおくといいかも。

投稿2017/02/16 06:59

zico_teratail

総合スコア907

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

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

KazutakaShimizu

2017/02/19 05:18

ご回答ありがとうございます。 おっしゃる通り人と一緒に働いていく上で大事なのは技術のことだけではありませんよね。 そのあたりも合わせて勉強しようと思います。
guest

0

すでに導入されているかどうかはわかりませんが、gitなどのバージョン管理システムは非常に重要になります。自分ひとりで開発しているときはいいのですが、多人数で開発するとなると、「なんか最新のコードで動かなくなった!」「このファイル修正したはずなのに誰かが上書きして巻き戻ってる!」「俺もそのファイル編集したいけど別の人が編集してるから待つしか無い」「動かなくなったから原因がわかるまで前の状態に戻したいけど前のファイルが残ってない…」といった問題が発生するようになります。この時バージョン管理システムがあれば、それらの問題を解決できます。
今のバージョン管理のトレンドはgitです。昔はCVSやSVNといった管理システムがありましたが、githubの存在がgitのデファクトスタンダード化を後押ししました。なによりCVSやSVNで問題となっていた箇所が改善されているのでgitが一番優秀だと思います。

投稿2017/02/16 02:25

masaya_ohashi

総合スコア9206

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

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

KazutakaShimizu

2017/02/19 05:32

ご回答ありがとうございます。 バージョン管理ツールはgitを使っておりますが、他にも色々なものがあるのですね・・・。 基本的にこのままgitを使うつもりですが、少し他のものもどんな感じなのか調べてみようと思います。
guest

0

開発者は複数いるけど作るのはいつも1案件1人!といった所にいるものです・・・
チームで作業するときに思っていることだけ。。

・バージョン管理ツールの導入
まだまだSubversionを使ってますが、ソースコードを集約できるっていうのがメインです。
使い方を全員が把握できていれば、そんなに困ることは無いです。

・コーディングルールの統一
古かろうがなんだろうが、記述が統一さえしてあれば読めるんです。
コードレビューで散々文句を言ってきましたが、これが無いと後になって困る!

作った人は居なくなるので、人が作ったプログラムを引き継ぐ・修正する
という所だけはどうにか考えておきたいですね。

私の方がレベル低い?頑張ります・・・

投稿2017/02/17 10:38

sakana009

総合スコア12

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

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

KazutakaShimizu

2017/02/19 05:10

ご回答ありがとうございます。 バージョン管理ツールはすでに使っているのですが、コーディングルールの統一というのは全くできておりませんね・・・。 僕自身がもともとエンジニアではなく、そういったルールに則ってコードを書いたこともないためなかなか想像がつきませんが、少し調べてみようと思います。
guest

0

既にベストアンサーも出ており、重要な回答は十分でているのですが、気になる話だったので、ちょっと違った角度から回答させて頂きます。

経験上、ひとり開発から複数人体制の移行時に直近で最も大きな、且つ長期的にも見過ごせない課題となるのが、属人化の問題ではないかと思われます。
要はナレッジ等情報共有と明確化ですね。

またその後、体制・フローが固まってきた時期には、品質や効率の向上が優先度の高い課題となり、さらに人が増えると・・・等と、課題は時期や人員、視点等によっても変わっていきます。

もちろん、経験豊かな回答者さん方の意見も、この問題を含めた数多の課題に対して様々な現場が培ってきたオールマイティな解ではありますが、大多数から集約された理想形が、現実の現場の最適解とは乖離している場面も多々あります。
大幅に生産性を落としてでも、(現場の幸せのために)これらの理想形を目指す、というのもアリ(というか、むしろ大歓迎)ですが、会社に体力と理解が無いと、これらも許されません。

前置きが長くなりましたが、結論としては、「回答者さん方の意見を将来的なビジョンとしてザックリ把握する程度に学びつつ、課題抽出・解決手法やPDCAサイクルの具体的な運用を学び、それらを運用していく中で出てくるその時々の最優先課題について、必要な知識と技術を学ぶ」でしょうか。

質問者さんは経営者でもあるので、上記のような各論めいたものより、「プロジェクトマネジメント手法を学ぶ」とかの方がストレートなのかもしれません。

投稿2017/02/21 09:09

masami

総合スコア42

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

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

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

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

質問する

関連した質問