とあるIT屋の独白

ITや経営について主に書きます

アジャイル開発におけるドキュメント

システム開発において、大抵の場合は要件定義書や設計書などのドキュメントは残すと思いますが、アジャイル開発を採用するケースではドキュメントは納品物として作成されない場合もあるそうです。もちろん納品物の内容について顧客と認識合わせをせずに進めるのは論外ですが、仕様について双方の合意が確認できるようなドキュメントがないと下記の記事のようなトラブルが発生することもあります。

 

アジャイルだか何だか知らないけれど、ドキュメントがないのでシステムは未完成ね】

http://www.atmarkit.co.jp/ait/spv/1704/17/news012.html

 

アジャイル開発においても、ドキュメントは作成不要というわけではなく、必要なドキュメントは残すべきと思います。ではどのようなドキュメントを残すべきかというと、下記の記事にあるような抽象度を上げたものや、利害調整で使用するものが挙げられます。

 

アジャイル開発でもドキュメントが重要と考える4つの理由】

http://risingsun-system.biz/documentation-in-agile-project-2/

 

もちろん、ドキュメント作成に工数をさくのはアジャイル開発の本質ではないので、いかに効率よく作成するかという観点も大事と思います。下記の記事のようなドキュメント作成とコーディングを並行するやり方も、参考になるかと。

 

【現場から届けるアジャイル開発 (2) ドキュメントを最新に保つ効率的な管理方法とは?】

http://s.news.mynavi.jp/series/agile_developme/002/

組織が失敗するとき

日本の会社は現場は優秀だが、経営がいまいちという話は、今に始まったことではないですが、もう少し具体的にどういう点がダメなのかというのを掘り下げてみたいと思います。

まずは、下記の記事をご覧いただきたいのですが、どうしても会社が大きくなるとリスクをとりずらい雰囲気になってしまうということが挙げられます。

 

【現場を知らないトンチンカンな「高学歴社員」が会社をダメにする】

http://shuchi.php.co.jp/article/4008

 

経営層が同じような人であれば、会社側の評価も何か変えるよりもなにも変えない人の方が、評価が上になるという悪循環になるでしょう。

また下記の東芝の失敗に言及した記事がありますが、既に投資してしまったことを覆すことができない、ということも変化に対応できない要因として挙げられています。

 

東芝大失敗の研究 〜組織は「合理的に」失敗する】

http://gendai.ismedia.jp/articles/-/51710

 

こういった過去に投資してしまったものは埋没費用と呼ばれるもので、本来は今より先を考えなければいけないにもかかわらず、過去にしばられて適切な判断がされないことは往々にしてあることです。

 

【サンクコスト(埋没費用)とは】

https://blog.kairosmarketing.net/marketing-strategy/what-is-sunk-cost/

UWPアプリとは

UWPアプリという言葉を時々見かけることがありますが、Windowsのアプリであるということは認識できるものの、今までのアプリとどう違うのかというのを少し調べてみました。

UWPはユニバーサルWindowsプラットフォームと呼ばれるもので、Windows10から導入されたアプリのプラットフォームです。

 

【Win32からUWPへ――、アプリケーションの移行を進めるMicrosoft

http://cloud.watch.impress.co.jp/docs/column/microsoft/1056615.html

 

基本的にUWPアプリはWindowsストアからのインストールとなっていて、おそらく海賊版を抑制する目的もあるのではと感じます。

もう少し詳細なメリット・デメリットは、下記の記事にまとめられています。

 

Windows 10 UWPで業務デスクトップアプリ開発はどう変わるのか?】

http://www.atmarkit.co.jp/ait/spv/1506/23/news012.html

システム開発のマネジメントで大事なこと

以前に本ブログで管理職についてふれましたが、

【管理職のありかた】

http://toaruit.hatenablog.com/entry/2017/05/25/014508

 

今回は、システム開発の管理についてもう少しフォーカスをあててみたいと思います。

システム開発の管理というと、工数や要員などのを管理するというのが主な仕事となると思います。もちろんこういった仕事も大事なのですが、そもそもチームの方向付けとして問題設定が適切であるかという点があって、下記記事ではその部分の重要性が述べられています。

 

伊藤直也氏が語る、マネジメントで本当に大事なのは「問題にフォーカスする」である理由】

https://codeiq.jp/magazine/2017/05/50869/

 

開発やチーム運営が上手くいっているように見えて実は進む方向が間違っていました、というのはよくある話なのでいかに問題設定を行うかというのは難しいのですが大事ですね。

アマゾンフレッシュの影響

今年の4月にAmazonが生鮮食品の宅配サービス、アマゾンフレッシュを日本でも始めました。取り扱いアイテム数は10万アイテムで、かなりの本気度がうかがえます。

 

【「アマゾンフレッシュ」の生鮮宅配にヨーカドーとヤマトが負ける日】

http://diamond.jp/articles/-/126017

 

競合となる国内の会社も、ネットの生鮮食品宅配サービスを既にやってはいるのですが、アマゾンの参入で競争が激しくなるかもですね。

 

【スーパーもなくなる? アマゾン参戦で激化する“野菜戦争”】

https://dot.asahi.com/wa/2017062000036.html?page=1

 

さて、本国のアメリカではどうかというと、下記の記事を読むとそこまで上手くいってるという感じではなくて、高級スーパーを買収し実店舗との連携に活路を見いだしていくかも、といったところです。

 

【米高級スーパーを買収したアマゾンが、食料品販売でトップになる日がやってくる】

https://wired.jp/2017/07/12/amazon-whole-foods-acquisition/

 

物流網の整備が、生鮮食品宅配成功の重要な要因の一つとなるのですが、個人運送業者との連携なども模索されているようです。

 

【アマゾンと楽天の「顧客ベース戦略」に注目せよ!】

https://dentsu-ho.com/articles/5145

最近話題のGraphQL

IT関連の記事を見ているとGraphQLというワードを最近見かけることがあります。下記の記事に概要は書いてあるのですが、すごくざっくりいうとRESTでいけていない部分を改善した、WebAPIの新しい仕様のようなものになります。

 

【RESTの次のパラダイはGraphQLか】

http://qiita.com/sergeant-wizard/items/f10669e33858543dbc0b

 

要はRESTだと、それを望む望まないにかかわらずAPIで定義されている全項目が取得されてしまい、一部の項目がとりたい場合はそれ用のAPIを作らなければいけないということになります。

もう少し具体的な機能は、下記の記事で解説されています。

 

Facebookが開発しているGraphQLとは?】

https://developer.ntt.com/ja/blog/ffc54b7a-77f6-4789-a93b-7bdbb89c4f7d

 

下記の記事に、他のRESTに代わる方法を含め、GraphQLの優位性が書かれています。GraphQLの難点としては、開発をしているFacebook自体がまだ正式採用していないことでしょうか。

 

【GraphQLはWeb APIの次のフロンティアか?】

http://postd.cc/api-paradigms/

オフショアやニアショアの苦労

オフショア開発を行うといったことは、最近では珍しくなくなりましたが、中々うまく軌道にのせるのは難しそうです。国内のニアショアでさえも、けっこう苦労するようです。

 

【開発残酷物語(3):カンボジアは残存率3割弱、離島の男性は全滅――山本一郎氏が聞く、オフショア&ニアショアで働き手を開拓し続けた企業の8年間】

http://www.atmarkit.co.jp/ait/spv/1703/06/news016.html

 

私も経験があるのですが、実装者に仕事をふる場合、ある程度実装者がそのシステムのアーキテクチャー等を把握していない限り、上手く組み上げるのはやはり難しいかなと感じます。下記のブログ記事にある通り、伝言ゲームみたいな各人があまり考えない状態も生まれてしまいます。

 

【ちょっと何を言っているのか分かりません、「IT業界にいた人は使えない」?】

http://lite.blogos.com/article/64682/

 

オフショアでこういった伝言ゲームとならない為には、通常プログラマーに仕事をふるよりも丁寧なコミュニケーションをとる必要があるといえそうです。また、丸投げではなく、きちんとオフショア先の管理をするといったことも必要に応じて出てきますが、その為にはオフショアの契約内容自体も考慮しなければいけません。

 

【オフショア開発はなぜ失敗したのか?その問題分析から課題解決を目指して|オフショア開発ならネオラボ】

https://neo-lab.co.jp/neolabox/2917/