  |
はてなキーワード: 非機能要件とは
コードの書けない人が設計をする事例は、現場によっては存在するかもしれませんが、それはあまり望ましい状況ではないと思います。コードの書けない人が設計をすると、以下のような問題が起こりやすいと考えられます。
以上のように、コードの書けない人が設計をすることは、システム開発において多くのリスクを伴います。コードの書けない人が設計をすることを避けるためには、以下のような対策が考えられます。
コードの書けない人が設計をすることは、現場の状況によっては避けられないことかもしれませんが、できるだけコードの書ける人に設計を任せることが望ましいと思います。コードの書けない人は、コードの書ける人と協力したり、ローコード開発などの手法を活用したりして、コードの書き方や技術の知識を身につけることが大切だと思います。
インフラにありがちだと思うけどトラブルが起きて初めて存在が認識される節があって、マッチポンプか否かにかかわらず何かしらのトラブルが起きてその解決をすることで仕事の成果が可視化される。マインススタートにすること意識されるようになり、それゆえゼロに戻した時の振れ幅が大きいと錯覚される。
問題を起こさないことがプロの仕事として評価されるべきなんだけど要件の時点で問題が起きないことが前提となってるので別に完成したところで振り幅は少ない。
不良がたまにみせる優しさが相対的に高く評価されるのと同じアレね。
当事者としてはトラブルないほうがはるかにいいのでテストや非機能要件には気を配ってるがそれが評価されづらいというのは体験としてあるけどこれはビジネス側と現場間にある大きな価値観の分断なんだろうね。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
「AWSによるクラウド入門」が2つ入っているのは?s=09というパラメータが付いているのと付いていないとので割れたせい。
ただ未来がないと喚いても仕方がないので、IT業界に来た若者向けに言いたい事。
受託開発でも何でもいいんだけど、
言われた事だけをこなす技術者にはならないで欲しい。
これは、言われなくても察しろとかそういう話ではなくて、
というのを常に考えて欲しい。
それと、案件に参加したならば
何か一つでいいので、
俺が考えたイカす機能というか、
要求仕様には無いけどサービスでやってやったぜというのを組み込んで頂きたい。
機能要件に関わるところでそれをやるとちょっと揉めることもあるので、
非機能要件で、使い心地を向上させる部分に、エゴを埋め込んでいくのがまずはオススメ。
こんなの作ってみました！どうすか！？やばないですか！？ と見せると
そのまま客先に持っていくことはできないかもしれないけど、
こいつ・・・やるな・・！ってなるはず。
そして、そういうのを後輩が持ってくるようなチームは、仕事が楽しくなる。
言われた事だけをひたすら実装するプログラマにはならないでほしい。
一口にIT土方と言っても色々な仕事があるが、その中でもブラックという悪名の大元になっている、開発の仕事を新卒から手がけて10年になったタイミングで、上司から「人の上に立つキャリアに行かないなら、技術者として横への広がりを」と勧められ(加えて開発の仕事があんまり取れない事情もあり)、そこから数年ほど運用チームの一員として業務をやってきたが・・・俺にはこの仕事のセンスがまるっきり無いことが判明しただけに終わった。
というか、今はもう運用という仕事に対して憎悪の感情しか沸かない。心底嫌気が差してしまった。
以下、色々向いていなかった系の主張メインの言い訳。
俺が長く手がけた開発は必ずゴールがあり、それを踏まえた細部への落し込みの段取りが仕事の核となる。そしてこの段取りを進める忙しさが常にあり、上手く行かなくなった時はブラック激務が待っていると。
一方の運用は、開発と比べたら桁違いにヒマで、しかもゴールがない。しかし、その緩やかな時間の中で日々業務改善に頭を巡らせ、より上手い回し方を工夫することが肝要である。
まず俺は、この時間感覚・仕事感覚の違いに、結局どうしても慣れなかった。ヒマに任せてひたすら惰眠を貪ってしまい、働かないオッサンに成り果ててていた。
多分このまま行ったら、給料泥棒としていずれ切られるだろう。
それから、今時のシステムにはサーバやスイッチのみならず、大小様々なアプライアンスが含まれる。それもアプライアンスが基幹装置だったりすることは全く珍しくないので、こいつらの監視は非常に重要なのだが・・・俺はこのアプライアンスというやつに全く興味が持てなかった。
真面目な運用者なら仕組みや機能を率先して調べ、業務改善や次期システムの提案に噛ませるなんてするんだろうけど、俺の場合「よくわからんブラックボックスで、でもなんかよろしくやってんだね、じゃあそれでいいんじゃね？」程度にしか思えず、出来れば障害の1つも起きないなら無視したいものだった。
これはもう運用者としては致命的にダメなセンスだろう。開発で例えるなら「ミドルウェアに興味ない」とか「クラスライブラリやフレームワークに興味ない」と言っているようなものである。
そうそう、開発と運用の違いと言ったら、確実に対立するポイントがある。
それは非機能要件の取り扱い。
開発にとって非機能要件というのは「障害発生時の検証用や、機能要件の異常系処理など、恙無くシステムを動かすのに最低限必要な仕組み以外は手を出したくないもの」だったりする。基本的に手を入れ始めたらキリがないので、やればやるほど仕事が増えてしまうのに、それに見合ったカネも時間も用意されていないことが多い(というかそんな見積もりを客に出すのは無理)からである。
一方の運用にとっては「機能要件は満たせていて当たり前で、その上で特に障害時の対応を中心とした非機能要件はきちんと作られるべきもの」である。システムトラブルで矢面に立つのは運用者であり、そこで手も足も出なければ存在意義を問われるのだから当然だろう。
このように非機能要件だけ取っても、同じシステム屋なのに見ているポイントが全く違う。
「正直気にしたって仕方ないような細かいところまで質問してきて、いちいちこっちの回答を言質に取って、その上で文句ばっかり付けてくる面倒な奴ら」
「いつも中途半端なモノを作り逃げし、いざという時も要領を得ない曖昧なことしか言えない、信用出来ない奴ら」
となる。
こういう、ともすれば対立の原因になる認識の違いを踏まえ、身も心も運用者になることが、俺にはできなかったと言ってもいい。
というわけで、これから俺はまた開発に戻る。
「流しのオッサンコーダー」として半年～1年単位で現場を点々とすることになると思うが、何年も椅子に座ってログを眺めているようで眺めていないよりは会社に貢献できるだろう。
或いは若手開発者育成という名の、ブラックな環境に飲まれないノウハウとか、「ハイリスクノーリターン」を避けるサバイバル術伝授とかやってもいいかなーと思っている。若手をOJTで潰すのは許せないので。
この場合、「この人にはどういう言い方をしたら通じるのか」という問題が今以上に重要になるだろうけど、それくらいは受けて立たないとという感じ。
追記歓迎
| 言葉 | 意味 |
|---|---|
| 議事録 | 気が変わる前の意見 |
| 非機能要件 | 実装するかは気分次第 |
| 確認しておきます | 今日は帰ります |
| オブジェクト指向 | オ○ニー |
| 偉い人の意見 | パルプンテ |
| ちょっとした仕様変更 | ザキ |
| 客先担当者の急な交代 | ザラキ |
| 要件定義から見直し | ザラキーマ |
| 確定した仕様 | 幻想 |
| WBS | Sはサグラダファミリア |
| キーマン | 鬱病になりにくいことがわかってる人 |
| ベストプラクティス | モジュール化されてません |
| 増員 | 導入教育で作業が止まる |
| それは新しい方法ですね | 問題がおきたらお前が対応しろ |
| 操作手順書 | 唯一多少参考になる設計ドキュメント |
| 備考 | 最も重要な考慮事項 |
| ＸＸはリスク | 問題が起きる(起きてる)けど俺は知りません |
| 試験のエビデンス | 誰も見ないけど一番手間のかかるもの |
| ペアコーディング | 今日はだるいから流すわ |
| すべての入力パターンを網羅したテスト | 1ケース0.1秒で実行しても宇宙が終わるほうが早い |
| フレームワークのバグ | 仕様です |
| カバレッジ100% | 不具合だらけですがコンパイルエラーはありません |
| トレードオフ | この仕事やるのと休日出勤どっちがいい？ |
| 動きます | 完成度10% |
| 一部のエラー処理がまだ | 完成度20% |
| 誰かの独自フレームワーク | お前はしぬ |
| 会社の独自フレームワーク | みんなしぬ |
