システム開発の成功を導く勘所

最近、システム開発はこうあるべきだよなって考えていたのと、他所のエンジニアリング文化についての記事を見たことから、自分にとっての今の理想と現実の間について整理して吐き出しておきたくなりました。

所詮理想ではあるものの、自身の環境におけるベストに近づけようとする思考や、ベストに程遠い状況を認識する、ということには意味があるのではないかと思う次第です。

はじめに

自分は100％WEB系出身ですが、全く異なる文化である SIer 方面のお話を読むのはわりと好きで、これらは興味深く読ませてもらいました。

だいたい SIer に対するイメージ通りではあるものの、シッカリしている点と、内容や契約によってそうでなくては成り立たないシステムもあるだろうことから、ある種のリスペクトを感じています。１度でも所属してしまうと、呪詛を抱くのかもしれませんけどね。

一方でWEB系は規模に幅があり、ベンチャーなど小規模ならではのキラキラ系（ドロドロ系？）の良し悪し、上場可能な規模からの急激な変化による良し悪しもあり、大規模になるほどやはり組織として堅くなっていく分、自分も思うところはあるので、そのあたりにエンジニアとしてのあり方とかシステム開発の勘所、みたいのがあるのではと思っています。

エンジニアリングの幅を表現すると、製造業的で決められたモノづくりから、創作的で流動的なモノづくりまで、広くあるとはいえ “開発者” としての本質はそこまで変わらなく、それを有効活用することにこそ成功の鍵があるのでは、という願望でもあります。

システムの存在価値

まず最初に整理しておきたい重要な要素として、システムの存在価値ってなんぞや？ってところです。システム開発が円滑に進行しない時、往々にして質を無視したスケジュール内での形だけの完成が目的になってしまうからです。

これは完全に私見ですが、ハッキリ２点に価値を見ています。

便利であること

楽しいこと

この片方もしくは両方を満たすシステムには価値があり、そうでないシステムは著しく品質が欠けているか、そもそもボツにした方がマシな場合も多いです。このシステム価値は、ユーザーにだけではなく、開発者にとってもモチベーションに関わる非常に重要な要素であると考えます。

システム開発は発想と組み合わせによるモノづくりであり、本質的にはゲームや玩具の延長線にある、それ自体が楽しいものであること。そして開発しているシステムに触れていれば、それが便利であるのか楽しいものであるのか、は必ず感じることとなります。

そこに価値を感じれば、例えデスマーチ寸前でも楽しさ喜びをもってモチベ高く良いモノづくりができますし、逆にどれだけ楽でもクソシステムならゴミづくりに感じてしまうわけで、詰まる所はその開発の経過と成果が成功に向かっているかどうか、という点がユーザーと開発者どちらにとっても最重要であるということになります。

システムの改善エネルギー

システム開発はいくつかの段階に分けられ、考案・設計・構築・運用といったどの段階にも品質を改良する思考が入る余地があります。もっと便利に・使いづらさを排除・見やすさ・わかりやすさ・触れる楽しさ、などいろんな角度から必ず改良することが可能なのは、最初から 100点なシステムは存在しないからです。

あらゆる段階で、あらゆる角度から、開発者自身が触れることでより便利により楽しいシステムになるよう、改善案が出るのはごく自然な現象であり、この開発中に自然発生するエネルギーこそがシステムの品質を向上させる１つの柱であると考えます。

ザックリとした企画なら、設計時により良い方向性や機能を思いついたり、
構築中に設計の見直しや表示の微調整などはいくらでも発生するし、
運用するとリリース前に思いつかない改善点など山のように出るでしょう。

システムの多くは役割分担とその結合によって出来上がるという特徴はあるものの、１つの創作物・作品とも捉えられるため、上から下に工程が流れるだけではベストに近づくことは難しく、各フェーズが相互に高め合うことにこそ、目的を高い品質で達成する可能性を含んでいます。

人数や時間の制約によって、開発構造が堅く細分化されるほど、この強力なエネルギーを有効活用せず封殺してしまう場合があり、それにより開発意欲と品質向上の機会を失う結果になることも多いのではないか── という観点では、そこに価値や楽しさを見出したい人材は、WEB界隈の方が合うだろうなってのはありつつも、

上振れしない代わりに下振れもしづらい製造業的な開発と違って、オモクソ上振れも下振れもするのがWEB界隈なので、業界と開発事情を合わせて自身の適性を考えるのが良さそうではあります。

分担の弊害

システム開発を数人レベルで行う場合で、特に社内開発の場合は、わりとお互いにあーでもないこーでもないと、ワチャワチャやりながら作り上げていくことが多いです。システムとしての確かさはマンパワーの技術力・統率力によって大きく上下するところではありますが、自由度とスピード感をもって大きく上振れしたりゴミになったりと、味のある仕上がりになりがちです。

これが一定以上の人数やシステム規模になると、マンパワーよりは組織パワーを前面に押し出し、役割分担が細かくなっていきます。その役割分担にも種類があり、１つのチーム内で完結する分担や、１企業内の部署間連携が必要な場合、複数企業にまたがる場合など、そのつなぎ目の性質には結構な違いがあります。

チーム内ならば、そこの統率者やチームワーク次第で意見交換や開発速度をいかようにも向上することが可能です。部署間になると、話を通すのに突然そこの部長間という経路などが必要になり、一気に開発者同士のコミュニケーション環境が悪化したりします。企業間となるとそれがより顕著になり、かつ契約もあるので、基本的に下請け側から依頼側に改善案などが上がることは少なく、また実際に作る側ではない方からは意見が強く反映されるか、もしくは丸投げに近いような、両極端になりがちです。

こういった分担によって、開発フェーズとしては設計だけする・コーディングだけする・正常運用を維持する、といった切り分けが発生し、システム全容の把握をしづらいままパーツを担うという業務スタンスが確立します。これには危うさをいくつか含んでいます。

１つはシステム全体としての完成度です。設計だけしても肝心のモノは目の前に積み上がらないし、開発中に改善点を見つけても設計に反映できないとか、運用効率が悪くとも意見を出さない・聞き入れてもらえない、といったことが小さくとも積み上がると、１つの作品としてはチグハグ感を抱えた歪なシステムとなります。──なりますが、それに気づいてか気づくこともなくか、そのままなんとか提供・運用されてしまうことも少なくないでしょう。

２つ目は開発自体の魅力です。システムは生き物とまでは言いませんが、全体を網羅的に把握することで改良したりバランスを取ることが可能な面は強いです。そのため、分担だけをすると隣り合うパーツとの適応性が不明なまま進行したり、関係ある箇所との意見交換が断たれている場合、全体のバランスや結合時の品質を損ないやすくなります。

つまり、その状態は自身の制作物の成果の劣化へと繋がるため、制作意欲に影響します。シンプルに言うと楽しくなくなります。逆に全体もしくは近辺を把握して、忙しくともアッチもコッチもあーだこーだ改善しながら効果的な構築をできるシステム作りには、確かな楽しさがあります。

とはいえ、全員が全容把握や意見交換に乗り出せば必ずしも良いというわけでもなく、専門性が高いパーツづくりに専念する方が良い場合や、経験不足な人材の場合も手を広げるよりはまず一箇所に集中した方が良いこともあります。

分担が基本必須である以上は、こういった様々な事情を汲んだ上で、各役割同士が双方向に意見交換できて、互いをリスペクトしつつ取り込めるコミュニケーションというか、文化的な素養を馴染ませ進行できるマネージメントをできる人材がいるかどうか、が結構な成否の鍵になるのではないでしょうか。

少なくとも、役割間で丸投げにして意見交換を断たれた環境だと、100点満点ベストなデキには程遠いということにはなります。

愛着と情熱

システムづくりの多くは業務やビジネスと捉えられます。役割分担はするし、給料をもらうなり直に儲けるなりするので、稼ぐための手段であることは間違いありません。

一方で、作品という見方もできるため、それが仕上がっていくさまに関わったり、使ってもらった感想をもらうことで、その作品には愛着が湧き、より良くしたいという情熱が湧きます。……そうじゃない人もいるだろうから、湧くことにします。

ただの業務として見た場合、目的をただ達成したり、指示されたことを実現するだけ、に留まるところ、愛着や情熱によって継続的な改善や運用を、自身の意思で考察して取り組むパワーの発生源となります。これを体感しているかどうかは、その人が何を作ってどういう成果となってきたか、という経験に大きく左右されるので、人によってはなかなか理解できないかもしれません。

これを真とすると、システムづくりにあるべき・あって欲しい要素として、最初から最後まで開発に関わる人材が最低１人以上いることが望ましく、システムの本質や道程を欠けることなく伝え保つことです。

厳しい時期があるとしても、できるだけ開発工程が適切で、高い品質で進行しようとしていれば、開発自体に楽しさを見いだせますし、それによって終始関わる人材が定着しやすくなります。便利で楽しいシステムを提供するには、なにより開発者が楽しむのが効果的な理想です。

逆に開発工程の管理が杜撰だったり、設計がイマイチで品質もイマイチになると、悪い事象が起きていきます。もろもろが噛み合わないことで、まずはスケジュールの遅延が発生します。遅延は焦りを生み、さらなる品質への悪影響を及ぼします。遅延と品質の悪化が長期化すると、人材の入れ替わりが起きやすくなる── といったことが考えられます。

最悪、人材が全て入れ替わると、そのシステムに対する愛着も情熱もリセットされ、酷い品質になっていくか、ただの業務としてなんとか形を成しているだけの完成へ漕ぎ着ける、くらいに留まることでしょう。

もし、そういった悪化した現状に対して、時間が足りないとか人が足りないとか、ただ目の前の要因を考えるだけではなく、それよりも根本的に、開始から現在に至る過程においてなるべくしてなっており、それは初期の設計や舵取りが原因である、ようなところまで振り返られる文化や人材だと、それも糧の１つとして成長していけるのではないかと思います。

肝は設計

ここまで、改善エネルギーだの愛着だの、エンジニアのくせにわりとスピリチュアルな話をしてきましたが、結局のところそれらにビシッと太っとい軸を通し成功に導くのは、序盤の設計に大半がかかっていると考えます。

業界によって設計がどういう成果物を指すのかは異なると思うので、そこには触れませんが、共通して言えることは設計は机上の成果物である、ということです。

机上において、テキストや図を用いてシステムの全体像を表現し、ミドルウェア選定やコーディング方法、データ構造といった内部構造まで広く手掛けるため、高い創造力と技術力を必要とします。その実力差によっては、机上で８割方を見通せるのか、２割程度になるのか、くらいの差がでるかもしれません。

非常に難しい役割ではありますが、重要度のわりに設計自体に要する時間は、開発全体からするとかなり小さい割合になるはずです。その小さな部分に、その後の開発・構築から完成品質までの多くの影響力が込められるわけで、そこに最強戦力を投入する価値があることは言うまでもありません。

そして設計者は、他者への理解を促す力も求められます。各開発者が設計の意図を汲み取って構築し、改善案も返してくれるなら最高の環境ですが、指示が多く必要な場合は時間をとって設計を噛み砕いていく必要が生じます。

また、システムの考案者や依頼者が他にいる場合、その良し悪しを設計時点で判断されない場合があります。これに似たセリフを聞いたことはないでしょうか。

「ある程度デキてみないとわからない」
「触ってみないと判断できない」

優秀な設計者はその仕上がり品質に一定以上の確信を持てますが、未熟で十分な確信を持てず、かつ稟議が設計で判断されない場合、確度が低いままにモックづくりへと突入することになります。設計時点で判断できるか、システムが可視化されてようやく判断できるか、の差はシステム開発の成否にモロかかってきます。

悪くすると右往左往した末に、人件費が全て吹っ飛び開発方針も迷宮入りして宙ぶらりんになったりもするので、設計者の実力を重視するのは当然のことながら、全体を通して設計を重んじる開発工程・文化であることが望ましいです。

設計を秘めない

そうはいっても、いろんな設計力のエンジニアがいるし、システムの難易度も関わるし、チームの錬成度も異なるしで、強者がいれば常時上手くいくと考えるのも危険です。

組織が大きくなると、部署やチームが細分化されるのは、１つの集団は何人以上にはしないとか、何人程度が適切である、といった考え方があるからです。これは正しくもありますが、各チームに絶対的な信頼のある人材が１人以上配属されるわけではない、という事象も起きたりします。

組織が小さく雑な時には、その組織内の強々エンジニアが各所に気を配ることが可能でも、規模が大きくなり各所が細分化されると、チームごとの強々エンジニアが不足になりがちです。良く言えば各チームに裁量を任せるということですが、悪く言えば組織全体として積み重ねた強みを活かしきれない構造とも言えます。

もしこれに似た状況になる場合、最低限守りたいことは、設計をチーム内に秘匿しないということです。案件によっては社内全体に公開はできないでしょうから、社内の信頼あるエンジニアだけにでも区切りで共有したいところです。

チーム事情によっては、チーム内で全てを完結したいとか、外部からの影響を遮断したい、などが発生することがあります。しかし、設計の重要度を理解していれば、設計時点で品質の確度を上げておくために、エースのような存在に添削してもらうことはチーム事情などより大切だと考えるはずです。

社内のエース的な存在は、技術に関わる何かを頼まれて渋ったり断るようなことはしません。もしするなら、そいつはエースではない、と断言しておきます。面白い｜怪しい案件があるんだけど見てくれます？と積極的に振れる文化にしていきたいところです。

とはいえ誰しも常に設計を高品質にできる保証などないので、重要なのはその設計力自体というよりは、設計に改善を受け入れる姿勢があること、だと考えます。

設計内容を共有して説明できるということは、良くすれば仕上がりに自信があるということ、悪くとも意見をもらって改善していく意思があるということです。説明を避けるということは、仕上がりに自信がないかよくわかっていない、他者の意見をシャットアウトしたい状態である、という黄信号になります。

とりわけ優秀とされる人材は、性格にクセがあったり口が悪かったりしたとしても、他者からの意見や感想を聞き取り入れることや、より良くする改善の変化に躊躇することはありません。それは目的がとにかく良いシステム開発をすることであるからで、そのための事柄に比べれば、それ以外の全ては些事だからです。

些事とは例えば、他者に口出しされたくない気持ちとか、意見の口調や忖度など、主に感情に由来する色々です。もちろん感情も重要な要素ではありますが、良いモノづくりをすることよりも感情を優先するようになったら、モノづくりとしては目的を見失って迷走している可能性が高いでしょう。

組織においては、１つのシステムを超良くするという上方向を見ることは大切ですが、泥沼に入らないようにする・泥沼から救い出すといった下方向を食い止めることも大切だったりします。組織構造が細分化されるほど、チームごとの実力差が出たり、コミュニケーション機会が失われたりするので、お互いに他人事になりすぎないような文化醸成が大事──なのですが、なかなかにパワーを要する事柄でもあります。

おわりに

システム開発はその環境によって全く風合いが異なり、１人で自由気ままな開発から、多人数でのシステマチックな開発まで、必要な能力も得られる能力も感じる魅力も様々です。

複数の環境条件を経験すると、どういう時に品質向上がしやすいのか、どういう時に悪化や失敗へ傾いているのか、という肌感覚が身についていきます。自由すぎても不安定な箇所が発生するし、堅すぎても期待を超える可能性を潰してしまいます。

特にありがちなのは、長期化した開発は概ね失敗するということです。一度バランスを失った開発は、情熱を失い、改善エネルギーが生まれず、なんとかバランスを保って漕ぎ着けるので精一杯となりがちです。

そこから立て直す事例・人材もあるとはいえ、もっと初期の設計という土台が強固で、そこに人材と理念という太い柱を何本か立てられていれば、立て直すエネルギーをより上を目指すために使えたのではないか、ということもあると思われます。

システムというモノづくりは厳格なものと捉える人もいるかもですが、その作り方は多岐にわたるため、１行のコードからユーザーインターフェースの触り心地に至るまで、『こだわり』がその品質を大きく左右するものです。

スケジュールとこだわりは若干相反する関係にあるとはいえ、こだわりにのよる品質向上は、余裕がなさすぎても逆にありすぎても発揮できないワガママ気質なところがあり、またスケジュールが守れても品質を損なえば、その”先”を失うことも考えられるため難しい話です。

時間・土台・モチベーションといった要素のバランスを取りつつ、ワガママな開発エネルギーを最大限引き出すというのは、書いてても理想論だなと思いますが、何事も楽しければ上手くいくことも多いので、それを保ちつつ成功に導くにはどうしたらよいかってのを常に考え続けることが大事なのかなと思います:-)