ソフトウェアエンジニアの本質はコードを書くこと。それ以外存在しない。

2023年3月17日 08:59

こんにちは！
クラウドサーカス開発部でチャットボットツール『IZANAI』の開発を担当している苑田です。

2023年1月まで弊社（以下、CC）の技術顧問に就任されていたまつもとゆきひろ（以下、Matz）さんとの社内勉強会で学んだことやそれを通じて変化したIZANAIチームの開発体制について、2回に分けて、発表します。
第一回は、ソフトウェアエンジニアの本質と題し、本質を意識したことで個人やチームがどのように変化したのかお伝えします。

思考の変化〜SEならコードを見て理解できるようになれ！〜

社内勉強会は全部で4回実施され、開発に対する取り組み姿勢という点でチーム全体の考え方が変わりました。私は、これまで詳細設計が非常に大事だという考えを持っていました。また、ドキュメントとして残っていたらなお良いと思っていました。なぜなら、詳細設計書を見れば、どのタイミングでジョインしても開発の全体像をイメージできるからです。詳細設計書を管理することは、とても面倒くさいというデメリットもありますが、それでも管理するべきだと考えていました。

しかし、Matzさんからは「そもそも誰がドキュメントを見るのかという問題もあり、別に管理しなくても問題ないのではないか。我々、ソフトウェアエンジニアの本質はコードを書くことなので、あくまで詳細設計はブレストレベルで、頭を整理するときに使うものである。つまり、管理も必要ない。たしかに最初の段階では必要かもしれないが、それを継続的に保つ必要はないと思う。」と仰っていただきました。
また、管理できるならしてもいいと前置きをいただいた上で、「どの選択肢を取るにしても、詳細設計の書かれたドキュメントはいずれ陳腐化する」とも仰っていました。

実際に、IZANAIでは、二重管理になっていましたし、詳細設計書としては破綻していました。最初に詳細設計まで行い、ドキュメントを残していました。しかし、私を含めたIZANAIの開発メンバーがその詳細設計に手を付けたとき、コードだけ変更して、ドキュメントは変更しないことが発生していました。この場合、実際のコードと詳細設計書が異なるため、新しくジョインしたメンバーは勉強にも使えず、本来、初心者向けに優しいはずの詳細設計書が足かせになる可能性がありました。

Matzさんからの言葉は、コードを見て理解できるようになることがソフトウェアエンジニアとしての本質であり、見て分かるコードを書くことが求められます。私はソフトウェア開発における本質に立ち戻れたと実感しています。

成果物から見る

現在、IZANAIチームの開発は、メインでレビューするところをシフトさせました。私たちが行っていた詳細設計は、プランニングと称して、事前に検討会を実施し、持っているタスクに対してどんな実装で進めていくかを考え、そこで決まったことを詳細設計書にコードレベルで書き起こし、レビューするという流れでした。

この段階では、まだ実際のコードは書かないということになりますが、そこが本質ではないという学びから、ファイルの構成やロジックなどメイン部分だけ確認して、あとは実際にコードを書き、その書いたコードをレビューするようにしています。

コードレベルで綺麗にすることを意識し、誰が見ても分かるようにコードを書けるようにチームで徹底しています。結果として、綺麗なコードが成果物から見る詳細設計に繋がります。
詳細設計はブレスト段階であり、アウトプットした成果物をコードをレビューするというシンプルで本質的な開発体制に変わりました。

コミュニケーションの増加と自主性の醸成

IZANAIの開発チームとしての開発の進め方は、メンバー全員が同じ方向を向いているように感じられます。そして、コミュニケーションの量が圧倒的に増えました。詳細設計書をドキュメントレベルで出す場合、コミュニケーションを取る必要がありません。ドキュメントに残して、レビューを依頼すれば済む話なので、詳細設計を書いた人の努力に頼りすぎてしまい、見落としを招く可能性があります。詳細設計がしっかりとされていても、コーダーが自分で考えずに実装すれば、より良いコードを発見することができず、スキルアップに繋がりづらいでしょう。

一方で、詳細設計をブレストレベルにした場合、設計書がざっとした内容になるため、コードレビューでコミュニケーションが必要になります。そして、詳細設計がざっとしているからこそ、実際に書いたコードに対する指摘点が増えます。実際に書いたコードをレビューすることによって、これまで見逃していたところに気づくことができました。私自身もClass図が読めているようでしたが、最近、実は読めていなかったことが分かりました。

そして、この方法の良い点は、設計者が説明できるようになるということです。設計者が自分でコードを書かなければならないため、自主性を持って開発に取り組み、自分の知識を活用して開発する必要があります。このような環境はスキルアップに繋がり、非常に大きなメリットとして実感しています。

ソフトウェア開発における本当に必要なことはコードを書くことです。IZANAIの開発チームは全員が同じ方向を向いて考え、格好良く表現するのであれば、シリコンバレーのスタートアップのような開発スタイルで進めていると思います。

これまでの「これでいいですか？」から、「こうした方が良いと思うんですけど〜」という提案型のコミュニケーションの変化は、チームとの活性化という点で今後も継続していきたいです。

まとめ

以上がIZANAIチームがMatzさんからいただいたアドバイスを元に、ソフトウェア開発の本質に辿り着いたことで起こった変化です。
次回は、本質を見たからこそ得られた環境の変化について書かせていただきます。