告知もしていないのに、気軽にCTOのお気軽質問を受け付けている、ユゲタです。
知り合いの会社のマネジメント、CTO、リーダー、役員などなど、名刺交換をしただけの人から、FacebookやTwitterなどを通して仲良くさせてもらっている方、よく飲みに行く方、から気軽にメールやチャットをもらって、CTOお悩み相談的な話をします。
一番多い相談は、「エンジニア採用」なんですが、これは劇的に効く薬というのはなく、採用方式が確立していない場合は、それに対するアイデアであったり、０からスタートの場合は簡単にセオリーなどをお伝えしています。
次に多い質問として、「開発がうまく進まないので、どうしたらいいか教えて欲しい」という内容です。
同時に、「トラブルが多いシステムの改修をどうしたら良いか？」というのも合わせ技質問でされることも多いので、
今回は、「安定したシステムを構築するために必要な事」というのを考えてみたいと思います。
安定したシステムとは何か？
そもそも、「安定したシステムを作りたい」というのは、誰もが開発初期に考える事ではありますが、
作っているうちに忙しくなってくると、「安定」から「とにかく完成させる」という思考になりがちです。
そして、日々、世の中でいろいろな便利ツールが出てきている中、「開発途中でその便利ツールを導入したら開発が効率化できる」と判断すれば、すぐに導入する判断をする人も多いと思いますが、
その為に、「少しシステムの変更が必要になる」というケースが発生してしまいます。
実はこの「少し便利になる（効率的になる）から、少し手直しが必要」というのが、積み重なって、雪だるま式に膨れ上がるケースが少なく無い様です。
その結果、本来の仕様を少し変える必要が出てくるという場合も多くあるようです。
安定したシステムを作ろうとしているのに、仕様が安定していないという事に気が付きませんか？
多くの開発現場で、こうした仕様をコロコロ変えて開発業務を行っているケースが存在するようです。
しかも、これをアジャイルと言っていて、もはやスプリントが何かなんて理解できていないようです。
まずは、安定を目標にした仕様とスケジュールを立てたのであれば、それを完了するという事が第一目標にしなければいけません。
どうしても途中で仕様を変えたくなったら、その時点でスタートに立ち戻るぐらいの覚悟をしましょう。
結果的に、気軽に仕様変更をしているチームでの開発は、極めてスピードが遅く、安定しないシステムが出来上がる事は、ユゲタの経験上かなりの確率でそうなりますよ。
早く開発するということは、プログラミングを早くする事では無い
どの会社さんも、サービス開発は一刻も早く完了したいと考えていて、プログラミングができる開発者を一生懸命探して、人数とスケジュールを正比例的に考えがちですが、
プログラマーがどれだけ増えても、そんなに開発スピードは変わらないという事実に気がついている開発担当者は少ないようです。
SESとして大規模開発に派遣されている人は、もはや気がついているかもしれませんが、大きなシステムでの機能追加やちょっとした変更点を開発作業するのに、10人以上の開発員を抱えて、1ヶ月とかそれ以上を平気でスケジューリングします。
金融システムなど、堅牢にしなければいけない場合や、テスト・チェックなどの検証作業が膨大に膨れ上がるなど、理由はたくさんありますが、とにかく、システムが大きくなったら比例して開発員が増えるというのは、仕方がないかもしれませんが、「人を増やす=開発効率が良くなる」という思考は疑ってみた方がいいと思います。
では、どうやったら、早く開発ができるのかというと、開発する工程をいかに明確にできるかを先に構築できれば、開発のほぼ半分以上は完了したことになります。
多くの開発現場では、やりたい目標を決めてその中身を開発しながら考えていくというやり方で進めているから、スケジュール通りに完了しないんですね。
でもこれってウォーターフォール開発ですよね？と考えると思いますが、どちらかというとアジャイルのスプリント開発で考えるといいかと思います。
もちろん、最初から最後まで仕様を確定できるのであれば、それに越した事はありませんが、全体スケジュールをキリの良い箇所で区切ったポイントをミニマムゴールにすることで、それを１つの開発としてウォーターフォールとして完結させる。
１つのスプリント開発が完了したら、次のスプリントの仕様をちゃんと計画するということで、柔軟なアジャイル開発のスタイルを維持することもできます。
アジャイル開発のスプリントを知らない人は、次のURLを読むとわかりやすいですよ。
スプリントとは、スクラムチームが一定量の作業を完了させる際の、短く区切られた期間を指します。
より良いチーム開発をしたい人が考えること
大規模開発は、システム自体が大きく、検証ポイントが多い為、そうした作業を行う人員や、コードをどんどん量産するプログラマーが必要というのは、なんとなく理解できますが、
実はこの背景には、ほとんど仕様変更がされていないという事実にも眼を向けてみるといいでしょう。
やることが決まっているということは、人手を増やせば工数は人数分見込めますが、実際にwebサービスの構築を行っている開発チームでは、
仕様が決まっておらず、プログラム言語や、フレームワークや、似た様なサービスを構築したことがある経験者を、採用したがりますが、そんなことをしても、ほとんど開発速度は変わりません。
むしろ、基本的に、仕様が決まっていない開発チームで人を増やしたら、その分作業効率は悪くなります。
社内スキルが足りていないから、スキルホルダーのイケてるエンジニアを採用したとしたら、きっと本来行うべき開発を根底から覆されて、予定していた仕様とは全くの別システムが出来上がるでしょう。
それを望んでいるのであれば、いいのですが、もはやチームの目的すらも変わってしまうことも考えられますね。
また、初心者を採用したとしたら、数ヶ月（または数年）は、その人員育成を行う必要があり、教育担当者という役割が追加されます。
また、人が増えた分、マネジメントや各種管理を行う必要があり、チーム内を分割したセクション事にリーダーを設置し、ますますマネジメント業務が膨れ上がってきます。
そして、そのリーダーをまとめ上げる、リーダーも必要になり・・・なんか雪だるま式にやることが増えていくのが想像できますね。
実際に、この方式で、想定していた仕事以外の作業が50%以上の割合を締めてしまったという経験をユゲタもこれまでしてきました。
ここで欠けていたのは、「組織思考」だったのではないかと考えて、ユゲタは10年前からブログを書き始めたんですが、おかげでいろんな会社さんとの交流や、自分の開発チームを一歩外からみる視点を身につけることができて、まあまあ助かりましたね。
自分のチームをより良くしたかったら、他のチームのことをよく知るべきなのかもしれませんね。
サービスを完成させるのではなく、資産を作る思考になれ
色々とチーム論やら、開発論を書いてみましたが、過去に別の会社からされた質問で最も未熟な質問として、ユゲタが思ったのは、
どのフレームワークを使うのがいいですか？
という質問で、今使っているフレームワークがサポートが終了して、世の中的にもオワコンムードがあるので、新たなフレームワークに乗せ替えたいのだそうですが、会社組織において、この思考をしているCTOがいたとしたら、ちょっとしんどいかもしれませんね。
なぜなら、おそらく3年後には、そのフレームワーク自体も大幅にバージョンアップしているか、オワコンになってしまい、その時に同じセリフで質問をしている可能性が高いからです。
経営者でもあるユゲタの思考としては、折角、人と金をかけて会社のシステムやサービスを開発するのであれば、ソフトウェア資産だけでなく、技術資産も同時に保持したいと考えたいですね。
ちゃんと開発員を雇って自社開発を行っているのに、結果的に、全てのアーキテクチャが、何かしらのフレームワークに依存していたり、「技術ポイントは何？」と聞いてみると、有名なライブラリの名前しか上がらないというサービスに、技術資産価値はありません。
エンジニアはそのフレームワークやライブラリの使い方に長けた単なる手慣れた作業者であり、技術資産を生み出す技術者ではないという厳しい見方もできます。
せっかく開発をするのだから、将来自分が作ったプログラミングコードを資産として残せる活動をするということは、エンジニアにとっても、すごく明るい未来とも考えられるし、そういう思考の会社で働きたいと思うエンジニアが多いのでは無いかと思いますね。
ということは、そういう思考になることで、採用活動なども、もしかしたら、優秀なエンジニア獲得につながるかも・・・と考えながら、結果的に、安定したシステム開発をするチーム作りではないかと、今現在のユゲタの思考をブログに書いてみました。
