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

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

ただいまの
回答率

90.12%

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

解決済

回答 7

投稿

  • 評価
  • クリップ 17
  • VIEW 1,910

KazutakaShimizu

score 158

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

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

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

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

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

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

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

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 7

checkベストアンサー

+14

エンジニアとしては、質問者さんのような方が経営者側であると嬉しいですね。
お役に立てるかは分かりませんが、エンジニアの責任者サイドとして覚えるべき事をまとめてみました。
完璧を目指すと長い道のりになると思いますので、ご自身で覚える 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/17 10:53

    質問履歴にはsymfonyのタグの質問が多く見受けられるので、
    フレームワークの導入という第一段階はクリアですね。

    既存のコードは下記のルールを全て守っていますか?
    symfonyでやるなら下記に従い、今後ジョインしてくる全てのエンジニアに従わせましょう
    http://docs.symfony.gr.jp/symfony2/contributing/code/standards.html

    さもないとソースコードは直ぐ様バラバラのぐちゃぐちゃになり、プロジェクトが空中分解します
    出来るエンジニアはその辺を把握しているので快く引き受けてくれると思います。

    キャンセル

  • 2017/02/19 14:29

    ご回答ありがとうございます。
    おお、こんなにたくさんアドバイスいただけるとは思ってなかったので感動しております・・・。

    おっしゃる通り現在はsymfonyをつかってサービスを作っておりますが、フレームワークに規約が内胞されてるとはしりませんでした。ちょっと後ほど詳しく見させていただきます。

    バージョン管理は現在gitを使い、bitbucketも使っております。
    ただプルリクは全く使っておりませんし、外部のエンジニアさんと一緒に開発するときも変更をレビューするようなことはしてないですね・・・。

    mamp、がっつり使っております・・・。「僕の環境では再現しませんでした。」現象、めちゃめちゃ出ております・・・。
    dockerもvargrantも全く存じ上げておりませんでした。
    世の中にはこんな便利なものがあるのですね。驚いております。

    キャンセル

+5

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

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+5

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/19 14:30

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

    キャンセル

+4

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/19 14:18

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

    キャンセル

+3

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/19 14:32

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

    キャンセル

+1

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/19 14:10

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

    キャンセル

0

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

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

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

  • ただいまの回答率 90.12%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる
  • トップ
  • PHPに関する質問
  • 社内のエンジニアの人数が増え、システムが大規模になって来た時に次に何を学べばいいのか