LoginSignup
994
989

More than 3 years have passed since last update.

15年間システム開発業を営んで来た結果の最適解

Last updated at Posted at 2019-08-26

15年間様々な環境を試してきましたが、これが最適かと思っている事を記載します。
随時更新し、各項目の詳細は別記事で記載していこうかと考えています。

2019/08/28追記
多くのいいねを頂きありがとうございます。
大切な業務分析が抜けていましたので、追記させて頂きました。

環境周り

開発環境

IntelliJ

vim・emacsでプラグインを使用、Eclipseなど様々なIDEを使用してきましたが、現在はIntelliJに統一しました。
以下採用理由です。

  • 構築が行いやすい
  • 多数の言語・フレームワークに対応している
    • あらゆるプロジェクトにて同じIDEを使用出来る
  • 補完が非常に便利
  • あらゆる操作にキーバインドが設定可能
  • 初心者から熟練者まで満足できる操作性

Docker

出来る限り環境依存を無くす為、データベースなどのサーバープロセスはDockerで構築しています。
但し、Tomcatは環境依存が少ないため、ローカルで立ち上げています。
まだ、本番運用では運用経験なし。

upsource

コードレビューはupsourceで行っています。
以下採用理由です。

  • gitの履歴が見やすい
  • upsourceのレビューをIntelliJから紐付け出来る
  • upsourceの通知をIntelliJから受け取れる
  • IntelliJ内でやり取りを行える

Jenkins

CI環境(自動テスト・デプロイ)は、特に不満がなくJenkinsを使用してます。
ただ、環境維持が面倒なので、クラウドサービスを採用しても良いかなとも思っています。

言語

バックエンド

PHP(CakePHP・Laravel)、Ruby(Ruby on Rails)、Java(SpringBoot)、NodeJSなど案件に合わせて最適な環境を選択していますが、特別な要件がない限り、Kotlin(SpringBoot)で開発しています。
以下採用理由です。

  • Kotlin
    • Rubyのようにサクサクプログラムが書ける
    • 最終的にはjavaのプログラムになる為、プログラムを動作させる環境依存が少ない
    • javaを知っていれば、サクッと習得できる
  • SpringBoot
    • 必要な機能(認証機能・データベース操作)がサクッと準備出来る
    • 大きな仕様変更がない(Ruby on Railsはこれで苦労)
    • ビジネスロジックを如何に綺麗にコーディングするかにフォーカスしやすい

フロントエンド

AngularJSをメインで使っていましたが、今はReactをメインにしています。学習コストがそれほど高くないですが、より綺麗な設計にする事がハードルが高く、プログラマーのスキルに依存してしまう事が現在の悩み。

本番環境

Heroku

特別な要件がない限り、Herokuで運用している事が多いです。
以下採用理由です。

  • SpringBootで開発している場合だとサクッとリリース可能
  • OSのアップデートなどの保守作業を行う必要がない
  • 大規模サイトではない限り低コストで運用可能
  • ログ監視サービス・DNSサービスなどサクッと準備可能

さくら VPS

特別な要件がある場合は、さくらのVPSを使用しています。
採用理由は安さですが、保守作業の手間や、さくらのメンテナンスの多さからメインで採用には至っていません。

社内運用

Redmine

社内のタスク管理はRedmineを使用しています。
以下採用理由です。

  • 設定項目が豊富で、社内に合った設定が可能
  • 足りない機能はカスタマイズ可能
  • APIが豊富
  • 特に他に移る理由がない

Slack

社内のコミュニケーションはSlackを使用しています。メールでは遅すぎますし、口頭では相手の集中力を妨げる事になるため、ほぼSlackだけでコミュニケーションをしています。
但し、Slackのチャンネル運用には気を遣ってます。理由は一つのチャンネルで話しが多すぎると、全メンバーがその情報の確認の為に時間をロスすることになったり、後から情報を参照しにくい為です。
SlackとRedmineを連動出来るROSAを採用しています。
採用理由は以下です。

  • 案件毎にチャンネルを持つことになるが、そのチャンネルではチケットの作成のみとなっている
    • 1案件1チャネルとすると話しが多すぎる
  • 1チケット1チャネルとなっている為、一つのタスクに話題をフォーカス出来る
  • チケットが終了状態となると、チャンネルもアーカイブされる
    • チャンネルが無限に増えない
  • Slackの情報がRedmineにも残るため、Slackで話された内容がRedmineの検索機能を用いて細かく検索出来る

Redash

Redmineに蓄積されたデータから、業務分析に使用しております。
活用内容はシステム開発における業務分析にまとめさせて頂きました。

円滑化

教育用Redmineプロジェクトを作成

Wikiに働く為の知識をまとめ、それぞれのステップで新人にチケットをアサインしています。
これによりその新人の教育プロセスが可視化され、予定工数と実績工数により、その人の習得の早さも判断しています。
以下Wikiに記載している情報です。

  • Redmineの使い方
  • Slackの運用方法
  • 心構え
    • 納期に対する考え方
    • 報告・連絡・相談の心構え・方法
    • 時間に対する価値
    • 品質を確保する方法
    • 仕事に対するベストプラクティス
  • 環境構築
  • gitの使い方
  • 各スタッフの紹介
  • IDEなどのTips
  • コーディングルール
  • レビューの行い方
  • Kotlinのチュートリアル
  • SpringBootのチュートリアル
994
989
13

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
994
989